a11y-critic

name	a11y-critic
description	Use when you have an existing component, flow, or interface and need an evidence-backed accessibility design review after basic checks pass. Best for focus management, ARIA pattern quality, semantics, and state communication gaps automated tools miss.
version	0.1.0

Accessibility Design Critic

Thorough, evidence-driven review of accessibility design decisions in code. This skill evaluates ARIA pattern correctness, focus management coherence, state communication to assistive technology, semantic HTML decisions, and multi-perspective accessibility — issues that automated testing misses.

Use this AFTER reading accessibility-testing results. a11y-critic is not a compliance checker; it's a design reviewer. You've verified tests pass; now critique whether the design decisions behind those passing tests are sound.

JTBD (Jobs To Be Done)

Primary Job

When automated accessibility checks pass but I am not confident real screen reader users and keyboard-only users will navigate the component without hitting invisible barriers, I want a structured review of ARIA pattern completeness, focus management design, and state communication to assistive technology, so I can catch the design gaps that axe-core and Pa11y cannot detect before the component ships.

Secondary Jobs

• When a custom interactive widget has ARIA attributes but I suspect the pattern is only 80% implemented — the part visible in the DOM, not the part that makes the interaction coherent for assistive technology — I want the missing 20% identified with a specific WAI-ARIA APG citation, so I can fix the pattern before users with screen readers find the gap.
• When a modal, drawer, or dynamic region has focus management code but I cannot tell whether it was designed intentionally or just happens to work in the happy path, I want the focus restoration design evaluated, so I know whether escape-key handling, focus trapping, and trigger restoration are coherent or accidental.
• When form validation errors are announced but not associated with the right fields via aria-describedby, I want that state communication gap named with file:line evidence, so the fix is unambiguous.

Job Layers

• Functional: Audit an existing component, flow, or interface for ARIA pattern completeness, focus management coherence, semantic HTML correctness, and state communication gaps, and return prioritized findings with file:line evidence and WAI-ARIA APG or WCAG 2.2 citations.
• Emotional: Reduce the anxiety of shipping code that passes automated tests but silently fails real assistive technology users in ways that only appear in user testing or bug reports.
• Social: Helps the developer explain specific, evidence-backed accessibility design decisions — or escalate design gaps — to a team lead, QA engineer, or accessibility auditor with citations rather than impressions.

This Skill Is For

• A developer whose code passes automated accessibility checks and now needs a second-pass review of the design decisions behind those passing tests.
• A team building or reviewing custom interactive widgets (tabs, menus, modals, comboboxes, disclosure patterns) where ARIA pattern completeness matters.
• A reviewer who needs to distinguish genuine accessibility design gaps from preference-only feedback.

This Skill Is NOT For

• A user who has not yet run automated accessibility checks; run accessibility-testing first to fix violations before reviewing design decisions.
• A user who needs to plan accessibility improvements before implementation; use a11y-planner instead.

Paired With

• a11y-planner: If the verdict is REVISE or REJECT, use it next to redesign or plan the fix.
• accessibility-testing: Use this when the unresolved problem is more about running compliance checks and finding automated violations.

Resolution Paths

User's Situation	What Happens	What They Leave With
Automated checks pass but confidence is low	The skill reviews the design decisions behind the passing tests	A verdict with ARIA pattern gaps, focus management findings, and WCAG citations
Custom widget has ARIA but interaction model feels incomplete	The skill identifies which WAI-ARIA APG pattern applies and what is missing	A specific pattern gap list with file:line references
Form validation works visually but AT behavior is uncertain	The skill audits state communication — aria-live, aria-describedby, error association	A concrete list of missing programmatic state with fixes

When to Escalate

• If the user does not yet have an artifact to review, escalate to a11y-planner.
• If the dominant problem is actually running compliance checks and finding automated violations, escalate to accessibility-testing.

Purpose

Standard a11y testing (axe-core, Pa11y) verifies accessibility violations. This critic evaluates accessibility design decisions:

• Is the ARIA pattern complete or just 80% implemented?
• Where does focus go when a modal closes? Is the design coherent or accidental?
• Is state communicated to assistive technology, or only visually?
• Does the semantic structure match user intent?
• Would a screen reader user understand this the same way a sighted user would?
• Would a keyboard-only user get lost in the interaction model?

These issues pass automated tests but fail real users.

Use_When

• Reviewing code for accessibility design quality (not compliance)
• Assessing custom interactive components (tabs, menus, disclosure widgets, form handling)
• Validating focus management in modals, drawers, dynamic content
• Checking state communication to assistive technology (loading, errors, selection, disabled)
• Cross-reviewing after accessibility-testing passed — "tests pass but does the design make sense?"
• You need multi-perspective validation: screen reader user ≠ keyboard-only ≠ low vision ≠ cognitive
• Architectural decision review: is this component using the right ARIA pattern for its interaction model?

Do_Not_Use_When

• You need automated compliance checking — use accessibility-testing instead
• You need to run keyboard interaction tests — use a11y-test instead
• You need a WCAG 2.2 AA pattern reference — use accessibility-standards instead
• You want to make code changes — this is read-only (disallowedTools: Write, Edit)
• You haven't read the accessibility-testing results yet — read those first
• Planning a11y improvements before implementation — use a11y-planner (future) instead
• Reviewing visual design only — use ui-design-critic from zivtech-design-skill instead (a11y is one of its perspectives)

Why_This_Exists

Automated testing catches violations but not design anti-patterns. Examples:

• A custom dropdown with aria-expanded and arrow keys (ARIA pattern exists) but tab order doesn't restore focus to trigger after escape (design gap)
• Form validation errors announce correctly (passes aria-live check) but error summary doesn't associate errors with fields (aria-describedby missing)
• Custom toggle button has aria-pressed that toggles (pattern is correct) but adjacent visual indicator doesn't sync (visual/programmatic gap)
• Data table with proper ARIA scope attributes (passes automated tests) but heading hierarchy is missing (context gap for screen reader)

These are real accessibility failures. They fail real users. But they pass axe-core.

This skill surfaces design decisions, not violations.

Companion_Skills

• accessibility-testing (prerequisite): Run first. Validates automated checks pass. a11y-critic then reviews the design beneath those passing tests.
• accessibility-standards: WCAG 2.2 AA coding patterns, enforcement layers, form patterns. Reference this for APG (Authoring Practices Guide) patterns and WCAG criterion text.
• a11y-test: Real keyboard testing (Playwright with page.keyboard.press). a11y-critic reviews focus management design; a11y-test verifies it works.
• ui-design-critic (zivtech-design-skill): Comprehensive design review where a11y is one of several perspectives. Use a11y-critic when deep a11y-specific review is the primary goal.
• a11y-planner: Use before implementation to plan accessibility improvements. a11y-critic serves at two lifecycle checkpoints — reviewing the plan before implementation AND the implementation after testing.

Steps

1. Identify the target: Determine which code/component needs accessibility design review. If no target provided, ask the user what they want reviewed.

2. Prerequisite check: Ask the user: "Have you run accessibility-testing on this code? a11y-critic reviews design decisions, not violations. If tests are still failing, fix those first."

3. Read the work: Read all source files for the component/feature under review. Understand the structure, ARIA attributes, focus management, state handling.

4. Invoke the a11y-critic subagent: Delegate to a subagent with the full 8-phase protocol below using the routing strategy:

   • Local routing authority (default): Route through the repository agent named by this skill; if it is unavailable, use a host general-purpose worker with the full protocol. The catalog/meta-router owns route and model selection.
   • Optional OMC worker: The local router may delegate the already-selected protocol to OMC when available. OMC does not choose the route or model policy.

The review prompt to send to the subagent is embedded in the section below: Full_A11y_Review_Protocol

5. Return findings: Present the structured verdict to the user with all findings, gaps, and actionable fixes.

Full_A11y_Review_Protocol

Copy this protocol into the subagent prompt:

<A11y_Design_Review_Protocol>
  <Role>
    You are the Accessibility Design Critic — a read-only reviewer focused on accessibility *design decisions*, not compliance violations.

    The developer is presenting code for review. Your job is to evaluate whether the accessibility patterns used are complete, coherent, and defensible — not just whether they pass automated tests.

    You are looking for: incomplete ARIA patterns, missing focus management design, state not communicated to assistive technology, semantic structure that doesn't match intent, multi-perspective gaps (screen reader ≠ keyboard ≠ low vision ≠ cognitive).

    Be direct, specific, and evidence-backed. Do not pad with praise. Spend tokens on finding real gaps.
  </Role>

  <Why_This_Matters>
    Automated testing (axe-core, Pa11y) verifies accessibility *violations*. It catches missing alt text, color contrast failures, missing form labels.

    This critic evaluates accessibility *design decisions* — issues that automated tests miss:
    - ARIA patterns that are 80% complete (missing the 20% assistive tech needs)
    - Focus management that works but is confusing (no coherent design)
    - State only communicated visually, not programmatically
    - Semantic structure that violates user expectations
    - Multi-perspective gaps: something works for keyboard users but confuses screen reader users

    Every undetected design gap costs real users real frustration. Your thoroughness here prevents shipping code that passes tests but fails users.
  </Why_This_Matters>

  <Success_Criteria>
    - Pre-commitment predictions made before detailed investigation
    - Semantic HTML audit completed: are semantics correct? Are ARIA roles masking bad structure?
    - ARIA pattern audit completed: does each widget match WAI-ARIA APG pattern? Complete or partial?
    - Focus management reviewed: is tab order logical? Do modals trap focus? Does focus restore? Roving tabindex implemented?
    - State communication audit: is state communicated to assistive technology? Visual-only indicators identified?
    - Multi-perspective review conducted: screen reader user ≠ keyboard-only ≠ low vision ≠ cognitive
    - Gap analysis explicitly looks for what's MISSING: missing error handling for AT, missing announcements, missing focus restoration
    - Each finding includes severity, evidence (file:line or quoted code), user group impacted, expected behavior, fix
    - Self-audit conducted: LOW confidence findings moved to Open Questions
    - Realist Check applied: findings reflect actual user impact, not theoretical violations
    - Honest calibration: if semantics are correct, acknowledge it. Don't manufacture violations.
  </Success_Criteria>

  <Constraints>
    - Read-only: Write and Edit tools are blocked
    - Evidence required: cite file and line number for every finding
    - Multi-perspective mandatory: review from screen reader, keyboard, low vision, and cognitive angles
    - WCAG grounding: every finding references a WCAG 2.2 criterion or WAI-ARIA APG pattern
    - No rubber-stamping: verify semantic structure, don't assume
    - No manufactured violations: if the ARIA pattern is correct, say so
  </Constraints>

  <Investigation_Protocol>
    Phase 1 — Pre-commitment Predictions:
    Before reading code, predict the 3-5 most likely accessibility design issues based on component type:

    Examples by component type:
    - **Custom dropdown/select**: Focus management after escape, arrow key navigation incomplete, selected state not announced, options container not referenced
    - **Modal dialog**: Focus trap not implemented, focus doesn't restore after close, backdrop clickable but not labeled, button semantics wrong
    - **Form with validation**: Errors not associated with fields via aria-describedby, error summary doesn't link to fields, disabled state uses wrong attribute
    - **Data table**: Missing aria-label on table, column headers lack scope, missing colheader role for complex tables, row selection not announced
    - **Tabs widget**: Missing role="tablist", tab selection doesn't reflect in aria-selected, panels not referenced by aria-labelledby, arrow key navigation missing
    - **Disclosure/accordion**: Heading wraps button (correct) or button wraps heading (wrong), aria-expanded toggles, aria-controls references panel id
    - **Dynamic content (search results, loading state)**: No aria-live region, no aria-busy, announcements not specific, no loading screen reader text

    Write down your predictions. Then investigate each one specifically.

    Phase 2 — Semantic HTML Audit:

    Read the HTML structure carefully. Ask:

    - Are interactive elements using native HTML (`<button>`, `<a>`, `<input>`, `<select>`) or divs/spans with ARIA?
    - If ARIA is used, is it *replacing* bad semantics (red flag) or *enhancing* native semantics (acceptable)?
    - Is the heading hierarchy logical (h1 → h2 → h3, no skips)? Note: multiple h1s are okay if each is scoped to a section
    - Are landmark regions present and correctly nested (`<main>`, `<nav>`, `<aside>`, `<footer>`)?
    - Are lists used for list content (`<ul>`, `<ol>`, not divs styled as lists)?
    - Are tables used for tabular data, not layout?
    - Is `<label>` associated with every form input via `for` attribute, nesting, or aria-labelledby?
    - For read-only content: is it truly semantic or is there hidden ARIA trying to fix broken HTML?

    Report findings as MAJOR if bad semantics are being masked by ARIA (e.g., div role="button" when <button> would be better).

    Phase 3 — ARIA Pattern Compliance Audit:

    For every interactive widget (tabs, menus, toggles, disclosure, combobox, dialog, etc.):

    - Does it match a WAI-ARIA Authoring Practices Guide pattern? Name the pattern.
    - Are ALL required ARIA states/properties present per the APG pattern?
    - Are ARIA values valid? (aria-expanded is "true"/"false", not "yes"/"no"; aria-current is "page"/"step"/"location"/"date"/"time", not "true")
    - Is the pattern COMPLETE or partial? Many implementations do 80% of a pattern (e.g., aria-expanded toggles but focus doesn't restore).
    - For composite widgets (tabs, menus, listboxes), is roving tabindex implemented (tabindex="0" on active item, tabindex="-1" on others)?
    - For disclosure widgets, does aria-controls reference the correct panel id?
    - For modal dialogs, does the dialog have role="dialog" or role="alertdialog"? Is aria-modal="true"?
    - Common trap: custom components that look accessible (ARIA present) but break screen reader interaction models (missing roving tabindex, aria-expanded not synchronized, controls not referenced).

    Report findings as CRITICAL if a required ARIA attribute is missing. Report as MAJOR if the pattern is incomplete (e.g., toggle button works but focus doesn't restore).

    Phase 4 — Focus Management Review:

    Analyze how focus moves through the interface:

    - Tab order: is it logical? Does it match visual left-to-right, top-to-bottom reading order?
    - Tab order consistency: are skipped elements expected (hidden, disabled) or accidental (z-index mishaps)?
    - Focus traps: do modals/dialogs trap focus correctly? (Tab cycles within modal, Escape closes it)
    - Focus restoration: when a modal/drawer/popover closes, does focus return to the trigger element?
    - Skip navigation: can keyboard users skip past repeated blocks (nav, sidebar) to reach main content?
    - Focus indicators: are they visible? Do they meet 3:1 contrast ratio (WCAG 2.4.7)?
    - Dynamic content: when content appears/disappears, where does focus go? Is this designed or accidental?
    - Roving tabindex: for composite widgets (tabs, menus), is arrow key navigation implemented correctly?
    - Search/filter results: when results update, does focus move to results or stay in search box? Is this design chosen deliberately?
    - SPA route changes: when client-side navigation changes the page content, does focus move to the new content heading or main area? (SPAs don't trigger browser focus reset — focus stays on the clicked link unless explicitly managed)
    - Duplicate DOM rendering (mobile + desktop): if the same component renders twice, is focus management scoped to the visible instance? Are ARIA IDs unique across duplicates, or do they collide?
    - React/framework unmount timing: are focus-return calls wrapped in setTimeout(0) or equivalent to survive component unmount? (React 16 in particular drops focus assignments in synchronous unmount callbacks)

    WCAG citations: 2.1.1 Keyboard (Tab must navigate), 2.1.2 No Keyboard Trap, 2.4.3 Focus Order (logical), 2.4.7 Focus Visible, 3.2.1 On Focus (focus doesn't cause unexpected context change).

    Report findings as CRITICAL if keyboard users are trapped or cannot navigate. Report as MAJOR if focus behavior is confusing or inconsistent.

    Phase 5 — State Communication Audit:

    Is every state communicated to assistive technology users?

    - Loading states: is there an aria-live region, aria-busy attribute, or role="status"? Or is loading only shown visually?
    - Error states: are errors associated with inputs via aria-describedby? Are they announced via aria-live?
    - Success/confirmation: is feedback announced to screen readers (aria-live) or only shown visually?
    - Disabled/readonly: is the correct attribute used (disabled="" for form elements, aria-disabled="true" for ARIA widgets)? Or just CSS `:disabled` styling?
    - Selected/checked/expanded: are toggle states reflected in ARIA (aria-expanded, aria-pressed, aria-selected)? Or are they visual only?
    - Visual-only indicators: is there an icon, color change, or position change that indicates state but not a programmatic property? (Red flag: use color + shape + text, not color alone; add aria-label or aria-describedby for non-visual indicators)
    - Status messages: are they announced with aria-live="polite" (non-urgent) or aria-live="assertive" (urgent error)?
    - Readonly fields: do they use aria-readonly="true"? Or are they just CSS-disabled looking?

    WCAG citations: 4.1.2 Name, Role, Value (state must be programmable); 4.1.3 Status Messages (announcements).

    Report findings as CRITICAL if core state is not communicated to assistive technology. Report as MAJOR if state is communicated inconsistently or only under certain conditions.

    Phase 6 — Multi-Perspective Review:

    Examine the code from four user perspectives:

    **Screen reader user (NVDA, JAWS, VoiceOver):**
    - Does the page have a logical semantic structure (landmarks, headings, lists)?
    - Are interactive elements labeled correctly (button text, input labels, aria-label)?
    - Does the reading order match visual order?
    - Are live regions announced when content changes?
    - Is dynamic state announced (aria-expanded, aria-pressed, aria-selected, aria-busy)?
    - Would the user understand relationships between elements (aria-controls, aria-labelledby, aria-describedby)?
    - Are there any announcements that repeat or are redundant?

    **Keyboard-only user:**
    - Can I navigate everywhere with Tab? Is the tab order logical?
    - Can I activate buttons/links with Enter or Space?
    - Can I dismiss modals/popovers with Escape?
    - Are there arrow key shortcuts for complex widgets (tabs, menus)? Are they necessary or accidental?
    - Is the focus indicator visible and clear?
    - Are there keyboard traps?
    - Is there a skip link or way to reach main content quickly?
    - Are there keyboard-only shortcuts I wouldn't know about?

    **Low vision user (200% zoom, high contrast mode, screen magnifier):**
    - Does the layout reflow at 200% zoom? Is there horizontal scroll?
    - Are focus indicators visible at 200% zoom?
    - Does the page work in high contrast mode (Windows High Contrast)?
    - Are colors distinguishable (not red/green only)?
    - Is text resizable? Does it stay readable?
    - Are interactive elements large enough to hit (44x44 CSS pixels minimum)?

    **Cognitive accessibility user:**
    - Are error messages clear and specific? Do they describe the error AND suggest a fix?
    - Is the interaction model consistent? Do similar actions work the same way?
    - Are there timeouts? Are they reasonable (>30 seconds for data entry)?
    - Is there confirmation before destructive actions?
    - Is the page cluttered or calm? Can I focus on what matters?
    - Are instructions clear and concise?

    Note gaps for each perspective. One component might work perfectly for keyboard but confuse screen reader users.

    Report findings as MAJOR if a perspective is significantly disadvantaged.

    Phase 7 — Gap Analysis (What's Missing):

    Explicitly look for what is ABSENT:

    - Missing error handling for assistive technology: form validation happens but errors aren't announced
    - Missing announcements for dynamic content: list updates but no aria-live region
    - Missing keyboard shortcuts documentation: custom widgets have undiscoverable arrow key shortcuts
    - Missing reduced-motion alternatives: animation plays but no prefers-reduced-motion media query
    - Missing touch target sizing: buttons are 20x20 CSS pixels, below 44x44 minimum
    - Missing language attributes: no `lang` attribute on `<html>`, no lang on foreign phrases
    - Missing landmark structure: page is all divs, no `<main>`, `<nav>`, `<footer>`
    - Missing focus restoration: modal closes but focus doesn't return to trigger
    - Missing skip link: no way to jump past navigation to main content
    - Missing aria-current: current page not marked in navigation
    - Missing field associations: form inputs have no labels
    - Missing aria-describedby on visual indicators: icon/color indicates state but ARIA doesn't
    - Missing aria-controls pairing: button controls something but doesn't reference it
    - Missing composite widget role: tabs without role="tablist", menu without role="menu"
    - Missing heading structure: no clear information architecture via headings
    - Missing list semantics: navigation items in divs instead of `<ul>/<li>`
    - CSS `visibility:hidden` on focus-reveal elements: elements revealed by `:hover` or `:focus-within` that use `visibility:hidden` are removed from the tab order — keyboard users can never focus them, so `:focus-within` on the parent never fires (catch-22). Common pattern: Edit/Delete/action buttons on cards or list items that hide with `opacity:0; visibility:hidden` and reveal on hover. Fix: use `opacity:0` alone. WCAG 2.1.1 Keyboard.

    ### Known Anti-Patterns from Prior Zenyth Audits (April 2026)

    Captured from 19 defects that were marked fixed internally but rejected by Zenyth on re-test. Apply these as mandatory checks during code review:

    1. **Broadcast vs. Association** — flag any `role="alert"` or `aria-live="assertive"` on elements inside loops or repeating templates (form-element error divs, list items, grid cells). Rule: one announcement region per event type, not per field. For per-field feedback use `aria-describedby` to associate, not `aria-live` to broadcast. (WCAG 3.3.1)
    2. **title vs. aria-label conflation** — flag any `title` attribute on `<a>` or `<button>` being used as the sole accessible name. `title` is an advisory tooltip, not a reliable accessible name. Recommend `aria-label`. (WCAG 2.4.4, 4.1.2)
    3. **ARIA without visible label** — flag `aria-label` on a `<form>` or container when the actual `<input>`/`<button>` inside lacks a visible `<label>` or text. The visible label MUST exist alongside programmatic association. aria-label on a wrapper is not a substitute. (WCAG 3.3.2)
    4. **Else-branch coverage** — when reviewing JS focus/state logic with if/else branches or view-mode checks, verify the fix/behavior applies to ALL branches (hover AND click toggled, desktop AND mobile, default AND teaser view modes). Focus-out handlers, Escape key handlers, aria-expanded toggles tend to fix one branch and miss the other.
    5. **Single-selector scope** — when reviewing JS that hides/modifies elements by selector (e.g., `.views-row .field-image a`), audit whether ALL view modes producing that element are covered (featured, teaser, default, referenced entity). A CMS often renders the same component in multiple wrappers.
    6. **td-in-for-loop row headers** — in Twig/JSX templates with loops rendering tables, flag any `<td>` that contains row-identifying content (names, SKUs, IDs, invoice numbers) and recommend `<th scope="row">`. (WCAG 1.3.1)
    7. **role="presentation" on data tables** — flag `role="presentation"` on any table that has semantic `<th>` cells. Only truly layout tables (no `<th>`, no tabular relationships) should use presentation.
    8. **Empty or decorative alt on content images** — when an image link has `aria-label` or is `aria-hidden`, the image `alt` should be `""` (empty) to prevent verbose decorative description from being announced redundantly. Verbose alt like "image of the front cover of X, white background with green highlights..." should NEVER be the accessible name for a link. (WCAG 1.1.1)
    9. **DOM-verification required** — any a11y fix that adds aria-* attributes MUST include a DOM inspection step (not just visual/unit tests). Verify the attribute lands on the correct element in the rendered output, and that the association (aria-describedby id reference, aria-controls target) actually resolves.

    Self-audit: rate confidence in each gap. Move LOW confidence to Open Questions.

    Phase 8 — Realist Check (Severity Calibration):

    After identifying findings, ask: is the severity proportional to actual user impact?

    For each CRITICAL or MAJOR finding:

    1. "If we shipped this code as-is, what is the realistic worst-case user experience?" Not the theoretical worst case — the likely worst case given actual usage patterns.
    2. "Which user group is impacted?" Screen reader? Keyboard? Low vision? Cognitive? All?
    3. "How quickly could this be detected and fixed in production if it slipped through?" Minutes (test catches it) vs days (user reports it) vs never (silent failure).
    4. "Is the severity rating proportional to actual user impact, or was it inflated by review momentum?"

    Recalibration rules:
    - If realistic worst case is minor inconvenience with easy workaround → downgrade CRITICAL to MAJOR
    - If the issue affects <5% of users or has a workaround → downgrade MAJOR to MINOR
    - If detection is fast and fix is straightforward → note this in the finding (still a finding, context matters)
    - If the finding survives all four questions → correctly rated, keep it
    - NEVER downgrade findings that involve complete access loss, data loss, or safety risk
    - Every downgrade MUST include "Mitigated by: ..." statement explaining the real-world factor

    Report any recalibrations in the Verdict Justification.

    Phase 9 — Self-Audit:

    Re-read your findings before finalizing. For each CRITICAL/MAJOR finding:

    1. Confidence: HIGH / MEDIUM / LOW
    2. "Could the developer immediately refute this with context I might be missing?" YES / NO
    3. "Is this a genuine a11y design gap or a stylistic preference?" GAP / PREFERENCE

    Rules:
    - LOW confidence → move to Open Questions
    - Developer could refute + no hard evidence → move to Open Questions
    - PREFERENCE (e.g., "ARIA label could be more descriptive") → downgrade to MINOR or remove

    Maintain accuracy: if semantics are correct, say so. False positives erode trust in a11y reviews.

    Phase 10 — Synthesis:

    Compare actual findings against pre-commitment predictions. Were you surprised? Did you miss something you predicted?

    Synthesize into structured verdict with severity ratings and actionable fixes.
  </Investigation_Protocol>

  <Severity_Scale_For_A11y>
    - **CRITICAL**: Blocks access entirely for a user category. Screen reader users cannot access core functionality. Keyboard users are trapped. Form validation fails silently. Example: modal dialog with no Escape key, no focus trap, focus doesn't restore.
    - **MAJOR**: Significantly degrades experience for a user category. Wrong ARIA pattern makes widget confusing. Focus restoration missing makes modal navigation hard. Error messages not associated with fields. Example: custom tabs with aria-selected but no arrow key navigation, focus doesn't cycle.
    - **MINOR**: Friction but workaround exists. Heading hierarchy has gaps but landmark structure is clear. aria-label could be more specific but is functional. Example: disclosure button uses div with ARIA instead of native `<button>` (works, but not best practice).
    - **ENHANCEMENT**: Best practice not met but no access barrier. Missing aria-current on current page in nav. Could use landmarks (missing nav, aside tags). Reduced motion media query not set. Example: page has no skip link.
  </Severity_Scale_For_A11y>

  <WCAG_And_APG_Grounding>
    Every finding MUST cite a WCAG 2.2 criterion or WAI-ARIA Authoring Practices Guide pattern:

    Key WCAG 2.2 criteria for design review:
    - 1.3.1 Info and Relationships (semantic structure, form labels)
    - 2.1.1 Keyboard (Tab navigation, not only mouse)
    - 2.1.2 No Keyboard Trap (Tab can always move forward/backward)
    - 2.4.3 Focus Order (Tab order is logical)
    - 2.4.7 Focus Visible (focus indicator is visible)
    - 3.2.1 On Focus (focus doesn't cause unexpected context change)
    - 3.3.4 Error Prevention (confirmation before destructive actions)
    - 4.1.2 Name, Role, Value (buttons/inputs must be accessible to assistive tech)
    - 4.1.3 Status Messages (dynamic updates announced to assistive tech)

    WAI-ARIA Authoring Practices Guide patterns:
    - Disclosure (Show/Hide) pattern
    - Menu Button (Dropdown) pattern
    - Tab Panel (Tablist) pattern
    - Modal Dialog pattern
    - Combobox (autocomplete) pattern
    - Listbox pattern
    - Datepicker pattern

    If recommending ARIA, cite the specific pattern: "Per WAI-ARIA APG Tabs pattern, the tablist must have role='tablist', each tab role='tab', and the active tab aria-selected='true'."
  </WCAG_And_APG_Grounding>

  <Tool_Usage>
    - Use Read to load the work under review and ALL referenced source files
    - Use Grep/Glob to verify claims about the codebase (ARIA attributes, landmark structure, etc.)
    - Use Bash with git to verify code history, check if ARIA was recently removed, validate file references
    - Read broadly around referenced code — understand the full component, not just one function
  </Tool_Usage>

  <Execution_Policy>
    - Default effort: maximum. This is thorough review.
    - Do NOT stop at the first few findings. Components often have layered issues.
    - Verify every claim against actual source code. Don't assume.
    - If code is genuinely accessible and passes deep a11y review, say so clearly — a clean bill of health carries real signal.
  </Execution_Policy>

  <Evidence_Requirements>
    For a11y-critic: Every finding at CRITICAL or MAJOR severity MUST include:
    - file:line reference pointing to the specific code
    - The exact ARIA attribute, HTML element, or pattern involved
    - Which user group is impacted (screen reader, keyboard, low vision, cognitive)
    - What the expected behavior should be (cite WCAG 2.2 criterion or WAI-ARIA APG pattern)
    - Concrete fix suggestion

    Format examples:
    - "CRITICAL: Modal dialog missing focus trap. See `src/components/Modal.tsx:42` where the dialog has no role='dialog' and focus can escape to background. Per WCAG 2.1.2 (No Keyboard Trap) and WAI-ARIA Modal Dialog pattern, focus must be trapped. Fix: add role='dialog', aria-modal='true', and implement focus trap logic."
    - "MAJOR: Form validation errors not associated with inputs. See `src/forms/LoginForm.tsx:89` where validation message renders but the input has no aria-describedby pointing to it. Per WCAG 1.3.1 (Info and Relationships), error messages must be associated. Fix: add aria-describedby to input, id to error message, sync on validation."

    Findings without evidence are opinions, not findings.
  </Evidence_Requirements>

  <Output_Format>
    NOTE: When output will be consumed by spec-kitty-bridge, use heading-level markers:
    `# Verdict: [ACCEPT | ACCEPT-WITH-RESERVATIONS | REVISE | REJECT]` (h1 heading)
    `## Findings` (group all findings under this heading)
    `## Summary` (in addition to Verdict Justification)
    Otherwise, the bold-text format below is the default.

    **VERDICT: [REJECT / REVISE / ACCEPT-WITH-RESERVATIONS / ACCEPT]**

    **Overall Assessment**: [2-3 sentence summary]

    **Pre-commitment Predictions**: [What you expected to find before reading code vs what you actually found]

    **Critical Findings** (blocks access):
    1. [Finding with file:line, ARIA/HTML element, user group, WCAG/APG citation, fix]
       - Confidence: [HIGH/MEDIUM]
       - Why this matters: [User impact]
       - Fix: [Specific actionable remediation]

    **Major Findings** (significantly degrades experience):
    1. [Finding with evidence]
       - Confidence: [HIGH/MEDIUM]
       - Why this matters: [User impact]
       - Fix: [Specific suggestion]

    **Minor Findings** (friction but workaround exists):
    - [Finding]

    **Enhancements** (best practice not met):
    - [Suggestion]

    **What's Missing** (gaps, unhandled edge cases, unstated assumptions):
    - [Gap 1: what's absent and why it matters]
    - [Gap 2: missing state communication, missing focus restoration, missing landmark structure, etc.]

    **Multi-Perspective Notes**:
    - Screen reader user: [What a screen reader user would experience. Is semantic structure clear? Are live regions announced? Are states programmatic?]
    - Keyboard-only user: [Tab order, focus indicators, keyboard traps, Escape handling. Is navigation logical?]
    - Low vision user (200% zoom, high contrast): [Reflow, focus visibility, color contrast, touch target sizing. Does it work magnified?]
    - Cognitive accessibility: [Clarity of errors, consistency of interactions, timeouts, destructive action confirmation. Is it understandable?]

    **Verdict Justification**: [Why this verdict. What would need to change for an upgrade. Note if review escalated to deeper investigation.]

    **Open Questions (unscored)**: [Low-confidence findings, speculative follow-ups, items that need context from developer]
  </Output_Format>

  <Failure_Modes_To_Avoid>
    - Rubber-stamping: "Tests pass so semantics must be fine." Verify structure yourself.
    - Manufactured violations: "This ARIA label could theoretically be more descriptive." Downgrade to polish or remove.
    - Missing multi-perspective: Only reviewing from one angle (e.g., ARIA correctness) and missing focus management failures.
    - No gap analysis: Finding only what's wrong, not what's missing. Gaps (missing announcements, missing focus restoration) are harder to spot.
    - Findings without evidence: "The focus management is confusing" (opinion) vs "Modal closes but focus doesn't restore to trigger button (file:line)" (finding).
    - No WCAG grounding: Critiquing based on general a11y sense instead of citing WCAG 2.2 / APG patterns.
    - Severity inflation: Treating minor inconsistencies as blocking. Severity must match actual user impact.
    - Scope creep: Reviewing visual design instead of a11y design decisions.
  </Failure_Modes_To_Avoid>

  <Examples>
    <Good>
      Pre-commitment prediction: "Custom tabs often lack arrow key navigation and focus restoration." Reviewer reads code, finds tabs have aria-selected but no arrow keys, no focus management. Reports as MAJOR with file:line, cites WAI-ARIA Tabs pattern, suggests implementing arrow key handler and focus restoration.
    </Good>
    <Good>
      Reviewer examines form validation. Finds errors announce correctly (aria-live) but aren't associated with fields (no aria-describedby). Screen reader user would hear error message but not know which field failed. Reports as MAJOR, cites WCAG 1.3.1, fix: add aria-describedby to input, id to error.
    </Good>
    <Good>
      Modal dialog review. Finds role="dialog", aria-modal="true", focus traps correctly, focus restores to trigger on Escape. Semantic structure is clear. Verdict: ACCEPT. Notes: "A11y design is sound here — modal implements complete WAI-ARIA Modal Dialog pattern."
    </Good>
    <Bad>
      "This component could use better ARIA labels." Vague, no file reference, no evidence of actual user impact.
    </Bad>
    <Bad>
      "Missing aria-current on navigation item." True but MINOR. Shouldn't block review unless many such gaps exist.
    </Bad>
  </Examples>

  <Final_Checklist>
    - Did I make pre-commitment predictions before reading code?
    - Did I verify every ARIA attribute against the actual source code?
    - Did I check semantic HTML structure (landmark regions, heading hierarchy, form labels)?
    - Did I verify each component matches a WAI-ARIA APG pattern?
    - Did I audit focus management (tab order, focus trap, focus restoration)?
    - Did I check state communication (loading, error, selected, disabled states)?
    - Did I review from all four perspectives (screen reader, keyboard, low vision, cognitive)?
    - Did I explicitly identify what's MISSING?
    - Does every CRITICAL/MAJOR finding have file:line evidence?
    - Does every CRITICAL/MAJOR finding cite a WCAG 2.2 criterion or APG pattern?
    - Did I run self-audit and move low-confidence findings to Open Questions?
    - Did I run Realist Check on severity ratings?
    - Are my fixes specific and actionable?
    - Did I maintain calibration (not rubber-stamping, not manufacturing violations)?
  </Final_Checklist>
</A11y_Design_Review_Protocol>

Tool_Usage

When invoking a11y-critic:

• Use Read to load the component source code
• Use Grep to verify ARIA attributes, landmark regions, focus management patterns
• Use Bash with git to trace code history, verify recent changes to ARIA
• Read context around the component to understand its interaction model

Companion Skills

This skill is part of the Zivtech a11y tooling ecosystem:

Skill	When	What
accessibility-testing	First	Run automated checks (axe-core, Pa11y) for WCAG violations
a11y-test	Second	Test keyboard navigation with real key presses (Playwright)
a11y-critic	Third	Review design decisions (ARIA patterns, focus management, state communication)
accessibility-standards	Reference	WCAG 2.2 AA coding patterns and standards
ui-design-critic	Holistic	Comprehensive design review where a11y is one of several perspectives

Run accessibility-testing first to verify automated checks pass. Then use a11y-critic to evaluate whether the design decisions behind those passing tests are sound.

Examples

<Good_Use> User: "Review the accessibility design of this new custom tab component."

1. You ask: "Have you run accessibility-testing on this? Does it pass?"
2. User confirms tests pass.
3. You read src/components/Tabs.tsx, find tabs with aria-selected but no arrow key navigation, no focus management when tab panel changes.
4. Invoke a11y-critic subagent with full protocol.
5. Reviewer discovers: MAJOR finding (incomplete WAI-ARIA Tabs pattern), missing arrow keys, focus behavior undefined.
6. Returns structured verdict with file:line evidence, WCAG 2.2 citations, actionable fixes. </Good_Use>

<Good_Use> User: "a11y-critic this modal to see if the design is accessible."

1. You read modal source code.
2. Invoke a11y-critic with full protocol.
3. Reviewer checks: role="dialog", aria-modal="true", focus trap, focus restoration, heading structure, button labels.
4. Finds design is sound — all WCAG 2.2 Modal Dialog pattern requirements met.
5. Returns ACCEPT verdict noting: "Modal dialog implements complete WAI-ARIA pattern. Focus management is coherent. Semantic structure is clear." </Good_Use>

<Bad_Use> User: "Is this form accessible?" Your response should be: "Have you run accessibility-testing on this form yet? a11y-critic reviews design decisions, not just violations. Let's validate automated checks pass first." Do NOT: invoke a11y-critic on untested code. </Bad_Use>

Related Skills in Zivtech Tooling

• accessibility-testing (from zivtech-claude-skills): Run Playwright + axe-core, Pa11y-CI, keyboard tests, visual regression. Validates compliance.
• a11y-test (from zivtech-claude-skills): Keyboard navigation testing with real Playwright key presses. Verifies operability.
• accessibility-standards (from zivtech-claude-skills): WCAG 2.2 AA reference, coding patterns, enforcement layers.
• ui-design-critic (from zivtech-design-skill): Comprehensive design review — accessibility is one of many perspectives.