Designing for Disability
Every accessibility decision affects real people. The way you build a button, structure a heading, or caption a video changes whether someone can complete a task or gives up. This page maps the five disability groups that drive most WCAG 2.2 requirements, and links to detailed guidance for each.
What disability types affect digital accessibility?
WCAG 2.2 success criteria address five core disability groups: visual (blind, low vision, colour blind), auditory (Deaf, hard of hearing), cognitive and learning (dyslexia, ADHD, autism, memory loss, anxiety, intellectual disability), physical and motor (limited fine motor control, tremor, paralysis, chronic pain) and speech (non-speaking users, augmentative communication device users). Approximately 21.4% of Australians live with disability, and most experience more than one barrier at a time. ExceedAbility tracks 20 distinct accessibility personas across these groups, each mapped to specific WCAG 2.2 criteria. Use the WCAG Criteria Search to find applicable rules, browse our free accessibility tools and guides, or contact our team to scope an audit or remediation engagement.
Last reviewed: May 2026
Five disability groups, one accessible product
Disability isn't a single experience. WCAG 2.2 success criteria exist because different people interact with digital products in different ways: some can't see the screen, some can't hear the audio, some find dense layouts overwhelming, some can't use a mouse, some communicate without speech. Good accessibility work starts with understanding who each rule protects, and then designing so all of those people can succeed.
Visual Disabilities
People who are blind, have low vision, or are colour blind. They rely on screen readers, magnification, high contrast modes, and meaningful colour choices to navigate digital content.
Read the visual disabilities guide → AuditoryAuditory Disabilities
People who are Deaf, hard of hearing, or have auditory processing differences. They depend on captions, transcripts, sign language, and visual alternatives to audio cues to access content.
Read the auditory disabilities guide → CognitiveCognitive and Learning
People with dyslexia, ADHD, autism, memory loss, anxiety, or intellectual disability. They benefit from plain language, predictable layouts, clear instructions, generous time limits, and content free of distractions.
Read the cognitive and learning disabilities guide → PhysicalPhysical Disabilities
People with limited fine motor control, tremor, paralysis, or chronic pain. They use keyboards, switches, eye-tracking, voice control, or assistive pointing devices and need large targets, full keyboard support, and forgiving interactions.
Read the physical disabilities guide → SpeechSpeech Disabilities
People who are non-speaking, have speech that automated systems struggle to recognise, or who use augmentative communication devices. They need text-based alternatives to phone calls and voice-only authentication.
Read the speech disabilities guide → EveryoneA Plain-English Primer
Not sure where to start? This article explains how disabilities intersect with digital experiences and why building accessibly benefits every user, not just those with a recognised disability.
Read the digital accessibility primer →Refine by need: 20 accessibility personas
The five groups above are useful shorthand, but most real design reviews and inclusive testing benefit from a finer-grained view. Use the filter below to narrow down to a specific group of 20 personas across cognitive, neurological, sensory and contextual needs, all aligned with WCAG 2.2 plus emerging cognitive-accessibility guidance.
Showing all 20 personas.
Blind screen reader user
Relies on screen readers and the semantic structure of pages, accessible names, headings, lists, landmarks and alt text. Cannot use anything that depends on visual layout alone.
View related WCAG 2.2 criteria →Low vision user
Uses zoom, magnification or screen-zoom up to 400 percent. Needs scalable layouts that reflow, strong contrast, and no horizontal scrolling at small viewports.
View related WCAG 2.2 criteria →Colour blind user
Cannot rely on colour alone to convey state, error, success or grouping. Needs colour paired with shape, label, icon or pattern so meaning never depends on hue.
View related WCAG 2.2 criteria →Deaf user
Cannot access audio at all. Needs accurate captions, transcripts, sign-language interpretation where appropriate, and visual equivalents for any audio cue or alert.
View related WCAG 2.2 criteria →Hard of hearing user
Benefits from adjustable audio levels, separate dialogue and background tracks, accurate captions, low background noise, and clear well-paced speech in spoken content.
View related WCAG 2.2 criteria →Motor impairment user
Uses a keyboard, switch, or assistive device rather than a mouse. Needs full keyboard support, visible focus, logical focus order, and large well-spaced targets.
View related WCAG 2.2 criteria →Fine motor difficulty user
Tremor or limited precision makes exact gestures hard. Needs forgiving inputs, no drag-only actions, generous click areas, and tolerance for accidental double activations.
View related WCAG 2.2 criteria →Speech impairment user
Cannot rely on voice interfaces, phone IVR menus, or speech-only authentication. Needs text-based contact paths, written chat options, and never speech as the only route to a critical function.
View related WCAG 2.2 criteria →Cognitive impairment user
Needs simple language, clear page structure, predictable layouts, and a minimal cognitive load to complete tasks. Benefits from one main action per screen.
View related WCAG 2.2 criteria →ADHD user
Needs reduced distractions, clear focus states, manageable content chunks, and the ability to control motion or auto-playing media that pulls attention away from the task.
View related WCAG 2.2 criteria →Autistic user
Benefits from predictable layouts, consistent navigation, literal language, and reduced sensory overload from animation, sound, busy backgrounds or unexpected interactions.
View related WCAG 2.2 criteria →Dyslexic user
Needs readable typefaces, generous line and letter spacing, plain language, optional text-to-speech, tolerant search, and forms that forgive misspellings.
View related WCAG 2.2 criteria →Memory impairment user
Needs reminders, persistent state, the ability to pause and resume tasks, and steps that don't depend on remembering content from earlier in the journey.
View related WCAG 2.2 criteria →Executive function difficulty user
Struggles with planning and sequencing. Needs guided flows, clear progress indicators, one decision at a time, and explicit confirmation before any destructive action.
View related WCAG 2.2 criteria →Language processing difficulty user
Benefits from plain English, visual aids alongside text, simplified instructions, and avoidance of jargon, idiom, abbreviation, or culturally specific references.
View related WCAG 2.2 criteria →Photosensitive epilepsy user
At risk from flashing or rapidly-changing content. Needs strict flash-rate limits respected, no large red flashes, and animations under user control.
View related WCAG 2.2 criteria →Vestibular disorder user
Sensitive to motion, parallax, large slide transitions and auto-scrolling. Needs a reduced-motion preference that genuinely disables non-essential animation.
View related WCAG 2.2 criteria →Anxiety or mental health condition user
Needs calm design, clear feedback, no surprise time limits, predictable outcomes, and an obvious way to undo, get help, or step away without losing progress.
View related WCAG 2.2 criteria →Temporary impairment user
For example a broken arm, eye drops after an appointment, or post-surgery recovery. Needs the same flexible interaction methods that permanent disabilities require, just for a shorter window.
View related WCAG 2.2 criteria →Situational impairment user
Bright sunlight on a phone screen, a crying baby, a noisy train, one-handed use while carrying shopping. Needs adaptable, resilient design that copes with the environment.
View related WCAG 2.2 criteria →Every audit finding is tied to the people it protects.
When ExceedAbility delivers an accessibility audit, every WCAG 2.2 issue we raise is mapped to the disability group it affects and the practical impact on a user. That keeps remediation conversations grounded in real users rather than abstract rule numbers.
Designing well for one, helps everyone
Captions help Deaf users, and they also help people watching on a quiet train. Large click targets help people with tremor, and they also help anyone using a phone on a bumpy bus. Plain language helps people with cognitive disabilities, and it also helps stressed users, second-language readers, and the team that has to maintain your content. Accessibility is rarely a niche fix, it almost always raises the floor for every user.
Common questions about designing for disability
Plain answers to the questions designers and developers ask most often.
How do I design for visual disabilities?
Designing for visual disabilities means: using semantic HTML so screen readers can structure content, providing meaningful alt text on informative images, ensuring colour contrast meets WCAG 2.2 AA (4.5:1 for normal text, 3:1 for large text and UI), never conveying information by colour alone, supporting text resize to 200% without loss of content, and testing with NVDA, JAWS and VoiceOver.
How do I design for auditory disabilities?
Designing for auditory disabilities requires: synchronised captions for all pre-recorded audio with dialogue (WCAG 1.2.2), a transcript for audio-only content, and captions for live audio at WCAG AA. For sign-language users, consider Auslan interpretation for important content. Captions should include speaker identification and relevant non-speech audio.
How do I design for cognitive disabilities?
Cognitive accessibility benefits from: plain language at a Year-9 reading level, clear and consistent navigation, predictable interactions, error prevention and recovery, generous time limits, no auto-playing media, no distracting motion, the ability to pause animations, and the ability to save progress in long forms. Cognitive needs vary widely - design for flexibility, not a single profile.
How do I design for physical and motor disabilities?
Designing for physical and motor disabilities means: full keyboard accessibility (every interactive element reachable by Tab and operable by Enter or Space), visible focus, no keyboard traps, target sizes of at least 24×24 CSS pixels (WCAG 2.5.8), keyboard equivalents for any drag interaction, and support for voice control and switch input through accessible names that match visible labels.
How do I design for speech disabilities?
Speech-disability accessibility means avoiding designs that require voice input as the only way to complete a task. Provide text-based alternatives to voice interactions, support assistive communication devices, and allow users to type or click through workflows that competitors gate behind voice. For phone or video support, also offer chat, email, or text-relay alternatives.
Do most users with a disability sit in just one category?
No. Many people have multiple disabilities (for example, low vision plus motor impairment) or experience disability in conjunction with age-related changes. Designing for a single disability type produces narrow solutions; designing for the underlying functional need (perceiving, operating, understanding) produces broader, more inclusive solutions.
Want help applying this to your product?
Contact our team to scope what you need, whether that's a single audit, ongoing remediation support, or capability uplift across your team. A 20-minute Discovery Call is usually enough to get started.
Contact ExceedAbility Book a Discovery Call