Accessibility for front-end developers

So who are we targeting? The first thought when people mention accessibility is disability, but in reality accessibility affects everyone. It’s important to understand people can be temporarily disabled (e.g. broken bones) or simply need to use tech in an unusual way, as well as having permanent medical complaints.

As web developers we should try to be empathetic towards everyone. Some people will need to use screen readers to access our content. Other people may rely on a keyboard for navigation, or perhaps not have the technical skills to use websites in the way you envisage. The best way to build accessible websites is to remove any assumption about how the content will be received; as well as a browser it could be read using a screen reader, RSS reader, printout or another method entirely.

Semantics

A semantic document with no additional styles or scripts is accessible by default. By starting with a semantic document as our base and adding functionality on top with progressive enhancements we can leave the heavy lifting to the browser.

Let’s consider the anchor element. By default they are usable with just a keyboard and expose their functionality to the accessibility tree. They work without JavaScript (and JavaScript does fail). They can be crawled by search engines. Next time you add an event listener to a span or an image think about all the additional work needed to add these features back in.

I find a great way to help enforce semantics is to not style any element directly. For example, rather than write

H2
{
    font-size: 20px
}

we should write

.heading-2
{
    font-size: 20px
}

This means that when our designer wants to style a h3 (or other element) like a h2, we don’t have to sacrifice semantics or repeat the heading-2 styles in a new selector. For headings this is particularly important due to the effect headings have on SEO. To deal with CMS content I would generally modify the second selector to be something like .heading-2, .content-editor , where any text coming from a textarea is wrapped in the content-editor class.

Alt text

Another rule of thumb is that every webpage should be usable in a text only browser. (Screenreaders and search engines are essentially text only browsers, and images may be disabled to save bandwidth). For images this text is provided as alt text. Alt text, or alternative text, is a fallback text used when the image is not viewable. Good alt text is short and concise and describes what the image is trying to convey. In those cases where an images is purely decorative and should not be read to a screen reader an empty alt text should be used. Without alt text a screen reader will read the image URL which is usually just an annoyance.

Sometimes we also want to provide alternative text to screen readers and search engines, but hide it for sighted users. An example of this is when a background image or icon is used. In this scenario we should use a special class to position the screen reader text off-screen. One of the more popular such classes is the visuallyhidden class from HTML5 boilerplate. We should not use display: none, because this will hide the element from the accessibility tree (and therefore won’t be read to screen readers).

Of course this also works the other way. For content that is truly hidden until a user interaction (content of dropdown menus, popups etc.) display: none should be preferred over opacity: 0. (Items hidden with opacity are included in the accessibility tree, and links hidden with opacity will be keyboard focusable).

Final thoughts

Although accessibility is a large topic and there is lots that you can potentially learn, getting started is easy. It’s easy to assume that knowledge of WAI-ARIA and accessibility tools is required, but in reality it is rarely needed. In fact poorly implemented ARIA can do more harm than good, if it is implemented in an inconsistent way.

Good accessibility affects everyone, even able-bodied people, and as developers we have a responsibility to consider it on every project. With a little bit of thought we can make our sites work better for everybody regardless of ability, age and circumstance.