Testing Accessibility

You cannot tell whether a page is accessible by looking at it. A button with no name looks exactly like a button with one; a keyboard trap is invisible until your mouse is gone. The only way to know is to use the page the way other people use it, and to let a program check the rules that can be measured.

Three kinds of test do that: the keyboard, a screen reader and an automated checker. Each finds problems the others miss, and on a site this size, all three together take less than an hour. Think of a building inspection. A checklist catches the missing handrail and the fire door without a sign. Only walking the stairs yourself tells you they are too steep to climb with a bag of shopping. The checklist is the automated test; walking the stairs is the keyboard and the screen reader.

How Do You Test with the Keyboard?

Put the mouse out of reach. Open the Home page, click once in the address bar so the browser has somewhere to start, and press Tab. Keep pressing it until you have been through the whole page, then use Shift and Tab to go back. Do the same on the Projects and Contact pages.

Four questions, on every page. Can you reach every link, button and form field? Can you always see where focus is, thanks to the site's :focus-visible rule? Does focus move in the same order as the page reads, top to bottom and left to right? And can you always move on, or does focus get stuck somewhere, which is called a keyboard trap?

Then operate everything. Enter follows a link and presses a button; Space presses a button too. Try the project filter, the theme button, and the contact form from the first field to the send button, including an error or two. If a panel opens, Escape should close it. Watch also for focus that disappears behind the sticky header as you move back up a long page with Shift and Tab; the previous topic fixed that with scroll-padding-top.

One trap for the tester rather than the page: by default, Safari on a Mac skips links and buttons when you press Tab, unless you switch on the setting to press Tab to highlight each item, in Safari's Advanced settings. Run the keyboard test in Chrome or Firefox, or change that setting first.

How Do You Try a Screen Reader?

You will not become an expert in one session, and you do not need to. The aim is to hear the site once the way a blind visitor hears it, which finds the worst problems in minutes.

On macOS, the screen reader is VoiceOver, built into the system. Press Cmd and F5 to turn it on and the same keys to turn it off; on a Mac with Touch ID you can also hold Cmd and press Touch ID three times. VoiceOver's commands all start with Control and Option held together. Control, Option and the right arrow move to the next item and read it. Control, Option and U open the rotor, a menu of the page's headings, links and landmarks; the left and right arrows switch between those lists. VoiceOver works best with Safari.

On Windows, the usual free choice is NVDA, from the non-profit NV Access; you download and install it yourself from their website. Windows also has a built-in screen reader, Narrator, turned on with Ctrl, the Windows key and Enter. In NVDA, the down arrow reads the next line, H jumps to the next heading, D to the next landmark and K to the next link, and pressing Ctrl stops the speech. NVDA works well with Chrome or Firefox.

Listen to the Home page. You should hear the page title first, then the banner landmark with your name, the navigation landmark with its three links, the main landmark, and your headings in order. Move by headings and by landmarks, not only item by item, because that is how experienced users skim. Anything announced without a useful name, or read in a strange order, goes on your list.

What Can Automated Checks Find?

An automated checker reads the page and tests every rule a program can measure. Lighthouse is a testing tool built into Chrome DevTools, and Chapter 13 uses it again to measure speed. For accessibility, open its panel, tick the Accessibility category, and press Analyze page load. It reports a score and a list of failures, each linked to an explanation. Several browser extensions do the same job with more detail, and are worth installing once you use them often.

They are reliable at what can be measured: an image with no alt at all, text below the contrast ratio, a form field with no label, a button or link with no name, a page with no lang attribute. Those are also the most common failures on the web. WebAIM's 2026 survey of the top million home pages found detectable failures on 95.9 percent of them, and those same six kinds of failure made up 96 percent of all the errors it detected.

They cannot judge meaning. A checker sees that an image has alt text, not whether "photo" describes it; that focus moves, not whether the order makes sense; that a heading exists, not whether it says what the section is about. In a 2017 test by the UK Government Digital Service, on a page built with 143 deliberate barriers, the best single tool found 37 percent of them, or 41 percent counting the places where a tool asked a person to check by hand. All ten tools tested, combined, found 71 percent. The rest needed a person.

Problem	Keyboard	Screen reader	Automated
Missing alt text	no	yes: often the file name	yes, reliably
Useless alt text	no	yes: you hear it	rarely
Low contrast	no	no	yes, reliably
Focus trap	yes: you get stuck	often	rarely
Confusing order	yes: focus jumps	yes: it reads oddly	no

What Did the Site's Test Find?

Run all three on the site as it stands and the results are clean, because every chapter built the accessible version first. The keyboard reaches every control, focus is visible throughout, and nothing traps it. The screen reader announces the landmarks, the headings in order, the labelled form fields and the form's messages. Lighthouse finds no missing alt text, no unlabelled field and no contrast failure.

Then make one change that many real sites make, and test again. On a narrow phone the header is crowded, and the theme button from Chapter 9 is the obvious thing to shrink: replace its words, Dark theme, with a small moon icon whose image has an empty alt. On screen it looks tidier. In the accessibility tree the button now has no name at all.

The keyboard test still passes it, because it is reachable and it works. But the screen reader announces only that there is a toggle button, not what it toggles, and Lighthouse lists it under buttons that do not have an accessible name. A sighted mouse user would never notice; only listening, or a program that checks names, finds it.

<button type="button" class="theme-toggle" aria-pressed="false">
  <img src="images/moon.svg" alt="" width="24" height="24">
  <span class="visually-hidden">Dark theme</span>
</button>

The fix keeps the icon and puts the words back, hidden from sight: a span with the visually-hidden class from earlier in this chapter, inside the button. Make the same change in the header of all three pages. Nothing changes on screen. A screen reader now says the name, Dark theme, then that it is a toggle button and whether it is pressed; the Accessibility pane in DevTools shows the name; and a second Lighthouse run no longer lists the button. The script from Chapter 9 needs no change, because it only reads and sets aria-pressed.

Run the keyboard and screen-reader tests once more too. A fix is finished when the test that found the problem passes.