Keyboard Accessibility and Screen Reader Testing: A Practical Guide

Put your mouse in a drawer for ten minutes and try to use your own website. Tab through the home page. Open the menu. Fill out the contact form. For many business owners, it is the most revealing ten minutes they will spend on their site all year.

Automated accessibility checkers are a useful first pass. They reliably flag missing alt attributes, low color contrast and empty links. What they can’t tell you is whether the focus order makes sense, whether a dropdown menu opens without a mouse, or whether a form error is announced to someone who can’t see it turn red. Those checks take a person. The good news is that you don’t need special training to start: a keyboard and a free screen reader will uncover many of the most serious barriers on a typical business website.

Start with the keyboard

Many people navigate the web without a mouse: people who are blind and use screen readers, people with tremors or limited hand movement, and power users who simply prefer the keyboard. If your site works well with a keyboard, you have solved a large share of accessibility problems in one pass.

The keys you need are few. Tab moves forward through links, buttons and form fields, and Shift+Tab moves back. Enter follows links and activates buttons, Space toggles buttons and checkboxes, the arrow keys move through menus, tabs, radio buttons and sliders, and Esc should close any menu, dialog or pop-up.

What to look for

As you move through your most important pages, ask a few questions, each tied to a WCAG success criterion:

• Can you reach and use everything? Every link, button and control should work from the keyboard (2.1.1 Keyboard).
• Can you always see where you are? There should be a visible focus indicator at every step (2.4.7 Focus Visible), and it shouldn’t disappear behind a sticky header or banner (2.4.11 in WCAG 2.2).
• Does the order make sense? Focus should move through the page in the order you read it (2.4.3 Focus Order).
• Can you always get out? You should never get stuck inside a video player, map or embedded widget (2.1.2 No Keyboard Trap).
• Can you skip the menu? A “skip to main content” link or proper page landmarks let people bypass the navigation on every page (2.4.1 Bypass Blocks).

Pay special attention to dialogs and pop-ups. When one opens, focus should move into it, and when it closes, focus should return to the button that opened it. Get this wrong and a keyboard user is dropped back at the top of the page with no idea what happened.

Then listen with a screen reader

A screen reader turns the page into speech or braille. Using one for the first time can feel overwhelming, because it reads everything, including things sighted users never notice. That is exactly why it is so useful for testing.

Which screen reader to use

NVDA is free and open source for Windows and is commonly paired with Chrome or Firefox. JAWS is a widely used commercial screen reader for Windows. VoiceOver is built into every Mac, iPhone and iPad; on a Mac, Command+F5 turns it on and off. TalkBack is built into Android, and Narrator comes with Windows.

You don’t need to test every combination. NVDA with Chrome on Windows and VoiceOver with Safari on an iPhone cover a large share of real-world use, and both cost nothing.

What to listen for

Start by jumping through the headings; in NVDA and JAWS browse mode, the H key does it. Do they outline the page in a sensible order, like a table of contents? Then check that the header, navigation, main content and footer are announced as landmarks.

Next, listen to your links and buttons. Each one should make sense on its own. Ten links that all say “Read more” are useless to someone navigating by a list of links. Listen to your images: meaningful ones should have helpful descriptions, and decorative ones should be skipped entirely. Then fill out a form. Every field’s label should be read aloud, required fields should be announced, and errors should be read out when you submit. Finally, watch for things that change on screen without a page reload, such as “added to cart” or “message sent.” Those status messages should be announced too (4.1.3 Status Messages).

Write down what you find

Testing only helps if the findings get fixed. For each problem, note the page, the steps to reproduce it, what you expected, what happened, the WCAG criterion involved and the browser and assistive technology you used. Rate the severity by asking whether it blocks a task, slows it down or is a minor annoyance.

Then fix the blockers on your key journeys first: contact forms, booking, checkout and login. Retest with the same setup to confirm the fix works.

When to bring in help

Self-testing finds a lot, but a structured audit covers every template and every WCAG criterion consistently, and gives you documentation of the work. EVERNET’s website accessibility audits combine automated scans with the kind of hands-on testing described here. To understand the standard you are testing against, read WCAG 2.1 vs 2.2, and for the legal picture, see ADA website requirements and recent lawsuits.