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.
Blind & Low Vision
People who are blind, have low vision, or are colour blind. They rely on screen readers, magnification, high contrast modes, and meaningful colour choices.
Designing for screen readers and high contrast → HearingDeaf & Hard of Hearing
People who are Deaf, hard of hearing, or have auditory processing differences. They depend on captions, transcripts, sign language, and visual alternatives to audio.
Designing captions, transcripts, and visual alerts → MobilityMobility & Dexterity
People with limited fine motor control, tremor, paralysis, or chronic pain. They use keyboards, switches, eye-tracking, voice control, or assistive pointing devices.
Designing for keyboard, switch, and voice control → CognitiveCognitive & Learning
People with memory loss, intellectual disability, anxiety, ABI, or learning differences. They benefit from plain language, predictable layouts, clear instructions, and patient timeouts.
Designing for plain language and clear structure → NeuroNeurodivergent Users
Autistic, ADHD, dyslexic, dyspraxic and other neurodivergent users. They benefit from low cognitive load, consistent layouts, sensory-calm defaults, and literal language.
Designing for low cognitive load and calm defaults → AgeingOlder People
By age 65 most Australians have at least one accessibility-relevant change in vision, hearing, dexterity or memory. Designing for ageing is designing for inevitability.
Designing for ageing eyes, hands, and memory → TemporaryTemporary Impairments
Broken arm, migraine, eye drops, laryngitis, concussion. Temporary impairments touch most adults several times a year. Accessibility built for permanent disability serves them too.
Designing for injury, illness, and recovery → SituationalSituational Limitations
Bright sunlight. A sleeping baby. A noisy train. One hand on a phone. Situational limitations affect every user, every day. Accessibility is what keeps you working through them.
Designing for sunlight, noise, and one-handed use →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.
Screen reader and alt-text WCAG 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.
Zoom, reflow, and contrast WCAG 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.
Use of Color (1.4.1) and contrast 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.
Captions, transcripts, and time-based media 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.
Audio control and clarity WCAG 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.
Keyboard, focus order, and target size 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.
Input modality and pointer gesture 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.
Speech-alternative WCAG 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.
Plain language and structure WCAG 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.
Timing, focus, and motion control WCAG criteria →Autistic user
Benefits from predictable layouts, consistent navigation, literal language, and reduced sensory overload from animation, sound, busy backgrounds or unexpected interactions.
Consistency and predictability WCAG criteria →Dyslexic user
Needs readable typefaces, generous line and letter spacing, plain language, optional text-to-speech, tolerant search, and forms that forgive misspellings.
Readability and tolerant input WCAG 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.
Pause, resume, and persistent state 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.
Input assistance and confirmation 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.
Plain English and reading level WCAG 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.
Flash limit and seizure-safety WCAG 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.
Reduced-motion and animation WCAG 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.
Calm-design and undo WCAG 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.
Flexible interaction WCAG 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.
Adaptable, resilient design WCAG 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