Don't Panic — Accessibility Testing and Auditing

Accessibility testing is how you find out whether a digital product can actually be perceived, operated, and understood by disabled people. An audit is the part that stops those observations becoming a haunted spreadsheet: it gives them a baseline, a scope, evidence, and a conclusion that says exactly what was checked.

The baseline is often WCAG 2.2 Level AA. That phrase is not a magic sticker for a footer. It names testable success criteria under four principles: perceivable, operable, understandable, and robust. The important trick is that conformance applies to full pages and complete processes. A checkout is not rescued because the cart behaved while the payment step quietly traps the keyboard.

The first useful idea is the control loop. Requirements define the target. Scope and sampling define what the conclusion can cover. Tests expose barriers. Evidence lets another person repeat the observation. Repair changes the product, and retesting checks the changed behavior. Without the boundaries, an audit report has the confidence of a weather forecast written on a napkin.

The second is that automation is a very good employee with a very small job description. It can repeatedly inspect implemented rules in a rendered state, which makes it valuable for regression checks. It cannot settle whether alternative text communicates an image's purpose, whether focus moves sensibly through a dialog, or whether someone can complete a task. “No violations found” means the executed rules found none in that state. It does not mean the product has achieved enlightenment.

The third is that interaction has states. A page before a menu opens, an error appears, or a dialog closes can be perfectly well behaved and still conceal the thing that breaks the task. Test keyboard paths, zoom and reflow, and the names, roles, values, and states exposed through assistive technology. Record the operating system, browser, settings, viewport, and input method, because behavior without an environment is difficult to revisit.

When a barrier appears, write a finding that a colleague can reproduce: where it happened, how to trigger it, what occurred, what should occur, which requirement applies, who is affected, and how to retest. Keep violations separate from needs-review results and tool failures. A changed line of code is not evidence that the barrier has gone away; observed behavior is.

For the working route, start with the Intro when the vocabulary is new. Use Slides to keep the audit loop and method layers in view. Keep the Cheatsheet nearby while recording a finding or planning a retest. Then use the Practice Reference for a bounded review that remains honest about what it did, and did not, examine.

Don't Panic — Accessibility Testing and Auditing

Relevant careers