Cognitive and learning disabilities are the largest and most diverse category of disability. They affect how people process, remember, understand, and communicate information — but they do not affect intelligence or capability in any universal way. A person with dyslexia may be an expert engineer; a person with ADHD may be a highly creative problem-solver. Cognitive accessibility is about removing barriers so people can demonstrate their actual abilities.
Approximately 4.4 million Canadians report a cognitive, mental, or learning-related disability. This makes cognitive accessibility design one of the highest-impact areas of accessibility work — yet it is also the area least addressed by current WCAG criteria.
Types of cognitive and learning disability
Type
Description
Common web barriers
Dyslexia
Difficulty decoding written text; letter reversals; slow reading
Memory, attention, and processing speed changes after TBI or stroke
Time limits, complex forms, inconsistent layout
Dementia
Progressive memory and cognitive decline
Complex navigation, confusing labels, lack of confirmation steps
Anxiety disorders
Intrusive worry affecting concentration and decision-making
Pressure tactics, ambiguous error messages, fear of making mistakes
Assistive technologies
Author Developer
Text-to-speech (reading aloud)
Many users with dyslexia use text-to-speech tools to listen to content rather than read it:
NaturalReader — standalone TTS application
Immersive Reader (Microsoft) — built into Edge, Word, and Office 365
Read Aloud (browser extensions)
Voice Dream Reader (iOS)
These tools rely on the same semantic HTML structure as screen readers — logical heading hierarchy, proper reading order, meaningful link text.
Dyslexia-friendly fonts and overlays
Some users apply browser extensions or system settings to change typography:
OpenDyslexic font (open source)
Colorveil / tinted overlays to reduce visual stress (Meares-Irlen syndrome)
Increased letter spacing and line height via browser extensions
Websites should not override user font preferences with !important declarations.
AAC (Augmentative and Alternative Communication)
Some users with severe intellectual or communication disabilities use AAC devices — dedicated hardware or software that generates speech from symbol grids or text input. These users often benefit from symbol-supported content and very plain language.
Password managers and autofill
Users with memory difficulties depend heavily on browser autofill and password managers. Blocking autofill on forms (using autocomplete="off") creates a significant barrier for these users.
Barriers on the web
Complex language and jargon
Barrier
Legal terms, technical jargon, acronyms, and long sentences without plain-language explanations exclude users with intellectual disabilities, acquired brain injuries, and users reading in a second language.
Assistive Technology
Text-to-speech, AAC devices
Design Consideration
Write at a lower secondary reading level where possible (WCAG 3.1.5 AAA). Define jargon and acronyms on first use. Use short sentences and active voice. See the Plain Language section for detailed guidance.
Inconsistent navigation and layout
Barrier
Navigation menus change order across pages, buttons appear in different locations, familiar UI patterns are replaced without warning — users who rely on spatial memory or routine are disoriented.
Assistive Technology
None — consistency is the design solution
Design Consideration
Navigation repeated on multiple pages must appear in the same relative order (WCAG 3.2.3 Level AA). Components that have the same function must be identified consistently (WCAG 3.2.4 Level AA). Don't redesign your navigation without a clear transition.
Time pressure and session timeouts
Barrier
Timed forms, ticketing systems, and session timeouts expire before users who process information slowly can complete tasks — the data they entered is lost.
Assistive Technology
None — time extension is the design solution
Design Consideration
Warn users before a time limit expires and allow at least a 20-second window to extend it (WCAG 2.2.1 Level A). For high-stakes forms (applications, complex transactions), preserve entered data across sessions where possible.
Unclear error messages
Barrier
Form errors say 'Invalid entry' or show only a red border with no explanation — users do not know what went wrong or how to fix it.
Assistive Technology
Text-to-speech
Design Consideration
Error messages must identify which field has an error and suggest how to correct it (WCAG 3.3.1 Level A, 3.3.3 Level AA). 'Please enter a valid email address (example: name@domain.com)' is helpful. 'Invalid input' is not.
Dense walls of text
Barrier
Long paragraphs without headings, lists, or visual breaks are cognitively exhausting to read — users with ADHD, fatigue, or processing difficulties lose their place or give up.
Assistive Technology
Text-to-speech
Design Consideration
Break content into short paragraphs. Use headings to divide sections. Use bullet lists for items that don't need to be prose. Ensure ample white space. Use progressive disclosure (show less, with an option to expand) for complex content.
Autoplay and unexpected content changes
Barrier
Videos start playing, banners rotate, notifications pop up, and page content shifts unexpectedly — these interruptions break concentration for users with ADHD and cause distress for users with autism who prefer predictable environments.
Assistive Technology
None — preventing unexpected changes is the design solution
Design Consideration
Never autoplay media with audio. Moving, blinking, or scrolling content that lasts more than 5 seconds must be pausable (WCAG 2.2.2 Level A). Context changes should only happen in response to explicit user actions (WCAG 3.2.1, 3.2.2 Level A).
Multi-step processes with no progress indicator
Barrier
Multi-page forms, checkout flows, and wizards provide no indication of how many steps remain or what stage the user is at — users with anxiety or cognitive disabilities do not know how much effort is left and may abandon.
Assistive Technology
None — progress indication is the design solution
Design Consideration
Always show step progress in multi-step flows (e.g., 'Step 2 of 4'). Allow users to go back and review previous steps. Preserve previously entered data when navigating backward.
Design considerations
Designer Author
Plain language principles
Use common words; if a technical term is unavoidable, define it on first use
Write sentences of 15–20 words maximum
Use active voice: “You must submit the form” not “The form must be submitted”
Use second person (“you”) to address the reader directly
Avoid double negatives: “You must not fail to submit” → “You must submit”
Use concrete examples instead of abstract descriptions
Front-load the key information — put the most important thing first
Typography for cognitive accessibility
Left-aligned text (not justified) — justified text creates uneven word spacing that disrupts tracking for dyslexic readers
Line height of at least 1.5 for body text
Adequate letter spacing — do not kern text tightly
Avoid text-only capitalization for long passages (ALL CAPS slows reading speed)
Body text at 16px or larger
Limit the number of fonts on a page
Reducing cognitive load
Limit choices: no more than 5–7 navigation items at a level
Use familiar icons with text labels — icons alone require learning
Provide breadcrumbs on deep pages
Use predictable URL structures that match navigation labels
Group related fields in forms — reduce the number of decisions on one screen
Confirm destructive actions before executing them
Memory and recall
Implement autocomplete for forms that collect common information
Show previously entered information when returning to a form
Allow users to save progress on long processes
Avoid requiring users to memorize information between steps (“remember the code from the previous screen”)
Development considerations
Developer
Autocomplete attributes
Enable browser autofill by adding autocomplete attributes to form fields. This dramatically reduces cognitive and motor load:
Never set autocomplete="off" on personal information fields — this is listed as a WCAG 1.3.5 failure and creates significant barriers for users with memory and motor disabilities.
Status messages
When content updates dynamically (search results load, form submits, errors appear), announce the change to users without moving focus:
<!-- Results count — polite update --><div aria-live="polite" aria-atomic="true"> <p>12 results found.</p></div><!-- Error summary — move focus to this on submit --><div role="alert" tabindex="-1" id="error-summary"> <h2>There are 2 errors in this form</h2> <ul> <li><a href="#email">Email address is required</a></li> <li><a href="#postal">Enter a valid Canadian postal code (A1A 1A1)</a></li> </ul></div>
Consistent identification
If a component performs the same function across pages, it must have the same accessible name. A search field labelled “Search” on one page and “Find content” on another violates WCAG 3.2.4.
<!-- Consistent across all pages --><label for="search">Search</label><input type="search" id="search" name="q" />
Testing for cognitive accessibility
Cognitive accessibility is difficult to fully evaluate through technical audits alone. Supplement automated and expert testing with:
Expert review checklist
Is every page’s primary purpose clear within 5 seconds?
Are all error messages specific and actionable?
Is progress indicated in all multi-step processes?
Are all forms labelled and logically grouped?
Is jargon defined on first use?
Does the navigation order stay consistent across pages?
Are destructive actions (delete, submit) confirmed before execution?
Is autocomplete enabled on all personal information fields?
User testing
Testing with people with cognitive disabilities reveals barriers that expert review misses. Recruit participants from local disability organizations or through services like Fable (remote accessibility testing with disabled users).