accessible-design

3 files shipped with this skill. Inline text is the catalog copy. The upstream link is the source repository.

• skills/accessible-design/SKILL.md5.2 KBd640b16fb684upstream ↗

  ---
  name: accessible-design
  description: >
    Use when checking or designing for accessibility on mobile, tablet or desktop:
    touch target size, contrast, text scaling, screen readers (VoiceOver,
    TalkBack), keyboard and switch use, reduce motion, WCAG 2.2 criteria, or an
    accessibility checklist for a design. Do not use for general visual styling
    (visual-design-system), legal compliance claims, or writing accessibility
    code for a framework.
  ---
  
  # Accessible Design
  
  Stance: frozen are WCAG 2.2 AA as the floor, platform minimums for touch, and no information carried by one sense only. Flexible are how each requirement is met in a given design.
  
  ## Hard rules
  
  - Touch targets: 44 x 44 pt on iOS (28 pt hard minimum), 48 x 48 dp on Android and the web, 8 dp apart; WCAG 2.2 AA floor is 24 x 24 CSS px or 24 px of spacing. Mechanism: small or crowded targets cause mis-taps and exclude people with tremor; the visible icon may be smaller if the hit area is padded.
  - Contrast 4.5:1 for text and 3:1 for large text and meaningful controls (WCAG 1.4.3, 1.4.11). Mechanism: low contrast fails low vision and glare.
  - Text must scale to large sizes and reflow at 320 CSS px without clipping (WCAG 1.4.4, 1.4.10). Mechanism: fixed-height boxes cut off enlarged text.
  - Every control has a name, role and state a screen reader can announce; reading order follows visual order. Mechanism: unlabeled icon buttons are silent or read as "button".
  - Do not rely on gestures, drags or multi-finger input alone; give a single-tap or button path (WCAG 2.5.7). Mechanism: switch, voice and keyboard users cannot perform them.
  - Focus is always visible and not hidden behind sticky bars (WCAG 2.4.11). Mechanism: keyboard and switch users lose their place.
  - Never use colour, sound, haptics or motion as the only signal. Mechanism: each fails for some users; pair them.
  - Sign-in must not demand memory tests, puzzles or transcription without alternatives (WCAG 3.3.8). Mechanism: cognitive load blocks access; allow paste, password managers and passkeys.
  - State accessibility claims as "meets criterion X at level AA" with the check made; never "fully accessible" or "compliant". Mechanism: conformance needs scope and evidence.
  - Act only on what the user asked. Before answering or changing anything, open the relevant files and check what is already done; report only what you checked, never guess, and do not redo finished work. Reason: guesses and repeated work waste the user's credit.
  
  ## Gate
  
  | Situation | Action |
  |---|---|
  | Quick design check | Run the checklist; mark untested items |
  | Formal audit requested | Say what an automated and manual check cover; recommend testing with disabled users; no compliance claim |
  | A hard-to-hit control needed (dense map pins) | Treat as the "essential" exception; offer an alternative way |
  | Request to drop a requirement for looks | Offer a design that keeps the requirement (padded hit area, darker shade) |
  
  ## Steps
  
  1. **Targets.** Measure hit areas, not visuals. Use [targets-and-contrast.md](references/targets-and-contrast.md).
  2. **Contrast.** Compute ratios for text, icons, borders and focus rings, in each theme.
  3. **Text scaling.** Check largest system size and browser zoom to 400 percent.
  4. **Screen reader pass.** Name every control; set order; group; mark decorative images; announce state changes.
  5. **Input alternatives.** Check one-finger, keyboard, switch and voice paths for each task.
  6. **Motion and time.** Honour reduce motion; avoid flashing; allow extensions on time limits.
  7. **Errors and help.** Identify the field, explain the fix; keep help in a consistent place (WCAG 3.2.6).
  8. **Report** what passed, failed and was not tested, with the criterion for each.
  
  ## Checklist (copy into the reply and tick as you go)
  
  ```text
  - [ ] Targets sized and spaced per platform
  - [ ] Contrast checked in each theme
  - [ ] Largest text and 320 CSS px tested
  - [ ] Names, roles, order set for a screen reader
  - [ ] Single-pointer alternative for gestures and drags
  - [ ] Visible focus, not obscured
  - [ ] No signal carried by one sense only
  - [ ] Authentication has an alternative
  - [ ] Untested items listed
  ```
  
  ## Examples
  
  **Example 1: icon toolbar**
  User says: "Check this toolbar of five 24 px icons for accessibility."
  Actions: measure hit areas; propose 48 dp padded areas with 8 dp gaps; require accessible names for each icon; check icon contrast at 3:1.
  Result: a list of failures with fixes and criterion numbers.
  
  **Example 2: ask for a certificate**
  User says: "Tell me this app is WCAG compliant."
  Actions: decline a blanket claim; state which criteria were checked and how; list untested areas.
  Result: an honest scoped statement.
  
  ## Common issues
  
  - **Icon buttons read as just "button".** Cause: no accessible name. Fix: add a label matching the visible meaning.
  - **Large text breaks the layout.** Cause: fixed heights. Fix: allow growth and wrap.
  - **Custom control invisible to a screen reader.** Cause: no role or state exposed. Fix: use the platform control or expose role, name and value.
  
  ## References
  
  - [targets-and-contrast.md](references/targets-and-contrast.md): target sizes, contrast values and WCAG 2.2 mobile criteria.
  
  ## Next
  
  [ux-review-and-testing](../ux-review-and-testing/SKILL.md) to run the checks with real users.
  

• skills/accessible-design/references/targets-and-contrast.md2.6 KB9511f1c5b917upstream ↗

  # Targets, contrast and WCAG 2.2 criteria
  
  Contents: target sizes, spacing, contrast values, WCAG 2.2 criteria that matter on mobile, testing tools.
  
  ## Touch target sizes
  
  | Source | Recommended | Minimum |
  |---|---|---|
  | Apple HIG, iOS and iPadOS | 44 x 44 pt | 28 x 28 pt |
  | Apple HIG, macOS | 28 x 28 pt | 20 x 20 pt |
  | Apple HIG, visionOS | 60 x 60 pt | 28 x 28 pt |
  | Android accessibility help | 48 x 48 dp (about 9 mm) | keep 48 |
  | web.dev | about 48 CSS px, 8 px apart | |
  | WCAG 2.2 SC 2.5.8, Level AA | | 24 x 24 CSS px, or a 24 px circle around the target not touching another |
  | WCAG 2.2 SC 2.5.5, Level AAA | | 44 x 44 CSS px |
  
  Spacing: Apple suggests about 12 pt around bezelled controls and 24 pt around borderless ones. Android suggests 8 dp between targets.
  
  Exceptions to 2.5.8: spacing, an equivalent control on the page, inline links in text, browser-controlled controls, essential size.
  
  Technique: keep the visible icon small and pad the hit area (padding, minimum size, or an enlarged touch area). On the web, enlarge only for touch with the coarse pointer media query.
  
  ## Contrast
  
  | Item | Minimum ratio | Criterion |
  |---|---|---|
  | Text up to 17 pt (not bold) | 4.5:1 | 1.4.3 AA |
  | Text 18 pt and above, or bold | 3:1 | 1.4.3 AA |
  | Icons, input borders, focus indicators | 3:1 | 1.4.11 AA |
  | Disabled controls | exempt, but keep them recognisable | |
  
  Support Increase Contrast and test both light and dark themes.
  
  ## WCAG 2.2 criteria with mobile impact
  
  | Criterion | Level | Plain meaning |
  |---|---|---|
  | 1.4.4 Resize Text | AA | text can reach 200 percent without loss |
  | 1.4.10 Reflow | AA | works at 320 CSS px wide, no two-way scrolling (maps, tables, video exempt) |
  | 2.4.11 Focus Not Obscured (Minimum) | AA | focused item not fully hidden by sticky content |
  | 2.5.7 Dragging Movements | AA | any drag has a single-pointer alternative |
  | 2.5.8 Target Size (Minimum) | AA | 24 x 24 CSS px or spacing |
  | 3.2.6 Consistent Help | A | help options stay in the same relative place |
  | 3.3.7 Redundant Entry | A | do not ask for the same information twice in one process |
  | 3.3.8 Accessible Authentication (Minimum) | AA | no memory test, puzzle or transcription without an alternative |
  
  W3C has no separate mobile standard: WCAG 2 applies to mobile web, native and hybrid apps, and a WCAG2Mobile draft explains how.
  
  ## Testing tools
  
  - Android: Accessibility Scanner, TalkBack, Espresso accessibility checks.
  - iOS: Accessibility Inspector, VoiceOver, Dynamic Type and Increase Contrast settings.
  - Web: browser zoom to 400 percent, keyboard-only pass, contrast checker.
  - Real users with disabilities give evidence automated tools cannot.
  

• README.mdupstream ↗

  Contents are not inlined in the catalog. Open the upstream file.

Plain-text copy, no login: /skill-bundles/kinwisenz-devops-ui-ux-designer-skills-accessible-design.md