On invocation: announce \"Running paad:agentic-a11y v1.31.0\" before anything else.
\nMulti-agent accessibility audit of user-facing code across any platform. Dispatches specialist agents in parallel — each focused on a different disability category — verifies findings to filter false positives, maps every issue to specific accessibility criteria, and produces a persistent report with concrete fix recommendations.
\nConformance target: WCAG 2.2 AA as baseline (applied via WCAG2ICT for non-web platforms). AAA criteria are flagged as bonus recommendations. Platform-specific guidelines (Apple HIG Accessibility, Android Accessibility, Xbox Accessibility Guidelines) are referenced where applicable.
\nThis is a technique skill. Follow the phases in order. Do not skip verification.
\nPre-flight:
\ndigraph preflight {\n \"Conversation has history?\" [shape=diamond];\n \"User-facing code exists?\" [shape=diamond];\n \"Proceed to Phase 1\" [shape=box];\n \"STOP: recommend new session\" [shape=box, style=bold];\n \"STOP: no user-facing code\" [shape=box, style=bold];\n\n \"Conversation has history?\" -> \"STOP: recommend new session\" [label=\"yes\"];\n \"Conversation has history?\" -> \"User-facing code exists?\" [label=\"no\"];\n \"User-facing code exists?\" -> \"STOP: no user-facing code\" [label=\"no\"];\n \"User-facing code exists?\" -> \"Proceed to Phase 1\" [label=\"yes\"];\n}\nAudit flow:
\ndigraph audit_flow {\n \"Scope size?\" [shape=diamond];\n \"Platform has framework-specific a11y pitfalls?\" [shape=diamond];\n \"Existing a11y tooling already catches it?\" [shape=diamond];\n \"Tooling misconfigured or finding suppressed?\" [shape=diamond];\n \"Barrier handled elsewhere?\" [shape=diamond];\n \"Confidence >= 60?\" [shape=diamond];\n \"Cited criterion correct?\" [shape=diamond];\n \"Reported by multiple specialists?\" [shape=diamond];\n \"AAA criterion?\" [shape=diamond];\n\n \"Detect platform(s), stack, tooling, steering files, manifest\" [shape=box];\n \"Partition files across 2 instances of each specialist\" [shape=box];\n \"Dispatch the 5 core specialists in parallel\" [shape=box];\n \"Dispatch the 5 core specialists + Platform-Specific Patterns in parallel\" [shape=box];\n \"DROP the finding\" [shape=box];\n \"Correct the criterion\" [shape=box];\n \"Assign severity: critical / serious / moderate / minor\" [shape=box];\n \"Merge duplicates, note the agreeing specialists\" [shape=box];\n \"List under Minor Issues & AAA Recommendations, prefix [AAA]\" [shape=box];\n \"Place under its severity section\" [shape=box];\n \"Write report to .reviews/a11y-reviews/a11y-<timestamp>.md\" [shape=box];\n \"Report location, counts by severity, Quick Wins guidance\" [shape=box];\n \"STOP: report is the deliverable — do NOT auto-fix\" [shape=box, style=bold];\n\n \"Detect platform(s), stack, tooling, steering files, manifest\" -> \"Scope size?\";\n \"Scope size?\" -> \"Platform has framework-specific a11y pitfalls?\" [label=\"small (<20) / medium (20-100)\"];\n \"Scope size?\" -> \"Partition files across 2 instances of each specialist\" [label=\"large (100+ user-facing files)\"];\n \"Partition files across 2 instances of each specialist\" -> \"Platform has framework-specific a11y pitfalls?\";\n \"Platform has framework-specific a11y pitfalls?\" -> \"Dispatch the 5 core specialists + Platform-Specific Patterns in parallel\" [label=\"yes\"];\n \"Platform has framework-specific a11y pitfalls?\" -> \"Dispatch the 5 core specialists in parallel\" [label=\"no\"];\n \"Dispatch the 5 core specialists in parallel\" -> \"Existing a11y tooling already catches it?\";\n \"Dispatch the 5 core specialists + Platform-Specific Patterns in parallel\" -> \"Existing a11y tooling already catches it?\";\n\n \"Existing a11y tooling already catches it?\" -> \"Tooling misconfigured or finding suppressed?\" [label=\"yes — specialists check this\"];\n \"Existing a11y tooling already catches it?\" -> \"Barrier handled elsewhere?\" [label=\"no\"];\n \"Tooling misconfigured or finding suppressed?\" -> \"DROP the finding\" [label=\"no — do not re-flag what tooling already catches\"];\n \"Tooling misconfigured or finding suppressed?\" -> \"Barrier handled elsewhere?\" [label=\"yes\"];\n \"Barrier handled elsewhere?\" -> \"DROP the finding\" [label=\"yes — parent, platform API, framework, library, system setting (verifier)\"];\n \"Barrier handled elsewhere?\" -> \"Confidence >= 60?\" [label=\"no\"];\n \"Confidence >= 60?\" -> \"DROP the finding\" [label=\"no\"];\n \"Confidence >= 60?\" -> \"Cited criterion correct?\" [label=\"yes\"];\n \"Cited criterion correct?\" -> \"Assign severity: critical / serious / moderate / minor\" [label=\"yes\"];\n \"Cited criterion correct?\" -> \"Correct the criterion\" [label=\"no\"];\n \"Correct the criterion\" -> \"Assign severity: critical / serious / moderate / minor\";\n \"Assign severity: critical / serious / moderate / minor\" -> \"Reported by multiple specialists?\";\n \"Reported by multiple specialists?\" -> \"Merge duplicates, note the agreeing specialists\" [label=\"yes\"];\n \"Reported by multiple specialists?\" -> \"AAA criterion?\" [label=\"no\"];\n \"Merge duplicates, note the agreeing specialists\" -> \"AAA criterion?\";\n \"AAA criterion?\" -> \"List under Minor Issues & AAA Recommendations, prefix [AAA]\" [label=\"yes — a recommendation, not a failure\"];\n \"AAA criterion?\" -> \"Place under its severity section\" [label=\"no\"];\n\n \"List under Minor Issues & AAA Recommendations, prefix [AAA]\" -> \"Write report to .reviews/a11y-reviews/a11y-<timestamp>.md\";\n \"Place under its severity section\" -> \"Write report to .reviews/a11y-reviews/a11y-<timestamp>.md\";\n \"DROP the finding\" -> \"Write report to .reviews/a11y-reviews/a11y-<timestamp>.md\" [label=\"counted under Filtered out\"];\n \"Write report to .reviews/a11y-reviews/a11y-<timestamp>.md\" -> \"Report location, counts by severity, Quick Wins guidance\";\n \"Report location, counts by severity, Quick Wins guidance\" -> \"STOP: report is the deliverable — do NOT auto-fix\";\n}\nagentic-a11y accepts optional $ARGUMENTS:
agentic-a11y — audit all user-facing code in the repositoryagentic-a11y src/components/ — scope the audit to a specific directoryagentic-a11y src/components/Modal.tsx — audit a specific fileWhen a path is provided, only audit files within that scope. Still detect platform and run all specialists, but limit the file manifest accordingly.
\nagentic-a11y to avoid context rot.\" Stop and wait.| Platform | \nFile indicators | \n
|---|---|
| Web | \n.html, .jsx, .tsx, .vue, .svelte, .ejs, .hbs, .blade.php, .erb, .jinja, .twig, .css, .scss, .less, plus JS/TS with DOM manipulation | \n
| iOS (native) | \n.swift (SwiftUI views), .m/.h (UIKit), .storyboard, .xib | \n
| Android (native) | \n.kt/.java (Compose or View classes), res/layout/*.xml | \n
| React Native | \n.jsx/.tsx with react-native imports | \n
| Flutter | \n.dart files with package:flutter imports | \n
| Desktop | \nElectron (web stack), Qt (.cpp/.qml), WPF/WinForms (.xaml/.cs), macOS AppKit/SwiftUI, GTK | \n
| CLI | \nAny code producing terminal output or accepting terminal input (look for stdout/stderr writes, readline, prompt libraries, curses/ncurses, argument parsers) | \n
| Game | \nUnity (.cs scripts), Unreal (C++/Blueprints), Godot (.gd/.tscn), custom engines with rendering/input systems | \n
Run these steps and collect results:
\nClassify the project into one or more platforms from the table above. A project may span multiple platforms (e.g., a web app with a CLI tool, or a React Native app with web support). Record all detected platforms — specialists will receive this classification.
\nPer detected platform:
\nreact-native-a11y)Collect all files that produce user-facing output or handle user interaction, grouped by platform.
\neslint-plugin-jsx-a11y, eslint-plugin-vuejs-accessibility, axe-core, pa11y, Lighthouse configsAccessibilityChecks.enable()@testing-library/react-native accessibility queriesSemanticsDebugger, accessibility-related widget tests--no-color support testsCLAUDE.md, AGENTS.md, any a11y-specific documentation or guidelines.
Files to audit, grouped for specialists, annotated with detected platform(s).
\nSteering file caveat: Include in every agent prompt: \"Steering files (CLAUDE.md, etc.) describe conventions but may be stale. If you find a contradiction between steering files and actual code, flag it as a finding.\"
\nDispatch these agents simultaneously using the Agent tool. Each receives: the file manifest, detected platform(s), steering file contents, existing a11y tooling notes, and their specialist focus.
\n| Agent | \nFocus | \nWho it helps | \n
|---|---|---|
| Screen Reader & Assistive Tech | \nProgrammatic exposure of UI semantics so assistive technologies can convey structure, content, and state to users | \nBlind and low-vision users using screen readers (VoiceOver, TalkBack, NVDA, JAWS, Orca) | \n
| Visual & Color | \nSufficient contrast, independence from color alone, support for magnification/text scaling, visible focus/selection indicators | \nLow-vision users, colorblind users | \n
| Keyboard & Motor | \nComplete operability without fine motor control — keyboard, switch, sip-and-puff, eye tracking, voice control — with adequate target sizes and no traps | \nMotor-impaired users, switch access users, sip-and-puff users, voice control users | \n
| Cognitive & Learning | \nConsistent, predictable interfaces with clear feedback, error recovery, plain language, and no unnecessary cognitive load | \nUsers with cognitive disabilities, learning disabilities, attention disorders, memory impairments | \n
| Multimedia & Temporal | \nAlternatives for audio/visual content, safe motion/animation, adequate time, no seizure triggers | \nDeaf/hard-of-hearing users, vestibular disorders, photosensitive epilepsy, users who need more time | \n
Dispatch using the Agent tool, exactly as for the core specialists, when the platform has framework-specific a11y pitfalls (web frameworks, SwiftUI, Compose, Flutter, React Native, game engines):
\n| Agent | \nFocus | \nInput | \n
|---|---|---|
| Platform-Specific Patterns | \nFramework/platform-specific a11y pitfalls, misuse of platform a11y APIs, navigation/routing a11y, dynamic content patterns | \nFile manifest + platform/framework detection results | \n
Each specialist agent prompt must include:
\nInclude the relevant platform section(s) in each specialist's prompt based on detected platform(s).
\nWeb: (1) Correct ARIA roles, states, and properties on custom components; (2) semantic HTML (headings, landmarks, lists, tables) over generic div/span; (3) heading hierarchy without skipped levels; (4) meaningful alt text (not filenames or \"image\"); (5) programmatically associated form labels; (6) aria-live regions for dynamic content; (7) link/button purpose clear from text or accessible name; (8) status messages via role=\"status\" or aria-live.
iOS: (1) accessibilityLabel set on all interactive and meaningful elements; (2) accessibilityTraits / SwiftUI .accessibilityAddTraits() correctly applied (.button, .header, .image, etc.); (3) accessibilityHint for non-obvious actions; (4) isAccessibilityElement grouping — containers group related info, decorative elements excluded; (5) accessibilityValue for sliders/progress; (6) UIAccessibility.post(.screenChanged, ...) and .layoutChanged notifications for dynamic updates; (7) custom actions via accessibilityCustomActions; (8) SwiftUI: .accessibilityElement(children: .combine) for logical grouping.
Android: (1) contentDescription on all interactive and meaningful elements; (2) importantForAccessibility set correctly — decorative elements marked no; (3) labelFor connecting labels to inputs; (4) accessibilityLiveRegion for dynamic content; (5) accessibilityHeading on section headers; (6) Compose: semantics { } block with appropriate properties, contentDescription, heading(), stateDescription; (7) custom AccessibilityNodeInfo actions where needed; (8) ViewCompat.setAccessibilityDelegate for custom views.
React Native: (1) accessibilityLabel on all interactive elements; (2) accessibilityRole set correctly (button, header, link, image, etc.); (3) accessibilityState for toggles, disabled, expanded states; (4) accessibilityHint for non-obvious actions; (5) accessibilityLiveRegion for dynamic updates; (6) accessibilityElementsHidden for decorative content; (7) AccessibilityInfo.announceForAccessibility() for dynamic state changes.
Flutter: (1) Semantics widget wrapping meaningful UI with label, button, header, image properties; (2) excludeSemantics: true on decorative elements; (3) MergeSemantics for logically grouped content; (4) SemanticsService.announce() for dynamic updates; (5) tooltip properties on IconButton and similar; (6) semanticsLabel on Text where displayed text differs from meaning.
CLI: (1) Structured, parseable output (not just visual formatting with boxes/lines); (2) information not conveyed solely by position/layout — screen readers linearize output; (3) progress indication via text updates, not just spinners or progress bars that rely on cursor repositioning; (4) error messages written to stderr with clear text (not just color/emoji).
\nGame: (1) UI elements have text alternatives available for screen reader narration mode; (2) menu items narrated with name, type, and state; (3) game state changes announced; (4) narration option in settings if not always-on.
\nWeb: Contrast ratios — AA: 4.5:1 normal text, 3:1 large text (18pt+/14pt+ bold), 3:1 UI components and graphics. AAA: 7:1/4.5:1. Check CSS custom properties and theme values. Flag color-only meaning (error states, status indicators, required fields, links distinguished only by color). Reflow at 320px width. Text spacing override support. prefers-contrast media query support.
iOS: (1) Dynamic Type support (UIFontMetrics, SwiftUI .dynamicTypeSize), test with all type sizes including accessibility sizes; (2) Bold Text support (UIAccessibility.isBoldTextEnabled); (3) Increase Contrast (UIAccessibility.isDarkerSystemColorsEnabled); (4) Reduce Transparency support; (5) sufficient contrast ratios in custom themes (same ratios as web); (6) color-only information has shape/icon/text alternatives; (7) SF Symbols accessibility variants.
Android: (1) sp units for text (scales with user preference); (2) test at 200% font scale; (3) High Contrast Text setting support; (4) sufficient contrast in custom themes; (5) color-only meaning has alternatives; (6) Magnification gesture compatibility (no content hidden at 200%+ zoom); (7) custom views render correctly with font scaling.
React Native: (1) Font scaling support — not disabled via allowFontScaling={false} unless justified; (2) layout accommodates scaled text without overflow/truncation; (3) contrast ratios on all custom-themed elements; (4) color-only meaning has alternatives.
Flutter: (1) MediaQuery.textScaleFactorOf(context) respected — UI tested at 2.0 scale; (2) contrast ratios met in custom ThemeData; (3) color-only meaning has alternatives; (4) MediaQuery.boldTextOf(context) support; (5) MediaQuery.highContrastOf(context) support.
CLI: (1) --no-color flag or NO_COLOR env var support; (2) information not conveyed by color alone — use labels, prefixes, symbols alongside color (e.g., [ERROR] not just red text); (3) supports TERM detection for capability; (4) works in high-contrast terminal themes.
Game: (1) Colorblind mode(s) — at minimum deuteranopia (red-green), ideally also protanopia and tritanopia; (2) UI element outlines/patterns supplement color; (3) font size options or UI scaling; (4) high contrast UI option; (5) brightness/gamma controls; (6) important game elements distinguishable by shape, not just color.
\nWeb: (1) Every interactive element reachable and activatable via keyboard; (2) no keyboard traps (focus can escape every modal, dropdown, overlay); (3) logical focus order matching visual layout; (4) visible focus indicators (not suppressed by outline: none without replacement); (5) skip navigation links; (6) custom widgets follow WAI-ARIA Authoring Practices keyboard patterns; (7) click targets at least 24x24 CSS px (AA), recommend 44x44 (AAA); (8) drag-and-drop has click/keyboard alternative; (9) single-character shortcuts remappable or only active on focus; (10) pointer-events, user-select not disabling expected interactions.
iOS: (1) Full Keyboard Access support — all actions reachable via external keyboard; (2) Switch Control compatibility — all interactive elements in accessibility tree with correct order; (3) AssistiveTouch custom gesture alternatives for complex gestures; (4) minimum 44x44pt tap targets (Apple HIG); (5) no gesture-only actions without alternatives (e.g., swipe-to-delete must have edit button); (6) custom gesture recognizers don't block Switch Control; (7) accessibilityActivationPoint set for non-standard hit areas.
Android: (1) Full keyboard navigation — android:focusable, logical nextFocusDown/Up/Left/Right; (2) Switch Access compatibility — all interactive elements focusable with adequate ordering; (3) minimum 48x48dp touch targets (Material Design); (4) no gesture-only actions without alternatives; (5) android:importantForAccessibility not hiding interactive elements; (6) custom views implement onKeyDown/onKeyUp for keyboard users; (7) TalkBack gesture alternatives for complex interactions.
React Native: (1) accessible={true} on all interactive elements; (2) accessibilityActions for custom actions; (3) onMagicTap, onEscape handlers where appropriate (iOS); (4) minimum touch target sizes (48x48dp Android / 44x44pt iOS); (5) gesture-based interactions have tap alternatives.
Flutter: (1) All interactive widgets have Semantics with tap/long press actions; (2) minimum touch targets via MaterialTapTargetSize.padded; (3) FocusNode and FocusTraversalGroup for logical keyboard order; (4) RawKeyboardListener/KeyboardListener for keyboard shortcuts; (5) no IgnorePointer/AbsorbPointer hiding accessible interactions; (6) custom GestureDetector actions have keyboard alternatives.
CLI: (1) Keyboard-only by nature, but check: interactive prompts (e.g., fuzzy finders, multi-select) navigable with arrow keys and enter; (2) Ctrl-C always exits; (3) no mouse-only interactions in TUI; (4) tab completion where appropriate; (5) long-running operations cancellable via keyboard.
\nGame: (1) Fully remappable controls; (2) multiple input device support (keyboard, mouse, controller, touch); (3) one-handed mode or alternative layouts; (4) no quick-time events without alternatives or adjustable timing; (5) auto-aim/aim assist option; (6) adjustable input sensitivity/dead zones; (7) hold-vs-toggle options for sustained inputs; (8) copilot/co-pilot mode if multiplayer.
\nAll platforms: (1) Consistent navigation patterns across screens/pages; (2) consistent identification of common elements; (3) clear error messages identifying the problem and suggesting a fix; (4) labels and instructions on all form inputs; (5) predictable behavior — no unexpected context changes on focus or input; (6) adequate time — adjustable/extendable timeouts, warnings before expiry; (7) help in a consistent, findable location; (8) no unnecessary re-entry of previously provided information; (9) accessible authentication — no cognitive function tests (CAPTCHAs) without alternatives.
\nWeb additionally: (1) lang attribute on <html> and lang attributes on content in other languages; (2) multiple ways to find pages (nav, search, sitemap); (3) breadcrumbs or location indicator.
iOS/Android additionally: (1) Back navigation always works predictably; (2) undo support for destructive actions; (3) confirmation dialogs for irreversible operations.
\nCLI additionally: (1) --help with clear, complete documentation; (2) confirmation prompts for destructive commands (with --yes/-y to skip); (3) meaningful exit codes; (4) consistent flag naming conventions (e.g., --verbose not -v in one command and --debug in another).
Game additionally: (1) Tutorial or onboarding; (2) difficulty options including easy/story mode; (3) objective tracking/quest log; (4) adjustable game speed; (5) pause in single-player; (6) clear visual/audio feedback for actions; (7) option to simplify UI.
\nAll platforms: (1) Pre-recorded video has captions; (2) pre-recorded audio has transcript; (3) no content flashes more than 3 times per second; (4) auto-playing media has pause/stop control; (5) moving/blinking/scrolling content can be paused; (6) no time limits, or limits are adjustable/extendable with warning.
\nWeb additionally: prefers-reduced-motion media query respected — all CSS animations/transitions have reduced or disabled alternatives. Audio descriptions for pre-recorded video (AA). <video>/<audio> elements have controls. No autoplay without mute.
iOS additionally: UIAccessibility.isReduceMotionEnabled / SwiftUI .accessibilityReduceMotion checked and respected — simplify or remove animations. UIAccessibility.isVideoAutoplayEnabled respected.
Android additionally: Settings.Global.ANIMATOR_DURATION_SCALE respected (set to 0 disables animations). View.IMPORTANT_FOR_AUTOFILL for form timing.
React Native additionally: AccessibilityInfo.isReduceMotionEnabled() checked — Animated and LayoutAnimation respect user preference.
Flutter additionally: MediaQuery.disableAnimationsOf(context) or MediaQuery.reduceMotionOf(context) checked and respected.
CLI additionally: No seizure-inducing rapid terminal updates (e.g., fast flickering progress bars). Long-running operations show progress without rapid screen clearing.
\nGame additionally: (1) Subtitle options with size/background/speaker-identification controls; (2) visual indicators for important audio cues (directional indicators, closed captions for sound effects); (3) screen shake toggle; (4) motion blur toggle; (5) field-of-view slider (reduces motion sickness); (6) photosensitivity mode reducing flashes/strobe effects.
\nWhen this agent is dispatched (see Conditional specialist above), include the\nrelevant examples below in its prompt:
\nReact: key on lists affecting screen readers, missing aria-live on state changes, portal focus traps, onClick on non-interactive elements without role/keyboard handling.
Vue: v-html with no a11y review, missing aria bindings on dynamic attributes, router afterEach not announcing navigation.
Angular: cdkTrapFocus misconfiguration, aria-describedby with *ngIf removing referenced elements.
Svelte: Reactive declarations removing focus targets, use:action without a11y side effects.
SwiftUI: .accessibilityRepresentation missing on custom controls, @AccessibilityFocusState not managing focus on navigation, .accessibilityRotor not used for long content, List/ForEach not providing per-item actions.
Jetpack Compose: Modifier.semantics not applied to custom composables, LazyColumn items missing individual semantics, AlertDialog not moving focus on show, ModalBottomSheet not trapping focus, clickable without role parameter.
Flutter: CustomPainter without SemanticsBuilder, Navigator transitions not announcing new routes, Hero animations conflicting with semantics, PlatformView breaking a11y tree.
React Native: FlatList/SectionList items not individually accessible, Modal not managing focus, platform-specific props missing (accessibilityLanguage iOS only, accessibilityLiveRegion Android emphasis).
Game engines (Unity): UI Toolkit vs UGUI a11y gaps, EventSystem not handling keyboard/controller navigation, TextMeshPro not exposing text to accessibility APIs.
Scaling for large scope (100+ files): Partition files across 2 instances of each specialist.
\nAfter all specialists complete, dispatch a single Verifier agent using the Agent tool, passing all findings. The verifier:
\nVerifier prompt must include: \"You are verifying accessibility findings. For each finding, read the actual code and confirm the barrier exists. Be skeptical — the platform, framework, or component library may already handle accessibility automatically. On iOS, UIKit provides some accessibility by default for standard controls. On Android, standard Material components include accessibility support. A finding reported by multiple specialists is more likely real. Ensure the cited criterion is correct. Do not modify any file in the repository. You may run read-only commands (existing tests, linters, type checkers) unchanged — their caches, coverage files, and build output are fine. If confirming a finding would require changing code, do not — treat the barrier as unconfirmed and drop it as you would any other false positive, rather than lowering the finding's confidence or severity.\"
\nWrite verified findings to .reviews/a11y-reviews/a11y-<YYYY-MM-DD-HH-MM-SS>.md.
Create the .reviews/a11y-reviews/ directory if it doesn't exist.
Report template:
\n# Accessibility Audit: <project-name>\n\n- **Date:** YYYY-MM-DD HH:MM:SS\n- **Commit:** <full-sha>\n- **Platform(s):** <detected platforms>\n- **Tech stack:** <frameworks, libraries, engines>\n- **Files audited:** N\n- **Existing a11y tooling:** <list or \"none found\">\n- **Conformance target:** WCAG 2.2 AA via WCAG2ICT (AAA noted as recommendations)\n- **Platform guidelines referenced:** <e.g., Apple HIG Accessibility, Material Design Accessibility, Xbox Accessibility Guidelines, or \"N/A\">\n\n## Executive Summary\n\n2-3 sentences: overall accessibility posture, highest-severity findings, estimated conformance level (A / partial AA / AA / partial AAA).\n\n## Impact Summary by User Group\n\nBrief summary of how the codebase affects each group:\n- **Screen reader users:** <1-2 sentences>\n- **Low-vision users:** <1-2 sentences>\n- **Colorblind users:** <1-2 sentences>\n- **Motor-impaired users (keyboard/switch/sip-and-puff):** <1-2 sentences>\n- **Cognitive and learning disabilities:** <1-2 sentences>\n- **Deaf and hard-of-hearing users:** <1-2 sentences>\n- **Vestibular and photosensitive users:** <1-2 sentences>\n\n## Critical Issues (Complete Barriers)\n\n### [C1] <title>\n- **File:** `path/to/file:line`\n- **Platform:** <which platform this applies to>\n- **Barrier:** What's wrong\n- **Criterion:** <WCAG criterion or platform guideline> — Level <A/AA>\n- **Affects:** Who is blocked and how\n- **Fix:** Concrete code-level recommendation\n- **Confidence:** High/Medium\n- **Found by:** <specialist name(s)>\n\n(Repeat for each critical issue, or \"None found.\")\n\n## Serious Issues (Major Difficulty)\n\n(Same structure as Critical, or \"None found.\")\n\n## Moderate Issues (Friction)\n\n(Same structure, or \"None found.\")\n\n## Minor Issues & AAA Recommendations\n\nOne-line entries with criterion reference. Omit section if none.\nMark AAA items with [AAA] prefix.\n\n## Conformance Checklist\n\nFor each WCAG principle, list criteria checked and their status. For non-web platforms, criteria are interpreted via WCAG2ICT. Mark criteria that do not apply to the detected platform as \"N/A\" with brief explanation.\n\n### Perceivable\n| Criterion | Level | Status | Finding |\n|-----------|-------|--------|---------|\n| 1.1.1 Non-text Content | A | Pass / Fail / Partial / N/A / Not assessed | #ID or — |\n(continue for all Perceivable criteria assessed)\n\n### Operable\n(same table format)\n\n### Understandable\n(same table format)\n\n### Robust\n(same table format)\n\n### Platform-Specific Guidelines\n| Guideline | Status | Finding |\n|-----------|--------|---------|\n| <e.g., Apple HIG: Dynamic Type> | Pass / Fail / Partial | #ID or — |\n(list platform-specific guidelines checked beyond WCAG, or omit section if web-only)\n\n## Quick Wins\n\nTop 5 fixes that would have the largest positive impact for the least effort. Each entry: what to fix, which findings it addresses, estimated effort (small/medium/large).\n\n## Audit Metadata\n\n- **Agents dispatched:** <list with focus areas>\n- **Platform(s) detected:** <list>\n- **Scope:** <files audited>\n- **Raw findings:** N (before verification)\n- **Verified findings:** M (after verification)\n- **Filtered out:** N - M\n- **By severity:** X critical, Y serious, Z moderate, W minor\n- **By conformance level:** X Level A, Y Level AA, Z Level AAA\n- **Steering files consulted:** <list or \"none found\">\n- **Existing a11y tooling:** <list or \"none found\">\nThese patterns produce low-quality audits. Avoid them:
\n| Mistake | \nWhat to do instead | \n
|---|---|
| Single-agent audit | \nAlways dispatch 5+ specialist agents in parallel via Agent tool — each disability has unique concerns that a generalist misses | \n
| Skipping verification | \nAlways run verifier — platforms and component libraries handle many a11y patterns automatically, producing false positives without verification | \n
| Assuming web platform | \nDetect the actual platform(s) first — iOS, Android, Flutter, CLI, and games all have different a11y APIs and patterns | \n
| Flagging issues handled by platform defaults | \nStandard UIKit controls, Material components, and Flutter widgets have built-in a11y — only flag if misused, overridden, or missing | \n
| Generic findings without file:line | \nEvery finding must reference exact code location — \"add alt text\" or \"add contentDescription\" is not actionable | \n
| Wrong criteria | \nVerify the correct WCAG criterion or platform guideline is cited — misattribution erodes trust in the report | \n
| Ignoring styling/theming | \nMany a11y issues live in styles (contrast, focus indicators, text sizing, elements hidden from assistive tech) regardless of platform | \n
| Only checking static/declarative UI | \nDynamic content, navigation transitions, and programmatic UI changes are where the hardest a11y bugs hide on every platform | \n
| Treating AAA as required | \nAAA items are recommendations, not failures — present them as enhancements to avoid overwhelming teams | \n
| Ignoring reduced-motion preferences | \nEvery platform has a reduce-motion setting — prefers-reduced-motion (web/CSS), isReduceMotionEnabled (iOS), ANIMATOR_DURATION_SCALE (Android), disableAnimations (Flutter) — vestibular disorders cause real physical symptoms | \n
| Applying web patterns to native | \nARIA is a web technology. Native platforms have their own accessibility APIs — don't recommend ARIA attributes for iOS/Android code | \n
| Ignoring CLI accessibility | \nCLI tools are user-facing too — color-only output, unstructured text, and missing --no-color support are real barriers | \n
After writing the report:
\nList every file this run wrote or changed, before anything else — a\nreport the developer does not know exists is a report nobody reads. One line\nper path, each marked new or updated, even when there is only one:
\nFiles written or updated:\n new .reviews/a11y-reviews/a11y-2026-08-01-10-42-13.md\nThen give the finding counts by severity
\nTell them: \"To address these findings, work through the Quick Wins first, then tackle Critical and Serious issues. Fix each issue with a per-fix commit. If you have the superpowers plugin installed, you can use the receiving-code-review skill and point it at this report for a guided workflow.\"
Do not auto-fix anything. The report is the deliverable.
\n