Accessibility testing
Accessibility testing is the evaluation of a website or application against the needs of people with disabilities: whether it can be operated by keyboard alone, read by a screen reader, understood with low vision or colour blindness, and used by someone who cannot rely on a mouse, sound or fine motor control. The usual benchmark is the Web Content Accessibility Guidelines published by the W3C.
The longer version
Accessibility testing has two layers. Automated scanners inspect the rendered page for defects a machine can detect: images with no text alternative, form fields with no label, text whose contrast against its background falls below the guideline's threshold, heading levels that skip. The second layer is manual: a tester navigates the whole flow by keyboard, then again with a screen reader, then at high zoom, and records every point where the flow stops or the announced content stops making sense. The manual layer is where the disabling defects live, because a page can pass every automated rule and still trap keyboard focus inside a modal.
The nearest confusion is with usability testing, which asks whether a typical user can complete a task comfortably. Accessibility asks whether a user with a particular impairment can complete it at all. A checkout that a sighted mouse user finds slightly awkward is a usability finding; a checkout whose payment button is a clickable div with no keyboard handler is an accessibility finding, and for a screen reader user the button does not exist. The two overlap in the fixes but not in the failures.
Teams run the scanner, fix the red rows and call the product accessible. Then a custom dropdown built from divs announces nothing, a carousel cannot be paused, an error message appears in red with no text change, and the site fails a user it was declared to pass. The other failure is timing: accessibility tested only at the end forces retrofits on components that should have been built accessible, which is why teams that take it seriously put the keyboard and screen-reader pass into the definition of done for every component.
Common questions
What is the difference between automated and manual accessibility testing?
Automated tools scan the rendered page for machine-detectable defects such as missing alt text, unlabelled fields and low contrast, and they run on every build. Manual testing has a person operate the flow by keyboard and with a screen reader to find what the scanner cannot judge: focus order, announced names, whether the flow can be completed. Both are needed.
Who is responsible for accessibility testing?
Everybody who ships the page, in the same way that everybody is responsible for functional correctness. Designers own contrast and focus states, developers own semantic markup and keyboard handling, QA owns the assistive-technology pass, and product owns whether accessibility is in the acceptance criteria. A single accessibility specialist audits; they cannot substitute for the rest.
What standard is accessibility testing measured against?
The Web Content Accessibility Guidelines, published by the W3C, are the benchmark that accessibility law and procurement requirements cite. They group success criteria into three conformance levels, A, AA and AAA, and a test plan names the level it is testing to, because a page can conform at one level and fail the next.
When should accessibility testing be done?
At the component level as each one is built, and again on the assembled flow before release. A button, a dropdown or a modal tested by keyboard and screen reader on the day it is written costs little to fix; the same defect found in an audit after launch means retrofitting every page that uses the component. Automated scans run on every build; the manual pass runs whenever a flow changes.
What tools are used for accessibility testing?
An automated scanner that inspects the rendered page against the guideline's machine-checkable rules, a contrast checker for colour, a keyboard with the mouse unplugged, at least one screen reader on desktop and one on mobile, and the browser's zoom and reduced-motion settings. The screen reader is the tool that matters most and the one teams most often skip, because using one well takes practice.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.