Cognitive Accessibility & COGA

The full lesson

Cognitive disabilities are the most common category of disability in the world. Yet they are the least systematically addressed in product design. Conditions like dyslexia, ADHD, autism spectrum disorder, traumatic brain injury, dementia, anxiety, and learning disabilities all affect how people read, remember, navigate, and make decisions. Most digital products are silently hostile to these users. The W3C’s Cognitive and Learning Disabilities Accessibility Task Force (COGA) exists to fill the gap that WCAG’s technical criteria leave open.

Understanding COGA is not just about passing a checklist. It is about recognizing that the cognitive load you create is a design decision — one with measurable consequences for the broadest, most underserved segment of your users.

What COGA Is and Why It Exists

WCAG’s success criteria are necessary, but they are structurally biased toward perceptual and motor accessibility. A page can have correct contrast ratios, ARIA labels, and keyboard focus management and still be cognitively inaccessible. Confusing navigation, jargon-filled error messages, time pressure, and memory demands all fall outside the scope of most WCAG criteria.

The Cognitive and Learning Disabilities Accessibility Task Force (COGA) is a joint W3C task force. Its main output is a document called Making Content Usable for People with Cognitive and Learning Disabilities — informally called the COGA Usability document. It is a W3C Note (guidance, not a testable standard). It organizes design guidance into eight Objectives, each addressing a fundamental cognitive need.

WCAG 2.2 absorbed several COGA-informed criteria directly into the normative standard:

These criteria are a floor. The full COGA Objectives cover significantly more ground.

The Eight COGA Objectives

The COGA Usability document organizes its guidance around eight high-level objectives. Each objective maps to a cluster of design patterns. Violating any of them adds cognitive friction that compounds for users with cognitive disabilities.

1. Help users understand what things are and how to use them Use familiar conventions. Custom icons without labels, ambiguous affordances, and novel interaction patterns all require users to learn your product before they can use it. Cognitive disabilities reduce the capacity for that learning.

2. Help users find what they need Navigation must be predictable. Search must be forgiving. Users must be able to orient themselves at any point. This connects to WCAG 3.2.3 (Consistent Navigation) and 3.2.6 (Consistent Help), but goes further: labels must match what users call things, not what engineering calls them.

3. Use clear and understandable content Write in plain language. Use short sentences, concrete examples, and visual support for complex instructions. Readability is a functional accessibility criterion — not just a content quality nicety.

4. Prevent the user from making mistakes and make it easy to correct them Use inline validation, confirmation steps for destructive actions, undo capability, and forgiving inputs. This objective has the most overlap with WCAG 3.3 (Input Assistance) criteria.

5. Help users focus and restore context after distraction Avoid auto-playing media, unexpected interruptions, and visual clutter. Session timeouts with adequate warning (WCAG 2.2.1) are part of this — but so is reducing ambient noise in the visual design.

6. Ensure processes do not rely on memory Show previously entered data. Provide visible hints. Do not rely on users to remember what happened two steps ago. WCAG 3.3.7 (Redundant Entry) directly encodes this principle.

7. Provide help and support Offer context-sensitive help, clearly labeled support options, and progressive disclosure of complexity. WCAG 3.2.6 (Consistent Help) is a subset of this objective.

8. Support adaptation and personalization Allow users to adjust text size, contrast, language complexity, and interface density. The WCAG 1.3.4–1.3.6 cluster (Identify Purpose, Personalization) addresses this partially. Supporting user-agent style overrides and OS-level accessibility settings matters here too.

Accessible Authentication: A WCAG 2.2 Deep Dive

Criterion 3.3.8 (Accessible Authentication Minimum, AA) is the most misunderstood COGA-origin criterion in WCAG 2.2. It states that a cognitive function test cannot be the only way to complete authentication — there must be an alternative method or assistance.

A cognitive function test includes:

• Transcribing distorted text (traditional image CAPTCHA)
• Solving a puzzle (drag-the-slider, identify-the-object)
• Remembering a username created more than 30 days ago (without a reminder mechanism)
• Mental calculation or pattern recognition

What passes:

• Password managers and copy-paste are allowed — do not block them
• Object recognition with an alternative text option passes if both methods are equally available
• Passkeys and biometric authentication pass
• Two-factor authentication with an authenticator app passes — but only if the code can be pasted, not just typed

The key practical implication: stop blocking paste in password and OTP fields. This is one of the most common WCAG 2.2 failures in production today. It directly harms users with cognitive disabilities who rely on password managers and clipboard tools.

Plain Language as a Functional Accessibility Requirement

Plain language is sometimes treated as a content style preference. In the context of cognitive accessibility, it is a functional requirement. WCAG 3.1.5 (Reading Level, AAA) asks for supplemental content at lower reading levels when text exceeds a secondary-education reading level. COGA guidance pushes this principle further — into every layer of interface text, not just body copy.

Concrete plain-language principles for UI text:

• Use the most common word. “Submit” over “Finalize transaction.” “Delete” over “Permanently remove this record.”
• Front-load instructions. Put the most important information first. Do not bury it in subordinate clauses.
• One idea per sentence. Complex compound sentences increase parsing load for users with processing differences.
• Write for action. Labels and headings should describe what the user does or gets, not system states. “Review your order” rather than “Order confirmation pending.”
• Use numbered lists for sequences. Multi-step processes written as prose paragraphs are much harder to follow than numbered steps.
• Avoid idioms and metaphors. These create unpredictable cognitive demands for users with autism, users working in a second language, and users with acquired language differences.

Reading ease scores (Flesch-Kincaid, Gunning Fog) are imperfect but useful automated checks. You can run them in CI pipelines against content strings extracted from the codebase. A score targeting grade 8 or below is a reasonable default for primary navigation, forms, and error messages.

Form Design for Cognitive Accessibility

Forms are where cognitive accessibility failures concentrate most visibly. Memory demands, time pressure, error recovery, and labeling conventions combine to create a minefield.

Labels and Instructions

Visible, persistent, top-aligned labels are the baseline. Placeholder-as-label fails cognitively even when it passes WCAG 3.3.2 (Labels or Instructions). When a user starts typing, the label disappears. The user must now hold the field’s purpose in working memory while entering data. Floating labels create the same problem on focus.

Format instructions (such as “Date: MM/DD/YYYY”) belong above the field — not only in error messages after submission. This is both a COGA and a WCAG 3.3.2 requirement: instructions must be available before the user starts entering data.

Error Messages

Specific, actionable error messages are required by WCAG 3.3.3 (Error Suggestion, AA). The minimum:

1. Identify the field by name, not just by proximity (“Date of birth is required” not “This field is required”)
2. Describe what is wrong specifically (“Must be a date in the past” not “Invalid date”)
3. Suggest the correction when possible (“Use the format DD/MM/YYYY”)
4. Link the error to the field using aria-describedby so screen reader users hear it on focus

Inline validation on blur (when the user leaves a field) is far better cognitively than submit-time validation. Users get immediate feedback while the context is still active in working memory. Submit-time-only validation forces users to re-navigate the form and reconstruct what they were doing — a significant burden for users with memory or attention differences.

Reducing Memory Demands in Multi-Step Flows

Multi-page or multi-step forms create particular cognitive risk. Best practices:

• Show a progress indicator with step labels, not just a step number
• Allow review before submission, not just a confirmation message after
• Do not clear previously entered data on back navigation
• Pre-fill known data — if a shipping address was entered, offer it as the billing address default (this also satisfies WCAG 3.3.7)
• Allow saving progress and returning later for long forms

Visual Clarity and Cognitive Load

Visual design choices have direct cognitive accessibility implications beyond color contrast.

Information density. Dense layouts increase cognitive load. Whitespace is not decorative — it creates the visual separation that lets users parse structure. Designs that pack every available pixel with content create ambient noise that degrades performance for users with attention differences.

Consistent layouts. Navigation in the same position across pages, icons used consistently, and predictable component behavior all reduce the need to re-learn the interface. WCAG 3.2.3 and 3.2.4 (Consistent Navigation and Identification) encode a subset of this. COGA extends it to component-level consistency.

Icons with labels. Icon-only controls are a COGA failure surface. Even icons considered universally understood (the hamburger menu, the gear icon, the share icon) are interpreted differently across cultures, ages, and cognitive profiles. Pairing icons with text labels removes this ambiguity at essentially zero layout cost on most surfaces.

Clear calls to action. Primary actions must be visually distinct from secondary actions and from body copy. A page with three equally weighted buttons creates decision paralysis for users with executive function differences. Visual hierarchy is a cognitive accessibility tool.

Timeouts and motion. Auto-updating content, carousels, and timed sessions all create cognitive disruption. Carousels that auto-advance distract users who are trying to read the current slide. Timed sessions that expire without clear warning interrupt the mental model a user has built about the current task. WCAG 2.2.1 requires that timeouts be adjustable or last at least 20 hours.

Testing for Cognitive Accessibility

Automated tools cannot directly test most cognitive accessibility failures. axe, Lighthouse, and similar scanners can confirm that a label element exists, but cannot tell you whether the label text is comprehensible. This makes cognitive accessibility uniquely dependent on human judgment and user research.

Practical testing approaches:

Heuristic review using the COGA Objectives. Walk each key flow against the eight COGA objectives. Mark failures and rate severity as blocking (user cannot complete the task), major (user completes with significant difficulty), or minor. This takes roughly an hour per flow and requires no participants — it is the highest-leverage starting point.

Plain-language review. Extract all interface strings (labels, button text, error messages, headings, onboarding copy) and evaluate them against plain-language criteria. A readability score combined with a human judgment pass on idioms and technical jargon is sufficient for most products.

Usability testing with cognitively diverse participants. Standard usability testing with five participants for qualitative problem-finding applies here. Recruiting participants with cognitive disabilities — via disability organizations, advocacy groups, or panels like Fable — is necessary to surface problems that are invisible to non-disabled evaluators. Behavioral data (what users do, where they pause, what they misread) is more reliable than self-reported difficulty ratings. The say/do gap is especially pronounced for tasks that involve cognitive load.

Browser zoom and text spacing override testing. Set the browser to 200% zoom and override text spacing (line height 1.5x, letter spacing 0.12em, word spacing 0.16em, paragraph spacing 2em) using a bookmarklet or browser extension. Layouts that break under these overrides are cognitively inaccessible to users who rely on these settings as a default.

What COGA Is Not

Two misconceptions are worth naming directly.

COGA is not about making things simpler for everyone. Cognitive accessibility is about removing unnecessary barriers for users with specific cognitive differences. A complex medical form might legitimately be long and detailed. The COGA goal is to make that complexity navigable and understandable — not to reduce the information.

COGA guidance is not normative WCAG. The COGA Usability document is a W3C Note — guidance, not a standard. It cannot be legally cited as a compliance requirement. What can be cited are the WCAG 2.2 criteria informed by COGA work: 3.3.7, 3.3.8, 3.2.6, and 2.4.11 among them. Organizations pursuing genuine cognitive accessibility will implement COGA guidance as a quality and inclusion target above the WCAG floor — not as a compliance checkbox.