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

Assistive technology (AT) helps people with disabilities access the web — screen readers, switch devices, voice control, magnifiers.

What is assistive technology (AT)?

Assistive technology (AT) is hardware or software that enables people with disabilities to perform tasks they otherwise couldn't — including using the web. The term covers a wide range: screen readers for blind users, screen magnifiers for low-vision users, switch devices for motor impairment, voice control for hands-free operation, alternative keyboards, eye trackers, and cognitive aids.

For web developers, AT is the "why" behind accessibility standards. WCAG, ARIA, and semantic HTML all exist to make sure assistive technologies can interpret and present web content correctly. A site that ignores AT excludes ~15-20% of users (per WHO disability prevalence data).

Categories of assistive technology

Disability area	Common AT
Vision (blind)	Screen readers (NVDA, JAWS, VoiceOver, TalkBack), Braille displays
Vision (low)	Screen magnifiers (ZoomText, macOS Zoom), high-contrast modes
Hearing	Captions, transcripts, sign-language video
Motor	Switch devices, head pointers, voice control (Dragon, Voice Control), eye trackers
Cognitive	Read-aloud tools, simplified UI modes, memory aids
Speech	Text-to-speech (TTS), AAC devices
Mixed/multiple	Combinations of the above

Major screen readers

Tool	Platform	Cost
NVDA	Windows	Free, open-source
JAWS	Windows	Commercial (~$1,000)
VoiceOver	macOS, iOS	Built-in
TalkBack	Android	Built-in
Narrator	Windows	Built-in
Orca	Linux	Free, open-source
ChromeVox	Chrome / ChromeOS	Built-in to ChromeOS

Per WebAIM Screen Reader User Survey 2024: JAWS 40%, NVDA 38%, VoiceOver 12% market share among professional users.

How assistive technology interacts with the web

AT typically uses the browser's accessibility tree (an internal representation of the page's semantic structure) — not the visible rendered pixels. Examples:

Screen reader announces the page's heading hierarchy (h1 → h2 → h3) for navigation
Switch device tabs through focusable elements (links, buttons, form fields)
Voice control uses element labels (aria-label, button text) to identify targets
Screen magnifier follows focus + cursor; respects CSS layout

If your HTML lacks semantic structure (e.g., everything is `

`), the accessibility tree is uninformative and AT can't help.

What developers do for AT

Use semantic HTML. <button> not <div onclick>, <nav> not <div class="nav">, etc.
Add ARIA only when HTML can't express semantics. Modal dialogs, tabs, autocomplete.
Provide text alternatives. alt for images, captions for video, transcripts for audio.
Ensure keyboard accessibility. Every action reachable + operable via Tab + Enter/Space.
Visible focus indicators. Don't outline: none without replacement.
Sufficient color contrast. WCAG AA: 4.5:1 normal text, 3:1 large.
Don't trap focus. Modal opens → focus inside; close → focus restores.
Test with real AT. NVDA + Chrome is free; reveal real issues automated tests miss.

Common AT-blocking pitfalls

Div soup. No semantic elements; AT sees a flat list of unidentified blocks.
Custom widgets without ARIA. Date picker built with divs is invisible to screen readers.
Mouse-only interactions. Hover-only menus, drag-drop without keyboard alternative.
Focus outline removed without replacement. Keyboard users can't see where they are.
Missing alt text. Image content lost.
Auto-playing media. Audio overlaps screen reader speech.
Inaccessible CAPTCHAs. Image-only CAPTCHA blocks blind users.
SPA route changes silent. AT doesn't know page changed; need aria-live announcement.

Testing with assistive technology

Approach	What it catches
Automated tools (axe, Lighthouse, WAVE)	~30% of issues — easy ones (missing alt, low contrast)
Manual keyboard test	Focus traps, missing focus indicators, unreachable controls
Screen reader test (NVDA, VoiceOver)	Misnamed buttons, wrong reading order, dynamic content not announced
Real-user testing with AT users	Real workflow blockers; subjective UX issues
Browser zoom test	Layout breaks at 200%/400% zoom

FAQ: Assistive Technology

What's the most common screen reader?

JAWS (40%) and NVDA (38%) on Windows; VoiceOver dominates on Apple devices. NVDA is free + good for testing.

Do all blind users use screen readers?

Most do, but some prefer Braille displays. AT use varies by individual + task.

How does AT handle JavaScript-heavy sites?

Modern AT runs JS. But SPAs that don't manage focus/announcements properly are still bad UX. Use aria-live for dynamic updates.

Is ARIA required for accessibility?

No — semantic HTML covers most cases. ARIA fills the gap for custom widgets HTML can't express.

What's the legal status of AT support?

Many jurisdictions require it: ADA (US), EAA (EU), AODA (Ontario), Equality Act (UK). Lawsuits are common; non-compliance is costly.

How do I test on iOS VoiceOver without an iPhone?

iOS Simulator on macOS supports VoiceOver. Or use Sauce Labs / BrowserStack with real devices.

Are accessibility overlays (e.g., AccessiBe) good?

Generally no — accessibility experts criticize them for not actually fixing underlying code, sometimes interfering with real AT. Lawsuits have ruled them insufficient.

Test AT-friendliness with LoadFocus

LoadFocus runs Lighthouse audits from 25+ regions including the Accessibility audit, flagging many AT-blocking issues automatically. Sign up free at loadfocus.com/signup.

How fast is your website?

Elevate its speed and SEO seamlessly with our Free Speed Test.

Start for free*No credit card required.