Assistive Technologies

Assistive technologies are the software and hardware that people with disabilities use to navigate the web: screen readers, magnifiers, voice commands, braille displays, switches. They depend entirely on the quality of the HTML code to function correctly.

A blind user opens your site with NVDA. A quadriplegic user opens it with Dragon NaturallySpeaking and a switch. A visually impaired user opens it with ZoomText at 400%. Three people, three different tools, one thing in common: these tools don't see your design. They read your code.

#What the term covers

The WCAG 2.2 define an assistive technology as hardware or software that acts as a user agent, or that works with a standard browser, to provide functionality suited to the needs of people with disabilities.

In practical terms, here are the main categories:

  • Screen readers (NVDA, JAWS, VoiceOver, TalkBack). They parse the browser's accessibility tree and render the page in speech synthesis or braille.
  • Screen magnifiers (ZoomText, magnifier built into Windows or macOS). They enlarge a portion of the screen, sometimes combined with a screen reader.
  • Voice commands (Dragon NaturallySpeaking, Voice Control on macOS/iOS). The user navigates and dictates by voice.
  • Switches: physical buttons for people with severe mobility limitations, coupled with a scanning system that cycles through interactive elements.
  • Braille displays: tactile output devices that translate text into braille cells in real time.

According to the WHO, 2.5 billion people will need at least one assistive product by 2030. The latest WebAIM survey (2024, 1,539 respondents) shows that NVDA is now the most used screen reader (65.6%), ahead of JAWS (60.5%).

#The mistake most developers make

Testing a site's accessibility with a single screen reader and declaring it "good". Screen readers represent only part of assistive technologies. A button accessible to a screen reader can be unusable for someone using voice commands if the visible label doesn't match the accessible name. A form that works with NVDA can become unreadable at 400% zoom if the layout breaks.

The other classic confusion: a screen reader is not speech synthesis. Speech synthesis converts text into sound. A screen reader interprets the structure of the document (headings, lists, links, forms) and uses speech synthesis as its output channel. Without proper HTML structure, the screen reader has nothing to interpret, regardless of voice quality.

#In summary

Assistive technologies are diverse. Your code must work with all of them, not just with a screen reader. The recipe hasn't changed: semantic HTML, ARIA attributes when native elements aren't enough, and testing with multiple tools.

Back to glossary
Share this article

Learn more

Screen reader

A screen reader is software that converts screen content into speech synthesis or braille. It traverses the browser's accessibility tree, not the design, to convey page structure to blind or low-vision users.

Compatible with Assistive Technologies

Web content is compatible with assistive technologies when the browser correctly transmits its information (name, role, value, states) to screen readers, braille displays, and other assistive tools. Native HTML elements like <button> or <input> are automatically compatible. Generic elements like <div> are not, unless manual addition of WAI-ARIA attributes and keyboard behaviors.

ARIA

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that describe interface components to assistive technologies. A custom button, a tabbed system, a dynamic notification: when semantic HTML is not enough, ARIA adds the missing information. But an ARIA attribute without the corresponding behavior does more harm than good.