DEV Community: Madalyn Rose Parker

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

Madalyn Rose Parker — Sat, 21 Dec 2019 00:20:47 +0000

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":

Perceivable
Operable
Understandable
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.

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

Getting Set Up to Manually Test Web Accessibility

Madalyn Rose Parker — Wed, 13 Nov 2019 20:37:29 +0000

The Basics

When I sat down with my brand new work computer, I wanted to get set up to manually test accessibility using as many browsers as I could. This meant keeping in mind a few key things and going through some extra steps. These steps are for using free screen readers with a Mac development environment.

I'm going to lay out:

Free Screen Readers
Browser/Screen Reader combinations
Extra configuration needed to test your project on different platforms

While this post will focus solely on setup, later posts in this series will cover other parts of accessibility manual testing.

Please reach out if there are other topics you'd like to hear about!

Screen Readers

Windows

Narrator (made by Microsoft, pre-installed)
NVDA (most popular free solution)

OSX

VoiceOver (made by Apple, pre-installed)

iOS

VoiceOver (made by Apple, pre-installed)

Android

TalkBack (made by Google, pre-installed)

Browser/Screen Reader Besties

When working on a11y at a previous company, I worked closely with a team at Microsoft. They recommended that I only test Internet Explorer with NVDA and Edge with Narrator. This notion of technology pairings is important for testing since some combinations do not play well together and some combinations aren't widely used.

Below are pairings in order of usage (omitting paid screen readers) according to a September 2019 survey of screen reader users:

NVDA & Firefox
NVDA & Chrome
VoiceOver & Safari
VoiceOver & Chrome
NVDA & Internet Explorer

Narrator & Edge is not explicitly in the survey but I think it's still worth testing as Edge's adoption increases.

Extra configuration

Browsers

Safari requires an extra setting to allow keyboard navigation:

Open up Preferences > Advanced in Safari
check "Press Tab to highlight each item on a webpage" under the "Accessibility" section

Mobile Devices

If you have an IRL mobile device you'd like to use to test out mobile screen readers and other assistive apps you can reach localhost there too!

Android

To access localhost from your Android device you'll need to do (more than) a few things:

First off, make sure your phone has developer options. You can do this by navigating to Settings > System > About Phone and then tapping Build number (the very bottom entry) seven times.
Now there should be a new list of settings under Settings > System > Advanced > Developer Options. Go here and enable USB Debugging
Connect your device to your development machine via USB.
From Chrome, access the remote devices panel in DevTools (under More Tools > Remote Devices).
You should see that there is a pending device at the top of the list of devices. Your phone should have a pop-up prompt asking you to accept remote debugging. Accept remote debugging from your phone.
Now you need to enable Port Forwarding from Settings in the Remote devices tab in DevTools. (Settings are at the very bottom of the list of devices so you may have to scroll down to find them.) Check the box to enable it and then click the Add Rule button to create a port for your phone to access what's in your browser. Type in the port you want to use on your phone on one side (e.g. 3000) and the local address you want to access from your computer (e.g. localhost:9000 for a served Gatsby site)
Boom! If you go to localhost:3000 on your phone you'll see your site!

EDIT (Jan 9, 2020): Device settings used to be part of DevTools but are now conveniently located at chrome://inspect/#devices

iOS

Make sure both your device and your computer are on the same WiFi network.
Make sure you specify the host as 0.0.0.0 when you run your server. (e.g. gatsby serve --host=0.0.0.0)
On your Mac, go to Settings > Sharing. You can find the address for your computer's localhost in fine print under where it says "Computer Name." It will be in the format of computer-name.local. You can edit this address by clicking the "Edit..." button. (e.g. I changed mine to gatsby.local so it would be easier to type on my device)
On your iOS device, navigate to the address determined in the previous step with your port specified. (e.g. gatsby.local:9000)

NOTE: My device tried to fill in the URL by adding www. at the beginning. If you're having trouble reaching your localhost, make sure there is no www. in your address bar.

Virtual Environments

VirtualBox

I downloaded a Windows 10 virtual machine from the Windows Dev Center

You can access your host computer's localhost from 10.0.2.2.

Parallels

Parallels is a paid product, but since it requires extra configuration to access localhost I figured I'd cover that here too.

When serving your site, make sure you are hosting it on 0.0.0.0. For example, if I am running a Gatsby site I'd do gatsby serve --host=0.0.0.0

Then, from your Parallels machine you can access localhost from 10.211.55.2

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:

Navigating the web using the keyboard
Screen reader tips and shortcuts
Testing techniques and methods
Other assistive technologies

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

DEV Community: Madalyn Rose Parker

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

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

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

3. Screen readers super power your keyboard.

4. The find function is your friend.

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

NVDA

VoiceOver

Narrator

6. (Bonus!) Practice makes approximate.

Up Next

Getting Set Up to Manually Test Web Accessibility

The Basics

Screen Readers

Browser/Screen Reader Besties

Extra configuration

Browsers

Mobile Devices

Android

iOS

Virtual Environments

VirtualBox

Parallels

Up Next

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

4. The `find` function is your friend.