When people ask about the types of web accessibility, they usually mean one of two things: the types of disabilities that accessibility addresses, or the categories of requirements that organizations like the W3C have defined to cover them.
Both are worth understanding, and they’re more connected than most guides make clear.
This post walks through both: the four main types of user needs that drive accessibility work, and the WCAG (Web Content Accessibility Guidelines) framework that translates those needs into practical requirements.
Types of Web Accessibility by User Need
The most useful way to understand web accessibility is to start with the people it serves. There are four main categories of user need, and most accessibility requirements trace back to at least one of them.
Visual Accessibility
Visual disabilities range from complete blindness to low vision to color blindness. Each creates different barriers on the web.
Users who are blind typically navigate with a screen reader, software that reads content aloud or outputs it to a refreshable Braille display. For them, a website that relies entirely on visual layout, unlabeled images, or icon-only buttons is effectively unusable.
Users with low vision may zoom in significantly, use high contrast modes, or increase text size to read comfortably. Designs that break when text is enlarged, or that rely on low-contrast color combinations, create real friction.
Color blindness affects roughly 8% of men and 0.5% of women. It doesn’t prevent someone from using a site, but it does mean that anything communicated by color alone, like a red error state or a green “success” indicator, won’t reach everyone.
What this means for your site: Text needs sufficient contrast. Images need descriptive alt text. UI states can’t rely on color as the only signal.
Auditory Accessibility
Auditory disabilities include deafness and varying degrees of hearing loss. On the web, the main barrier is audio-only content: a video with no captions, a podcast with no transcript, or an audio CAPTCHA with no visual alternative.
Many users with hearing loss are entirely fluent in written language. The barrier isn’t comprehension; it’s access to the content format.
What this means for your site: Videos need accurate captions. Audio content needs transcripts. Anything conveyed through sound needs a text equivalent.
Motor Accessibility
Motor disabilities affect how people interact with devices. This includes conditions like cerebral palsy, spinal cord injuries, repetitive strain injuries, and Parkinson’s disease, but also includes temporary situations, like a broken arm or recovering from surgery.
Some motor-impaired users navigate entirely by keyboard. Others use switch access, eye tracking, mouth sticks, or voice control. What almost all of them have in common: they can’t use a standard mouse in the way it’s typically assumed.
Motor accessibility isn’t a niche concern. Temporary motor impairments (a broken arm, post-surgery recovery, a phone in one hand) affect almost everyone at some point.
A website that requires precise mouse movements, has no keyboard support, or uses hover-triggered interactions puts up an immediate wall for these users.
What this means for your site: Every interactive element must be reachable and usable with a keyboard alone. Focus indicators need to be visible. Hover-only interactions need keyboard equivalents.
Cognitive Accessibility
Cognitive accessibility is the broadest category, and often the most overlooked. It covers users with learning disabilities like dyslexia, ADHD, autism, memory impairments, and anxiety disorders, as well as users who are simply tired, distracted, or reading in a second language.
The barriers here are less about input method and more about clarity. Complex navigation, dense walls of text, inconsistent UI patterns, time-limited sessions, and confusing error messages all create friction for users with cognitive differences.
What this means for your site: Use plain language. Keep navigation consistent. Label everything clearly. Give users enough time to complete tasks. Write error messages that explain what went wrong and how to fix it.
Cognitive accessibility improvements tend to benefit everyone: simpler copy, clearer navigation, and better error messages make sites easier to use across the board.
The POUR Framework: How WCAG Organizes These Needs
The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility, published by the W3C. They organize all accessibility requirements around four core principles, known as POUR: Perceivable, Operable, Understandable, and Robust.
Every WCAG success criterion falls under one of these four principles. Understanding them helps you see why specific rules exist, not just what they are.
Perceivable
Content must be presented in ways that users can actually perceive, meaning it can’t rely on a single sense.
This principle covers:
- Alt text for images (visual content → text equivalent)
- Captions and transcripts (audio/video → text equivalent)
- Color contrast (visual presentation → readable by more users)
- Resizable text and adaptable layouts
The underlying question: can every user perceive this content in some form, even if not in the way it was originally presented?
Operable
Users must be able to interact with the interface, regardless of how they’re navigating.
This principle covers:
- Keyboard accessibility for all interactive elements
- Sufficient time to complete tasks (no sudden timeouts)
- No content that flashes in ways that trigger seizures
- Clear, descriptive page titles and headings for navigation
The underlying question: can every user operate this interface, even if they’re not using a standard keyboard and mouse?
Understandable
Both the content and the interface behavior must be comprehensible. A technically operable page can still fail users if the language is impenetrable or the UI behaves unpredictably.
This principle covers:
- Plain language and appropriate reading level
- Clear labels on form fields
- Consistent navigation across pages
- Error messages that explain what went wrong
The underlying question: would a user with a cognitive or language difference be able to understand this and know what to do?
Robust
Content must work reliably across a wide range of technologies, including current and future assistive technologies.
This principle is mostly about clean, valid code. Screen readers and other assistive tools parse the underlying markup. If the HTML is malformed, ARIA is misused, or components are built with non-semantic elements, assistive technology may interpret the page incorrectly, even if it looks fine in a visual browser.
This principle covers:
- Valid, well-structured HTML
- Correct use of ARIA roles and attributes
- Name, role, and value exposed for all UI components
The underlying question: will this work for assistive technology users today, and hold up as technology changes?
How User Needs Map to POUR
These two frameworks (disability categories and POUR principles) aren’t parallel tracks. They overlap.
| User need | Primary POUR principle(s) |
|---|---|
| Visual (blind, low vision) | Perceivable, Operable, Robust |
| Auditory (deaf, hard of hearing) | Perceivable |
| Motor (keyboard, switch users) | Operable |
| Cognitive (learning, memory, attention) | Understandable, Perceivable |
No single POUR principle maps cleanly to one disability type. A screen reader user benefits from Perceivable content (alt text), Operable interfaces (keyboard nav), and Robust code (correct semantics). Keyboard users need Operable interfaces but also Understandable ones: a keyboard-navigable modal that gives no feedback about what’s happening isn’t actually usable.
The table above is a starting point, not a strict rule.
WCAG Conformance Levels
WCAG success criteria are organized into three conformance levels.
Level A is the minimum baseline. These are the most critical barriers: missing alt text, no keyboard access, no page title. A site that fails Level A has issues that completely block some users.
Level AA is the standard most organizations aim for, and what most accessibility laws (including the ADA and European Accessibility Act) require. AA adds requirements like color contrast ratios, consistent navigation, and visible focus indicators.
Level AAA is the highest level, covering specialized requirements like sign language interpretation for video and enhanced contrast ratios. Most organizations don’t target AAA across the board; it’s better used selectively for specific content types or audiences.
If you’re starting from scratch or auditing an existing site, Level AA is the right target.
Where to Start
Understanding the types of web accessibility is useful, but the real question is where to focus first.
Start with the failures that affect the most users and are the most fixable:
- Color contrast: affects visual users, flagged under Perceivable, Level AA. Most design tools have a built-in checker.
- Alt text: affects blind users, flagged under Perceivable, Level A. Missing alt text is present on more than half of all websites.
- Form labels: affects screen reader and keyboard users, flagged under Perceivable and Understandable. Missing labels block task completion entirely.
- Keyboard navigation: affects motor users and screen reader users, flagged under Operable. Tab through your site and see what you can’t reach.
An automated scanner can catch many of these quickly across your whole site. AAArdvark’s accessibility scanner flags contrast, alt text, label, and keyboard issues automatically, so you’re not hunting for them page by page.
Once you’ve addressed the high-impact basics, dig into the most common web accessibility problems to see what else is likely lurking.
The Bigger Picture
Web accessibility isn’t one thing. It’s a set of overlapping needs (visual, auditory, motor, cognitive) organized into a framework that gives you actionable requirements to work against.
You don’t have to understand every WCAG criterion before you start. But understanding why those requirements exist (who they’re for and what barrier they address) makes the work clearer and easier to prioritize.
Start with the users. The guidelines will make more sense from there.