Assistive Technology (AT): Definition, Types, Web Examples

What is assistive technology (AT)?

Assistive technology is any hardware or software that helps a person with a disability do something they could not otherwise do, such as using a website. On the web it includes screen readers, screen magnifiers, voice control, switch devices, braille displays, eye trackers and captioning tools. Accessible sites are built so these tools can read, announce and operate every part of the page.

The WHO estimates that 1.3 billion people, about 16% of the world's population, live with significant disability. Standards such as WCAG and ARIA exist so that assistive technology has something reliable to work with.

Common types of assistive technology

Screen readers

A screen reader turns on-screen content into speech or braille. MDN lists JAWS as a commercial product for Windows, NVDA (Windows), ChromeVox and Orca (Linux) as free, and VoiceOver (macOS and iOS), ChromeVox on Chromebooks and TalkBack (Android) as built in. NV Access describes NVDA as free and open source. In the WebAIM Screen Reader User Survey #11 (July to August 2026, 1,780 valid responses), respondents named JAWS (55.0%), NVDA (32.9%) and VoiceOver (6.5%) as their primary desktop screen reader. Respondents are a self-selected group, so treat the figures as a guide, not as market share.

How assistive technology reads the web

Assistive technology does not read pixels. The browser builds an accessibility tree from the page markup and exposes it through platform accessibility APIs. The tree holds each element's role, name and state. A screen reader announces from it, voice control matches spoken names to it, and a switch device steps through its focusable items. If the markup says nothing about what an element is, the tree is empty of meaning and the tool has nothing to report.

Example: a button that is invisible to assistive technology

A developer builds a "Buy now" control as <div class="btn" onclick="buy()">Buy now</div>. Sighted mouse users see a button. A keyboard user cannot tab to it, a screen reader announces plain text and no "button", and a voice user who says "click Buy now" may get nothing. Replacing it with <button type="button">Buy now</button> gives it a role, a name, keyboard focus and Enter and Space activation with no extra code.

What developers should do

• Use semantic HTML first: buttons, links, headings, lists, landmarks, labelled form fields.
• Add ARIA only where HTML cannot express the pattern, such as tabs or a custom combobox, and follow the documented keyboard behaviour.
• Give every image and media item a text alternative.
• Keep focus visible and in a logical keyboard navigation order. Never remove the outline without a clear replacement.
• Manage focus in dynamic UI. When a dialog opens, move focus into it, and return it on close.
• Announce changes that happen without a page load, such as route changes in a single page app, with a live region or a focus move.

Common mistakes

• Building widgets from <div> elements with click handlers only.
• Hover-only menus and drag-and-drop with no keyboard alternative.
• Removing focus outlines.
• Empty or missing alt text on meaningful images, or vague link text such as "click here".
• Autoplaying audio that talks over a screen reader.
• CAPTCHAs that rely on an image alone.
• Trusting an automated score as proof that the site works with assistive technology.

Testing with assistive technology

Automated tools such as Lighthouse and axe catch a part of the issues, mostly missing labels, contrast and invalid ARIA. They cannot judge whether a screen reader user can finish a task. Combine them with a keyboard-only pass, a screen reader pass (NVDA with Firefox or Chrome on Windows, VoiceOver on a Mac or iPhone), a 200% zoom check, and where possible sessions with people who use assistive technology.

LoadFocus page speed monitoring runs scheduled Lighthouse audits from 25 cloud regions, and accessibility is one of the Lighthouse categories each audit captures, so regressions in the automated checks show up between releases. It is a safety net, not a replacement for manual testing. For where performance and accessibility meet, read why performance testing should include accessibility, and for tool options see website accessibility testing tools.

FAQ: assistive technology

Is a screen reader the only assistive technology for the web?

No. Screen readers are the best known, but magnifiers, voice control, switch devices, braille displays, captions and reader modes are all in use. Many people use more than one tool.

Which screen reader should I test with?

NVDA is free and runs on Windows, which makes it the usual starting point. Add VoiceOver for Apple devices and TalkBack for Android if your audience uses them. Results differ between combinations of screen reader and browser, so test the ones your visitors use.

Do I need ARIA to support assistive technology?

Not for most pages. Native HTML elements already expose the right role, name and state. ARIA fills the gaps for custom widgets, and wrong ARIA can make things worse than none.

Can automated tests tell me my site works with assistive technology?

No. They find a subset of problems that can be detected from the markup. Whether the reading order, focus behaviour and announcements make sense needs manual checks.

Are there legal requirements for supporting assistive technology?

Many countries have accessibility laws or procurement rules that refer to WCAG, but the details differ by country and sector. Check the rules that apply to you with your legal team.