Learn Accessibility

It’s important to remember that the web is for everybody. You should strive to build interfaces that are accessible to as many people as possible. This means specifically including users who often get left out: those with disabilities.

As developers we have both a moral and legal imperative to make sure our applications are accessible. A UI that can only be used by a sighted person with a mouse should be considered broken, just like a UI that isn’t usable with a mouse would be considered broken.

This workshop will cover some of the ways disabled users browse the web, how to design/develop to meet those needs, and how to test your code to make sure that it does.

Key points

• Don’t make assumptions about how people will use your site
• Strive to make your UI usable by everyone
• Get out of your comfort zone when testing your UI

Common problems

It’s easy for developers to forget that people using their apps aren’t necessarily like them. This can include both permanent disabilities, temporary disabilities, and even unavoidable technical limitations.

Here are some examples:

• A colorblind user cannot perceive the difference between certain colours. If you use only colour to indicate what a button does they won’t be able to use it.

• A blind user cannot see your UI, and may use screen reader software to have the elements on the page read out loud by their computer. If you only communicate important information visually (e.g. using images) they won’t hear it.

• A user with a broken arm in a sling cannot use their mouse. If your UI doesn’t allow them to navigate with their keyboard they won’t be able to use it.

• A low-income user may not have the latest iPhone. If your app only works properly on fast, new, expensive devices you are excluding them.

This document will mostly focus on keyboard and screen reader access, since those tend to be the predominant problems for web developers to solve. However that does not mean other disabilities are not important to consider when designing and developing interfaces.

Different ways to navigate

If you’re a non-disabled web developer it’s possible you aren’t aware of or haven’t tried navigating the web using anything but your mouse. It’s important to get a sense of how other people will be attempting to use the sites you build.

Keyboard navigation

Many users cannot use a mouse, or find it easier to use their keyboard to navigate. This also applies to some visually-impaired users who will struggle to use a mouse if they cannot see the cursor.

You can scroll a web page up or down by pressing the up ↑ or down ↓ arrow keys. You can jump a whole “page” (equal to the viewport height) down with the spacebar.

You can also jump a page up or down using the Page Up or Page Down keys. On Mac keyboards without these keys you can use ⎇ option + ↑ or ↓.

You can scroll right to the top or bottom of a page using the Home or End keys. On Mac keyboards without these keys you can use ⌘ command + ↑ or ↓.

The most important key is “tab” ⇥. This will move your “focus” to the next interactive element on the page. For example links, buttons or inputs. This allows you to quickly jump between these elements, e.g. to fill out a form.

By default a “focused” element has an outline around it (in Chrome this is like a blue glow). You can “click” a focused button or link with the “return” ⮐ or spacebar keys. You can submit a form by pressing return whilst focusing an input.

Try using only your keyboard to navigate while you’re reading the rest of this page.

Screen readers

Navigating via keyboard still requires you to know what content is on the page. Visually-impaired and blind people use “screen reader” software to read whatever is on the page out loud.

Most operating systems have a built-in screen reader now. macOS has VoiceOver, Windows 10 has Narrator and Linux has Orca.

Expand the relevant section below to get instructions for your operating system. Once you’ve got your screen reader working try to use it to navigate this page. It takes a bit of practice to get used to.

sudo apt install orca

Combinations

It’s important to bear in mind that people don’t fall neatly into separate categories. For example lots of keyboard users still use their mouse too. Lots of keyboard users can see the page fine. 85% of blind people have some degree of light perception, and so they may still use visual cues, or their mouse.

Developers sometimes try to detect what “type” of user is on the page, so they can enable/disable certain things (e.g. only show focus outlines for keyboard users). This is almost always a bad idea—you cannot detect accurately, and even if you could it’s better to provide as similar an experience as possible to all users.

Testing accessibility

Web accessibility (often abbreviated to “a11y”) is governed by the Web Content Accessibility Guidelines (WCAG). This is a shared standard that includes different criteria you can check your site against.

WCAG is quite long and complex, so a quick way to test a site is to use The A11y Project’s Checklist. This is a list of simple things you should do on every site you build.

You can also use automated testing tools to catch some types of problems. Chrome comes with a “Lighthouse” tab in the Developer Tools. This can run different types of tests on a page, including “Accessibility”. It will inform you of obvious failures like low colour contrast or missing image alt text. However it cannot catch more complex problems, like a custom component that cannot be controlled with the keyboard.

Most importantly you should manually test—use the page in different ways and see if you get stuck. Try to fill out a form using only your keyboard. Turn your screen reader on and see if critical information gets left out. This will help you catch broken interactions that automated tools cannot.

Challenge

You’re going to be identifying and fixing a11y problems on this example page. The page contains 11 failures; try to find them all.

1. Re-read The A11y Project’s Checklist before you start so you can identify obvious WCAG violations.
2. Don’t forget to use Chrome’s Lighthouse tab to find easy problems.
3. You’ll have to manually test with your keyboard and screen reader to find some of the issues.