Screen reader users and the tab key
Posted 21st December 2023 in Accessibility
Screen reader users who use a laptop or desktop computer generally (though not always) use their keyboard to control their screen reader software. But that doesn’t mean they use the keyboard like a keyboard-only user.
Keyboard-only users
A keyboard-only user gets around an interface with only a handful of keys:
- The up and down arrow keys to scroll up and down the page
- ⇥ (Tab) and ⇧ (Shift) + ⇥ to move focus from one interactive element (links, buttons, form fields) to the next
- ⏎ (Return), Space, and the arrow keys to interact with elements when they have focus
- One or two other keys, such as Esc which should close a modal or popover
- They’ll also type freely into text-based form fields
Keyboard-only users only need to interact with the content on the screen, and we can assume that they can see non-interactive content like headings and paragraph text.
Screen reader users
With screen reader users, there’s no guarantee that they can see the contents of the screen, so they’ll use their screen reader to access to any content on the screen, not just interactive stuff like buttons, links, and so on.
If a screen reader user were to use ⇥ to jump from one interactive element to the next they’d miss important content, so they’d use their screen reader software’s navigation shortcut keys to get around instead.
They’d move from one chunk of content to the next, jump from heading to heading to get a feel for the content on the page, skip straight to a particular page landmark like the footer; that kind of thing. Other than filling in form content, they’d be unlikely to use the same keys to negotiate an interface as a keyboard-only user.
Note: That’s not to say that screen reader users will never use the tab key; more that screen reader users will only use the it if they already know exactly what’s on the screen.
Manual testing
This is one to bear in mind if you’re doing any manual accessibility testing. Using the keyboard and using a screen reader should be treated separately:
- First test using the keyboard like a keyboard-only user
- Then test with a screen reader using its build-in key commands