5 Things You Need to Know About Manual Accessibility Testing with the Keyboard and Screen Readers
Tags: a11y, testing, keyboard
Published: 2019-12-21 00:20:47


**Note:** As part of the Manual Accessibility Testing Manual, this will cover keyboard testing with **free** screen readers.

## 1. Keyboard testing is vital in ensuring a site is accessible.

Accessibility of a site is determined based on the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/TR/WCAG20/#guidelines). These rely on four principles that every accessible site should have, often referred to by the acronym "POUR":
1. Perceivable
2. Operable
3. Understandable
4. Robust

While automated tests can mostly verify that a site has perceivable content (e.g. color contrast meets standards, non-text content is presented with text alternatives, etc.), the majority of these principles rely on the actual experience of the site. 

The second principle, "Operable," explicitly calls out [keyboard accessibility](https://www.w3.org/TR/WCAG20/#keyboard-operation). In order to be WCAG compliant, a site must:
* make all content and functionality operable from the keyboard without special timing of strokes
* ensure there are no [keyboard traps](https://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-trapping.html) (situations where focus can be moved to a component using the keyboard but cannot leave the component using the keyboard)

You'll need to test that manually. It also calls out [navigation](https://www.w3.org/TR/WCAG20/#navigation-mechanisms) in general and gives explicit points that you can test against manually. The main one that will come into play here is [focus order](https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html).

Keyboard testing will also help you identify violations in the ["predictable"](https://www.w3.org/TR/WCAG20/#consistent-behavior) section of the "Understandable" principle. This section focuses mainly on preventing unexpected context changes. Context changes happen when content changes on a page without alerting the user, which can cause disorientation to someone unable to view the whole page at once. For example, think of chat boxes that autofocus your cursor when they have a new message. This is helpful to users who can see the entire page simultaneously, but would be confusing for a screen reader user who was previously navigating another part of the page.

## 2. The `tab`, `space`, `enter`, `shift`, and `pageup`/`pagedown` keys will get you **most** of the way there.

* `tab` will take you to the next focusable element. `shift + tab` will take you to the previous one.
* `enter` will "click" an interactive element
* `pageup`/`pagedown` or `shift + space`/`space` will scroll page content

If there is an interactive or focusable element you cannot reach or select, debug from there to figure out why. Are there clear focus indicators on those elements? 

## 3. Screen readers super power your keyboard.

Your `tab` key will continue to help you navigate the page, but as soon as you fire up your screen reader you will have a whole host of new ways to reach content.

* Each screen reader has its own list of specialized shortcuts. [Deque](www.deque.com) has a nice [consolidated list](https://dequeuniversity.com/screenreaders/) of shortcuts by platform and screen reader with a handy single-page cheat sheet for each. Their [survival guide](https://dequeuniversity.com/screenreaders/survival-guide) is a great place to start.
* Across the board, screen readers have shortcuts that enable you to navigate by headings and tables. Windows screen readers additionally let you navigate by landmark/region. Navigating by landmarks in VoiceOver is possible, but takes an extra couple steps and will be covered later.
* Screen readers will also allow you to "navigate" what is being read, choosing to read as granularly as you'd like by paragraph, line, sentence, word, or even character.

If you're using VoiceOver, you'll have to use the VO (VoiceOver) keys (`Control + Option`) a lot. I recommend either binding them to a single key on your keyboard or "locking" them using `Control + Option + ;`. Locking the keys means they are implicitly pressed and you can invoke commands without them (e.g. `Control + Option + Command + H` becomes `Command + H` to reach the next heading). Narrator and NVDA also have modifier keys, which default to the `insert` keys but can be changed in settings.


| Screen Reader          | Headings                         | Tables                           | Landmarks       | Lists                            |
|-----------|----------------------------------|----------------------------------|-----------------|----------------------------------|
| NVDA      | `H`                  | `T`                  | `D` | `L`                 |
| VoiceOver | `VO + Command + H` | `VO + Command + T` | see below | `VO + Command + X` |
| Narrator (while in scan mode using `Caps Lock + Space`) | `H`                  | `T`                  | `D` | `K`                  |

## 4. The `find` function is your friend.
If you know what you're looking for, sometimes a page search is the easiest way to navigate to that content. Screen readers allow for finding keywords, which can be pretty powerful if you're looking for that "Contact" link or something even more particular without having to manually read the entire page. The commands are slightly different depending on the screen reader:


| Screen Reader | Open Find Dialog                      | Find Next                    | Find Previous                        |
|---------------|---------------------------------------|------------------------------|--------------------------------------|
| NVDA          | `NVDA modifier key + Control + F`     | `NVDA modifier key + F3`     | `NVDA modifier key + Shift + F3`     |
| VoiceOver     | `VO + Shift + F`                      | `VO + down arrow`            | `VO + up arrow`                      |
| Narrator      | `Narrator modifier key + Control + F` | `Narrator modifier key + F3` | `Narrator modifier key + Shift + F3` |


## 5. Screen readers supply a summary of page elements to ease navigation.

The implementation is slightly different for each screen reader, but they all allow you to access a list of page elements. They essentially pop up a consolidated menu of elements. You can then select what types of elements you'd like to list (e.g. landmarks, headings, links) and then quickly skip to those elements. This makes navigating a page really fast.

This is helpful in testing for a few reasons:
* you can ensure that all of the important information on your page correctly appears in that list
* you can choose how you would like to browse the page
* it approximates the experience of users who can visually scan the entire page to pick out the important information

### NVDA

NVDA calls this the [Elements List](https://www.nvaccess.org/files/nvda/documentation/userGuide.html#ElementsList). It can be pulled up using the `NVDA modifier key + F7`. It defaults to showing a list of links. From there you can use the arrow keys to cycle through elements. If you'd like to change the type of elements you'd like to list, you can tab through until you reach the "Type" radio buttons, which allow selection of Links, Headings, Form Fields, Buttons, and Landmarks.

![the UI for the Elements List showing a list of links for this blog post](https://thepracticaldev.s3.amazonaws.com/i/ajb4prikrncmdmfdrc61.png)

### VoiceOver

In VoiceOver, menus for common actions like this are called "rotors", and this is called the [Web Item rotor](https://www.apple.com/voiceover/info/guide/_1134.html#mchlp2719). This is how you can navigate by landmark in VoiceOver. You can open the web item rotor by pressing `VO + U`. Move through elements using the up and down arrow keys and select other types of items using the right and left arrow keys. This rotor includes links, headings, landmarks, sections, form controls, "web spots", and more. 

Web spots are groups of UI elements that VoiceOver has determined go together based on design. You can edit the list of web spots by removing web spots (`VO + Command + Shift + {`), create new web spots (`VO + Command + Shift + }`), and even set one as a "sweet spot" (`VO + Command + Shift + } + }`) to have it always show up first in the list.

![VoiceOver web item rotor UI listing headings for this page](https://thepracticaldev.s3.amazonaws.com/i/kfc8neiwazkuxeh6dve7.png)


### Narrator

Narrator calls this feature ["Views"](https://support.microsoft.com/en-us/help/4462794). You can switch between views using `Narrator modifier key + pageup` and `Narrator modifier key + pagedown` and navigate elements using `Narrator modifier key + left arrow` and `Narrator modifier key + right arrow`.  Types of Views include links, headings, landmarks, form fields, tables, paragraphs, lines, words, and characters. There isn't a graphical interface for Narrator Views so I don't have a picture of them.


## 6. (Bonus!) Practice makes approximate.

As you become more comfortable testing with your keyboard and screen reader, you will develop habits and fall into a groove for what works best for you. Keep in mind that your set of self-imposed constraints while testing will likely widely differ from those experienced by daily assistive technology users. Screen readers are highly customizable, meaning that every user could be using wildly different settings and workflows.

## Up Next

There will be more posts in this series to equip you to manually test the accessibility of websites. For now, topics and timing are still up for discussion. 

I hope to cover topics like:
* Screen reader tips tricks
* Testing techniques and methods
* Other assistive technologies

What would you like to see? Do you have tips you'd like to share?

Be sure to check out the first post in this series on [Getting Set Up to Manually Test Web Accessibility](https://dev.to/madalynrose/getting-set-up-to-manually-test-web-accessibility-3gon)!