A screen reader is a piece of assistive technology used by people who may need help reading what is on the screen. It’s commonly used by people with visual impairments (it’s one of the only ways blind people can use computers), and also by people with severe dyslexia. It reads out what is on the screen aloud, and can be connected to a braille output device for people who are also unable to hear, or just prefer braille.
According to RNIB, two million people in the UK are visually impaired. 360,000 people are registered as blind or partially sighted. According to British Dyslexia Association, “Ten percent (10%) of the population are dyslexic; 4% severely so.” While there isn’t a reliable way to detect the exact number of people using screen readers, it’s safe to assume that it’s a big number of people.
For a longer read on why I believe accessibility is important, check out another article I wrote: The Case For Web Accessibility.
Why would I learn how to use a screen reader?
There are automated tools available that will test your website for some common problems, and a lot of people choose to use these tools instead of learning how to use a screen reader to test their site, or hiring a disabled usability tester.
These automated tools are a good start —but you can do much better. These tools don’t find everything: all these tools do is help you make sure that your code meets a set of rules; they don’t ensure that the user experience for a person with a visual impairment is good, or that your site is easy to use. When I was learning how to make websites accessible, the thing I found most useful was learning how to use a screen reader. Being able to test the website myself instead of having to rely on a usability tester was really useful for being able to quickly fix issues; instead of having to guess how to fix it, send it back to the tester, and then doing the whole thing over again.
It also helped me gain perspective—screen readers are so much trickier to use than reading the screen as a sighted user; it really made me recognise how privileged I am.
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 people who use screen readers, such as visually impaired users and people with severe dyslexia. You still have to consider other disabilities.
How to use a screen reader
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, and you only have to reboot—but 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, so do most other front-end developers; so I’m going to be explaining how to use VoiceOver. The same principles apply to other screen readers, but the keyboard shortcuts and behaviours will be slightly different.
To start using VoiceOver, press cmd+F5 (note: if you’re using a MacBook, you probably need to press alt as well or you’ll just be decreasing your keyboard brightness). 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.
Navigation
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. 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 even 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; 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 shortcuts I introduced above:
| Action | Keyboard command |
| Read contents of VoiceOver cursor | VO+a |
| Move VoiceOver cursor right / left | VO+right / VO+left |
| Find next heading | VO+cmd+h |
| Find next link | VO+cmd+l |
| Find next form control | VO+cmd+j |
| Perform default action | VO+space |
Remember, the VoiceOver keys referred to in keyboard controls are ctrl+alt.
Editing
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.
| Action | Keyboard command |
| Read out paragraph | VO+p |
| Read out sentence | VO+s |
| Read out word | VO+w |
| Skip one word to the right / left | alt + right / left |
| Move cursor to right / left | cmd + right / left |
The web rotor
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.
However, 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!
More helpful commands
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 it 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 to simulate 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 (if you’re using a MacBook, you’ll have to press fn, too: this isn’t a very nice keyboard shortcut). Be careful. Write down the keyboard shortcut so that you know how to turn the screen back on again.
| Action | Keyboard command |
| Activate keyboard help | VO+k |
| Toggle VO lock | VO+; |
| Modify speech settings | VO+cmd+left / right / up / down |
| Toggle screen curtain | VO+shift+F11 |
Summary
While learning how to use a screen reader and then being able to use it to test your website is definitely a bigger time investment than just running your website through an automated tool, it is definitely worth doing if you want to take accessibility seriously.
That said, following a checklist is better than nothing, and will also warn you about issues affecting other types of disabilities. I usually use both, although I spend more time with a screen reader.
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.