What Is Accessibility Testing?

Accessibility testing is the practice of checking whether a website, app, or digital product can be used by people with disabilities, including those who rely on screen readers, keyboard-only navigation, voice control, or assistive input devices. It covers things like whether images have alt text, whether color contrast is high enough to read, whether every interactive element can be reached without a mouse, and whether a screen reader announces content in a sensible order. It applies to web pages, native mobile apps, PDFs, and increasingly to software with voice or gesture interfaces. Teams run it manually, with automated scanning tools, or both, depending on how much confidence they need, and mature organizations tend to layer all three approaches rather than picking just one.

The reason accessibility testing exists is that most software is built by people who don't use assistive technology, and inaccessible design tends to happen by default rather than by intent. A developer who can see color differences won't notice a low-contrast button. A designer who uses a mouse won't notice a form that traps keyboard focus. Without a deliberate check, these gaps ship to production and quietly exclude a meaningful share of users, some of whom simply leave and never say why. Accessibility testing exists to catch what normal QA and normal usage patterns miss, because the people running normal QA usually share the same unconscious assumptions as the people who built the product in the first place.

What distinguishes accessibility testing from general QA is that it tests against a specific, external standard rather than internal expectations. The most common reference is the Web Content Accessibility Guidelines (WCAG), which lays out testable success criteria at three conformance levels: A, AA, and AAA. Most legal and organizational requirements target AA. Testing against WCAG means checking concrete, verifiable things, contrast ratios, focus order, ARIA labeling, form error handling, rather than subjective impressions of usability. That's what lets teams call a page "compliant" or "not compliant" instead of just "better" or "worse," and it's what lets two different testers, working independently, arrive at the same conclusion about the same page.

By 2026, accessibility testing has moved from a nice-to-have to a standard line item in release checklists, driven by a mix of legal exposure (lawsuits and demand letters over inaccessible websites have become routine in several markets), procurement requirements (large enterprises and government agencies now ask vendors for accessibility conformance reports before signing contracts), and a genuine broadening of who tests: aging populations, temporary impairments, and situational limitations like using a phone one-handed in bright sunlight all benefit from the same fixes. Automated scanners have also gotten better and cheaper, which means catching the easy 30 to 40 percent of issues no longer requires specialized headcount. What used to be a specialized, expensive consulting engagement is now something a mid-sized engineering team can build into its own pipeline with an afternoon of setup work.

This page covers what accessibility testing actually checks, how manual and automated methods differ, where it fits in a build pipeline, and what a team needs to do it well rather than perform it superficially. Strip away the tooling and the compliance talk, and the idea holds up on its own: usability isn't one-size-fits-all, and testing against a real, documented standard is the only way to know whether a product actually works for people who don't interact with it the way you do. That distinction is what lets a team stop treating accessibility as a legal checkbox and start treating it as a quality attribute they can actually measure, track over time, and improve the same way they'd track performance or defect rates.

• Accessibility testing checks whether people relying on screen readers, keyboards, or other assistive technology can actually use the software. Looking fine visually is a different question entirely.
• WCAG (usually level AA) is the standard most testing is measured against, which makes results verifiable rather than opinion-based.
• Automated scanners catch a meaningful chunk of issues quickly and cheaply, but they cannot detect everything, especially problems with logical flow, meaning, or context.
• Manual testing with real assistive technology, particularly screen readers and keyboard-only navigation, is required to catch what scanners miss.
• Skipping accessibility testing carries legal risk, shuts out real users, and increasingly disqualifies a vendor from enterprise and government contracts.

Accessibility testing looks at a defined set of concerns rather than a vague sense of "is this usable." Visual issues include color contrast ratios between text and background, text resizing without breaking layout, and whether information is conveyed only through color (a red border alone to mark an error field fails, for instance, because someone with color blindness won't see it). Structural issues include whether headings are used in a logical order, whether tables have proper row and column labels, and whether the reading order announced to a screen reader matches the visual order a sighted user sees. A page can look perfectly fine to a sighted tester clicking through it and still fail every one of these checks, which is exactly why testing needs to be deliberate rather than incidental.

Interaction issues are usually where the real problems live. Can every action a mouse user can take also be done with a keyboard alone, using tab, enter, and arrow keys? Is there a visible focus indicator so a keyboard user can tell where they are on the page? Do custom components, like a dropdown built from styled divs instead of a native select element, announce their role, state, and value to a screen reader? These are the things that break silently, because they still look correct to someone testing with a mouse and their eyes. A modal window that opens but doesn't trap focus inside it, for example, lets a keyboard user tab straight through to content hidden behind it, and nobody notices unless they specifically test for it.

Content and forms get their own category of checks. Every form field needs a programmatically associated label, not just placeholder text that disappears once someone starts typing. Error messages need to be announced to assistive technology when they appear, not just displayed in red text near the field. Images need alt text that describes their function or content, and decorative images need to be marked as such so screen readers skip them instead of reading out meaningless file names. Instructions like "fields marked with an asterisk are required" also need to be tied to the actual fields programmatically, since a sighted user connects the asterisk to the field visually but a screen reader user needs that relationship spelled out in code.

Media and dynamic content round out the list. Videos need captions and, in some cases, audio description. Content that updates without a page reload, like a live chat window or a stock ticker, needs to be announced through ARIA live regions so screen reader users know something changed. Timed interactions, like a session that logs a user out after five minutes, need a way to extend the time or be warned before it happens. Each of these maps to a specific, testable WCAG success criterion, which is what makes the difference between "this feels accessible" and "this passed a real test." Teams that treat these as a checklist rather than a set of judgment calls tend to get more consistent, defensible results across a large product.

Automated accessibility tools work by scanning rendered HTML and flagging patterns that violate known rules: missing alt attributes, insufficient contrast ratios, missing form labels, invalid ARIA attributes, and similar structural problems. They run fast, they can be wired into a CI pipeline to catch regressions on every pull request, and they're good at catching the same small set of mistakes over and over across a large codebase. Most estimates put their coverage at somewhere around a third to just under half of all WCAG success criteria, because a machine can check for the presence of an attribute but can't judge whether that attribute's content is actually meaningful. That still makes automated scanning worth running constantly, since it's cheap enough to run on every commit and catches the same repeat mistakes before they multiply across dozens of pages.

That coverage gap is exactly why manual testing exists as a second layer. A scanner can confirm an image has alt text; it cannot tell you the alt text says "image1234.jpg" instead of describing what's in the picture. A scanner can confirm a button has an accessible name; it cannot tell you the accessible name is confusing or that the button does something different from what it announces. Manual testing means a person, ideally someone experienced with a screen reader like NVDA, JAWS, or VoiceOver, actually navigates the interface using only the keyboard and their ears, and evaluates whether the experience makes sense. This kind of testing takes real judgment, since the tester has to decide whether a confusing but technically compliant experience still counts as passing.

There's a third layer worth naming separately: testing with actual disabled users. Internal testers who are experienced with assistive technology but don't have a disability themselves will still miss things that only show up when someone who depends on the technology daily tries to get something done. This is the most expensive and least common form of testing, but it catches issues no scanner or trained non-disabled tester will find, particularly around cognitive load, task completion time, and whether a workaround exists but is impractical. Recruiting this kind of tester takes more lead time than the other two layers, which is part of why it happens less often, but the feedback it produces tends to carry more weight with product and leadership teams than a scanner report ever will.

In practice, most mature teams run all three layers at different frequencies. Automated scans run on every build because they're cheap and fast. Manual keyboard and screen reader testing happens on new features or significant UI changes, since it takes real time per page or flow. User testing with people who have disabilities happens periodically, often once or twice a year or before a major redesign, because it requires recruiting and is the most resource-intensive. Treating these as separate layers with separate cadences, instead of picking just one, is what actually produces reliable results, and it also means a budget conversation about accessibility can be broken into concrete pieces instead of one vague, hard-to-estimate line item.

The legal argument for accessibility testing has gotten sharper over the last several years. Demand letters and lawsuits over inaccessible websites have become a routine cost of doing business in some markets, and they don't only target large companies; small and mid-sized businesses with a public-facing site get targeted too, often through a wave of similar letters from the same law firms. A company that can point to an ongoing testing program and a documented remediation plan is in a materially better position than one that has never looked at the issue, even if neither company is perfectly conformant.

The procurement argument is newer but growing faster. Large enterprises and government agencies increasingly require an accessibility conformance report, often a Voluntary Product Accessibility Template or an equivalent, before they'll sign a contract with a software vendor. This isn't a formality that gets rubber-stamped; procurement and legal teams read these reports, and gaps in them can stall or kill a deal that took months to build. For a vendor selling into enterprise or public-sector accounts, having a current, honest conformance report is close to a sales requirement now, not a nice-to-have.

The reach argument is the one that gets less attention but shows up directly in revenue numbers. People with disabilities represent a meaningful share of any large population, and an inaccessible checkout flow or signup form doesn't just annoy them, it often blocks the transaction entirely. Add in the much larger group of people with situational or temporary limitations, a broken arm, a bright screen in sunlight, a slow connection that breaks a JavaScript-heavy interaction, and the practical audience affected by accessibility problems is far bigger than the number of people with a permanent disability.

There's also a trust dimension that's harder to quantify but real. Customers and employees notice when a product clearly wasn't built with them in mind, and word travels, particularly within communities that rely on assistive technology and talk to each other about which products work and which don't. A company that tests for accessibility and fixes what it finds builds a reputation that compounds quietly over time, the same way a company that ignores it builds the opposite kind of reputation.

Accessibility testing fits naturally into any product with a real user-facing interface: public websites, customer portals, internal enterprise tools, mobile apps, and government or education systems where legal obligations are often explicit. It's especially important for anything a broad, unpredictable public will use, since there's no way to know in advance who's going to hit that "submit" button with a screen reader running. It also matters more than people expect for internal tools, since companies are legally required to accommodate employees with disabilities, and an inaccessible internal system can become a real employment issue. Software vendors selling to enterprise and government buyers now routinely get asked for a formal accessibility conformance report as part of procurement, which means the testing has to happen regardless of whether the vendor's own leadership sees it as a priority.

It fits less cleanly, though still matters, in fast-moving prototype and internal-only tooling contexts where the audience is small, known, and doesn't currently include anyone using assistive technology. That's not a reason to skip it forever, but it is a reasonable argument for sequencing: get the product validated first, then build in the accessibility work before it goes to a wider audience, rather than gold-plating a prototype that might get thrown away. The mistake teams make here isn't deprioritizing accessibility for throwaway work, it's assuming "we'll add it later" and then never revisiting it once the throwaway prototype becomes the production system, which happens constantly. A better pattern is to set an explicit trigger, a certain number of users, a funding round, a move from internal beta to public launch, that forces the accessibility conversation instead of letting it slip indefinitely.

Accessibility testing is not a substitute for accessible design decisions made upfront. A test suite can tell you a color combination fails contrast requirements, but it can't fix your color palette for you, and finding these problems late, after a design system is locked in and used across two hundred screens, is far more expensive than catching them during design review. Testing is a verification step, not a design process, and treating it as the only accessibility activity in a project guarantees expensive rework. Teams that get this right build accessibility requirements into their design system components once, at the source, so every screen that uses that button or that form field inherits the fix automatically.

It also doesn't replace legal review for organizations with specific regulatory exposure, like those covered by Section 508 in the US public sector or the European Accessibility Act. WCAG conformance is the technical backbone those laws point to, but the legal requirements sometimes add specifics, like required documentation formats or specific reporting templates, that a standard WCAG test won't produce on its own. Teams operating under those obligations need both the technical testing and a legal or compliance read of what's required, since a technically passing test suite doesn't automatically satisfy every procedural requirement a specific regulation might impose.

The realistic starting point is automated scanning wired into the existing pipeline, using a tool like axe-core, Lighthouse, or a comparable scanner, set to fail a build on new critical violations while not blocking on the backlog of existing ones. This gets a team real signal within days rather than months, and it stops the bleeding: no new accessibility debt gets added while the team figures out what to do about the old debt. Trying to fix everything before shipping anything is the most common way accessibility initiatives stall out before they start, because the backlog of existing issues on a mature product can look overwhelming enough that nobody wants to own the first step.

Next, pick a small number of critical user flows, checkout, signup, the core task the product exists to perform, and do manual keyboard and screen reader passes on those specifically, rather than trying to audit the entire site at once. This targets effort where it has the most business impact: a broken accessibility experience on the signup flow costs real conversions and real legal exposure, while a minor issue on a rarely visited terms-of-service page carries much less weight. Prioritizing by traffic and business criticality, not just by severity score, keeps the effort proportional to the payoff, and it gives leadership an easy way to see progress on the flows that actually matter to revenue.

Build accessibility checks into the definition of done for new features, not as a separate audit that happens after launch. A designer checking contrast ratios in Figma before handoff, and a developer running a quick keyboard-only pass before opening a pull request, catches problems when they're cheap to fix, a five-minute CSS change instead of a multi-sprint retrofit. This requires some training investment upfront, since most designers and developers have never used a screen reader and don't know what "good" looks like, but that training pays for itself quickly once people internalize the patterns, and it tends to change how people design and build even outside of any formal accessibility review.

Finally, get an outside accessibility audit periodically, even if the internal program is solid, because outside auditors catch blind spots that build up when the same team checks the same product repeatedly. This doesn't need to happen every sprint. Annually, or before a major release or redesign, is usually enough for most organizations, and it also produces the kind of documentation, a conformance report, that procurement and legal teams increasingly ask for before signing contracts. Keeping that report current, rather than letting it go stale for a few years, is often what closes the deal when a large customer's legal team asks for proof before signing.

• Run automated scans on every build, but treat a clean scan as a starting point, not proof of accessibility.
• Test critical flows, checkout, signup, core tasks, with an actual screen reader and keyboard-only navigation. A scanner alone won't catch what these flows need.
• Fix issues at the design and component level so the correction propagates everywhere that component is used, instead of patching one page at a time.
• Include accessibility in code review and design review, not as a separate audit bolted onto the end of a project.
• Document what was tested, what standard it was tested against, and what remains open, and track those numbers over time by severity the same way defect counts or performance metrics get tracked, so progress is visible and defensible rather than a one-off audit score nobody revisits.

• "Our automated scan came back clean, so we're accessible." Scanners catch roughly a third to half of known issues; a clean scan means fewer obvious problems, not full conformance.
• "Accessibility is only about blind users and screen readers." It also covers motor impairments, low vision, hearing loss, and cognitive disabilities, each with different needs.
• "It's a legal checkbox we do once and forget." New features and content constantly introduce new issues, so testing needs to be ongoing, not a one-time project.
• "Accessible design looks worse or more boring." Good accessible design is usually just good design: clear contrast, logical structure, and predictable interaction patterns benefit everyone.
• "This only matters for public-facing consumer products." Internal tools, enterprise software, and government systems carry the same obligations and the same real user impact.