Accessibility Testing

You have built the pages. You have added labels, roles, and live regions. But how do you know it works?

You test. Accessibility testing is not one big exam at the end. It is a habit: a quick check as you build, a sturdier check before you ship, and a conversation with real people whenever you can. This lesson gives you a toolkit for all three, and a plain look at what each one can and cannot tell you.

What You Will Learn

The three layers of accessibility testing
What automated tools catch, and what they miss
A fast keyboard, zoom, and colour test you can do in five minutes
How to test with a screen reader
Why testing with real people matters
How to report, prioritise, and fix problems
How to stop them coming back

The Big Idea

HTML Code
Mini Page Auditor

index.html
<!-- A page that automated tools will like... -->
<button type="button" aria-label="Close">
  <svg aria-hidden="true" focusable="false"></svg>
</button>

<!-- ...but a human still has to check: -->
<!-- Does "Close" make sense here? Does focus return somewhere sensible? -->
<!-- Is it visible when focused? Is the target big enough to tap? -->

Run the messy page, fix every problem in the box, and then run it again. Then read on to see why a clean result is only the beginning.

The Three Layers of Testing

Layer	What it is	Good at	Weak at
Automated	Tools that scan the code or page	Fast, repeatable, catches missing labels, alt, contrast, and bad markup	Cannot judge meaning, order, or ease of use
Manual	You test with a keyboard, zoom, and a screen reader	Finds focus, structure, and flow problems	Slower, and needs practice
With people	Disabled and older users try real tasks	Finds the problems you did not think of	Takes planning, time, and care

You need all three. Automated testing is the cheapest and fastest, so it goes first. But it is only the start.

Layer 1: Automated Tools

Automated tools scan your page and report problems they can detect from the code. Some of the most widely used:

axe DevTools (browser extension, and the axe-core library for your own tests)
Lighthouse (built into Chrome DevTools; gives an accessibility score)
WAVE (a browser extension that overlays icons on the page)
Accessibility Insights (a free tool with a guided manual check)
Browser developer tools (the Accessibility panel shows the tree, names, and roles)
Linters such as eslint-plugin-jsx-a11y, which flag problems as you type
pa11y and jest-axe, for running checks in automated builds

What they are good at

Missing alt, missing form labels, empty buttons and links, low contrast, a missing lang, duplicate ids, bad ARIA attribute names and values, and skipped heading levels.

What they cannot do

A tool can tell whether a label exists. It cannot tell whether it is helpful. It does not know whether your focus order makes sense, whether a modal traps focus, or whether your instructions depend on colour. Widely quoted estimates say automated tools find only a portion of real problems, often less than half. The exact number depends on the tool and the page.

A perfect score is not "accessible"

A Lighthouse score of 100 means the checks it ran did not fail. It does not mean the page is accessible. Treat the score as a smoke alarm, not a safety certificate.

Try it yourself: for each problem below, decide whether a tool can catch it.

A first automated test

If you use JavaScript, axe-core runs in a few lines:

a11y-check.js
// npm install axe-core
import axe from "axe-core";

const results = await axe.run(document);

results.violations.forEach((violation) => {
  console.log(violation.id, violation.help);
  violation.nodes.forEach((node) => console.log("  ", node.target));
});

Or open Chrome DevTools, then Lighthouse, tick "Accessibility," and run it on any page, with no setup.

Layer 2: Manual Testing

You can find the biggest problems in about five minutes, with no special software.

The keyboard test

Put the mouse away.
Press Tab through the whole page. Can you reach every link, button, and field?
Can you always see where you are?
Does the order make sense?
Can you operate each control: Enter for links and buttons, Space for buttons and checkboxes, arrows for menus, tabs, and radios?
Do menus and dialogs let you leave with Esc, and does focus return to where you were?
Is there a skip link at the start, and does it work?

Most serious failures show up here. See Keyboard Accessibility and Focus Management.

The zoom and reflow test

Zoom your browser to 200 percent, then 400 percent, or make the window 320 CSS pixels wide.
Is everything still readable and usable?
Do you need to scroll sideways to read ordinary text? (Wide tables and maps may be exceptions.)
Increase text size only. Is anything cut off or overlapping?

The colour test

Use a contrast checker (such as the one in the browser tools) on body text, buttons, and form borders.
View the page in greyscale. Can you still tell the states apart without colour?
Try dark mode and high contrast or forced colours mode, if your system has it.

The motion and media test

Turn on your system's reduce motion setting. Do animations calm down?
Do videos have captions, and do audio clips have a transcript?
Does anything flash more than three times per second?

You do not need to be an expert. Even a few minutes of listening will teach you a lot. Common choices (check current versions and combinations):

System	Screen reader	Often paired with
Windows	NVDA (free)	Firefox or Chrome
Windows	JAWS (paid)	Chrome or Edge
Windows	Narrator (built in)	Edge
Mac and iPhone	VoiceOver (built in)	Safari
Android	TalkBack (built in)	Chrome

Then try this:

Listen to the page from the top. Does it make sense?
Open the headings list and the landmarks list. Is the outline sensible?
Complete your page's main task (sign up, search, check out) using only the screen reader and keyboard.
Cause an error and a success message. Are they announced?
Walk through your icons and images. Any noise, or missing names?

You will sound clumsy at first, and that is fine

Learn four or five commands: start and stop, next item, next heading, next link, and list of headings. Expert users move much faster than you will, so do not judge by your own pace. Use your testing to find missing names and broken structure, not to measure how fast someone can go.

Make a plan

Here is a starter test plan. Use it on any page you build:

Layer 3: Test with Real People

No checklist replaces watching a person use your product. Disabled and older users find things that tools and experts miss, because they live with the barriers every day.

Recruit a range: people who use screen readers, magnifiers, voice control, switch devices, captions, and people with cognitive differences.
Pay them for their time and expertise.
Give them real tasks, not a tour: "Find a recipe and save it."
Watch, do not rescue. Note where they struggle, but do not explain the page. If you have to explain it, that is the finding.
Ask for consent before recording anything, and explain what you will keep.
Keep the sessions short and kind.

If you cannot run formal sessions, offer a feedback route on your site (an email address or form) and a public accessibility statement that says what is supported and how to report a problem. Then answer the messages.

Reporting and Fixing Problems

A good bug report is easy to act on. Write down:

Where: the page and the part of the page.
What happened, and what you expected.
How to reproduce it, step by step, with the browser and assistive technology used (for example, "NVDA with Firefox").
Why it matters: who is blocked, and from what task.
The rule it breaks, if you know it (for example, a WCAG success criterion).
A suggested fix, if you have one.

Deciding what to fix first

Fix problems in this order, as a general guide:

Blockers: people cannot finish a key task at all (a keyboard trap, an unlabelled "Pay" button).
Major: people can finish, but with great difficulty or help.
Minor: annoying, but there is a workaround.
Polish: small improvements.

Also consider how many people hit the problem, and how central the page is.

Stop Problems Coming Back

A fixed bug can come back with the next release. To keep it fixed:

Run a linter in your editor, so common mistakes are caught as you type.
Add automated checks to your build or pull requests (axe-core, pa11y, or jest-axe).
Test components once, and reuse them. A well-tested button, dialog, and form field help every page.
Add a keyboard and screen reader pass to your "definition of done."
Re-test after big design changes, and after upgrading frameworks or libraries.
Train the team. Designers, writers, and developers all affect accessibility.
Track problems like any other bug, with an owner and a date.

Test early

The cheapest time to fix an accessibility problem is while you are designing it. Check sketches for contrast, focus, and labels before any code is written.

Standards and Reports

Teams often test against WCAG (usually 2.1 or 2.2, at level AA). You can write up the results in an accessibility conformance report (sometimes called a VPAT), and publish an accessibility statement. Requirements differ between countries, sectors, and contracts, so check what applies to you. This is not legal advice.

For more on levels and success criteria, see WCAG Basics.

Good Habits

Test as you build, not only at the end.
Start with a keyboard, and then add a screen reader.
Use at least one automated tool, and keep it in your build.
Fix the cause, not only the symptom: a bad component makes the same bug everywhere.
Test on real devices, especially phones.
Test with several browsers and assistive technologies.
Write down what you tested, with versions.
Listen to real users, and thank them.

Accessibility Checklist

Security and Privacy Notes

Do not paste private pages into online checkers. A page behind a login can contain personal data. Use local tools or a test account.
Use test data. Never test with real customers' records, and mask personal details in screenshots and recordings.
Check extension permissions. Browser extensions can read the pages you visit. Install testing tools only from trusted sources, and turn them off for sensitive sites.
Be careful with recordings. A recording of a screen reader session may capture names, emails, or messages. Get consent, store it safely, and delete it when you no longer need it.
Consent and fairness: compensate participants, explain how their data is used, and let them stop at any time.
Do not rely on "overlay" widgets that promise to fix accessibility automatically. Many do not work, and some collect user data. Fix the code instead.

Global Audience Notes

Test in each language you support. Labels, error messages, and live announcements need real translations, and the lang attribute must match.
Test right-to-left layouts, including focus order, icons, and zoom.
Test on common, modest devices and slow networks. An accessible page that never loads is not accessible.
Screen reader availability and popularity differ around the world. Ask your own users which tools they use.
Test with input methods used locally: on-screen keyboards, voice input, and IME typing for languages such as Japanese, Chinese, and Korean.
Check regional rules, as accessibility laws and standards differ by country.

Common Mistakes to Avoid

Trusting a score. A Lighthouse 100 is not proof of accessibility.
Only testing with a mouse.
Only testing one browser, one device, or one screen reader.
Testing once, at the very end, when fixes are most expensive.
Treating automated warnings as noise, or "fixing" them just to silence the tool.
Never listening to a screen reader.
Judging screen reader speed by your own beginner pace.
Skipping real users, or testing only with colleagues.
Using overlay "fix-it" widgets instead of fixing the code.
Not writing bugs down, so they are forgotten.
Fixing symptoms, not the shared component that causes them.
No accessibility statement and no feedback route.

Practice Time

Try these in your browser and your editor:

Run the mini page auditor on the messy page, fix every problem, and run it again.
Take the "what can a tool catch" quiz. Which answer surprised you?
Install axe DevTools or WAVE, and run it on a page you built.
Run Lighthouse on the same page. Compare what it finds with axe.
Do the five-minute keyboard test on your own site, and write down every problem.
Zoom to 400 percent. What breaks?
Turn on a screen reader and complete one task. What did you learn?
Write one bug report using the six points above.
Add eslint-plugin-jsx-a11y or pa11y to a project.
Bonus: ask a friend who uses assistive technology (with their consent and a fair reward) to try your main task, and watch without helping.

Quick Recap

Click a question to check your answer.

1. What are the three layers of accessibility testing?

Automated tools, manual testing (keyboard, zoom, screen reader), and testing with real people. You need all three.

2. What can automated tools find, and what can't they?

They find mechanical problems, such as missing alt text, missing labels, low contrast, and bad markup. They cannot judge whether a label is helpful, whether the focus order makes sense, or how usable the page really is.

3. What is the fastest useful manual test?

Put the mouse away and use the page with the keyboard alone, with visible focus, a logical order, and no traps.

4. Which zoom levels should you check?

Check 200 percent and 400 percent (or a 320 CSS pixel wide window), looking for cut-off text, overlapping, and sideways scrolling for ordinary text.

5. Why test with real people?

They find problems that tools and checklists miss, because they live with those barriers. It is the best way to learn what actually works.

6. How do you stop accessibility bugs coming back?

Add linters and automated checks to your build, reuse well-tested components, include keyboard and screen reader checks in your "definition of done," and track bugs like any others.

Key Takeaways

Test early, often, and in three layers: tools, hands-on checks, and real people.
Automated tools are fast but limited. A clean score is not proof.
The keyboard test finds the biggest problems in minutes.
Zoom, contrast, motion, and screen reader checks cover the rest of the basics.
Write clear bug reports, and fix the worst problems first.
Put checks into your build, so fixed bugs stay fixed.
Protect privacy when you test, and avoid "fix-it" overlays.
Listen to the people who use your site.

You have now finished the accessibility section. Go back to the section overview, and pick any lesson you want to revisit. Then take what you learned and test one of your own pages today.

What You Will Learn​

The Big Idea​

The Three Layers of Testing​

Layer 1: Automated Tools​

What they are good at​

What they cannot do​

A first automated test​

Layer 2: Manual Testing​

The keyboard test​

The zoom and reflow test​

The colour test​

The motion and media test​

The screen reader test​

Make a plan​

Layer 3: Test with Real People​

Reporting and Fixing Problems​

Deciding what to fix first​

Stop Problems Coming Back​

Standards and Reports​

Good Habits​

Accessibility Checklist​

Security and Privacy Notes​

Global Audience Notes​

Common Mistakes to Avoid​

Practice Time​

Quick Recap​

Key Takeaways​