There are a large number of people with disabilities browsing the internet—people who want to browse your content, read your articles, and buy your products. These people often find using their computers and the internet a lot trickier than we as people who work in tech do and will use assistive technology to aid them, and if we don't think about these people and make adjustments for them, we might find that our websites aren't as useable as they should be.
In making websites accessible, we remove the barriers that prevent these users from being able to use our websites. For example, adding subtitles to videos and audio would mean that deaf people would not be excluded.
It isn't difficult to make a website accessible, but you do have to take the time to learn how to do it.
"They're only a tiny percentage of users, it's not worth the time!", you say.
Not true:
In the UK, there are over 11 million people with a limiting long term illness, impairment, or disability*. That's 17% of the population. Not all of these people will be affected by their condition when browsing the internet, so we can break it down into categories we know will definitely have barriers when using computers:
* Family Resources Survey 2011/12
- Visual impairment: According to RNIB, two million people in the UK are visually impaired. 360,000 people are registered as blind or partially sighted, and it's safe to assume that a lot of these people will be using assistive technology.
- Dyslexia: "Ten percent (10%) of the population are dyslexic; 4% severely so.", according to the British Dyslexia Association.
- Hearing loss: Action On Hearing Loss say that there are 11 million people with hearing loss in the UK, 900,000 of those severely or profoundly deaf.
- Colour blindness: according to Colour Blind Awareness, colour blindness affects an estimated 2.7 million people in the UK—or 4.5% of the population.
- Motor impairments: a big category of disabilities—too many to lump into one number—that on one side of the spectrum might just mean that the user is unable to use a mouse, and on the other end could mean that the user operates their computer using an eye gaze system or by blowing into a tube.
- Epilepsy: Epilepsy Action say that 600,000 people in the UK have epilepsy: this one is especially important to consider, because not only could you make your website inaccessible, you could potentially trigger a seizure!
And those are just the big ones: there's a tonne of other disabilities that make it trickier to use computers. We definitely shouldn't be discarding these users as "only a tiny percentage of users".
It's also the law to make your website accessible. The Disability Discrimination Act states, among other things:
From 1st October 1999 a service provider has to take reasonable steps to change a practice which makes it unreasonably difficult for disabled people to make use of its services.
In the context of web development, that means we have to take reasonable steps to remove the barriers that users with disabilities will face on our websites, or we are breaking the law.
Tim Berners-Lee, inventor of the World Wide Web and W3C director, said the following:
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
It's not fair to our users with disabilities if we decide that we don't want them on our websites. We should all try to be as inclusive as possible.
If all those reasons weren't enough, be entirely selfish: by making changes that will help people with disabilities, we will be making changes that will at some point benefit ourselves.
Not all disabilities are permenant: an example of a situational disability, a disability that is imposed on you by your current environment, would be when you are in a loud environment and have forgotten your headphones, so can't hear your device. An example of a temporary disability would be a broken wrist, which could affect your ability to use a mouse.
Changes you have made to help deaf people will help people who can't hear because they're in a noisy environment. Changes you have made to help visually impaired people will help users who can't see their phones because they are in direct sunlight.
In terms of accessibility, a worrying large number of people and businesses do nothing.
Of those that do, the most common approach is to search for an accessibility testing tool, which will give you a list of things to fix (such as missing alt text or small touch inputs). For example, if I run AChecker on the Lost My Name website, I get a long list containing, among others, the following errors:
These tools are good, but have their drawbacks. They don't order errors by priority, meaning that errors such as the above errors—which basically aren't going to affect anyone at all—are displayed above errors like missing alt text and missing label elements.
Automated tools like these also won't notice things that aren't there. For example, when improving the Lost My Name website, it only had images of the books, and they were background images: nowhere on the website was it explained what the product actually was in text or alt text, and an automated tool won't notice stuff like that!
I don't think just using a tool like AChecker is enough—it's useful, and will help us find some things, but I don't find it sufficient to make a truly accessible website.
I'd recommend taking the following steps:
A good place to start is the Web Content Accessibility Guidelines (WCAG) 2.0.
This contains a number of guidelines sorted under four guidelines: websites must be perceivable, operable, understandable, and robust. It explains what you as a developer can do to make your website accessible to people with various different types of disabilities, and recommends three levels of conformance: where level A is the website should be functional for people with disabilities, and level AAA is the website should be perfect for people with disabilities.
Another good way to tell how good your site is for users with disabilities and how you can make improvements is simply by talking to your users with disabilities. In my experience, they'll be glad to help—especially if you offer them some money off your website!
Another approach would be to hire a professional disabled user tester. There are individuals who will be happy to help you, and there are also organisations like AbilityNet. Be aware that they are usually very experienced users of assistive technology—they may miss some advice that would help people with less experience using assistive technology. Still, they're very useful people to have on your team: I would definitely recommend adding a disabled user tester to your QA process if you have the budget and committment.
What I found most useful when I was learning how to make websites accessible was actually learning how to use a screen reader. Being able to test the website myself instead of having to rely on a user tester was really useful for being able to quickly fix issues, instead of having to guess how to fix it, sending it to the tester, and then trying another fix. Also, it helped me gain perspective—screen readers are so much trickier to use than just reading the screen like a sighted user would be able to, and it made me recognise really how privileged I was.
It's important to be aware when testing with a screen reader that issues you find might not be issues with the website or issues with the screen reader: they might be issues with you. Without having the experience that a visually impaired user has, you may get stuck or not know how to do something. It takes practice to get good at using a screen reader.
Note that improvements you make to your website to make it easier to browse using a screen reader won't necessarily make it easier for people with other disabilities to use your website—it will only help visually impaired users and people with severe dyslexia, who will often use a screen reader. You still have to consider other disabilities. In my experience, other disabilities are easier to cater for.
Having recommended that you learn to use a screen reader, I'm now going to teach you how!
There are many screen reader solutions available. JAWS and NVDA are two available for Windows, and VoiceOver is built in to OS X. JAWS is super expensive—although the trial lasts 80 minutes, you just have to reboot—so if you're using Windows, it might be better to look into NVDA. Voice Over comes with OS X, and you don't need to pay anything to enable it.
I use a Mac, and according to most polls, most other front-end developers also use Macs, so I'm going to be explaining how to use VoiceOver (it's also the only one I know how to use). The same principals apply to other screen readers, but the keyboard shortcuts and behaviours will be slightly different.
To start using VoiceOver, press cmd+F5 (note: you probably need to press alt). VoiceOver will then tell you some information about the application you're in: it will both read it out—make sure your laptop isn't muted—and display the text in a box on the screen. If the speech is too slow or fast for you, go into VoiceOver Utility -> Speech to change the settings.
At any time, you can press "ctrl" to get the screen reader to stop speaking.
VoiceOver is controlled using the keyboard. Most of the keyboard commands used to interface with VoiceOver involve pressing the "VoiceOver keys", which are "ctrl" and "alt" together. When I talk about "VO" in a keyboard command, those are the keys I'm referring to. For example, to open VoiceOver help, press VO+h, which is ctrl+alt+h. The "Commands Help" section can be useful for finding the keys for actions you don't know about.
While you're learning how to use VoiceOver, it's probably best to keep the monitor on so you can see what you're doing.
The VoiceOver cursor is the black rectangle that appears around the text being read out, and marks where the focus of the screen reader is. Learning how to control where this is is probably the most important thing to know about VoiceOver as a web developer: it's useful to know how to work with inputs and edit text, but not as essential as being able to hear what the page sounds like when read out.
Open a browser—I use Safari when using VoiceOver because I could never get it to work in Chrome—and open a website with a good accessibility record like gov.uk. Be aware that some websites are better than others: if you try to learn how to use VoiceOver by browsing a website that doesn't work well with screen readers, you're not going to have a great time. Press VO+a to tell VoiceOver to read everything. It will then read everything on the page, from the top to the bottom (remember: press ctrl to stop it from reading).
That's good, but you probably don't want to read out the entire page—especially on some websites where the header contains a tonne of links! To move the VoiceOver cursor left or right, press VO+left or VO+right. This allows you to skip around the page a bit quicker, avoiding listening to paragraphs you know you don't care about. Go ahead and try it out in your browser.
In addition to browsing the HTML elements one at a time, you can also browse by heading: to jump between headings, press VO+cmd+h. This is important to be aware of when writing HTML: this is a common way to browse using a screen reader, so you should ensure that you have good headings. For example, on gov.uk, the links to sections of the website are both links and headings to make it easy to skip between them. It's much quicker to press VO+cmd+h a few times than to press VO+right and listen to all the paragraphs, too!
With quite a few of the VoiceOver shortcuts, you can hold down shift while typing the command to go backwards instead of forwards: for example, press shift+VO+cmd+h to move the VoiceOver cursor to the previous heading.
You can also skip between links by pressing VO+cmd+l. Much like browsing by headings, browsing by link can be a lot quicker than navigating through every element. It also has implications for use as web developers: if you have a link that has only the text "Read more", then a user browsing by links will have no idea what the link leads to. "Read more about [article title]" would be much more effective.
While you can browse through a tonne of different types of element—see VoiceOver help -> Commands Help -> Find—the only other one I often use is Find Next Control, triggered by VO+cmd+j. This one is great for when browsing through forms: if your form controls have title attributes or label elements, it will read out the label. Note that if an element doesn't have a corresponding label or a title, VoiceOver will read out "edit text" or "required, edit text" and this method of browsing breaks down. You should keep that in mind when writing your HTML.
When browsing a website using the keyboard, you click form elements using the space key, and click links using the enter button. That's not ideal, if you can't see the screen (it's pretty confusing if you can!) VoiceOver solves this problem with the Perform Action command, triggered by VO+space. This performs the default action of the currently focused element: for example, it clicks links, presses buttons, and opens select elements.
With these few commands, you should be able to browse around most websites. You will find out for yourself why images need alt text, why input boxes need labels, and why icon fonts are bad for accessibility. Here's a table containing the keyboard shorcuts I introduced above:
<tr>
<td>Read contents of VoiceOver cursor</td>
<td>VO+a</td>
</tr>
<tr>
<td>Move VoiceOver cursor right / left</td>
<td>VO+right / VO+left</td>
</tr>
<tr>
<td>Find next heading</td>
<td>VO+cmd+h</td>
</tr>
<tr>
<td>Find next link</td>
<td>VO+cmd+l</td>
</tr>
<tr>
<td>Find next form control</td>
<td>VO+cmd+j</td>
</tr>
<tr>
<td>Perform default action</td>
<td>VO+space</td>
</tr>
| Action | Keyboard command |
|---|
Remember, the VoiceOver keys referred to in keyboard controls are ctrl+alt
While not as important to know as a developer, VoiceOver makes it easier to interact with form inputs such as <textarea> elements.
To play with this, you simply need a website or application with a big input element, such as Pastebin.com. Websites like GitHub Gist do not work, because they have syntax highlighting and are not actually input elements at all.
Go ahead and start typing normally, and you'll notice that when you type a word, VoiceOver will read out what you just typed. There are a couple commands to hear what you just wrote: you can press VO+s to read out the sentence, and you can press VO+w to read out the word the cursor is on. If you press VO+w again, it will spell the word out a letter at a time, and if you press it once again, it will spell the word out using the phonetic alphabet.
For navigating around the text, just use the standard controls. These are good to know anyway even when not using a screen reader—it's much quicker to use the keyboard shortcuts for navigating around text than moving your hand to the mouse and clicking the right point in the text.
<tr>
<td>Read out paragraph</td>
<td>VO+p</td>
</tr>
<tr>
<td>Read out sentence</td>
<td>VO+s</td>
</tr>
<tr>
<td>Read out word</td>
<td>VO+w</td>
</tr>
<tr>
<td>Skip one word to the right / left</td>
<td>alt + right / left</td>
</tr>
<tr>
<td>Move cursor to right / left</td>
<td>cmd + right / left</td>
</tr>
| Action | Keyboard command |
|---|
Safari includes an accessibility feature called the web rotor. It's similar in idea to browsing by heading or link by pressing VO+cmd+h or VO+cmd+l: it displays a list of links or headings and makes it easy to browse between them.
Press VO+u in Safari to activate web rotor.
It will display a list of all the links on the page, and tell you how many links there are. You can then use the up and down keys to browse between them. "See more" links are especially useless in this view! Pressing enter will take you to that link on the page, and you can then press VO+space to click on the link.
Web rotor does more than just display links: if you press the left or right arrow keys when in the web rotor, you'll see that you can also browse by heading, form controls, web spots, and landmarks. You already know what headings and form controls are (I hope!), but the other two might be less obvious.
VoiceOver allows you to create web spots, sections on the page which it automatically detects in the future and allows you to skip to easily—or it can start there in the future, if you tell it to. I have never found this feature useful, but here's the support article if you want to try it out: VoiceOver: Navigate webpages using web spots.
Landmarks are an article to themselves. When you use a semantic HTML5 element such as <header>, or an aria role such as role="main", it's set as a landmark, and you can then easily browse between them using the web rotor. This can be very useful when trying to skip a large header on a site that doesn't have a "Skip to content" link!
There are a few other commands that I've found useful when learning how to use VoiceOver and browsing websites when developing.
Keyboard help, activated by pressing VO+k, tells you what a key or keyboard shortcut does. For example, when you're in keyboard help, pressing ctrl+alt+p will tell you the keys you just pressed and that that is the keyboard shortcut to read out a paragraph.
Instead of pressing the VoiceOver keys every time, you can lock the VO keys by pressing VO+;. Now, you don't need to press the VoiceOver keys: you can press just "cmd+h" to find the next heading, or just "space" to click a link.
There are a number of keyboard commands for changing the speech settings such as pitch and rate. To open the rotor and skip between settings, press VO+cmd+right (or left to go the other direction), and then to modify a setting, press VO+cmd+up or VO+cmd+down. You'll probably find that as you use VoiceOver more and more, you'll become more comfortable with it speaking quickly and want to increase the rate—and then when you're showing people, you'll need to slow it back down again!
Finally, there's the screen curtain. Activating the screen curtain will effectively turn off the screen. This is useful when you're better at using a screenreader at simulating what a visually impaired user will experience—although pretty much impossible to do if you're not that experienced in using a screen reader. To activate screen curtain, press VO+shift+F11 (you'll probably have to press fn, too: this isn't a very nice keyboard shorcut). Be careful. Write down the keyboard shortcut so that you know how to turn the screen back on again.
<tr>
<td>Activate keyboard help</td>
<td>VO+k</td>
</tr>
<tr>
<td>Toggle VO lock</td>
<td>VO+;</td>
</tr>
<tr>
<td>Modify speech settings</td>
<td>VO+cmd+left / right / up / down</td>
</tr>
<tr>
<td>Toggle screen curtain</td>
<td>VO+shift+F11</td>
</tr>
| Action | Keyboard command |
|---|
The best way to get good at using a screen reader is simply by using one. Once you're proficient at using a screen reader, you will be able to experience websites you're developing just as a visually impaired user of your website would, meaning that you'll be able to see what needs changing or adding in order to make your website accessible to those users.
Learning how and then using a screen reader to test your website, while definitely a bigger time investment than just running through your website through an automated tool, is definitely worth doing if you want to take accessibility seriously. That said, following a checklist is better than nothing, and also warns you about things affecting other types of disabilities–I usually use both, although I spend more time with a screen reader.