Accessibility Testing Explained: A Beginner-Friendly Guide

Accessibility in plain words

A building with a step at the entrance works perfectly — unless you use a wheelchair. Nothing is broken; the design simply assumed one kind of body. Software does the same thing constantly. A menu that only opens on hover assumes a mouse. An error shown only in red assumes colour vision. A form label that vanishes as soon as you type assumes memory and good eyesight.

Accessibility testing is the practice of looking for those steps at the entrance, on purpose, before people hit them.

Why it matters

Roughly one in six people worldwide lives with a significant disability, and the number grows with an ageing population. Beyond that, accessibility work helps everyone: captions in a noisy room, larger text on a bright day, keyboard shortcuts for power users. Many countries also make digital accessibility a legal requirement for public bodies and, increasingly, private companies.

Key terms, made simple

What WCAG is

WCAG — the Web Content Accessibility Guidelines — organises testable requirements under four ideas: content should be perceivable (you can take it in), operable (you can use it), understandable (it makes sense), and robust (it works with assistive technology). Requirements come at three levels, A, AA, and AAA. Most organisations target AA. Your project should state which version and level it aims for, because "accessible" on its own is not a testable claim.

Four checks you can run today

1. Put the mouse down. Press Tab repeatedly. Can you reach every control, in a sensible order, and can you always see where you are?
2. Zoom to 200%. Does content reflow and stay readable, or does it overlap and get cut off?
3. Break a form on purpose. Submit it empty. Does the error name the field and say how to fix it — and is that message reachable without a mouse?
4. Run an automated checker such as axe in your browser's developer tools, then read each result rather than just the score.

When you are ready for the fifth check, learn four screen-reader commands and listen to one critical journey. It changes how you look at every interface afterwards.

What tools miss

Example: a registration form

Check that every field has a label that stays visible while typing, that required fields are explained before submission rather than after, that errors identify both the field and the correction, that focus moves somewhere sensible after a failed submit, that status messages are announced rather than only shown, and that the whole thing still works at large text sizes. Test a complete failure and recovery — not individual controls in isolation.

Your first week

1. Agree the target: WCAG 2.2 level AA is the common choice. Write it down.
2. Pick your single most important journey — signup, checkout, or search.
3. Run the four checks above on that journey and log what you find.
4. Add an automated accessibility check to one existing automated test, so regressions get caught for free.
5. Fix the issues in shared components first; that fixes many screens at once.
6. Book thirty minutes to watch someone use a screen reader, in person or via a recorded session.

How to report a barrier so it gets fixed

• Lead with the human impact: which task becomes impossible, and for whom.
• Record the page, browser, assistive technology, and versions.
• Give short reproduction steps and what actually happened.
• Describe the expected accessible behaviour concretely.
• Reference the specific WCAG criterion when you have confirmed it.
• Attach focused evidence, with no personal data in the screenshots.

Common mistakes

• Treating an automated score as a pass mark
• Testing individual controls but never a complete task
• Adding ARIA where plain HTML would already have worked
• Removing focus outlines because they look untidy
• Using placeholder text as the only label
• Assuming one screen reader represents every user

Key takeaways

• Accessibility testing looks for barriers in real tasks, not violations in isolation.
• WCAG gives you testable criteria; judgment is still required.
• Automated tools are a starting point covering a minority of real issues.
• Keyboard, zoom, contrast, and screen-reader checks are free and immediately useful.
• Report impact, not just rule numbers — that is what gets things prioritised.

Frequently asked questions