Cognitive Accessibility — Designing for Neurodivergent Users Guide
In this tutorial, you'll learn about Cognitive Accessibility. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.
Cognitive Accessibility means designing interfaces that work for people with cognitive and learning disabilities — including ADHD, dyslexia, autism, executive dysfunction, and memory impairments — by reducing cognitive load, using plain language, and providing consistent predictable interactions.
What You'll Learn
By the end of this guide, you'll understand the WCAG success criteria that specifically address cognitive Accessibility, how to design for common neurodivergent conditions, plain language writing principles, how to reduce cognitive load in forms and navigation, and how to test your designs with users who have cognitive disabilities.
Why Cognitive Accessibility Matters
An estimated 15-20% of the global population is neurodivergent. Cognitive disabilities are the most common disability type, yet they are the most overlooked in Accessibility efforts. A user with ADHD who cannot focus through a cluttered dashboard, a user with dyslexia who cannot parse dense text, or a user with autism who is overwhelmed by auto-playing media — all are excluded by design choices that prioritize visual polish over clarity. At DodaTech, Doda Browser includes a focus mode that strips away distracting elements, and Durga Antivirus Pro uses plain-language threat descriptions instead of technical jargon.
Cognitive Accessibility Decision Flow
flowchart TD
A[User with cognitive disability] --> B{Interface clarity}
B -->|Clear| C[Task completion]
B -->|Unclear| D[Cognitive overload]
D --> E{Design improvements}
E --> F[Plain language]
E --> G[Consistent navigation]
E --> H[Generous time limits]
E --> I[Error prevention]
E --> J[Focus management]
F --> C
G --> C
H --> C
I --> C
J --> C
{{< callout type="info" icon="sparkles" >}} Prerequisites: Basic understanding of WCAG principles. No specialized knowledge of cognitive disabilities is required — this guide starts from first principles. {{< /callout >}}
WCAG Success Criteria for Cognitive Accessibility
Several WCAG success criteria directly address cognitive Accessibility:
3.1.5 Reading Level (AAA) — Content requires reading ability no more advanced than lower secondary education level. Provide a version for advanced readers.
2.2.1 Timing Adjustable (A) — Time limits must have an option to turn off, adjust, or extend.
3.3.3 Error Suggestion (AA) — Error messages must suggest corrections, not just indicate failure.
3.2.3 Consistent Navigation (AA) — Navigational mechanisms that repeat across pages must appear in the same relative order each time.
3.2.4 Consistent Identification (AA) — Components with the same functionality must be identified consistently.
1.4.12 Text Spacing (AA) — Users must be able to override text spacing without losing content or functionality.
Designing for ADHD
Users with ADHD struggle with sustained attention, distraction, and task completion. Design strategies include:
- Minimal visual noise — Remove non-essential animations, decorative elements, and sidebar clutter.
- Single-task focus — Present one task per page or step. Multi-step processes should show progress.
- Clear calls to action — Primary actions should be visually dominant. Secondary actions should be de-emphasized.
- Generous time limits — If timers exist, provide a pause or extend option. Durga Antivirus Pro lets users pause scans and resume later.
- Focused notifications — Batch non-critical notifications. Provide a "Do not disturb" mode.
<!-- Progress indicator for multi-step forms -->
<nav aria-label="Progress" role="progressbar" aria-valuenow="2" aria-valuemin="1" aria-valuemax="4">
<ol class="progress-steps" style="list-style:none;display:flex;gap:8px;">
<li aria-current="step">1. Select scan type</li>
<li><strong>2. Choose files</strong></li>
<li>3. Review settings</li>
<li>4. Run scan</li>
</ol>
</nav>
Designing for Dyslexia
Dyslexia affects reading fluency and accuracy. Design strategies include:
- Use sans-serif fonts with adequate letter spacing and line height (1.5x minimum).
- Avoid justified text — right-aligned text creates uneven word spacing.
- Use bullet points instead of dense paragraphs.
- Support text-to-speech — many users with dyslexia rely on screen readers.
- Do not rely on spelling — use icons alongside text labels.
- Use high contrast (not just for visual impairments) — low contrast strains decoding.
/* Dyslexia-friendly text settings */
body {
font-family: Arial, Helvetica, sans-serif;
line-height: 1.6;
letter-spacing: 0.05em;
text-align: left;
}
p {
max-width: 70ch;
margin-bottom: 1.5rem;
}
Designing for Autism Spectrum
Users with autism may experience sensory sensitivities and benefit from predictability:
- Predictable navigation — Menus and links should not change behavior or location unexpectedly.
- Avoid auto-playing media — Video and audio should only play on user activation.
- Use clear literal language — Avoid metaphors, idioms, and sarcasm.
- Provide consistent page structure — Same heading hierarchy, same layout, same terminology.
- Avoid flashing content — Beyond seizure risk, flashing and rapid motion can cause sensory overload.
- Offer a simplified view — A text-only or high-contrast mode toggle.
<!-- Simplified mode toggle -->
<button onclick="toggleSimplifiedMode()" aria-pressed="false">
<span aria-hidden="true">☰</span> Simplified view
</button>
<script>
function toggleSimplifiedMode() {
const body = document.body;
const isSimplified = body.classList.toggle('simplified-mode');
document.querySelector('[aria-pressed]').setAttribute('aria-pressed', isSimplified);
}
</script>
Designing for Executive Dysfunction
Executive dysfunction affects planning, organizing, and completing tasks. Design strategies include:
- Pre-fill defaults — Reduce choices where possible. For example, default scan settings in Durga Antivirus Pro are optimal for most users.
- Undo support — Every action should be reversible. DodaZIP includes an undo button for file operations.
- Step-by-step wizards — Break complex tasks into small steps with clear progress.
- Confirm before action — Especially for irreversible actions like deletion.
- Save progress automatically — Users should not lose work if they get distracted and navigate away.
// Auto-save form progress with undo
class AutoSave {
constructor(formId, storageKey) {
this.form = document.getElementById(formId);
this.key = storageKey;
this.form.addEventListener('input', () => this.save());
this.restore();
}
save() {
const data = new FormData(this.form);
const obj = {};
data.forEach((value, key) => { obj[key] = value; });
localStorage.setItem(this.key, JSON.stringify(obj));
}
restore() {
const saved = localStorage.getItem(this.key);
if (!saved) return;
const data = JSON.parse(saved);
Object.entries(data).forEach(([key, value]) => {
const field = this.form.querySelector(`[name="${key}"]`);
if (field) field.value = value;
});
announce('Your previous progress has been restored.');
}
clear() {
localStorage.removeItem(this.key);
}
}
Plain Language Principles
Plain language is essential for cognitive Accessibility. Follow these guidelines:
| Principle | Example (Before) | Example (After) |
|---|---|---|
| Use active voice | "The file was deleted by the system" | "The system deleted the file" |
| Short sentences | Keep sentences under 20 words | Break long sentences in half |
| Common words | "Utilize the configuration panel to initiate a threat assessment" | "Open Settings to start a scan" |
| Define jargon | "Ransomware" | "Ransomware — a virus that locks your files" |
| One idea per paragraph | Combine multiple concepts | Separate each idea clearly |
<!-- Plain language alert in Durga Antivirus Pro -->
<div role="alert" class="threat-alert" style="
background: #fff3cd; border: 1px solid #ffc107;
padding: 16px; border-radius: 8px;
">
<h3>Threat found: Trojan.Generic.2</h3>
<p>This file contains a virus that can steal your data.</p>
<p><strong>What we did:</strong> We blocked the file. It cannot harm your computer.</p>
<p><strong>Next step:</strong> Run a full scan to check for more threats.</p>
<button onclick="startFullScan()">Run full scan</button>
<button onclick="dismissAlert()">I understand, dismiss</button>
</div>
Common Mistakes
1. Using Carousels and Auto-Rotating Content
Auto-rotating carousels force users to read at a set pace. Users with cognitive disabilities may need more time. Always provide pause controls and manual navigation.
2. Dense Walls of Text
Large blocks of text without headings, bullet points, or visuals overwhelm users with dyslexia and ADHD. Break content into scannable chunks.
3. Inconsistent Navigation
Moving the search bar, changing menu order, or using different labels for the same action across pages disorients users with autism and executive dysfunction.
4. Uncontrolled Motion and Animation
Parallax scrolling, animated backgrounds, and transitions without prefers-reduced-motion support cause nausea and sensory overload.
5. Complex Error Messages
"Error 0x87E10BD0" tells the user nothing. A good error message says "Connection failed. Check your internet and try again."
6. No Time Limit Controls
If a session times out without warning, users with ADHD who got distracted lose all their work. Always warn before timeout and allow extension.
7. Jargon-Heavy Interfaces
Security software is especially prone to jargon. Terms like "heuristic analysis" or "sandboxing" should include tooltip explanations or plain language alternatives.
Practice Questions
1. Which WCAG success criterion addresses reading level?
3.1.5 Reading Level (AAA). It recommends content be written at or below lower secondary education level.
2. Why should auto-playing media be avoided for cognitive Accessibility?
Auto-playing media causes sensory overload for users with autism, distracts users with ADHD, and disorients screen reader users who rely on audio.
3. What line-height is recommended for dyslexia-friendly text?
At least 1.5 (150%) line height, with adequate letter spacing and sans-serif fonts.
4. What is the key difference between a good and bad error message?
A good error message explains what went wrong and suggests a fix in plain language. A bad error message shows a code or generic message with no actionable information.
5. Challenge: Audit the security settings panel of a tool you use. Identify five instances of jargon that could be replaced with plain language. Rewrite each one.
Real-World Task
Enable prefers-reduced-motion support in your CSS. Then install a screen reader and navigate a complex dashboard using only the keyboard. Document every point where cognitive load becomes overwhelming (too many choices, unclear labels, no progress indicator).
FAQ
Try It Yourself
Apply plain language to a security alert from Durga Antivirus Pro:
<!-- Before: Jargon-heavy -->
<div class="alert" role="alert">
<h3>Heuristic analysis flagged anomalous Process behavior</h3>
<p>PID 3847 is attempting unauthorized registry modification in HKLM\SYSTEM\CurrentControlSet\Services.</p>
<button onclick="quarantine()">Quarantine</button>
<button onclick="allow()">Allow</button>
</div>
Rewrite it with plain language, clear next steps, and a plain-English explanation of the risk.
What's Next
Congratulations on completing this Cognitive Accessibility tutorial! Here is where to Go from here:
- Practice daily — Rewrite one error message in plain language each day
- Build a project — Create a simplified view mode for a complex interface
- Explore related topics — Learn PDF and document Accessibility next
- Join the community — Discuss with other learners and share your progress
Remember: every expert was once a beginner. Keep coding!
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro