Testing a Page for Accessibility

Concept

Accessibility testing has three layers, and none of them replaces the others.

1. Automated - fast, repeatable, and finds roughly a third of issues.
2. Manual - keyboard, screen reader, zoom. Finds most of the rest.
3. People - testing with disabled users. The only way to find genuine usability problems.

Automated tools cannot judge whether alt text is useful, whether a heading structure is logical, or whether an error message is helpful. They can only check what is mechanically checkable.

Automated checks

Browser built ins

Chrome and Edge include Lighthouse, which produces an accessibility score and a list of failures. Firefox has an Accessibility panel with a check for common issues. Both are one click and worth running on every page.

The score is a rough guide, not a verdict. A page can score one hundred and still be unusable, because the score only measures what could be tested automatically.

Browser extensions

Several free extensions run a rule set against the live page and annotate the failures in place. They catch contrast problems, missing labels, empty links, duplicate ids, invalid ARIA references and heading order issues quickly.

In the build

// an accessibility assertion inside an existing test
test("home page has no detectable accessibility violations", async () => {
  const results = await runAccessibilityScan(document);
  expect(results.violations).toEqual([]);
});

Adding a check to continuous integration prevents regressions, which is where most of the value is - fixing a page once and letting it decay is the common pattern.

What automated tools reliably catch

• Missing alt attributes
• Form fields with no label
• Insufficient colour contrast
• Missing lang on the root element
• Empty links and buttons
• Duplicate ids
• Skipped heading levels
• ARIA attributes referencing missing ids
• Invalid ARIA role and attribute combinations

What they cannot catch

• Alt text that exists but says nothing useful
• A heading structure that is technically valid and logically wrong
• Link text that is unclear out of context
• Whether the keyboard order makes sense
• Whether focus is managed after a dynamic change
• Whether an error message explains how to fix the problem
• Whether a custom widget behaves the way its role promises
• Whether the page is understandable

A fifteen minute manual routine

1. Unplug the mouse - three minutes

Tab through the whole page.

• Can you reach every control?
• Can you see where focus is at all times?
• Is the order sensible?
• Can you activate everything with Enter or Space?
• Can you close every dialog and menu with Escape?
• Is there anywhere you get stuck?

2. Read the headings - two minutes

Use a heading map extension or the DevTools accessibility tree. Does the outline read as a table of contents? Is there exactly one h1? Are levels skipped?

3. Turn off images - one minute

What content vanished? Anything that disappeared and mattered needs alt text.

4. Zoom to 200 percent - two minutes

Does anything overlap, clip or disappear? Does horizontal scrolling appear?

5. Read the links out of context - two minutes

List every link on the page. How many say click here or read more?

6. Use a screen reader - five minutes

Every platform ships one. Turn it on, close your eyes, and try to complete one task on the page.

The first attempt is disorienting. Do it anyway - fifteen minutes of hearing your own page read aloud teaches more than any checklist.

A checklist for review

Structure
  [ ] one h1, no skipped heading levels
  [ ] main, nav, header, footer landmarks present
  [ ] lang set on the html element
  [ ] page title unique and descriptive

Images and media
  [ ] every img has alt; decorative ones have alt=""
  [ ] video has captions, audio has a transcript
  [ ] no meaningful text inside images

Forms
  [ ] every control has a visible label
  [ ] related groups in a fieldset with a legend
  [ ] errors described in text, not colour alone
  [ ] focus moves to the first error on failed submit

Keyboard
  [ ] everything reachable and operable
  [ ] focus indicator visible everywhere
  [ ] no focus traps
  [ ] skip link present and working

Colour and motion
  [ ] body text at 4.5 to 1, large text at 3 to 1
  [ ] no information by colour alone
  [ ] prefers-reduced-motion honoured
  [ ] anything moving over five seconds can be paused

Dynamic content
  [ ] status messages in a live region
  [ ] aria-expanded and other states kept accurate
  [ ] focus managed after content replacement

Validate the markup too

Many accessibility problems are also validity problems: duplicate ids, badly nested elements, missing required attributes. Running the validator is a free first pass.

Important rules

• An automated score is not a conformance statement.
• Roughly a third of issues are automatically detectable.
• Keyboard testing costs nothing and finds a great deal.
• Test on a phone as well; touch and screen reader gestures differ.
• Testing early is far cheaper than fixing late.

Common mistakes

• Treating a perfect Lighthouse score as done.
• Testing only the home page.
• Never testing dynamic states - open menus, submitted forms, error conditions.
• Testing with a screen reader while looking at the screen.
• Auditing once and never again.
• Filing accessibility issues as low priority by default.

Best practices

• Run an automated check on every page in continuous integration.
• Do the keyboard pass on every feature before it ships.
• Keep the checklist in the pull request template.
• Test the states, not only the initial render.
• Learn the basics of one screen reader.
• Include disabled people in real testing where you can.

Practice

1. Run Lighthouse on a page, fix everything it reports, then do the manual routine and count what remains.
2. Tab through a form with a deliberate validation error and check what a screen reader announces.
3. Turn on a screen reader and complete one task on your own site without looking.
4. Add an automated accessibility check to a build and break a page to confirm it fails.