5 Things You Need to Know About Manual Accessibility Testing with the Keyboard and Screen Readers

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). 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. 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 (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 in general and gives explicit points that you can test against manually. The main one that will come into play here is focus order.

Keyboard testing will also help you identify violations in the “predictable” 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 has a nice consolidated list of shortcuts by platform and screen reader with a handy single-page cheat sheet for each. Their 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.

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:

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. 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.

VoiceOver

In VoiceOver, menus for common actions like this are called “rotors”, and this is called the Web Item rotor. 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.

Narrator

Narrator calls this feature “Views”. 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!