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.
Keyboard Navigation
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.
Action Item for Keyboard Navigation
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. 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
- WAI-ARIA Authoring Practices
- WebAIM: Alternative Text
- WebAIM: Captions, Transcripts, and Audio Descriptions
prefers-reduced-motion-simulation- Web Developer-extension
Cover photo by Glenn Carstens-Peters on Unsplash
Top comments (6)
The hint for checking your site (if it's a website you're making) with the browser's text zoom is a good one that's often overlooked.
Too often I've heard people saying something doesn't work - like a button's missing or something - and the front-end developer squints at it and says, "oh, you're zoomed in, let me fix that", hits
ctrl-0and everyone says, "ahh, gotcha" and passes the release.A great "back to basics" checklist for stuff that should be super easy to fix / identify without any accessibility knowledge! ❤🦄
If every website managed to pass just these few simple points we would be twice as accessible as we are now!
Thanks for writing this. Appreciate your work.
I have seen many devs shunning their responsibility for making web accessible, and consider it an edge case or an optional thing. I never condone this mindset. I believe it's the lack of education around this area. I wonder why it was not taught to us in the college. Or why it was not a mondatory subject.
Nonetheless, I have seen some great efforts being made to make accessibility a core part of web development. We all have to play our parts in it. Let's make web inclusive and accessible.
Thanks Eevis.
For Windows 10 you can turn on a default color filter and enable Win+Ctrl+c as a keyboard shortcut to quickly toggle grayscale on and off (or other colorblindness filters)!
I found this shortcut accidentally before it had to be an enabled shortcut and it was very confusing 😅
I am getting old and it is becoming harder to focus my sight. Many webpages do not allow zooming by pinching the screen. For those pages I am reliant on an external app for zooming. But is is not as good as native zooming.
Thank you for this article, Eevis!
Regarding font sizes, some devs overlook the important of text sizes. If the text is too small, some people might have some problems reading it.