People with disabilities use the web with assistive technology — tools like screen readers, magnifiers, keyboard-only navigation, voice control, and captions — that translate a webpage into a form they can perceive and operate. When a site is built well, these tools work seamlessly; when it isn’t, they hit barriers that lock people out.
Understanding how real people navigate your site is the foundation of accessibility. The WCAG 2.1 AA guidelines and the POUR principles (Perceivable, Operable, Understandable, Robust) exist precisely because different people interact with the same page in very different ways. Below is a plain-language overview of the main disability categories, the assistive technology each relies on, and the barriers that trip them up.
The four main categories of disability online
Disabilities that affect web use fall into four broad groups. Most accessibility work touches all four, because a single page can present a different obstacle to each.
| Category | Examples | Common assistive technology |
|---|---|---|
| Visual | Blindness, low vision, color blindness | Screen readers, magnifiers, high-contrast modes, braille displays |
| Motor / mobility | Limited dexterity, tremors, paralysis, RSI | Keyboard-only navigation, switch devices, voice control, eye tracking |
| Auditory | Deafness, hard of hearing | Captions, transcripts, sign-language video |
| Cognitive | Dyslexia, ADHD, memory or attention differences | Clear layouts, reading tools, text-to-speech, reduced motion |
These categories overlap. Aging often brings several at once — reduced vision, less precise motor control, and slower processing — which is why accessible design helps a far larger audience than the “disabled” label suggests.
Visual disabilities and the web
Blindness and screen readers
People who are blind typically use a screen reader — software that converts on-screen content into synthesized speech or braille. The most common are NVDA and JAWS on Windows and VoiceOver on macOS and iOS. We cover them in depth in our screen readers guide.
A screen reader doesn’t “look” at your page the way a sighted person does. It builds a linear model from your HTML and announces it element by element. Users navigate by jumping between headings, links, form fields, and landmarks — not by scanning visually. That means:
- Images need accurate alt text, or the user hears a filename or nothing at all.
- Headings must be real
<h2>/<h3>elements in logical order, not just big bold text. - Buttons and links need meaningful names; “click here” and “read more” tell a screen-reader user nothing out of context.
- ARIA labels and roles fill gaps where native HTML can’t convey meaning — but ARIA misused can make things worse than no ARIA at all.
Low vision and color blindness
Many more people have low vision than are fully blind. They may use screen magnification, browser zoom, larger fonts, or high-contrast themes rather than a screen reader. People with color blindness can’t rely on color alone to understand information.
The barriers here are concrete: text that doesn’t meet color contrast requirements, layouts that break when zoomed to 200%, and error messages that turn a field “red” without any text or icon. WCAG’s contrast minimum of 4.5:1 for normal text exists for exactly this reason.
Motor and mobility disabilities
People with limited dexterity, tremors, paralysis, or repetitive strain injuries often can’t use a mouse. They navigate with the keyboard alone, with switch devices, with eye-tracking, or with voice control like Dragon or Voice Control.
The single most important thing your site can do for these users is full keyboard operability. Every link, button, menu, form field, and interactive widget must be reachable and usable with Tab, Enter, Space, and arrow keys — and the focus indicator must always be visible so the user knows where they are. Our keyboard navigation guide walks through this in detail.
Common barriers include:
- Keyboard traps — focus enters a widget (like a date picker or modal) and can’t get out.
- Invisible focus — the outline is removed in CSS, so keyboard users are flying blind.
- Mouse-only interactions — hover menus, drag-and-drop, or controls that only respond to a click.
- Tight time limits — sessions or carousels that move faster than someone can operate them.
If a feature works with a mouse but not a keyboard, it is broken for this entire group.
Auditory disabilities
Deaf and hard-of-hearing users need an alternative to audio. For video, that means captions — synchronized text of speech and meaningful sounds. For audio-only content like podcasts, it means a transcript. Some users also benefit from sign-language interpretation.
The barriers are usually straightforward to fix: uncaptioned videos, auto-generated captions full of errors, and audio that plays with no text equivalent. Under WCAG 2.1 AA, captions for prerecorded video and transcripts for audio are required, not optional extras.
Cognitive disabilities
Cognitive and learning differences — dyslexia, ADHD, memory and attention differences, and more — are the most common and the most overlooked. There’s no single assistive device; instead, these users depend on the clarity of the page itself, often paired with text-to-speech tools, reading-mode browsers, or reduced-motion settings.
What helps:
- Plain language and short, scannable sections instead of dense walls of text.
- Consistent, predictable navigation so the layout doesn’t change unexpectedly.
- Clear instructions and error recovery in forms, so a single mistake doesn’t strand the user. See our accessible forms guide.
- Respecting reduced-motion preferences so animation doesn’t distract or trigger discomfort.
Designing for cognitive accessibility tends to make a site clearer for everyone — the classic “curb-cut effect” we’re named for.
Why this matters legally — and why overlays don’t solve it
In the US, courts widely treat business websites as places of public accommodation under ADA Title III, and federal agencies follow Section 508 for their own sites. The DOJ has affirmed that the ADA applies to web content, and thousands of ADA web lawsuits — often starting with a demand letter — are filed each year. The practical conformance target is WCAG 2.1 AA. (This is general information, not legal advice; consult an attorney about your specific situation.)
Many businesses try to shortcut compliance with an accessibility overlay — a JavaScript widget that promises instant compliance. It doesn’t work. Overlays can’t reliably read author intent, can’t fix the underlying broken HTML, and frequently fight with the very screen readers and keyboard tools described above. Overlay-equipped sites are still sued routinely. The reasons are laid out in why overlays don’t work.
Real accessibility comes from understanding how people actually use your site and fixing the code by hand. That’s what a proper accessibility audit finds and what manual remediation repairs — the kind of work an overlay can only pretend to do, and the kind documented in a VPAT or accessibility conformance report when you need to prove conformance.
Build for how people really browse
The web works for everyone when it’s built to match the way real people navigate it — by ear, by keyboard, by voice, by zoom, by patience. Every barrier on this page is fixable, and none of them require asking your visitors to change how they get around.
Curious where your site stands? Run a free accessibility scan to surface the most common barriers, or learn more about the benefits of an accessible website for your business and your visitors.
Learn more
For deeper dives by topic, see how to make your website ADA compliant, explore the POUR principles that organize all of this, or read about the specific types of disabilities and web barriers. Authoritative outside references include the W3C Web Accessibility Initiative, ADA.gov, WebAIM, and Section508.gov.