Testing a Page for Accessibility

After this lesson you can

• Test a page by hand with the keyboard, a screen reader such as Narrator or VoiceOver, 200% zoom and captions
• Run Lighthouse or axe DevTools and explain what automated tools catch and what they miss
• Choose the fix a barrier needs, such as a native element, a label, alt text, a heading level, the focus order or ARIA

Key takeaways

• Test every page the same way, in the same order, so nothing gets skipped.
• The keyboard pass and the screen-reader pass find what a person meets, such as a fake button or a link that says "click here".
• Lighthouse and axe DevTools find missing things fast, such as alt text, labels and button names, but they can't judge whether the words make sense.
• Zoom to 200% and turn captions on, because low-vision and Deaf visitors meet the page that way.
• Each barrier you find has its fix in HTML you know, a native element, a label, alt text, a heading or a captions track, with ARIA as the last resort.

Before you hand in a project, send a client the link to their new site, or close a ticket that says "make the page accessible", you need to know it works. "It looks fine to me" only tests one way of using a page: yours. This lesson gives you a checklist you can run on any page in about fifteen minutes, the same way every time, and it's the one you'll use on the Starlight Cinema in the exercise that follows.

The checklist

A pilot runs the same checklist before every flight, even after thousands of flights, because a checklist doesn't forget. An accessibility check works the same way. Here's the whole thing; the sections below go through each step:

1. Keyboard only     Tab through everything. Can you reach it, see it and use it?
2. Screen reader     Listen by headings, landmarks and links. Does it make sense?
3. Automated tools   Run Lighthouse and axe DevTools. Fix what they find.
4. Zoom to 200%      Is anything cut off, hidden or overlapping?
5. Captions on       Does every video have captions, and do they match the words?
6. Write it down     One line per barrier: where, what, who it stops, the fix.

Do the two by-hand passes first, while the page is new to you: you notice more before a tool tells you what to look for.

1. The keyboard pass

Put the mouse out of reach. Click in the browser's address bar, then press Tab again and again until you've been through the whole page, and Shift + Tab to come back. At each stop, ask three questions:

• Can I reach it? Everything you can click with a mouse should get focus. Something clickable that Tab skips is often a <div> pretending to be a button.
• Can I see where I am? A visible focus ring on every stop.
• Can I use it? Enter follows links and presses buttons; Space ticks checkboxes; the arrow keys move through radio buttons.

Also notice the order. Does focus move the way you read, or does it jump? A jump usually means a positive tabindex, or HTML written in a different order from the screen.

2. The screen-reader pass

Screen-reader users rarely listen to a page from top to bottom. They jump around: by headings to see how the page is laid out, by landmarks to reach the main content, by links to find where they can go. Test the same way. You only need a handful of keys:

In Narrator, Caps Lock (or Insert) is the Narrator key. Its letter keys work in scan mode, which is usually on by itself in a web page; Caps Lock + Space turns it on and off. On a Mac, Control + Option are called the VO keys, and you hold them down for every VoiceOver command. Both take getting used to: expect the first ten minutes to feel strange.

Listen for:

• Pictures read as file names, such as "poster dash comet dash riders dot svg": an image with no alt.
• Headings that skip levels, or a page with none.
• A form field read as "edit text" with no name: an input with no label.
• "Button" with nothing after it: a button with only an icon.
• Links that say "click here" or "read more": in a list of links, they don't say where they go.

Try it. Turn on Narrator or VoiceOver and open the list of headings on a news site you read. Can you tell what's on the page from the headings alone?

3. Automated tools: Lighthouse and axe DevTools

Two free tools check a page in seconds:

• Lighthouse is built into Chrome and Edge: open the developer tools (F12), choose the Lighthouse panel, tick Accessibility, and click Analyze page load. You get a score out of 100 and a list of problems, each with the elements it found.
• axe DevTools is a free browser extension from Deque, for Chrome, Edge and Firefox. Once it's installed, it adds an axe DevTools tab to the developer tools, where a full-page scan lists each problem, why it matters and how to fix it. Lighthouse uses the same checking engine, axe-core, so their lists often overlap.

They're good at finding things that are missing or measurable: a picture with no alt, a form field with no label, a button with no name, text whose color doesn't stand out enough from its background, a positive tabindex, no main landmark.

They can't judge whether things make sense, because that takes a person:

So a score of 100 means "no problems a tool can find", not "accessible". Run the tools, fix what they find, and keep your by-hand passes.

4. Zoom to 200%, and 5. captions on

Zoom. Many low-vision people browse with the page zoomed in, and WCAG asks that text still works at twice its size. Press Ctrl and + (on a Mac, Command and +) until the browser says 200%. Read the whole page. Is any text cut off, covered by something else, or pushed off the side so you have to scroll sideways to read every line? Ctrl + 0 (Command + 0) sets it back.

Captions. Play every video on the page with the sound off. Is there a CC button, and do the captions match what's said? A missing captions track shows in the HTML too, once you know where to look:

<video controls width="640" height="360">
  <source src="media/comet-riders-trailer.mp4" type="video/mp4">
  <track kind="captions" src="media/comet-riders-trailer.vtt" srclang="en" label="English">
</video>

No <track kind="captions"> means no captions. Captions and Subtitles showed how a captions file is written.

6. From a barrier to its fix

A check isn't finished until each barrier is written down with its fix. Most fixes are HTML you already know:

Notice how far down the list ARIA comes: once, for a button that has no words on the screen. That's the first rule of ARIA at work.

Check yourself

2 questions to try on the lesson page.

So what

Fifteen minutes with a keyboard, a screen reader, two free tools, the zoom keys and the CC button finds most of what stops people on a page, and the habit of running them every time is what makes a developer someone teams trust with accessibility.

Key terms

• Screen reader
• Lighthouse
• Developer Tools
• Captions track

Cheat sheets

• Testing a Page for Accessibility