The First Look Media technology team strives to put groups often marginalized by new technologies on equal footing. As we prepare for the next iterations of our sites — including Topic, The Nib, and The Intercept — we’re placing accessibility at the center of many of our conversations about design and technology choices.

This is a new way of thinking for many of us. For most developers, accessibility ranks fairly low on the list of concerns (behind such items as “making sure it doesn’t break” and “aligning everything so that the page looks like the wireframe”). We are intentionally trying to break this habit and address accessibility at each point of the development process.

This post is the first in a series that will chronicle the strategies our development team is using to implement accessible design across our products.

Putting accessibility at the center of our process.

Why is accessibility important?

There are a number of reasons to be intentional about accessibility. The most practical is the legal aspect. The threat is real: companies in the US have been sued for not having accessible sites. To greatly simplify a number of court rulings, the general rule seems to be that if a company’s storefronts are accessible, there’s a legal requirement under the ADA for their site to be accessible as well.

There’s also the argument that focusing on accessibility is good for engineering in general. It adds a new set of requirements and inputs to the software development process, true, but it also forces designers and engineers to consider page structure and interaction design more precisely and thoroughly, leading to a more thoughtful approach overall.

Another reason — perhaps the most important — is the ethical aspect of accessibility work. Roughly 15% of the world’s population and 20% of Americans have disabilities, frequently relying on hardware and software specifically designed to make screens more navigable. There is no question that following established accessibility software design and development techniques can help bridge the gap between content and audience.

How can accessibility be measured?

With accessibility, there’s always more to be done. However, there are some guidelines that can be considered good places to start. The W3C’s Web Content Accessibility Guidelines provide some excellent reference points. There are four major principles that should be followed according to the W3C; I’ve listed them here, with a few examples of situations that might apply under each one.

Perceivable: All users, including those with decreased vision, should be able to perceive events that occur on the page.

Is any non-text content given a text alternative? Conversely, are purely decorative elements ignored by assistive technology?

Is information that is conveyed through color also conveyed through text or screen reader? For example, a field that turns red when input is invalid should also have an icon or text.

Is it clear what clicking on each link or other clickable element will do?

Operable: All parts of the page should be useable without a mouse and should not cause the user undue difficulty.

Are any elements revealed on mouseover also revealed when focused?

Are elements which are invisible or offscreen also unfocusable?

Is any flashing on the page kept to a minimum to avoid seizures?

Is there a way to skip repetitive blocks of content? For example, there should be a “skip to main content” button that skips all the navigation.

Understandable: The operation and content of the user interface should be clear and precise.

Can the default language of the page be programmatically determined?

Is the tab order of elements logical? For example, when a modal opens, focus should go into the modal and not leave it until the modal has closed.

Are input errors clearly conveyed? For example, when a user enters an invalid email, the “Please enter a valid email” message should read out through the screen reader.

Robust: The page follows the above guidelines across multiple screen readers and other assistive technology devices.

Thinking about accessibility

In order to think productively about accessibility, one needs to step backwards a little bit and spend some time contemplating responsive design. Responsiveness in a design context of course doesn’t refer only to the visuals of a site. The job of a designer or developer is to structure a page so that at any given moment, the user can easily access precisely the information they want. While generally one talks about this concept in the realm of rearranging elements into different configurations in order to manage mobile breakpoints, it also applies to the flow and clarity of users navigating sites through screen readers or without the use of the mouse.

Frank Chimero’s 2015 article “The Web’s Grain” is a touchpoint I return to again and again. It’s a wonderful meditation on many things: the essence of the web and what it means to create a responsive website, the conceptualization of breakpoints as points of reassembly, the compounding ubiquity of technology in our everyday lives. There’s one thought in particular, though, that sticks in my mind and stays there. “What would happen if we stopped treating the web like a blank canvas to paint on, and instead like a material to build with?”

As a practice, web design has the most in common with not painting or drawing, but with sculpture. Each layout has its own depth, measured in the relationships between elements and the ways in which they interact. At First Look, we use React, which has a powerful set of tools to handle interactivity and flexibility — state, event handlers, refs, and more. These tools allow us to more easily shape the pages we build, to redraw the connections and relationships between elements, creating a simple and logical path through the information at hand.

What comes next?

In the next post in this series, we will be going through a few techniques to make common components accessible in React, including modals, carousels, navigation, and more. Check back soon!

Resources

ChromeVox Screen Reader Chrome Extension: I have found this very useful for doing a quick overview of the accessibility of a site, and it has the benefit of working on a Mac/Chrome setup. It’s used by about 0.4% of users, so one should also use another setup for final tests, but it is a good starting point. WebAIM: A collection of articles and resources about web accessibility.

Illustration Credits: “Coding” and “Accessibility Optimization” icons from SBTS on The Noun Project