Apple accessibility review
Review reusable SwiftUI in the consumer workspace for accessibility and platform interaction. Prefer findings and a fix plan; change code only when authorized.
Inspection order
Work top-down through the component or shared UI under review:
- VoiceOver — meaningful labels, traits, values, hints only when needed; correct grouping/combine; decorative images hidden; custom controls expose actions.
- Dynamic Type — layouts reflow; scroll by default; primary text grows first; no truncated essential text at large sizes; avoid fixed heights that clip content.
- Focus and keyboard — logical order on platforms with keyboard/focus (especially macOS); no keyboard traps; actionable elements reachable.
- Touch and hit targets — controls remain usable; spacing does not rely on tiny hit areas alone.
- Color and contrast — text and essential icons remain readable; Increased Contrast considered when the project supports it.
- Reduce Motion — essential feedback not motion-only; honor reduced-motion preferences for non-essential animation.
- Differentiate Without Color — state not conveyed by hue alone (icons, text, shapes).
- Icon-only controls — every one has a descriptive accessibility label (not the SF Symbol name alone when that is opaque).
- Platform differences — when iOS and macOS both ship the UI, note divergent interaction (pointer, menus, tab vs sidebar) and verify both if behavior differs.
Findings format
For each issue: control/view, problem, user impact, recommended fix, and evidence type (code-review | build | runtime-hierarchy | manual-VoiceOver | manual-keyboard). Severity: blocking / should-fix / note.
Review-only vs fix
- Review-only: severity-ranked findings + recommended sequence; no product code changes.
- Authorized fixes: smallest accessibility-correct change; add focused tests/examples where practical.
- Do not use this skill for non-UI services, token-only design work, or pixel-only critique.
Stop conditions
- Non-UI services, networking, or pure data layers → out of scope.
- Token-only or general design-system authoring without UI review →
apple-design-system.
- Pixel-perfect visual critique without a11y criteria → out of scope.
- Review-only request → do not change code unless authorized.
Claims and verification
- Do not claim VoiceOver, keyboard, or contrast “passed” without corresponding evidence. List manual checks the environment cannot automate.
- Prefer runtime hierarchy or screenshot evidence when available via XcodeBuildMCP UI tools.
- When platforms diverge, verify both or explicitly mark the skipped platform as residual risk.
- After authorized fixes to shared UI, re-check the affected items and use
swift-testing-verification for logic/tests that support accessibility behavior.
Inputs: reusable SwiftUI views and supported platforms. Output: actionable findings, focused tests/examples where possible, documented manual checks, and both-platform verification when behavior differs. Do not claim automated validation for semantics the environment cannot test.
1---2name: apple-accessibility-review3description: Use when reviewing reusable SwiftUI UI for accessibility. Do not use for non-UI code, general design-token work, or pixel-only critique.4---56# Apple accessibility review78Review **reusable SwiftUI** in the **consumer workspace** for accessibility and platform interaction. Prefer findings and a fix plan; change code only when authorized.910## Inspection order1112Work top-down through the component or shared UI under review:13141. **VoiceOver** — meaningful labels, traits, values, hints only when needed; correct grouping/combine; decorative images hidden; custom controls expose actions.152. **Dynamic Type** — layouts reflow; scroll by default; primary text grows first; no truncated essential text at large sizes; avoid fixed heights that clip content.163. **Focus and keyboard** — logical order on platforms with keyboard/focus (especially macOS); no keyboard traps; actionable elements reachable.174. **Touch and hit targets** — controls remain usable; spacing does not rely on tiny hit areas alone.185. **Color and contrast** — text and essential icons remain readable; Increased Contrast considered when the project supports it.196. **Reduce Motion** — essential feedback not motion-only; honor reduced-motion preferences for non-essential animation.207. **Differentiate Without Color** — state not conveyed by hue alone (icons, text, shapes).218. **Icon-only controls** — every one has a descriptive accessibility label (not the SF Symbol name alone when that is opaque).229. **Platform differences** — when iOS and macOS both ship the UI, note divergent interaction (pointer, menus, tab vs sidebar) and verify both if behavior differs.2324## Findings format2526For each issue: control/view, problem, user impact, recommended fix, and evidence type (`code-review` | `build` | `runtime-hierarchy` | `manual-VoiceOver` | `manual-keyboard`). Severity: blocking / should-fix / note.2728## Review-only vs fix2930- **Review-only:** severity-ranked findings + recommended sequence; no product code changes.31- **Authorized fixes:** smallest accessibility-correct change; add focused tests/examples where practical.32- Do not use this skill for non-UI services, token-only design work, or pixel-only critique.3334## Stop conditions3536- Non-UI services, networking, or pure data layers → out of scope.37- Token-only or general design-system authoring without UI review → `apple-design-system`.38- Pixel-perfect visual critique without a11y criteria → out of scope.39- Review-only request → do not change code unless authorized.4041## Claims and verification4243- **Do not claim** VoiceOver, keyboard, or contrast “passed” without corresponding evidence. List manual checks the environment cannot automate.44- Prefer runtime hierarchy or screenshot evidence when available via XcodeBuildMCP UI tools.45- When platforms diverge, verify both or explicitly mark the skipped platform as residual risk.46- After authorized fixes to shared UI, re-check the affected items and use `swift-testing-verification` for logic/tests that support accessibility behavior.4748Inputs: reusable SwiftUI views and supported platforms. Output: actionable findings, focused tests/examples where possible, documented manual checks, and both-platform verification when behavior differs. Do not claim automated validation for semantics the environment cannot test.
brbndon