# Cognitive Accessibility (W3C COGA)

Source: [Making Content Usable for People with Cognitive and Learning Disabilities](https://www.w3.org/TR/coga-usable/) (W3C)

## Why this is separate from WCAG

COGA is explicit that this guidance sits **on top of** WCAG, not inside it:

> "Following this guidance is not required for conformance to WCAG. However, following this guidance will increase accessibility for people with cognitive and learning disabilities."

This matters because cognitive and learning disabilities are mostly **hidden, hard to diagnose, and very common** — and WCAG's testable success criteria don't capture most of what these users need. A page can pass WCAG and still be unusable for someone with dyslexia, ADHD, dementia, or aphasia. So treat COGA as the place to look when something is *technically conformant but still confusing, overwhelming, or memory-heavy.*

## Who it covers

A person typically has *some* cognitive functions affected while others are fully intact, and may have more than one condition at once. COGA's personas span: mild cognitive impairment / aging, autism, Down syndrome, dementia, dyscalculia, traumatic brain injury, memory loss, aphasia, dyslexia, and ADHD. Neurodiversity here means the different ways a brain can process and interpret information — not a deficit to be "fixed."

## The eight objectives and their patterns

Use the objectives as a checklist; reach for the specific patterns when a flow is failing one of them.

### 1. Help users understand what things are and how to use them
Make the page's purpose clear · use a familiar hierarchy and design · use a consistent visual design · make each step clear · clearly identify controls and their use · make the relationship clear between controls and the content they affect · use icons that help the user (pair icons with text labels).

### 2. Help users find what they need
Make important tasks and features easy to find · make the site hierarchy easy to understand and navigate · use a clear, understandable page structure · make the most important actions and information prominent · break media into chunks · provide search.

### 3. Use clear and understandable content
Use clear words · use a simple tense and voice · avoid double negatives and nested clauses · use literal language (avoid idioms/metaphor) · keep text succinct · use clear, unambiguous formatting and punctuation · include the symbols/letters needed to decipher words · provide a summary of long documents and media · separate each instruction (one instruction per step) · use white space · ensure foreground content isn't obscured by background · explain implied content · provide alternatives for numerical concepts.

### 4. Help users avoid mistakes and know how to correct them
Ensure controls and content don't move unexpectedly · let users go back · notify users of fees and charges at the start of a task · design forms to prevent mistakes · make it easy to undo form errors · use clear, visible labels · use clear step-by-step instructions · accept different input formats (e.g., phone numbers with or without spaces) · avoid data loss and timeouts · provide feedback · help the user stay safe · use familiar metrics and units.

### 5. Help users focus
Limit interruptions · make short critical paths · avoid too much content (don't overload the screen) · provide the information a user needs to complete and prepare for a task.

### 6. Ensure processes do not rely on memory
Provide a login that doesn't rely on memory or other cognitive skills · allow a simple, single-step login · provide a login alternative with fewer words · let users avoid navigating voice menus · don't rely on users calculating or memorizing information across steps.

### 7. Provide help and support
Provide human help · provide alternative content for complex information and tasks · clearly state the results and disadvantages of actions, options, and selections · provide help for forms and non-standard controls · make it easy to find help and give feedback · provide help with directions · provide reminders.

### 8. Support adaptation and personalization
Let users control when content moves or changes · enable APIs and extensions · support simplification · support a personalized and familiar interface (let people keep settings that work for them).

## How to apply this in a review

1. Read the actual user-facing text aloud. If a sentence has a double negative, an idiom, jargon, or more than one instruction, rewrite it (Objective 3).
2. Trace the critical path. Count the steps and the things the user must *remember* between steps — eliminate the memory dependencies (Objectives 5 & 6).
3. Look at every form and destructive action. Can mistakes be prevented, undone, and clearly explained? Are costs and consequences shown *before* commitment (Objective 4 & 7)?
4. Check consistency and labels. Same thing named the same way everywhere; icons paired with text (Objectives 1 & 2).

# Motion, Sensory, and Age-Related Needs

## Reduced motion

Animation is not neutral. For people with **vestibular (inner-ear) disorders**, motion like scaling, panning, parallax, and large transitions can trigger genuine nausea, dizziness, and disorientation. For people with **photosensitive epilepsy**, flashing can trigger seizures.

Operating systems expose a user setting for this, and the web surfaces it through the `prefers-reduced-motion` media feature.

Source: [prefers-reduced-motion — MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion)

> "is used to detect if a user has enabled a setting on their device to minimize the amount of non-essential motion. The setting is used to convey to the browser on the device that the user prefers an interface that removes, reduces, or replaces motion-based animations."

Values:
- `no-preference` — no preference set; evaluates as false.
- `reduce` — the user has asked for reduced motion; `@media (prefers-reduced-motion)` is equivalent to `@media (prefers-reduced-motion: reduce)`.

### The key principle: reduce or replace, don't just delete

Motion often carries meaning (where did this come from, what just changed). When a user prefers reduced motion, **swap the vestibular-triggering motion for a calmer cue** — a cross-fade/opacity change instead of a scale or slide — rather than removing all feedback. The MDN example does exactly this: a pulsing scale animation becomes a gentle dissolve.

```css
.animation {
  animation: pulse 1s linear infinite both;
  background-color: purple;
}

/* Tone down the animation to avoid vestibular motion triggers. */
@media (prefers-reduced-motion: reduce) {
  .animation {
    animation: dissolve 4s linear infinite both;
    background-color: green;
    text-decoration: overline;
  }
}

@keyframes pulse {
  0%   { transform: scale(1); }
  25%  { transform: scale(0.9); }
  50%  { transform: scale(1); }
  75%  { transform: scale(1.1); }
  100% { transform: scale(1); }
}

@keyframes dissolve {
  0%   { opacity: 1; }
  50%  { opacity: 0.3; }
  100% { opacity: 1; }
}
```

What to reduce or replace when `reduce` is set: scaling (`transform: scale()`), panning large objects, parallax scrolling, large page transitions, autoplaying motion, and zoom effects. Subtle opacity/color transitions are generally safe.

On native platforms the same idea applies — read the OS "Reduce Motion" flag (e.g., `MediaQuery.disableAnimations` in Flutter, `UIAccessibility.isReduceMotionEnabled` on iOS, `Settings.Global.ANIMATOR_DURATION_SCALE` on Android) and pick a calmer transition.

### Flashing

Independently of the user's motion preference, never show content that flashes more than about three times per second — it is a seizure risk for photosensitive users.

## Older users: age-related ability change

Source: [Older Users and Web Accessibility — W3C WAI](https://www.w3.org/WAI/older-users/)

Ageing brings gradual changes that overlap directly with established disability access needs, across four areas:

- **Vision** — "reduced contrast sensitivity, color perception, and near-focus, making it difficult to read web pages."
- **Physical / motor** — "reduced dexterity and fine motor control, making it difficult to use a mouse and click small targets."
- **Hearing** — "difficulty hearing higher-pitched sounds and separating sounds," especially with background music.
- **Cognitive** — "reduced short-term memory, difficulty concentrating, and being easily distracted, making it difficult to follow navigation and complete online tasks."

The encouraging consequence:

> "websites, applications, and tools that are accessible to people with disabilities are more accessible to older users as well."

In other words, you don't need a separate "senior mode." Solid contrast, large and well-spaced targets, clear audio, simple navigation, and low memory load — the same things you do for disabled users — cover most age-related needs. W3C notes WCAG addresses most older-user needs already.

> Scope note: this file is about *age-related ability decline*, which is accessibility. The broader treatment of **age as context and identity** — first-time-online confidence, life stage, designing for children — lives in the **inclusive-design** skill, not here.