Skip to main content
Accessibility.com, LLC
Category: Testing and Evaluation

Assistive Technology Testing

Also known as: AT Testing, Testing with Assistive Technology, AT-based accessibility testing
Simply put

Assistive technology testing is a way of checking whether a website, app, or digital document actually works for people who rely on tools like screen readers, screen magnifiers, or other assistive technology. Instead of only running automated scans, a tester uses the same technology a person with a disability would use to confirm the experience is usable. This kind of testing helps reveal problems that other methods may miss, though it is not required in every situation.

Formal definition

Assistive technology (AT) testing is the manual evaluation of a digital product or service using the same assistive technologies people with disabilities rely on, such as screen readers, screen magnification, voice control, or alternative input devices, to verify that the product can be operated and understood through those tools. It complements automated and other manual testing methods, since automated checks detect only a portion of accessibility issues and cannot confirm the real-world experience an AT user would have. AT testing is applied where standards conformance and usability need to be validated in practice; as some authorities note, it is not necessary in all cases, and conformance can sometimes be confirmed through other means without it. AT testing supports, but does not by itself guarantee, conformance with standards such as WCAG or legal compliance, and it should be combined with other evaluation techniques. This entry is informational and not legal advice.

Why it matters

Automated accessibility scans are valuable for catching certain categories of issues at scale, but they detect only a portion of the barriers a person with a disability may encounter. A page can pass automated checks and still be confusing or unusable when navigated with a screen reader, operated by voice, or viewed under high magnification. Assistive technology testing closes that gap by evaluating the product the way real users experience it, surfacing problems, such as unclear reading order, unlabeled controls, or focus that becomes trapped, that other methods may miss.

Because accessibility testing is fundamentally about confirming that people with disabilities can actually use a digital product or service, testing with the same tools those users rely on provides a more direct form of validation than inference from code alone. This helps teams verify not just that standards criteria appear to be satisfied, but that the resulting experience is operable and understandable in practice.

At the same time, AT testing is not required in every situation. Some authorities note that conformance with accessibility standards can often be confirmed without assistive technology, depending on the content and context. AT testing supports, but does not by itself guarantee, conformance with standards such as WCAG or legal compliance, and it is most effective when combined with automated and other manual techniques. This entry is informational and not legal advice; organizations with specific compliance questions should consult qualified legal counsel and current agency guidance.

Who it's relevant to

Accessibility engineers and QA testers
Practitioners responsible for evaluating digital products use AT testing to confirm that content and controls work with screen readers, magnification, voice control, and alternative input. It helps them find issues automated tools cannot detect and verify fixes against the actual user experience.
UX and product designers
Designers benefit from observing how their interfaces behave under assistive technology, which can reveal problems with reading order, labeling, focus, and interaction patterns that are not apparent from visual review alone.
Developers
Developers use AT testing to validate that the markup and code they produce translate into an operable and understandable experience for AT users, complementing automated checks that catch only a portion of issues.
Compliance officers and accessibility program managers
Those overseeing accessibility efforts rely on AT testing as part of a broader evaluation strategy to support conformance with standards such as WCAG. They should note that AT testing does not by itself guarantee conformance or legal compliance and is not required in every case.
Content authors and document producers
People creating digital documents and web content can use AT testing to confirm their material is accessible in practice, while recognizing that conformance can often be confirmed through other means when AT testing is not necessary.

Inside AT Testing

Screen Reader Testing
Evaluating content using screen readers such as JAWS, NVDA, and VoiceOver to verify that text, structure, labels, and interactive elements are announced accurately and in a logical order to users who are blind or have low vision.
Keyboard-Only Navigation
Testing that all functionality can be operated without a mouse, confirming logical focus order, visible focus indicators, and the absence of keyboard traps for users who rely on keyboards or keyboard-emulating assistive technology.
Screen Magnification Testing
Assessing how content behaves when magnified or zoomed, checking that reflow, readability, and functionality are preserved for users with low vision who rely on magnification tools.
Voice Control and Speech Input Testing
Verifying that voice recognition and speech input software can identify and activate controls, which often depends on accurate accessible names and visible labels.
Assistive Technology and Platform Combinations
Testing across representative pairings of assistive technology, browsers, and operating systems, since behavior can vary by combination rather than being identical across all environments.
Relationship to WCAG
Assistive technology testing helps confirm real-world outcomes for success criteria that automated tools cannot fully evaluate; it complements, rather than replaces, conformance checks against WCAG success criteria.

Common questions

Answers to the questions practitioners most commonly ask about AT Testing.

If our site passes automated accessibility checks, do we still need assistive technology testing?
Yes. Automated testing detects only a portion of accessibility issues and cannot fully evaluate how content behaves with assistive technologies. Manual testing with tools such as screen readers, screen magnifiers, and voice control software is generally needed to assess the actual user experience. Meeting WCAG success criteria or passing automated scans does not guarantee that all users can effectively use a product, nor does it guarantee immunity from legal claims.
Does successful assistive technology testing mean our product is legally compliant?
Not necessarily. Assistive technology testing supports conformance evaluation and improves usability, but it is distinct from legal compliance. In the US, obligations arise from authorities such as Title II or Title III of the ADA, Section 508, and Section 504 of the Rehabilitation Act, and requirements continue to evolve through regulation and case law. Testing results can demonstrate diligence, but they do not by themselves establish legal safety. This is not legal advice; consult qualified legal counsel for your specific situation.
Which assistive technologies should be included in a testing plan?
A representative plan commonly includes screen readers, screen magnification software, voice control or speech recognition tools, keyboard-only navigation, and alternative input devices. The specific mix often depends on your audience, platforms, and the technologies your users are likely to rely on. Because assistive technology behavior can vary across combinations of software and browsers, teams frequently test several commonly used pairings rather than a single configuration.
How does assistive technology testing relate to WCAG conformance evaluation?
Assistive technology testing is one method within a broader conformance and usability evaluation process. Many WCAG success criteria require manual or assistive technology verification to confirm that content is perceivable and operable in practice, for example, confirming that names, roles, and states are conveyed to a screen reader. Testing complements automated checks and manual inspection rather than replacing them, and results should be interpreted against the WCAG version and level you are targeting, most commonly AA.
Who should perform assistive technology testing?
Testing is often conducted by trained accessibility specialists and, where feasible, by people who use assistive technologies as part of their daily workflow. Experienced testers understand expected behaviors and can distinguish product issues from tool-specific quirks, while participants who rely on assistive technology can surface real-world usability problems. Combining both perspectives generally produces more reliable findings than either alone.
When in the development process should assistive technology testing occur?
Testing is generally most effective when performed iteratively rather than only at the end. Evaluating designs and components early, and re-testing after significant changes, can help identify issues before they become costly to fix. Ongoing testing is also useful because assistive technologies, browsers, and content change over time, so a product that tested well previously may need re-verification as those factors evolve.

Common misconceptions

Passing automated accessibility checks means assistive technology testing is unnecessary.
Automated testing detects only a portion of accessibility issues. Manual testing with assistive technology is generally needed to evaluate factors such as meaningful announcements, logical reading and focus order, and usable interactions that automated tools cannot reliably assess.
Testing with a single screen reader or one assistive technology is sufficient.
Behavior can differ across assistive technologies and their combinations with specific browsers and operating systems. Testing with a representative range of tools and platforms provides a more accurate picture of the user experience.
Successful assistive technology testing guarantees WCAG conformance and legal compliance.
Assistive technology testing supports better usability and helps evaluate certain success criteria, but it does not by itself establish full WCAG conformance or immunity from legal claims. Requirements evolve through regulation and case law, and this guidance is not legal advice.

Best practices

Combine assistive technology testing with automated and manual evaluation, recognizing that automated tools catch only a portion of issues.
Test with more than one screen reader (for example JAWS, NVDA, and VoiceOver) across representative browser and operating system combinations rather than relying on a single environment.
Include keyboard-only navigation checks for logical focus order, visible focus indicators, and the absence of keyboard traps.
Involve people who use assistive technology in their daily lives to capture real-world usability issues that testers may otherwise miss.
Document the specific assistive technology, browser, and operating system versions used so results are reproducible and comparable over time.
Consult qualified legal counsel and monitor current agency rulemaking and case law, since testing outcomes do not guarantee conformance or legal safety.