How to do Web Accessibility QA: Part 1

So your organization has decided to champion web accessibility. Awesome! 

Your design and content teams are designing for accessibility and creating accessible content. Bonus! Your front-end developers are writing a11y-friendly code. Crucial!

Now it's your turn: time to do accessibility quality assurance testing.

Gulp — what's WCAG, again?

If you're nervous about doing accessibility QA for the first time, I'm with you. Thanks to Jeremy Fields and others, I had multiple background sessions — but I still felt lost when it came time for real testing.

Don't sweat it; a11y testing is straightforward once you understand a few foundational concepts. Here's my two-part guide to accessibility testing so you can help make your sites as inclusive as possible. (Here's Part 2.)

Step 1: Realize that people don't use computers like you do

After doing accessibility QA a couple times, I realized the key to understanding accessibility has nothing to do with WCAG or particular testing tools. The key concepts are more fundamental — more human — than that: 

• People physically interact with a computer in different ways than I do. Specifically, millions of people use a computer without a mouse/trackpad or without seeing what's on-screen, and use a mobile device without seeing the screen.
• Those ways of using a computer have seemingly subtle differences that profoundly affect whether a website is pleasant and comprehensible or hair-pulling and unintelligible.

I also realized that those ways of using a computer are completely out of my frame of reference. While I was vaguely intellectually aware of the above concepts, I couldn't truly understand them until I used computers in those ways myself.

So before diving into WCAG and accessibility QA, you need to use a computer or mobile device in those ways, too: without a mouse as the input device (we'll use a keyboard instead), and without a screen as the output device (we'll use a screen reader application). Here's what that looks like.

Note: I'll walk through this using a Mac, but the concepts are representative of similar use with iOS, Windows, and Android devices.

Step 2: Put Away Your Mouse

Let's start by looking at using only a keyboard as the input device. (There are various types of non-mouse input devices, but a keyboard is the most common and is a reliable proxy for other types.)

When I go to apple.com using a mouse, I can move the cursor and click anywhere I want. I can "hover" the cursor over various elements, which in many cases triggers "hover state" effects. But I can't do that while using just a keyboard. In fact, there isn't a cursor — or hover states — when using a keyboard.

Instead I traverse the page by pressing the Up/Down Arrow keys to scroll, or by pressing Tab or Shift+Tab to move between links and other interactive elements. The technical term for "move-betweenable clickable elements" is "focusable"; pressing Tab advances the "focus state." 

To click a link or a button using the keyboard, or to manually trigger a hover-state effect, I move the focus state to that element and press the Return key.

Try it yourself: Go to apple.com, take your hand off the mouse or trackpad, and start pressing the Tab key. (Make sure your computer has "Preferences > Keyboard > Shortcuts > Full Keyboard Access: All controls" selected.) Press Return to click a link. See what it's like to interact with a carousel using only the keyboard.

Go to atlanticphilanthropies.org (Jeremy Fields' excellent handiwork) and do the same. As you Tab through the main navigation, you'll see how subnavigation menus — which open on hover when using a mouse — work with a keyboard: press Return to expand a subnav menu, use Tab and Return to go through the menu items, and press Esc to close the menu. 

Try a few other sites and see how they feel.

Step 3: Listen to Your Site

Now let's look at — or listen to — what it's like to use a computer without the screen. To do this, we'll use software called a screen reader.

I'm embarrassed to admit that when I first heard the phrase "screen reader" and the name of a popular Windows screen reader app — JAWS — my mental model was a magnifying screen clamped on an old-timey microfiche machine, like ungainly headgear for the computer. This obviously makes no sense, but shows how far out of my frame of reference screen readers were.

In fact, a screen reader app traverses a web page's code (HTML, CSS, and JavaScript) and reads aloud portions of the code: on-screen text, meta-information about content (e.g. descriptions of images), and meta-information about page context (e.g. identifying navigation and links). Screen readers have their own keyboard commands for interacting with page content and manually traversing a page.

Apple computers have a built-in screen reader application called VoiceOver, which is what we'll use to understand what it's like to use a computer this way.

Open Safari (VoiceOver works best with Safari) and go to massgeneral.org (more great work by Jeremy Fields and Jeremy Frank). Press the Command+F5 keys to turn on VoiceOver; VoiceOver will start reading aloud. (Command+F5 also turns VoiceOver off.) Leave your screen turned on so you can see how VoiceOver corresponds to what you see — or don't see — on the page.

Once VoiceOver is in the page's HTML portion, press Control+Option+A and VoiceOver will start reading. You can pause the reader by pressing Control. You can manually move to the next readable item by pressing Control+Option+Right Arrow (or move to the previous item by pressing Control+Option+Left Arrow), or press Tab to move to the next link or form control. You can click a link by pressing Control+Option+Spacebar.

The first few times using VoiceOver, let the reader go through the whole page so you can get a feel for the kinds of things it reads aloud. Then experiment with clicking links and manually traversing the page.

Here are two VoiceOver cheat sheets for reference.

Step 4: Reflect

Using a keyboard and screen reader for the first time is revelatory.

When I use a computer, how I traverse and comprehend a page is largely up to me. But when I use a keyboard or screen reader instead of a mouse and my eyeballs, how I traverse and comprehend a page is largely up to the code and the people who wrote it. 

What are some implications of that?

OMG don't make me Tab through every freaking nav link on every freaking page

Go to apple.com/iphone and put the mouse aside again. Press the Down Arrow key to scroll the page until you reach a link. Press the Tab key to try to click that link.

Ack! You're jumped back to the top of the page, where the first navigation link — not the down-page link you were trying to click — now has focus state.

What happened? Well, the Down Arrow key scrolled the page — but scrolling didn't advance the focus state.

This is a subtle but major difference from how I use the computer. I can scroll and click any link I see with a mouse. But you don't have that freedom when using just the keyboard.

Rather, if you want to click a down-page link using a keyboard, by default you need to press Tab to advance through all the focusable elements between the currently focused item and the item you want to click on. Likewise, to reach that down-page link with VoiceOver, you'd need to wait for VoiceOver to read all of the preceding content, or manually advance to the link.

This default behavior is super frustrating. So one important accessibility item is to add "skip navigation," aka "skip links" aka "jump links," as the first focusable item: a link or links that allow users to "jump" the focus state directly to e.g. the main content area or the footer.

Umm, why are you reading me the sidebar before the main article?

Imagine if every time you read a web page, little hands reached out of the screen, grabbed your eyeballs, and forced you to look at the page in a particular order. 

People using screen readers experience this all the time, except they're at the mercy of the page code rather than tiny computer demons. Screen readers read in order of the page's HTML, so if the code is not ordered purposefully then users may hear content being read conceptually out of order.

A big part of accessibility is ordering code to make content comprehensible. 

Gee, thanks for telling me IMG_70887776.jpg is on this page

Imagine if you're looking at a web page and instead of seeing a bunch of images you only see their filenames. Real useful, right?

That's a common experience for screen reader users. By default, a screen reader will read the image's filename — which is no more useful when you hear it read aloud than if you saw the filename instead of the photo on the screen.

Various accessibility items relate to giving screen readers useful information to read (in this scenario, we'd add an image description) to give screen reader users more context and understanding. 

Step 5: Test!

Once you run through a few sites with a keyboard and screen reader, you'll be all set for testing. In my next post, we'll apply this foundational understanding to learn a simple process for doing accessibility QA.