Assistive Technology Compatibility is the discipline of building interfaces that work correctly with the tools people actually use to operate software: screen readers (NVDA, JAWS, VoiceOver, TalkBack), switch access, voice control, and screen magnification. Compatibility is not assumed from passing an automated scan; it is verified by using the right markup and then testing with the real assistive technology. An interface is accessible to a screen-reader user only when a screen-reader user can actually complete the task.
The mistake is to build custom widgets out of generic elements and sprinkle ARIA on top to "make them accessible." This usually makes things worse. The first rule of ARIA, from the W3C, is to prefer a native HTML element with the semantics and behavior you need over re-purposing a div with an ARIA role, because native elements bring keyboard behavior and AT support for free, while ARIA declares semantics but adds no keyboard behavior at all. The community shorthand is blunt and correct: no ARIA is better than bad ARIA.
So the work is layered. Use semantic HTML first. When a native element cannot do the job, follow an established pattern from the ARIA Authoring Practices Guide, with its required roles, states, and keyboard model. Ensure every interactive control is fully keyboard operable. Then verify with the assistive technology real users rely on, because automated checks catch only part of what matters.
The principle: build for the assistive technology people actually use. Prefer semantic HTML, use ARIA correctly and sparingly, guarantee keyboard operability, and verify by testing with real screen readers and other AT.
Assistive Technology Compatibility rests on usage data, an authoritative pattern library, and the limits of automation.
The usage data tells you what to build for. WebAIM's Screen Reader User Survey #10 (1,539 responses, collected December 2023 to January 2024) found primary desktop screen-reader use split mainly across JAWS (40.5 percent), NVDA (37.7 percent), and VoiceOver (9.7 percent), with JAWS and NVDA now nearly even. On mobile, VoiceOver leads at 70.6 percent and TalkBack at 34.7 percent. Critically, 71.6 percent of respondents use more than one desktop screen reader, and 43 percent use three or more. The practical implication is a testing matrix, not a single tool: you cannot verify compatibility against one screen reader and assume the rest.
The pattern library tells you how to build. The W3C ARIA Authoring Practices Guide (APG) is the definitive reference for accessible widgets, providing reference implementations for dialogs, tabs, accordions, comboboxes, menus, tree views, and more, each with the required ARIA roles and states and a defined keyboard interaction model. But the APG sits underneath a stricter rule set. The W3C Using ARIA document defines the rules of ARIA use, the first of which is to prefer native HTML, and it is explicit that ARIA controls must be fully keyboard operable because ARIA does not add keyboard behavior. Misused ARIA produces a worse experience than no ARIA, which is why semantic HTML is the default and custom widgets are the exception.
The limits of automation tell you how to verify. Google's web.dev accessibility guidance is direct that testing with assistive technology reveals problems automated tools cannot detect, and that AT testing and asking users about their experience "often yields different results." Both are needed. Automated checks are necessary for catching regressions at scale, but they cannot tell you whether a screen-reader user can actually understand and complete a flow. Only testing with the real AT, and ideally with real users, answers that.
For Users: When a product is built for the assistive technology you actually use, you can complete tasks with your screen reader, switch, or voice control instead of hitting a wall the automated scan never saw.
For Designers: Compatibility starts in design: specify semantics, reading order, names, and states so they survive into the build. A component designed as a real control, not a styled div, is far more likely to work with AT.
For Developers: This is largely yours. Reach for native HTML first, follow APG patterns when you must build custom, guarantee keyboard operability, and never put aria-hidden or role=presentation on a focusable element. Then test with NVDA, JAWS, and VoiceOver, not just a linter.
For Accessibility: Compatibility is the difference between compliant and usable. A page can pass automated checks and still be impossible to operate with a screen reader. Verification with real AT is the only proof.
Assistive Technology Compatibility comes down to native-first markup, correct ARIA, keyboard operability, and real verification.
Use semantic HTML first. A button, a link, a checkbox, a select, and proper headings and landmarks bring keyboard behavior and AT semantics built in. This removes whole classes of defects before they exist.
Use ARIA only when native cannot, and follow the APG. When you must build a custom widget, implement an established APG pattern with its required roles, states, and keyboard model. Do not invent ARIA; misused ARIA is worse than none.
Guarantee keyboard operability. Every control reachable by mouse or touch must be operable by keyboard, with visible focus and a logical focus order. ARIA declares semantics but adds no keyboard behavior, so you must implement it.
Build a testing matrix from real usage. Test the screen readers people actually use, NVDA and JAWS with their common browsers on Windows, VoiceOver on Apple, plus VoiceOver and TalkBack on mobile. One screen reader is not enough.
Verify with AT, not just automation. Run automated checks for regressions, then manually test with screen readers, and where possible with assistive-technology users, to catch the barriers automation cannot see.