Accessibility testing
Accessibility testing asks concrete, checkable questions. Can a screen reader user understand and operate every interactive element on the page. Can someone navigate the entire interface using only a keyboard, with no reliance on a mouse. Is there enough color contrast for someone with low vision to actually read the text. Do images carry meaningful alt text, and does a form error get announced in a way assistive technology can pick up. It's less about whether an interface looks accessible and more about whether it's genuinely operable without sight, without a mouse, or with an assistive device standing in for either.
Most teams measure against the Web Content Accessibility Guidelines, known as WCAG, which is organized into levels, A, AA, and AAA. Level AA is the one most organizations target, and often the one effectively required by law, like the ADA in the US or the European Accessibility Act, for a public-facing site. The guidelines describe concrete, testable criteria, specific contrast ratios, keyboard operability, ARIA labeling, rather than vague principles that are left open to interpretation.
A meaningful share of issues can be caught automatically, missing alt text, insufficient contrast, missing form labels, using a scanning tool as part of a build. But automated scanning only catches a portion of what actually matters. Whether a screen reader announces content in a genuinely usable order, or whether a keyboard trap exists that technically passes an automated check, generally needs a person testing manually, sometimes someone who actually relies on assistive technology day to day.
What gets checked
- Whether every interactive element is operable using only a keyboard, with no reliance on a mouse.
- Whether a screen reader can understand and announce the interface in a sensible order.
- Whether color contrast meets a minimum ratio for people with low vision or color blindness.
- Whether images have meaningful alt text, and form fields have clear, programmatically associated labels.
- Whether an error or a status change gets announced to assistive technology, not just shown visually.
Where it shows up
- Automated scanning integrated into a CI/CD pipeline, catching missing alt text or insufficient contrast on every build.
- Manual testing with a screen reader, walking through a critical flow like checkout the way an actual user would.
- A legal or compliance requirement, like the ADA or the European Accessibility Act, that a public-facing site has to meet.
- A redesign audit, checking that a visual refresh didn't quietly break keyboard navigation or contrast that used to pass.
Benefits and challenges
| Benefit | Challenge |
|---|---|
| Makes an application usable by a meaningfully larger audience, not just the subset everyone happens to design for by default. | Automated scanning only catches a portion of real issues, a lot of what actually matters needs a person testing manually. |
| Reduces real legal and compliance risk in jurisdictions where accessibility is a legal requirement, not just a best practice. | Retrofitting accessibility into an application built without it in mind is far more work than designing for it from the start. |
| Concrete, testable standards, like WCAG's contrast ratios, give a clear target instead of a vague sense of accessible enough. | Passing an automated scan doesn't guarantee genuine usability, a page can be technically compliant and still frustrating to actually navigate. |
Frequently asked questions
What is WCAG, and what level should a site aim for?
WCAG, the Web Content Accessibility Guidelines, is the standard most accessibility testing measures against, organized into levels A, AA, and AAA. Level AA is the most common target, and the one most legal requirements, like the ADA in the US, effectively expect.
Can accessibility testing be fully automated?
No. Automated tools catch a meaningful share of issues, missing alt text, poor contrast, missing labels, but things like whether a screen reader announces content in a genuinely sensible order still need a person testing manually, sometimes someone who actually relies on assistive technology day to day.
Is accessibility testing only relevant for public-sector or regulated sites?
No, though those sites often have the clearest legal obligation to do it. Any application with real users benefits from being usable by people with disabilities, and the same fixes, better contrast, clearer labels, sensible keyboard navigation, tend to improve usability for everyone, not just users of assistive technology.
How Klarent helps
Klarent's AI agents can check core accessibility criteria, like keyboard operability and proper labeling, as part of testing a user flow, alongside functional checks rather than as a separate, disconnected audit.