Don't Develop Just for Yourself - A Developer's Checklist to Accessibility

Reading time: about 8 minutes

Published 28th May, 2021

A notebook with a checklist. Hand holding a pen, writing a new item on the list. On the background, there's a blurred blue and white cloth.

We, as developers, tend to develop sites unconsciously for people like ourselves. If we don't actively pay attention, the sites are often accessible only for certain types of people: Sighted mouse-users, who have good fine motor skills and are good at using computers.

It leads to moments where no one who navigates the web with only a keyboard (or keyboard simulating device) can access and interact with the site. It is a pretty big group of people!

We have a responsibility to make sites that work for all of our users. In some cases, it is required by law, but it is not the only reason we should care.

This blog post is aimed for those at the beginning of their accessibility journey. You might know some things, like "always provide an alt-text for an image," but are unsure what to write there. Or you don't have any idea how to know if your site is accessible at all.

Following this blog post won't make your site 100% accessible! The goal of this post is to provide some information about some things to check manually after using some automated testing.

First of all, abandon your mouse for a second. Don't use it. Try to navigate through the website using only the keyboard. Try to complete every task user needs to be able to complete on the website. Can you do it? Can you see where you are at the moment? Is the focus indicator (yes, that thing many designers and developers like to remove) visible enough?

If you can't use the whole website with only a keyboard, that is an accessibility and usability problem. However, one thing to note here is that keyboard interaction is not necessarily accomplished with just tab and enter, as it has been at some point. The general pattern goes, as WAI-ARIA Authoring Practices state:

A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements.

Another thing to consider in this point is focus indicators. They should be visible, and even if the default focus indicator on the browser is sufficient to pass the WCAG-requirements, it might be hard to see. So I would recommend enhancing the focus indicator to be more visible. Just remember that the color of the indicator should have a sufficient contrast ratio with the adjacent background.

Using only your keyboard, navigate through your site. Pay attention to navigation menus and other custom widgets that might lose focus because some elements are hidden incorrectly.

Is everything reachable and operable without a mouse? Can you see the focus every time?

Alt-Texts

Another thing to check manually is alternative texts for the pictures. You might wonder, isn't it a thing automated testing catches? Well, yes. Automated testing tools crawl through the markup, and when they find an img-element, they check if the alt-attribute is present. They don't (and can't) check the quality of the alternative texts.

Not all images need alternative texts; however, they do need the alt-attribute. So for a purely decorative image, you need to provide an empty alt-attribute. This "hides" the image from the screen reader so that it won't get read at all.

You might ask, shouldn't screen reader users know about everything on the page? A person, who consumes the web by listening, might want to reduce the amount of information.

Action Item for Alt-Texts

Go through every image on the page. You can use, for example, Web Developer-extension or the developer tools and check the image's alt attribute.

Is the text descriptive? Or is the picture decorative? You can find more information on how you should write the alt-text for every type of image from WebAIM: Alternative Text.

Page Language

Another thing that automated tests catch, if it's missing, is the page language. Some of the project starters, such as create-react-app, have the lang-attribute set automatically, but some (I'm looking at you, NextJS) don't.

If the site's language is English, you're pretty much okay with the automatic language (if it exists). However, if it is not, then you need to change it. The reason is that the language screen readers use for the page comes from that lang-attribute. So if you have a page with content in Finnish, and there is that en-attribute, a screen reader would pronounce every word with an English accent. That's not beautiful. Here's an example with another way around. It's almost as bad:

Action Item for Page Language

Check the language of the page in the page's html-attribute. You can do this from developer tools' Elements-tab. Is the language code the same as the primary language on the page?

Text Resizing

Some people increase the text size of the webpage with, for example, browser settings. It means that the content takes more space and might flow differently. Developers should test if the site is working when text size has been increased to at least 200%.

Action Item for Text Resizing

Have the webpage on two browsers open, preferably side by side. In the first browser, use browser's built-in zooming for testing by using CMD++ if you're using a Mac, and CTRL++ if you're using Windows or Linux. Increase the size to the maximum, which should be 200%. Compare the zoomed site and the one without a zoom.

Does your site still work? Is the text flowing okay? Does increasing the text size add horizontal scrolling? Is all the information still there?

Color Alone

If color alone conveys meaning, there are lots of users who miss out on that information. For example, suppose there is a list of different activities, and their level of advancement is communicated only with a colored box. In that case, there are some groups of people who can't access that information.

For example, a person who is color blind can't separate certain color combinations, and thus the information, when it's conveyed only with color, is not understandable. Also, for screen reader users, the color does not say anything; screen readers don't say anything about the web page's styles.

Action Item for Color Alone

One thing that could be used as help for testing if the color alone is used to convey a meaning is to change the site into grayscale.

How to turn a page grayscale?

You can turn a page grayscale from the developer tools in Chrome and Edge from the "Rendering"-tab. You can find it with the same instructions as for the [`prefers-reduced-motion`-simulation][3]. There is a header "Emulate vision deficiencies" on that tab, and you can choose Achromatopsia from the select.

Can you still understand all the information on the page?

Mobile Zooming

I remember, that at some point it was customary to add this <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" /> to disable the pinch-zoom on webpages. Nobody ever explained why it was, but it was everywhere I copied code to my projects. I didn't know then that it would make zooming on touch devices harder.

Some people need to use zoom to see the elements on the page. Also, many people want to, for example, zoom in on pictures to see how they look in that picture or some other detail. And sometimes, the website is unusable without zooming. That is a thing that would need fixing from the developers' side, but things don't always happen too fast, so meanwhile, users would need to use the zoom.

Action Item for Mobile Zooming

Open your site or app on a mobile device. Try zooming in with your fingers. Can you do it?

Captions and Transcripts

Captions

Imagine if you couldn't hear the words said in the video. How would you then understand what is going on in that video? It can happen for numerous reasons. You could have a hearing-related disability or be in a crowded place where you don't want to turn the sound on.

For these situations, captions are essential. Captions are a bit different from subtitles. They also contain information about important sounds on the video, and they identify the speaker if they're not easy to identify from the video. Captions can be either closed, meaning they can be turned on, or open, meaning they are always present.

And a word about auto-captions: Please, no. The speech recognition algorithms aren't that good yet, and they produce lousy quality. Some even call them "auto-craptions." Suppose you don't have a hearing-related disability and haven't encountered this in your life. In that case, I have another example that could maybe give some context: Services like Netflix and subtitles (when the subtitle language is not English). I mean, at least for Finnish, the subtitles are often just crap. The reason is either using automated translations or not paying enough for professionals to do the translations.

Transcripts

Transcripts are a way for DeafBlind users to understand what's going on in videos or audio content (say, podcasts). Also, for audio-only content, transcripts are the only way for Deaf people to get the message.

If you're interested to learn more about captions, transcripts, and audio descriptions (which I'm not covering here), WebAIM: Captions, Transcripts, and Audio Descriptions is a good resource on that.

Action Item for Captions and Transcripts

Go through every piece of multimedia on your website. Are the captions and transcripts in place (depending on the media type)?

Wrapping Up

In this blog post, I have introduced seven checks any developer can do to ensure that their website is a bit more accessible. Some of them take more time than others, but they're worth it!

Do you have any tips for simple checks for accessibility problems that aren't easy to catch with automated tests?

Resources

Cover photo by Glenn Carstens-Peters on Unsplash