Introduction
Being able to check some code changes or a design with a screen‐reader is a major part of understanding accessibility, but many people put it off as it is so daunting.
It’s certainly understandable as most times you might see people using a screen‐reader they will have the speed turned up so high it is difficult to follow and they might jump around the page seemingly randomly.
But, for the most basic of testing, a simple top to bottom run through the page, you only need to know one or two keys commands.
What is a screen-reader?
(incl. difference to text-to-speech, braille output)?
Analytics
(why we can’t, how work use might differ from non-work)
- tracking screen-reader users is not a thing (mainly for privacy reasons, but has been prevented by browsers / os)
Who uses them?
- don't assume the screen-reader user is blind or even has poor eyesight
- keep parity between visible labels and what is announced
- keep hidden text to a minimum
- need to think about users who are new to a screen-reader so may need to use the most basic navigation modes
How do you use one?
Before we get into starting up our screen‐reader, let’s think about how a screen‐reader will move you around the page.
So the same as a keyboard user? Different navigation strategies and when users might use each Simple navigation More complex interactions Link off to guides
Screen‐reader beginner’s guides (for NVDA, Voiceover and JAWS) which take you through everything from how to understand what the screen‐readers are saying, to viewing lists of links and headings, how to navigate tables and more.
Navigating by headings
This is all well and good, but it can take a long time to read through all of a page like this. So let’s add in one shortcut, navigating by headings.
For Voiceover you can use Ctrl + Alt + Cmd + h to jump from heading to heading, NVDA users have it a lot easier as they can just hit the h key to do the same. Add in the shift key to reverse the direction.
You will hear the heading level read out as you do this and this highlights the importance of getting your heading hierarchy right as navigating by headings is a good technique for someone to get a mental layout of a page and its content and how it all relates to each other.
That’s it - that’s the basic navigation for using a screen‐reader!
You can turn off your screen-reader now - Command + F5 for Voiceover or if you are using NVDA you can quit via the tray icon.
Where am I?
The first thing you might want to know when you land on a page which you can’t see, is “am I on the right page?”. To help with this the first thing you will hear when a page loads is the contents of the page title element. This is why having the title contain the purpose of the page (ideally the same as the page's h1 ) as well as the site's name is a great idea.
Not your typical keyboard user
Yes, screen‐readers make use of the keyboard to navigate, but put away thoughts that you will be moving about the page by hitting the tab key. Doing that will only let you hear the interactive content (links, form inputs, buttons etc), so you wouldn't really be able to listen to an article by tabbing around.
Instead you’ll be using the arrow keys to move up and down the page. As you move you will see an outline around content and this is a visual representation of what’s called the virtual cursor. This allows you to move by blocks of text, reading it aloud as you go, but will also read out extra information when you get to buttons, form inputs or other components.
As you move around the page you will see the browser focus (that focus state you get when you tab about with a keyboard) move with you when you reach an interactive element like a link, but then get left behind as you carry on using the virtual cursor.
One long tube
As you move about with a screen‐reader you will notice that the reading order follows the code order. To a screen‐reader user the page is always one long tube of content - the visual layout doesn’t really matter - which is also why “directional content” (where you might refer to content “over to the right”) is discouraged (although “above” or “below” is generally ok).
Content and screen-readers
You might hear some content read out differently to how you might expect. In general, don’t worry about this (or check with an experienced user) as screen‐reader users can have different settings depending on their preferences. In particular reference numbers is one area where we see developers trying to force the screen‐reader to read it out in a particular way, not realising that all screen‐readers allow users to move character-by-character if required, so they can easily check the exact details if they want.
If you find yourself thinking more content is needed to help screen‐reader users understand an interface, the chances are they either don’t (again, check with an experienced user), or that content would help all users, or the interface may need to be reworked.
Reading more than text
- what gets announced may vary from screen-reader to screen-reader (eg image, graphic) Differences to text-to-speech Semantics
- touch on accessibility tree (link off to tree module)
Different screen-readers
The different screen-readers Mobile vs desktop screen-readers Browser choice matters
Testing with screen-readers
Should I test with a screen-reader?
Yes and no.
Which one to use
- Which one to use
- you are not your user (you have perhaps used VO, they will use JAWS or NVDA)
- iOS VO and MacOS VO are different
- WebAim Screen-reader survey
- how to decide what to test with
- different results for same page for different screen-readers / browsers
- if I could only test one screen-reader ...
- Assistiv Labs
What to look for
- Accessible names
- Headings - using various dev tools to check
- landmarks
- Alt text
- W3C alt text decision tree
- background images (using hidden copy referenced by role="img" aria-describedby)
- Common issues
Verifying an issue
- verify the issue with someone who has experience with a screen-reader - an accessibility specialist or by user testing
- check for issues
- NVDA github
- Webkit issue tracker
- freedom scientific issues
- we need to work with what we have - not what we wish screen-readers would do