name	accessibility-and-inclusive-design
description	Design inclusive interfaces with WCAG compliance and accessibility frameworks

Accessibility and Inclusive Design

Overview

This skill provides a systematic framework for creating universally accessible interfaces that work for everyone, regardless of ability, situation, or context.

Core Principle: Accessibility constraints make design BETTER for everyone, not just users with disabilities. High contrast helps in sunlight. Large touch targets help when distracted. Clear language helps when stressed.

Framework: The Universal Access Model - 6 dimensions ensuring comprehensive accessibility coverage.

When to Use

Load this skill when:

User mentions "accessibility", "WCAG", "inclusive design", "screen reader"
Designing or critiquing any interface (accessibility is universal)
User asks about contrast ratios, colorblind-safe design, keyboard navigation
Compliance required (legal, ethical, best practices)
Evaluating existing designs for accessibility issues

Don't use for: Pure visual aesthetics (use visual-design-foundations first, then verify with this skill)

Critical Note: This skill should be referenced by ALL other Lyra skills. Accessibility is not optional or separate - it's integrated into every design decision.

The Universal Access Model

A systematic 6-dimension framework for evaluating and ensuring universal access:

Visual Accessibility - Contrast, zooming, color-independent information
Motor Accessibility - Touch targets, keyboard navigation, no precision required
Cognitive Accessibility - Clear language, reduced mental load, forgiving
Screen Reader Compatibility - Semantic structure, labels, logical order
Temporal Accessibility - No timeouts, pauseable content, user-paced
Situational Accessibility - Works in varied contexts (noise, sunlight, one-handed)

Each dimension has specific WCAG criteria, testing methods, and patterns.

Dimension 1: VISUAL ACCESSIBILITY

Purpose: Users with vision differences (low vision, colorblindness, blindness) can access content

Evaluation Questions

Contrast:

Does text meet 4.5:1 contrast ratio (WCAG AA)?
Does large text (18pt+) meet 3:1 ratio?
Do UI components meet 3:1 contrast against backgrounds?
Is contrast even higher for critical actions (7:1 for AAA)?

Zoom & Resize:

Can users zoom to 200% without horizontal scrolling?
Does text remain readable when zoomed?
Do layouts reflow gracefully at high zoom levels?
Are font sizes relative (em, rem) not fixed (px)?

Color Independence:

Is information conveyed with more than color alone?
Can colorblind users distinguish states (red/green)?
Are links distinguishable without relying on color?
Do charts/graphs use patterns in addition to color?

Readability:

Is body text at least 16px on mobile, 14px on desktop?
Is line height comfortable (1.5x for body text)?
Is line length appropriate (45-75 characters)?
Are fonts clear and legible (avoid decorative for body)?

WCAG 2.1 AA Requirements

1.4.3 Contrast (Minimum) - Level AA:

Normal text: 4.5:1 minimum
Large text (18pt/14pt bold+): 3:1 minimum
UI components and graphics: 3:1 minimum

1.4.4 Resize Text - Level AA:

Text can be resized up to 200% without loss of content or functionality

1.4.11 Non-text Contrast - Level AA:

UI components and graphical objects: 3:1 minimum against adjacent colors

1.4.1 Use of Color - Level A:

Color is not the only visual means of conveying information

Patterns (Good)

High Contrast Text:

Body text: #000000 on #FFFFFF (21:1) ✓
Links: #0066CC on #FFFFFF (8.6:1) ✓
Large headings: #333333 on #FFFFFF (12.6:1) ✓

Color + Icon/Text Indicators:

Error: Red background + "X" icon + "Error" text
Success: Green background + checkmark icon + "Success" text
Warning: Yellow background + "!" icon + "Warning" text
(Colorblind users see icon/text, not just color)

Link Differentiation:

Links: Blue (#0066CC) + underline (always visible)
Or: Different font weight + underline on hover
Not: Just color change (insufficient for colorblind)

Zoom-Friendly Layouts:

Relative units: font-size: 1rem (16px base)
Viewport units: max-width: 90vw
Flexible grids: display: flex with wrap
Not: Fixed pixel widths everywhere

Anti-Patterns (Problematic)

Low Contrast:

Light gray on white: #999999 on #FFFFFF (2.8:1) ✗
Fails WCAG AA (needs 4.5:1)

Color as Sole Indicator:

"Red items are errors, green items are valid"
Colorblind users can't distinguish ✗
Add icons/text to each state ✓

Fixed Font Sizes:

font-size: 12px; (user can't resize)
Use: font-size: 0.75rem; (scales with user preference)

Tiny Text:

Body text at 12px on mobile (too small) ✗
Minimum 16px on mobile, 14px on desktop ✓

Insufficient Line Height:

line-height: 1.0; (cramped, hard to read) ✗
line-height: 1.5; (comfortable spacing) ✓

Testing Methods

Contrast Tools:

WebAIM Contrast Checker: https://webaim.org/resources/contrastchecker/
Stark plugin (Figma/Sketch): Real-time contrast checking
Chrome DevTools: Built-in contrast ratio in color picker
Accessible Colors: Suggests accessible alternatives

Colorblindness Simulation:

Stark (Figma): Protanopia, Deuteranopia, Tritanopia filters
Colorblinding Chrome extension
Sim Daltonism (macOS): System-wide colorblind filters
Test with Protanopia (red-blind) and Deuteranopia (green-blind) at minimum

Zoom Testing:

Browser zoom to 200% (Cmd/Ctrl + Plus)
Check for horizontal scrolling (bad)
Check for overlapping content (bad)
Check for cut-off text (bad)

Visual Testing Checklist:

All text meets 4.5:1 contrast (WebAIM)
UI components meet 3:1 contrast
Links distinguishable without color
Zoom to 200% works without horizontal scroll
Colorblind simulation passes (Stark)
Body text minimum 16px mobile, 14px desktop

Dimension 2: MOTOR ACCESSIBILITY

Purpose: Users with motor control differences (tremors, limited dexterity, paralysis) can interact

Evaluation Questions

Touch Targets:

Are all interactive elements at least 44x44px (iOS) or 48x48dp (Android)?
Is spacing adequate between tap targets (8px minimum)?
Can users with tremors hit targets reliably?
Are critical actions away from screen edges (accidental activation)?

Keyboard Navigation:

Can users navigate entire interface with keyboard only?
Is tab order logical (top-to-bottom, left-to-right)?
Are focus indicators visible (2px outline minimum)?
Can users activate all functions via keyboard?
Are keyboard shortcuts provided for common actions?

No Precision Required:

Can users interact without fine motor control?
Are drag-and-drop operations optional (alternative method)?
Are hover-only interactions avoided?
Can users pause/cancel actions (no irreversible quick gestures)?

WCAG 2.1 AA Requirements

2.1.1 Keyboard - Level A:

All functionality available via keyboard interface

2.1.2 No Keyboard Trap - Level A:

Focus can move away from component using keyboard alone

2.4.7 Focus Visible - Level AA:

Keyboard focus indicator is visible

2.5.5 Target Size - Level AAA (Best Practice):

Touch targets at least 44x44 CSS pixels (iOS guideline, WCAG AAA)

Patterns (Good)

Large Touch Targets:

Buttons: min-height: 48px, min-width: 48px
Icons: 44x44px clickable area (icon may be smaller, hit area large)
Form inputs: height: 48px
List items: min-height: 56dp (Android Material)

Adequate Spacing:

Margin between buttons: 8px minimum
Padding inside buttons: 12px vertical, 24px horizontal
Space between form fields: 16px minimum

Visible Focus Indicators:

button:focus {
  outline: 2px solid #0066CC;
  outline-offset: 2px;
}

Do not: outline: none; (removes accessibility) ✗

Keyboard Shortcuts:

Common actions:
- Tab: Next element
- Shift+Tab: Previous element
- Enter/Space: Activate button/link
- Esc: Close modal/dismiss
- Arrow keys: Navigate menus/lists

Custom shortcuts:
- Cmd/Ctrl+S: Save
- Cmd/Ctrl+Z: Undo
- /: Focus search (common web pattern)

Skip Links:

<a href="#main-content" class="skip-link">
  Skip to main content
</a>

Allows keyboard users to skip repetitive navigation

Anti-Patterns (Problematic)

Tiny Touch Targets:

Buttons: 30x30px (too small, frustrating) ✗
Minimum 44x44px (iOS), 48x48dp (Android) ✓

Crowded Tap Targets:

Buttons with 2px spacing (accidental taps) ✗
Minimum 8px spacing between interactive elements ✓

No Focus Indicator:

*:focus { outline: none; } ✗
Keyboard users can't see where they are
Keep default or enhance: outline: 2px solid blue; ✓

Hover-Only Interactions:

Dropdown menu appears only on hover (keyboard inaccessible) ✗
Add keyboard trigger: click or Enter key ✓

Illogical Tab Order:

HTML order: Header → Sidebar → Content
Visual order: Header → Content → Sidebar
Tab order follows HTML (confusing) ✗
Reorder HTML or use tabindex carefully ✓

Mouse-Only Actions:

Right-click context menus only (no keyboard equivalent) ✗
Provide button or keyboard shortcut alternative ✓

Testing Methods

Keyboard Navigation Test:

Unplug/hide your mouse
Navigate entire interface with Tab, Shift+Tab, Enter, Space, Esc, Arrows
Check:
- Can you reach all interactive elements?
- Is focus indicator always visible?
- Is tab order logical?
- Can you activate all functions?
- Can you escape modals/menus?

Touch Target Testing:

Use browser DevTools to measure elements (should be 44x44px minimum)
Test on actual mobile device (finger test)
Try tapping with thumb while holding phone (reachability)

Motor Accessibility Checklist:

All touch targets 44x44px minimum
8px spacing between interactive elements
Entire interface navigable via keyboard only
Focus indicators visible on all interactive elements
Tab order is logical
No hover-only critical interactions
Keyboard shortcuts for common actions

Dimension 3: COGNITIVE ACCESSIBILITY

Purpose: Users with cognitive differences (dyslexia, ADHD, anxiety, memory issues) can understand

Evaluation Questions

Language Clarity:

Is language simple and clear (8th grade reading level)?
Are sentences short (20 words or less)?
Is jargon avoided or explained?
Are instructions direct and actionable?

Cognitive Load:

Is information chunked (5-7 items per group)?
Are headings and lists used to organize content?
Is progressive disclosure used (simple first, advanced later)?
Are users required to remember information across screens?

Error Prevention & Recovery:

Are errors prevented with constraints and validation?
Are error messages clear and helpful?
Can users easily undo mistakes?
Are confirmations provided for destructive actions?

Visual Clarity:

Is layout consistent across screens?
Are visual cues provided (icons, color, spacing)?
Is there adequate white space (not overwhelming)?
Are animations purposeful (not distracting)?

WCAG 2.1 AA Requirements

3.1.5 Reading Level - Level AAA (Best Practice):

Text does not require reading ability more advanced than lower secondary education

3.2.3 Consistent Navigation - Level AA:

Navigational mechanisms that are repeated occur in same order

3.2.4 Consistent Identification - Level AA:

Components with same functionality are identified consistently

3.3.1 Error Identification - Level A:

Errors are identified and described to user in text

3.3.2 Labels or Instructions - Level A:

Labels or instructions provided when content requires user input

3.3.3 Error Suggestion - Level AA:

Suggestions provided when input error is automatically detected

3.3.4 Error Prevention (Legal, Financial, Data) - Level AA:

Submissions are reversible, checked, or confirmed

Patterns (Good)

Clear Language:

Good: "Enter your email address"
Bad: "Input your electronic mail identifier"

Good: "Delete this file?"
Bad: "Permanently remove this resource from the filesystem?"

Target 8th grade reading level (Hemingway Editor)

Chunked Information:

Group related fields:
┌─────────────────────┐
│ Contact Information │
│ - Name              │
│ - Email             │
│ - Phone             │
└─────────────────────┘

Not: 15 fields in one long list

Progressive Disclosure:

Default view: Basic settings (3-5 options)
"Advanced" button reveals: Power-user settings
Not: All 30 settings visible at once (overwhelming)

Helpful Error Messages:

Good: "Email format incorrect. Example: name@example.com"
Bad: "Invalid input in field 3"

Good: "Password must contain: 8 characters, 1 number, 1 uppercase"
Bad: "Password requirements not met"

Confirmation for Destructive Actions:

User clicks "Delete Account"
Modal: "Are you sure? This will permanently delete your account and all data. Type 'DELETE' to confirm."
Prevents accidental data loss

Visual Hierarchy:

Use headings, spacing, color to create structure:
- H1: Page title (32px, bold)
- H2: Section headers (24px, bold)
- H3: Subsections (18px, bold)
- Body: Content (16px, regular)
- Spacing: 24px between sections

Anti-Patterns (Problematic)

Complex Jargon:

"Utilize the aforementioned methodology" ✗
"Use this method" ✓

Wall of Text:

Paragraph with 200 words, no headings or lists ✗
Break into sections with headings, use bullet lists ✓

Overwhelming Choices:

15 buttons on one screen (decision paralysis) ✗
1 primary action, 1-2 secondary, hide rest in menu ✓

Cryptic Errors:

"Error 4032" (user has no idea what to do) ✗
"Email already in use. Try logging in instead." ✓

No Confirmation for Destructive Actions:

Single click deletes account (disaster) ✗
Confirmation modal with type-to-confirm ✓

Inconsistent Patterns:

"Save" button top-right on page 1, bottom-left on page 2 ✗
Consistent placement across all screens ✓

Testing Methods

Readability Testing:

Hemingway Editor: Checks reading level (aim for grade 8 or lower)
Readable.io: Analyzes content complexity
Read text aloud: If it sounds awkward, rewrite

Cognitive Load Testing:

Count choices per screen (5-7 max before chunking)
Measure form fields (chunk into logical groups)
Check memory requirements (can user see info they need to reference?)

User Testing:

Watch users complete tasks (where do they hesitate?)
Ask users to explain what they think will happen (mental model check)
Test with users with cognitive disabilities if possible

Cognitive Accessibility Checklist:

Language at 8th grade level or lower (Hemingway)
Sentences short (20 words or less)
Information chunked (5-7 items per group)
Error messages clear and actionable
Destructive actions require confirmation
Consistent navigation and patterns
Adequate white space and visual structure

Dimension 4: SCREEN READER COMPATIBILITY

Purpose: Users with screen readers (NVDA, JAWS, VoiceOver, TalkBack) can navigate and understand

Evaluation Questions

Semantic HTML:

Are proper HTML elements used (button, nav, main, article)?
Is heading hierarchy logical (h1 → h2 → h3, no skipping)?
Are landmarks used (header, nav, main, aside, footer)?
Are lists used for lists (ul, ol, not divs)?

Alternative Text:

Do images have descriptive alt text?
Are decorative images marked as decorative (alt="")?
Do icon buttons have text labels or aria-label?
Are complex images explained (charts, diagrams)?

Focus Management:

Is focus order logical?
Does focus move to opened modals?
Is focus trapped in modals (can't escape to background)?
Does focus return to trigger element when modal closes?

ARIA Labels:

Are ARIA labels used when semantic HTML insufficient?
Are form inputs properly labeled?
Are dynamic updates announced (aria-live)?
Are expanded/collapsed states indicated (aria-expanded)?

WCAG 2.1 AA Requirements

1.1.1 Non-text Content - Level A:

Images have text alternatives

1.3.1 Info and Relationships - Level A:

Information, structure, relationships conveyed through markup

2.4.1 Bypass Blocks - Level A:

Mechanism to skip repeated blocks of content

2.4.6 Headings and Labels - Level AA:

Headings and labels describe topic or purpose

4.1.2 Name, Role, Value - Level A:

For all UI components, name and role can be programmatically determined

4.1.3 Status Messages - Level AA:

Status messages can be programmatically determined and announced

Patterns (Good)

Semantic HTML:

<header>
  <nav aria-label="Main navigation">
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about">About</a></li>
    </ul>
  </nav>
</header>

<main>
  <h1>Page Title</h1>
  <article>
    <h2>Section Heading</h2>
    <p>Content here...</p>
  </article>
</main>

<footer>
  <p>&copy; 2025 Company</p>
</footer>

Not: <div class="header">, <div class="nav">, <div class="button">

Descriptive Alt Text:

Good:
<img src="chart.png" alt="Line chart showing revenue growth from $1M in 2020 to $5M in 2025">

Bad:
<img src="chart.png" alt="chart">
<img src="chart.png" alt=""> (if informative, needs description)

Decorative:
<img src="decorative-line.png" alt=""> (empty alt for decorative)

Heading Hierarchy:

<h1>Page Title</h1>
  <h2>Section 1</h2>
    <h3>Subsection 1.1</h3>
    <h3>Subsection 1.2</h3>
  <h2>Section 2</h2>
    <h3>Subsection 2.1</h3>

Not: <h1> → <h3> → <h2> (illogical)

Form Labels:

<label for="email">Email Address</label>
<input type="email" id="email" name="email" required>

Or with ARIA:
<input type="email" aria-label="Email Address" required>

Not: Placeholder as label (disappears when typing)

Icon Button Labels:

<button aria-label="Close modal">
  <svg><!-- X icon --></svg>
</button>

Or:
<button>
  <svg aria-hidden="true"><!-- X icon --></svg>
  <span class="visually-hidden">Close modal</span>
</button>

Skip Links:

<a href="#main-content" class="skip-link">Skip to main content</a>

<!-- Allows screen reader users to skip navigation -->

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

Live Regions:

<div role="status" aria-live="polite">
  File uploaded successfully
</div>

aria-live="polite": Announces when screen reader finishes current task
aria-live="assertive": Interrupts to announce immediately

Anti-Patterns (Problematic)

Divs for Everything:

<div class="button" onclick="doSomething()">Click me</div> ✗

Use: <button onclick="doSomething()">Click me</button> ✓

Missing Alt Text:

<img src="important-chart.png"> ✗
<img src="important-chart.png" alt="Revenue chart"> ✓

Skipping Heading Levels:

<h1>Title</h1>
<h3>Subsection</h3> ✗ (skipped h2)

Use logical hierarchy: h1 → h2 → h3 ✓

Placeholder as Label:

<input type="text" placeholder="Email"> ✗
(Placeholder disappears when typing, screen reader may not announce)

Use: <label for="email">Email</label> ✓
     <input type="email" id="email">

Icon Without Label:

<button><i class="icon-trash"></i></button> ✗
(Screen reader announces "button" - user has no idea what it does)

<button aria-label="Delete"><i class="icon-trash"></i></button> ✓

No Focus Management in Modals:

Modal opens, focus stays on background element ✗
Focus moves to modal, traps within modal, returns on close ✓

Testing Methods

Screen Reader Testing:

Windows - NVDA (Free):

Download NVDA: https://www.nvaccess.org/download/
Install and launch
Navigate with:
- Down arrow: Next item
- H: Next heading
- Tab: Next interactive element
- Enter: Activate link/button
- Insert+Down: Read all
Check: Can you navigate? Do elements announce correctly?

Windows - JAWS (Commercial, most popular):

Similar to NVDA, industry standard for Windows
Free 40-minute trial sessions

macOS - VoiceOver (Built-in):

Enable: Cmd+F5
Navigate with:
- VO+Right Arrow: Next item (VO = Ctrl+Option)
- VO+H: Next heading
- Tab: Next interactive element
- VO+Space: Activate
Check: Does content make sense? Are labels clear?

Mobile - TalkBack (Android) / VoiceOver (iOS):

Enable in Accessibility settings
Swipe right to next element
Double-tap to activate
Test: Can you complete core tasks?

Automated Testing:

Axe DevTools (Chrome): Catches 30-40% of issues automatically
Lighthouse (Chrome): Accessibility score and specific issues
WAVE (browser extension): Visual feedback on accessibility issues

Manual Testing Checklist:

Navigate entire site with screen reader (NVDA/VoiceOver)
Check heading hierarchy (use headings list in screen reader)
Verify all images have alt text
Test forms (labels announced correctly?)
Test modals (focus management works?)
Run automated tests (Axe, Lighthouse, WAVE)
No elements announced as "clickable" or "button" without context

Dimension 5: TEMPORAL ACCESSIBILITY

Purpose: Users have adequate time to read, interact, and complete tasks

Evaluation Questions

Timeouts:

Are timeouts avoidable or adjustable?
Are users warned before session expires?
Can users extend timeouts easily?
Are timeouts necessary or arbitrary?

Moving Content:

Can users pause, stop, or hide animations?
Is auto-playing content controllable?
Are carousels pausable?
Do animations respect prefers-reduced-motion?

Time Limits:

Are time limits user-adjustable (extends, disables)?
Are real-time events (auctions) the only exception?
Are users given 20 seconds warning minimum before timeout?
Can users save work if timeout occurs?

WCAG 2.1 AA Requirements

2.2.1 Timing Adjustable - Level A:

User can turn off, adjust, or extend time limits (except real-time events)

2.2.2 Pause, Stop, Hide - Level A:

User can pause, stop, or hide moving, blinking, or scrolling content

2.2.6 Timeouts - Level AAA (Best Practice):

Users are warned of the duration of inactivity that could cause data loss

Patterns (Good)

No Auto-Timeout on Critical Flows:

Form filling: No timeout (or 20+ minutes with warning)
Shopping cart: No timeout (save for later)
Authentication: 30-minute timeout with 5-minute warning

Not: 2-minute timeout on complex form (anxiety-inducing)

Timeout Warnings:

Modal appears 5 minutes before timeout:
"Your session will expire in 5 minutes due to inactivity.
[Extend Session] [Log Out]"

Clicking "Extend Session" resets timer

Pausable Animations:

Carousel with controls:
[Previous] [Pause/Play] [Next]

Autoplay pauses on hover or focus
User can disable autoplay entirely

Respect prefers-reduced-motion:

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Users with motion sensitivity can disable animations

User-Controlled Content:

Video/Audio:
- Autoplay disabled (or muted with clear unmute button)
- Play/Pause controls always visible
- Volume controls available

Anti-Patterns (Problematic)

Tight Timeouts:

2-minute timeout on multi-page form ✗
Users with cognitive disabilities need more time
Minimum 20 minutes, with warning and extend option ✓

No Timeout Warning:

Session expires suddenly, work lost ✗
Warning 5+ minutes before, with extend option ✓

Auto-Playing Video:

Video plays on page load with sound ✗
(Disorienting, accessibility violation)
Require user interaction to play ✓

Unstoppable Animations:

Constant animation with no pause button ✗
Motion sickness, distraction
Provide pause control ✓

Carousel Auto-Advance:

Carousel advances every 3 seconds, can't pause ✗
Users with reading difficulties can't keep up
Pause on hover, manual controls, disable autoplay ✓

Testing Methods

Timeout Testing:

Leave interface idle for timeout period
Check: Is warning shown before timeout?
Check: Can user extend session?
Check: Is work saved if timeout occurs?

Animation Testing:

Enable prefers-reduced-motion in OS settings (macOS: Accessibility > Display > Reduce Motion)
Check: Do animations disable or significantly reduce?
Check: Is functionality still accessible without animations?

Auto-Play Testing:

Load pages with video/audio/carousels
Check: Does anything auto-play without user action?
Check: Are pause controls visible and accessible?
Check: Can user disable autoplay permanently?

Temporal Accessibility Checklist:

No critical timeouts under 20 minutes
Timeout warnings shown 5+ minutes before expiration
Users can extend timeouts easily
All animations pausable/stoppable
Respect prefers-reduced-motion setting
No auto-playing video/audio
Carousels have pause controls

Dimension 6: SITUATIONAL ACCESSIBILITY

Purpose: Design works in varied real-world contexts and situations

Evaluation Questions

Environmental Contexts:

Does it work in bright sunlight (mobile)?
Does it work in low light (desktop at night)?
Does it work with one hand (mobile, carrying things)?
Does it work in noisy environments (captions available)?
Does it work in quiet environments (visual feedback, not just audio)?

Connection Contexts:

Does it work on slow connections (3G, rural)?
Does it work offline (progressive web app)?
Are large assets lazy-loaded?
Is there feedback during loading?

Device Contexts:

Does it work on small screens (iPhone SE)?
Does it work on large screens (4K monitors)?
Does it work on old devices (performance)?
Does it work on different input methods (touch, mouse, keyboard, voice)?

User Contexts:

Does it work when distracted (errors prevented)?
Does it work when stressed (clear language)?
Does it work when tired (high contrast, large text)?
Does it work for temporary disabilities (broken arm, eye dilation)?

Patterns (Good)

High Contrast Mode:

@media (prefers-contrast: high) {
  body {
    background: #000000;
    color: #FFFFFF;
  }
  a {
    color: #FFFF00; /* Yellow on black */
  }
}

System-level high contrast settings respected

Dual Feedback (Visual + Audio):

Notification arrives:
- Visual: Toast notification on screen
- Audio: Subtle sound (optional, user can disable)
- Vibration: Haptic feedback (mobile)

Works in noisy (visual) and quiet (visual) environments

Progressive Enhancement:

Core content: Loads first, readable without JS/CSS
Styling: CSS loads, visual hierarchy added
Interactivity: JS loads, enhanced interactions

Works on slow connections (core content first)
Works with JS disabled (basic functionality remains)

Offline Functionality:

Service Worker caches essential assets
Offline page explains situation: "You're offline. Some features unavailable."
Work continues (drafts saved locally, sync when back online)

Responsive Images:

<picture>
  <source media="(max-width: 600px)" srcset="image-small.jpg">
  <source media="(max-width: 1200px)" srcset="image-medium.jpg">
  <img src="image-large.jpg" alt="Description">
</picture>

Appropriate size loaded based on screen (saves bandwidth)

One-Handed Use (Mobile):

Primary actions in thumb zone (bottom 50% of screen)
Swipe gestures accessible from edges
Important actions reachable without shifting grip

Anti-Patterns (Problematic)

Low Contrast in Sunlight:

Light gray on white (#CCCCCC on #FFFFFF) ✗
Invisible in bright sunlight on mobile
Use high contrast: #000000 on #FFFFFF ✓

Audio-Only Feedback:

Error announced via sound only ✗
Fails in quiet environments (library, meetings)
Visual indicator required (toast, highlight) ✓

Heavy Assets on Slow Connections:

5MB images load before content ✗
Lazy load images, optimize sizes, show content first ✓

Requires Two Hands (Mobile):

Critical action in top-left corner (requires shifting grip) ✗
Primary actions in thumb zone (bottom half) ✓

No Offline Fallback:

Blank white screen when offline ✗
Offline page explaining situation + cached content ✓

Fixed Design (No Responsive):

Desktop-only design (breaks on mobile) ✗
Responsive design (adapts to all screens) ✓

Testing Methods

Sunlight Testing:

Test mobile app outdoors in bright sunlight
Check: Can you read text?
Check: Can you see buttons?
Solution: Increase contrast, larger text

One-Handed Testing:

Use phone with one hand only
Check: Can you reach primary actions?
Check: Can you navigate comfortably?

Slow Connection Testing:

Chrome DevTools > Network > Throttle to "Slow 3G"
Check: Does core content load first?
Check: Is there loading feedback?
Check: Can user accomplish tasks on slow connection?

Offline Testing:

Chrome DevTools > Network > Offline
Reload page
Check: Is there offline fallback?
Check: Is user informed?

Noise Testing:

Disable device sound
Check: Can you still use all features?
Check: Is visual feedback provided?

Situational Accessibility Checklist:

High contrast mode supported
Works in bright sunlight (high contrast)
Works in noisy and quiet environments (dual feedback)
Works on slow connections (progressive enhancement)
Works offline (service worker, cached content)
Works with one hand (mobile)
Works on small and large screens (responsive)

Practical Application

Step-by-Step: Accessibility Audit

Step 1: Automated Scan

Install Axe DevTools (Chrome extension)
Open your design/site in browser
Run Axe scan
Note critical and serious issues (contrast, missing labels, etc.)

Step 2: Visual Accessibility

Check contrast ratios (WebAIM Contrast Checker)
Test colorblind simulation (Stark or Colorblinding extension)
Zoom to 200% (check for horizontal scroll, overlapping)
Verify text sizes (16px mobile minimum)

Step 3: Motor Accessibility

Unplug mouse, navigate with keyboard only
Check focus indicators visible
Measure touch targets (44x44px minimum)
Verify spacing between interactive elements (8px)

Step 4: Cognitive Accessibility

Read content aloud (does it make sense?)
Check reading level (Hemingway Editor - grade 8 or lower)
Count choices per screen (5-7 max before chunking)
Test error messages (clear and actionable?)

Step 5: Screen Reader

Enable screen reader (NVDA on Windows, VoiceOver on macOS)
Navigate with keyboard shortcuts (arrows, H for headings, Tab for links)
Check: Are labels clear? Is order logical? Are images described?
Test forms (are fields labeled correctly?)

Step 6: Temporal Accessibility

Check for timeouts (are they adjustable?)
Test animations (can user pause/stop?)
Enable prefers-reduced-motion (do animations disable?)
Check auto-playing content (is it user-controlled?)

Step 7: Situational Accessibility

Test in bright light (can you read it?)
Test on slow connection (DevTools throttling)
Test offline (is there fallback?)
Test one-handed (mobile - can you reach actions?)

Step 8: Document & Prioritize

List all issues by WCAG severity (A > AA > AAA)
Prioritize: Critical (blocking) > Major (difficult) > Minor (annoying)
Create fix plan with ownership and deadlines
Re-test after fixes

WCAG 2.1 AA Compliance Quick Reference

Level A (Must Have)

1.1.1 Non-text Content - Images have alt text 1.3.1 Info and Relationships - Semantic HTML structure 2.1.1 Keyboard - All functionality keyboard accessible 2.1.2 No Keyboard Trap - Can move focus away 2.4.1 Bypass Blocks - Skip links for navigation 3.3.1 Error Identification - Errors described in text 3.3.2 Labels or Instructions - Form fields labeled

Level AA (Should Have)

1.4.3 Contrast (Minimum) - 4.5:1 for text, 3:1 for large text 1.4.4 Resize Text - 200% zoom without loss 1.4.11 Non-text Contrast - 3:1 for UI components 2.4.6 Headings and Labels - Describe purpose 2.4.7 Focus Visible - Keyboard focus indicator visible 3.2.3 Consistent Navigation - Same order across pages 3.2.4 Consistent Identification - Same function, same label 3.3.3 Error Suggestion - Suggestions for fixing errors 3.3.4 Error Prevention - Reversible, checked, or confirmed

Level AAA (Nice to Have)

1.4.6 Contrast (Enhanced) - 7:1 for text, 4.5:1 for large text 2.5.5 Target Size - 44x44px touch targets 3.1.5 Reading Level - Lower secondary education level

Note: WCAG AA is the legal standard in most jurisdictions. AAA is best practice.

Accessibility Tools Reference

Contrast Checkers

WebAIM Contrast Checker: https://webaim.org/resources/contrastchecker/
Stark (Figma/Sketch): Real-time contrast checking in design tools
Chrome DevTools: Color picker shows contrast ratio

Colorblind Simulation

Stark: Protanopia, Deuteranopia, Tritanopia filters (Figma)
Colorblinding: Chrome extension
Sim Daltonism: macOS system-wide filters

Screen Readers

NVDA (Windows): Free, open-source - https://www.nvaccess.org/
JAWS (Windows): Commercial, most popular - https://www.freedomscientific.com/
VoiceOver (macOS/iOS): Built-in (Cmd+F5 to enable)
TalkBack (Android): Built-in (Settings > Accessibility)

Automated Testing

Axe DevTools: Chrome/Firefox extension, catches 30-40% of issues
Lighthouse: Chrome built-in, accessibility score + specific issues
WAVE: Browser extension, visual feedback on issues

Readability

Hemingway Editor: Checks reading level (aim for grade 8 or lower)
Readable.io: Analyzes content complexity

Performance & Loading

Chrome DevTools Network Throttling: Test slow connections
WebPageTest: Real-world performance testing

Cross-Platform Accessibility Considerations

Mobile (iOS/Android)

Voice Control:

iOS: Voice Control for hands-free operation
Android: Voice Access for voice navigation

Magnification:

iOS: Zoom (triple-tap with three fingers)
Android: Magnification gestures (triple-tap)

Screen Readers:

iOS: VoiceOver (swipe right to next element, double-tap to activate)
Android: TalkBack (swipe right to next element, double-tap to activate)

Touch Targets:

iOS: 44x44pt minimum
Android: 48x48dp minimum

References:

iOS: Accessibility > lyra/ux-designer/mobile-design-patterns
Android: Accessibility > lyra/ux-designer/mobile-design-patterns

Web Applications

Keyboard Shortcuts:

Essential: Tab, Shift+Tab, Enter, Esc, Arrow keys
Optional: Cmd/Ctrl+S (save), Cmd/Ctrl+F (find), / (search)

Focus Management:

Modals: Trap focus, return to trigger on close
Single-page apps: Manage focus on route changes

ARIA Live Regions:

Dynamic updates announced to screen readers
Form validation errors announced

References:

Web accessibility > lyra/ux-designer/web-application-design

Desktop Software

Keyboard-First:

All functions accessible via keyboard
Customizable shortcuts for power users

Zoom:

System-level zoom support (macOS: Cmd+Plus, Windows: Ctrl+Plus)
Application-level zoom for specific content

High Contrast Mode:

Windows: High Contrast themes
macOS: Increase Contrast setting

References:

Desktop accessibility > lyra/ux-designer/desktop-software-design

Game UI

Colorblind Modes:

Deuteranopia (red-green)
Protanopia (red-green)
Tritanopia (blue-yellow)

Subtitles & Captions:

Dialogue subtitles
Sound effect indicators (footsteps, gunfire direction)

Difficulty Adjustments:

Easier difficulty for cognitive accessibility
Assist modes for motor accessibility

References:

Game UI accessibility > lyra/ux-designer/game-ui-design

Common Accessibility Mistakes & Fixes

Mistake 1: Low Contrast Text

Problem: Light gray text on white background (#999 on #fff = 2.8:1) Fix: Use darker gray (#595959 on #fff = 7:1) or black (#000 on #fff = 21:1) Tool: WebAIM Contrast Checker

Mistake 2: Color as Sole Indicator

Problem: "Red items are errors" (colorblind users can't see red) Fix: Red + "X" icon + "Error" text Tool: Stark colorblind simulation

Mistake 3: Missing Alt Text

Problem: <img src="chart.png"> (screen reader says "image") Fix: <img src="chart.png" alt="Revenue growth from $1M to $5M over 5 years"> Tool: Screen reader testing (NVDA/VoiceOver)

Mistake 4: Divs for Buttons

Problem: <div onclick="submit()">Submit</div> (not keyboard accessible) Fix: <button onclick="submit()">Submit</button> Tool: Keyboard navigation test (unplug mouse)

Mistake 5: No Focus Indicators

Problem: *:focus { outline: none; } (keyboard users lost) Fix: button:focus { outline: 2px solid blue; } Tool: Keyboard navigation test

Mistake 6: Tiny Touch Targets

Problem: 30x30px buttons (frustrating on mobile) Fix: 44x44pt (iOS) or 48x48dp (Android) minimum Tool: DevTools measure, finger test on device

Mistake 7: Auto-Playing Video

Problem: Video plays on page load with sound (disorienting) Fix: Require user interaction to play, or autoplay muted with clear controls Tool: Load page with sound on

Mistake 8: Illogical Heading Hierarchy

Problem: <h1> → <h4> → <h2> (screen reader users confused) Fix: Logical hierarchy: <h1> → <h2> → <h3> Tool: Screen reader headings list (NVDA: Insert+F7)

Mistake 9: Placeholder as Label

Problem: <input placeholder="Email"> (disappears when typing) Fix: <label for="email">Email</label><input id="email"> Tool: Screen reader test (is label announced?)

Mistake 10: Timeout Without Warning

Problem: Session expires at 5 minutes, work lost Fix: 20+ minute timeout with 5-minute warning and extend option Tool: Leave interface idle, observe timeout behavior

Related Skills

Core UX Skills:

lyra/ux-designer/visual-design-foundations - Color contrast, typography readability (Dimension 1, 5)
lyra/ux-designer/interaction-design-patterns - Keyboard navigation, focus states, touch targets (Dimension 2, 4)
lyra/ux-designer/information-architecture - Logical structure, clear navigation (Dimension 3, 4)
lyra/ux-designer/ux-fundamentals - Accessibility principles and terminology

Platform Skills:

lyra/ux-designer/mobile-design-patterns - Touch target sizing, platform accessibility APIs
lyra/ux-designer/web-application-design - ARIA, semantic HTML, keyboard shortcuts
lyra/ux-designer/desktop-software-design - Keyboard-first design, system accessibility settings
lyra/ux-designer/game-ui-design - Colorblind modes, subtitle/caption systems

Cross-Faction:

muna/technical-writer/clarity-and-style - Plain language, 8th grade reading level (Dimension 3)

Further Resources

WCAG Guidelines:

WCAG 2.1: https://www.w3.org/WAI/WCAG21/quickref/
WCAG 2.2 (latest): https://www.w3.org/WAI/WCAG22/quickref/

Testing Tools:

Axe DevTools: https://www.deque.com/axe/devtools/
WAVE: https://wave.webaim.org/
Lighthouse: Built into Chrome DevTools

Screen Readers:

NVDA (Windows): https://www.nvaccess.org/
JAWS (Windows): https://www.freedomscientific.com/
VoiceOver (macOS): Built-in (Cmd+F5)

Learning:

WebAIM: https://webaim.org/ (excellent articles and guides)
A11y Project: https://www.a11yproject.com/ (community-driven resources)
Inclusive Components: https://inclusive-components.design/

Remember: Accessibility is not optional. It's a legal requirement in most jurisdictions and an ethical imperative. Design for everyone from the start - retrofitting accessibility is expensive and incomplete.

Install Skill

SKILL.md

Accessibility and Inclusive Design

Overview

When to Use

The Universal Access Model

Dimension 1: VISUAL ACCESSIBILITY

Evaluation Questions

WCAG 2.1 AA Requirements

Patterns (Good)

Anti-Patterns (Problematic)

Testing Methods

Dimension 2: MOTOR ACCESSIBILITY

Evaluation Questions

WCAG 2.1 AA Requirements

Patterns (Good)

Anti-Patterns (Problematic)

Testing Methods

Dimension 3: COGNITIVE ACCESSIBILITY

Evaluation Questions

WCAG 2.1 AA Requirements

Patterns (Good)

Anti-Patterns (Problematic)

Testing Methods

Dimension 4: SCREEN READER COMPATIBILITY

Evaluation Questions

WCAG 2.1 AA Requirements

Patterns (Good)

Anti-Patterns (Problematic)

Testing Methods

Dimension 5: TEMPORAL ACCESSIBILITY

Evaluation Questions

WCAG 2.1 AA Requirements

Patterns (Good)

Anti-Patterns (Problematic)

Testing Methods

Dimension 6: SITUATIONAL ACCESSIBILITY

Evaluation Questions

Patterns (Good)

Anti-Patterns (Problematic)

Testing Methods

Practical Application

Step-by-Step: Accessibility Audit

WCAG 2.1 AA Compliance Quick Reference

Level A (Must Have)

Level AA (Should Have)

Level AAA (Nice to Have)

Accessibility Tools Reference

Contrast Checkers

Colorblind Simulation

Screen Readers

Automated Testing

Readability

Performance & Loading

Cross-Platform Accessibility Considerations

Mobile (iOS/Android)

Web Applications

Desktop Software

Game UI

Common Accessibility Mistakes & Fixes

Mistake 1: Low Contrast Text

Mistake 2: Color as Sole Indicator

Mistake 3: Missing Alt Text

Mistake 4: Divs for Buttons

Mistake 5: No Focus Indicators

Mistake 6: Tiny Touch Targets

Mistake 7: Auto-Playing Video

Mistake 8: Illogical Heading Hierarchy

Mistake 9: Placeholder as Label

Mistake 10: Timeout Without Warning

Related Skills

Further Resources