Written by the AX4E accessibility team. Checked against the primary sources listed at the end of this page (W3C, U.S. Department of Justice, ISO and others). Last reviewed November 4, 2026. Read how we write and review guides in our editorial standards.
The fastest way to understand accessibility is to understand the tools. When you know how a screen reader moves through a page, or how someone controls a computer by voice, most accessibility requirements stop looking like rules and start looking like common sense.
Screen readers
Who uses them: people who are blind or have low vision, and some people with reading or cognitive disabilities.
How they work: a screen reader converts what is on screen into speech or braille. Users rarely listen to a page top to bottom. They jump between headings, landmarks, links and form fields, often at high speed. Common examples include JAWS and NVDA on Windows, VoiceOver on Apple devices and TalkBack on Android.
What they need from you:
- Real headings in a logical order, so the page has a navigable outline.
- Text alternatives for meaningful images, and empty alternatives for decorative ones.
- Every form field labeled, and errors announced in text, not just color.
- Links and buttons with names that make sense out of context. "Read more" ten times is a wall.
- Standard HTML elements, or correct ARIA when custom components are unavoidable.
- Documents that are tagged, with a reading order. A scanned PDF is silent.
Screen magnifiers and zoom
Who uses them: people with low vision, and a growing number of older adults.
How they work: magnifiers enlarge part of the screen, sometimes many times over, so the user sees only a small window of the page at once. Others use browser zoom or larger system text.
What they need from you: layouts that reflow at 400% zoom without sideways scrolling, text that resizes, strong contrast, and related information placed close together so it is not lost outside the magnified area.
Voice control
Who uses it: people with motor disabilities, repetitive strain injuries or limited hand use.
How it works: users speak commands such as "click Submit" or "show numbers" to operate the device. Tools include Voice Control on Apple devices, Voice Access on Android and Dragon on Windows.
What it needs from you: controls whose visible label matches their accessible name. If a button says "Send" but is coded as "btn-47", "click Send" fails.
Keyboard and switch access
Who uses them: people who cannot use a mouse, including many screen reader users and people with motor disabilities. Switch users operate a device with one or two buttons, a sip-and-puff device or a head movement.
What they need from you: everything reachable and usable with the keyboard, in a logical order, with a clearly visible focus indicator, and no traps. Large enough targets and no reliance on dragging, which WCAG 2.2 now addresses directly.
Captions, transcripts and visual alerts
Who uses them: people who are Deaf or hard of hearing, and anyone watching without sound.
What they need from you: accurate captions on video, transcripts for audio, and visual equivalents for any sound-only alert. Auto-generated captions are a start, not a finish.
Cognitive and reading support
Some people use text-to-speech, reading rulers, simplified layouts or browser extensions that change fonts and spacing. What helps them most is in your control: plain language, consistent navigation, clear instructions, enough time and forms that do not ask for the same thing twice.
How to test with assistive technology
- Unplug the mouse. Use Tab, Shift+Tab, Enter and the arrow keys to complete your three most important tasks.
- Turn on a screen reader. VoiceOver is built into Macs and iPhones. NVDA is free for Windows. Navigate by headings and see whether the page makes sense.
- Zoom to 400%. Does the content reflow, or do you lose things off the side?
- Try voice control on a phone and say the names of buttons you see.
- Bring in real users. Your own tests catch a lot. People who use these tools every day catch what you will not.
Why this matters for a business
Assistive technology users are customers, employees, patients and students. When a checkout, a job application or a benefits form does not work with their tools, they leave, and they tell others. Designing for these tools from the start is far cheaper than retrofitting after a complaint.
Common questions
What is the most common assistive technology for the web?
For people who are blind, screen readers are the most widely discussed. In practice, keyboard navigation, zoom and magnification, and captions are used by an even larger group of people.
Does an accessibility widget replace assistive technology?
No. People bring their own assistive technology, configured the way they need it. A widget on your site cannot replace those tools, and some widgets can interfere with them. See our guide to accessibility widgets.
Do we need to test with every screen reader?
Not every combination, but testing with at least one screen reader on desktop and one on mobile, plus keyboard-only and zoom checks, covers the most common barriers. Testing with real users adds what automated and internal testing miss.
Want a second set of eyes?
Request a free assessment. A real person on our team looks at your site or documents and tells you, in plain language, what to fix first.
Request a free assessment Run a free scan