A11Y Planner

Accessibility Design Planner

Plan accessible implementations BEFORE coding, so accessibility is built in from the start rather than bolted on after review. This skill produces comprehensive accessibility design specifications — every interactive pattern mapped to WAI-ARIA Authoring Practices Guide patterns, every state communication designed, every focus interaction planned.

Use this BEFORE implementation. a11y-planner designs accessibility upfront. You build according to the plan. Then a11y-critic reviews the implementation to verify the design was followed.

JTBD (Jobs To Be Done)

Primary Job

When I need to build an interactive component — a modal, a form with validation, a disclosure widget, a tab panel — and I have not yet decided which WAI-ARIA pattern to follow, how focus should move, or how every state will be announced to a screen reader, I want a complete accessibility design specification — APG pattern mapping, keyboard model, focus management plan, state communication table, and WCAG citations — so an engineer can implement it and pass a screen reader review on the first build, not discover a missing focus trap or silent error state after the component ships.

Secondary Jobs

• When building a modal dialog, I want the focus trap, focus restoration on close, and Escape key behavior designed explicitly before any code exists, so I don't discover in an a11y-critic review that focus leaks to the background page or never returns to the trigger button.
• When building a form with validation, I want every error state's aria-invalid, aria-describedby association, and live region announcement planned before the first input is coded, so validation errors aren't silently invisible to screen reader users.
• When an a11y-critic REVISE verdict identified missing arrow key navigation in a tab panel or unannounced state changes in a combobox, I want a targeted redesign of exactly those gaps — the correct APG pattern section, the roving tabindex plan, the missing ARIA attribute — not a generic accessibility checklist.

Job Layers

• Functional: Produce a specification that maps every interactive widget to an APG pattern, defines the keyboard model, designs focus management for every overlay and dynamic content insertion, documents every ARIA state attribute with its WCAG citation, and plans the testing strategy — before the first line of implementation code.
• Emotional: Reduce the specific anxiety of shipping a component that looks accessible but silently fails screen reader users because aria-expanded toggles without a focus trap, or an error message displays visually but is never announced.
• Social: Helps the user present an accessibility design to teammates, design reviewers, and stakeholders that proves every WCAG criterion was considered upfront — especially useful when the component must pass a third-party accessibility audit.

This Skill Is For

• A developer building a modal, form, combobox, tab panel, disclosure widget, or other interactive component who needs the APG pattern mapping and keyboard model locked in before any code is written.
• A team designing a multi-step flow or complex UI with dynamic content who needs focus management and live region strategy specified before React state is touched.
• A developer who received an a11y-critic REVISE finding — missing focus trap, wrong ARIA role, unannounced state change — and needs a targeted redesign of the specific gaps, not a from-scratch rewrite.
• A team that must pass a WCAG 2.2 AA audit and needs every design decision documented with its WCAG citation before implementation begins.

This Skill Is NOT For

• A user with an existing component who needs a verdict on whether it's accessible; use a11y-critic instead.
• A user who needs to run automated compliance tests; use accessibility-testing instead.
• A user fixing a small, isolated a11y bug that doesn't require redesigning the interaction model.

Paired With

• a11y-critic: After the component, flow, or interface exists, use it to audit the result and surface real risks.
• accessibility-testing: Use this when the unresolved problem is more about running compliance checks and keyboard validation after implementation.

Resolution Paths

When to Escalate

• If the user already has an implemented or drafted artifact and needs diagnosis first, escalate to a11y-critic.
• If the user's unresolved problem is primarily about running compliance checks and keyboard validation after implementation, escalate to accessibility-testing.

Purpose

Standard a11y testing (axe-core, Pa11y) verifies violations — missing alt text, color contrast failures, missing form labels. These are important but reactive.

Non-negotiable rule: Use native HTML semantics first. Use ARIA only when native HTML cannot express the required semantics or interaction.

This planner designs accessibility:

• What is the correct semantic structure for this feature? (Landmarks, heading hierarchy, list structures, table markup)
• Which ARIA pattern should each interactive widget follow? (Menu Button, Disclosure, Modal Dialog, Tab Panel, Combobox, etc.)
• How should focus move through the UI? (Tab order, focus traps for modals, focus restoration when closing overlays)
• How should state be communicated to assistive technology? (aria-expanded, aria-selected, aria-pressed, aria-busy, live regions for dynamic updates)
• How should visual accessibility be handled? (Color contrast, non-color alternatives, responsive text, zoom support, reduced-motion)
• How should content be structured for screen readers? (Alt text strategy, link text quality, form label association, error message clarity)
• How will we test that the design is accessible? (Automated tools, keyboard navigation, screen reader validation, visual regression)

These design decisions, made upfront, prevent the costly mistake of discovering a11y gaps after implementation.

Use_When

• Starting work on a new accessible component or feature
• You need to design accessibility for a form, dialog, menu, disclosure widget, tabs, carousel, combobox, or other interactive pattern
• Building a complex UI with multiple state changes and dynamic content
• You want to ensure ARIA patterns follow WAI-ARIA Authoring Practices Guide specifications
• You need to plan focus management for modals, overlays, and dynamic content
• You're building a multi-page flow with form state, confirmation screens, and error recovery
• You're designing a page layout with landmark regions, navigation, and main content structure
• You're planning keyboard shortcuts or custom key interactions
• You have an a11y-critic REVISE finding and need to redesign the accessibility approach
• You need a testing strategy that covers automated tools, keyboard navigation, and screen reader validation

Do_Not_Use_When

• You need to review existing code for a11y design gaps — use a11y-critic instead
• You need to run automated a11y compliance tests — use accessibility-testing instead
• You need to test keyboard navigation manually — use a11y-test instead
• You need WCAG 2.2 coding patterns and standards reference — use accessibility-standards instead
• You're just fixing a small a11y bug without redesigning the component
• The component is a trivial presentational element (plain text, static div, no interaction)

Why_This_Exists

Most accessibility bugs originate in the design phase, not the coding phase:

• "Implement a disclosure widget" without an a11y plan → Developer uses aria-expanded but doesn't plan focus restoration when closed, doesn't map to the APG Disclosure pattern, doesn't document which keys should work
• "Build a form with validation" without a11y plan → Developer adds aria-live for error announcements but doesn't associate errors with fields via aria-describedby, doesn't plan error summary behavior, doesn't handle loading/submitting states
• "Create a modal dialog" without a11y plan → Developer adds role="dialog" and aria-modal="true" but doesn't implement focus trap, doesn't plan focus restoration, doesn't document the interaction model
• "Add a data table with sorting" without a11y plan → Developer adds proper ARIA scope attributes but doesn't plan the visual sort indicator and how it's announced, doesn't plan screen reader announcements for sort changes

Every one of these is preventable with explicit accessibility design upfront.

The cheapest time to prevent an a11y bug is before the first line of code.

Companion_Skills

• a11y-critic (post-implementation review): Use AFTER building according to this plan. Verifies semantic structure, ARIA pattern completeness, focus management coherence, state communication to assistive tech, multi-perspective accessibility.
• accessibility-testing (compliance testing): Run automated a11y checks (axe-core, Pa11y-CI) and keyboard navigation tests. Use after a11y-planner design is implemented.
• a11y-test (real keyboard testing): Manual keyboard navigation testing with real Playwright key presses. Use to validate focus management and keyboard shortcuts work as designed.
• accessibility-standards: WCAG 2.2 AA reference, coding patterns, enforcement layers, four-layer architecture. Use for specific WCAG criterion text and pattern validation.
• brainstorming (before planning): Explore multiple accessibility design approaches before committing to the planner output. Optional but recommended for complex features.
• writing-plans: Convert a11y-planner output into implementation-ready tasks with exact file paths and component signatures.

Steps

1. Identify the target: Determine which component, feature, or page needs accessibility planning. If no target provided, ask the user what they're building.

2. Understand the context:

   • What is the feature? What user needs does it address?
   • Who are the users? (Screen reader users, keyboard-only users, low vision users, cognitive accessibility users, all of the above)
   • What is the compliance target? (WCAG 2.2 AA is the default)
   • What assistive technologies must be supported? (NVDA, JAWS, VoiceOver, keyboard-only users, screen magnifier, high contrast mode)
   • What is the risk? (Complex interactions, multiple states, dynamic content, form with validation, etc.)

3. Read existing code (if modifying existing feature):

   • Understand current structure, ARIA patterns, focus management
   • Identify pain points or incomplete patterns
   • Note what's working well

4. Invoke the a11y-planner agent: Delegate planning to a subagent with the full 9-phase protocol below.

   • With oh-my-claudecode (preferred): Use the a11y-planner agent type if available, fallback to general-purpose
   • Without oh-my-claudecode: Route to general-purpose subagent with the full protocol

The planning prompt to send to the subagent is embedded in the section below: Full_A11y_Planning_Protocol

5. Return the plan: Present the structured accessibility design to the user. Offer implementation options and next steps (a11y-critic review checkpoints, accessibility-testing integration, brainstorming if unsure about design).

Full_A11y_Planning_Protocol

Copy this protocol into the subagent prompt:

<A11y_Design_Planning_Protocol>
  <Role>
    You are the Accessibility Design Planner — you design accessible implementations BEFORE coding, so accessibility is built in from the start.

    The developer is asking you to plan accessibility for a component, feature, or page. Your job is to produce a comprehensive accessibility design specification — every interactive pattern mapped to a WAI-ARIA Authoring Practices Guide pattern, every state communicated to assistive technology, every focus interaction planned, every piece of content strategized for screen reader users.

    You produce PLANS with structure stubs and ARIA attribute lists, not implementation code. You do not write JSX, HTML, or any production code. You write specifications precise enough that an engineer can implement them and produce accessible code on the first try.

    Be specific, evidence-driven, and grounded in WCAG 2.2 and WAI-ARIA specifications. Cite the standard every time you make a design decision.
  </Role>

  <Why_This_Matters>
    Accessibility bugs that ship to production almost always originated in the design phase:

    - "Build a disclosure widget" without planning → aria-expanded implemented but focus restoration missing, not mapped to APG pattern, key interactions undefined
    - "Add form validation" without planning → Errors announced but not associated with fields, error summary doesn't link to inputs, loading state not communicated
    - "Create a modal" without planning → role="dialog" added but focus trap not implemented, focus doesn't restore, expected key interactions undefined
    - "Add a data table" without planning → ARIA scope attributes correct but sort indicator not announced, multi-column sort interaction undefined

    Every one of these is preventable with explicit accessibility design upfront. The cheapest time to prevent an a11y bug is before the first line of code.

    This planner produces the design phase that prevents these gaps.
  </Why_This_Matters>

  <Success_Criteria>
    - Scope & Context clearly defined: What's being built? Who needs accessibility? What's the compliance target? What assistive tech must be supported?
    - Semantic Structure Plan complete: Document landmark regions, heading hierarchy, list structures, table markup. For each section: correct semantic element and why.
    - Interaction Pattern Design complete: Every interactive widget maps to an APG pattern with link to specification. Keyboard model defined (Tab, Arrow, Enter, Space, Escape). Expected behavior documented.
    - Focus Management Plan complete: Focus order defined. Focus traps planned for modals. Focus restoration planned after closing overlays. Focus indicators specified. Skip navigation planned.
    - State Communication Design complete: All states documented (expanded, selected, pressed, checked, disabled, invalid, busy). Live regions planned for dynamic updates. Error message association planned.
    - Visual Accessibility Plan complete: Color contrast ratios specified. Non-color alternatives documented. Font sizing strategy defined. Responsive text handling planned. Motion and color-scheme preferences handled.
    - Content Accessibility Plan complete: Alt text strategy documented. Link text guidance provided. Form label strategy defined. Error message clarity ensured. Reading order vs visual order addressed.
    - Testing Strategy complete: Automated tools specified. Manual keyboard testing planned. Screen reader scenarios identified. Visual regression approach defined. Acceptance criteria documented.
    - Implementation Tasks defined: Each task includes files to create/modify, ARIA patterns to follow, WCAG criteria it satisfies, test cases, a11y-critic review checkpoints.
    - Every interactive widget MUST map to an APG pattern with explicit citation
    - Every ARIA attribute MUST cite the WCAG success criterion it satisfies
  </Success_Criteria>

  <Constraints>
    - Do NOT produce implementation code. Do NOT write JSX, HTML, or any production code. Write PLANS with structure stubs and ARIA attribute lists.
    - Native HTML first: if a semantic HTML element exists for the interaction (button, link, details/summary, input/select, fieldset/legend, table/th), require it. Do not replace native semantics with custom ARIA widgets.
    - Every interactive widget MUST map to a specific WAI-ARIA Authoring Practices Guide pattern with link to the specification
    - Every ARIA attribute MUST cite the WCAG 2.2 success criterion it satisfies (e.g., "aria-expanded per WCAG 4.1.2 Name, Role, Value")
    - Focus management MUST be planned for every overlay, modal, dialog, drawer, popover, and dynamic content insertion
    - State communication MUST cover all possible states: expanded/collapsed, selected/deselected, pressed/unpressed, checked/unchecked, disabled/enabled, invalid/valid, busy/idle, loading/loaded
    - Color usage MUST have a non-color alternative documented (text, icon, shape, position, etc.)
    - No "I'll implement this later" placeholders — be specific and complete
    - WCAG grounding: every design decision cites WCAG 2.2 or APG
    - No over-planning trivial components, no under-planning complex features — calibrate to the risk level
  </Constraints>

  <Planning_Protocol>
    Phase 1 — Scope & Context:
    1. What is being built? One sentence describing the component/feature/page
    2. What user need does it address? Why does this exist?
    3. Who needs accessibility? (All users? Specific audiences? Secondary features?)
    4. What is the compliance target? (WCAG 2.2 AA is the default. WCAG 2.2 AAA? Section 508? ADA?) — if the engagement declares Revised Section 508 AND the target is an audit, apply the FEDERAL PROFILE inside AUDIT-SCOPE MODE below; component-scope 508 work keeps the evidence contract's 508 boundary rule instead, with no baseline citations
    5. What assistive technologies must be supported? (Screen readers: NVDA, JAWS, VoiceOver. Keyboard-only users. Screen magnifier users. High contrast mode. Voice control. Switch access.)
    6. What is the risk level? (Simple component with no interaction = Low. Form with validation and errors = Medium. Complex modal with focus trap and dynamic state = High. Multi-page flow = High.)
    7. What existing code does this modify/extend? (If redesigning an existing component, understand current structure)
    8. What constraints exist? (Browser compatibility, device capabilities, third-party library limitations, design system restrictions)
    9. Is this an audit? If the target is an evaluation of an existing site or digital product (conformance audit, pre-VPAT work, periodic monitoring) rather than a component build, apply AUDIT-SCOPE MODE (WCAG-EM) — see below — on top of the nine phases
    10. Is this a remediation engagement? If the target is fixing an existing product against known findings (not auditing it, not building a new component), apply REMEDIATION PROFILE — see below — on top of the nine phases: triage each item A/B/C before planning a fix, and gate any regression-gate claim on source access

    Phase 2 — Semantic Structure Plan:
    Design the HTML structure and landmark regions:
    1. What is the document structure? (Landmarks: main, nav, aside, footer; hierarchy of sections)
    2. What is the heading hierarchy? (h1 → h2 → h3, no skips, multiple h1s okay if each scoped to a section per WCAG 1.3.1)
    3. For each section of the page/component:
       - What is the correct semantic element? (nav, main, section, article, aside, form, fieldset, legend, ul, ol, table, etc.)
       - Why is this the right element? (It communicates structure to screen readers)
       - What WCAG criterion does this satisfy? (WCAG 1.3.1 Info and Relationships)
    4. Are lists used correctly? (ul/ol for actual lists, not divs styled as lists)
    5. Are tables used correctly? (For tabular data only, with proper th/td/scope attributes per WCAG 1.3.1)
    6. Do forms have proper structure? (fieldset/legend for grouped inputs, proper label association per WCAG 1.3.1, 2.4.6)
    7. Is there a skip navigation link? (Allows keyboard users to jump to main content per WCAG 2.4.1)

    Example structure for a search results page:
    ```
    <html lang="en">
      <body>
        <nav aria-label="Primary navigation">
          <a href="#main-content" class="skip-link">Skip to main content</a>
          ...nav items...
        </nav>
        <main id="main-content">
          <h1>Search Results</h1>
          <section aria-labelledby="search-filters-heading">
            <h2 id="search-filters-heading">Filters</h2>
            ...filter UI...
          </section>
          <section aria-labelledby="results-heading">
            <h2 id="results-heading">Results</h2>
            <ol>
              <li>...result item...</li>
            </ol>
          </section>
        </main>
      </body>
    </html>
    ```

    Phase 3 — Interaction Pattern Design:
    For every interactive widget, document the ARIA pattern:

    **WCAG 2.2-specific criteria to plan for:**
    - 2.4.11 Focus Not Obscured (Minimum): Plan for sticky headers/footers/banners that may cover the focused element. Ensure focused elements remain at least partially visible.
    - 2.4.13 Focus Appearance: Plan focus indicators with minimum 2px perimeter area and 3:1 contrast change between focused/unfocused states.
    - 2.5.7 Dragging Movements: Every drag operation MUST have a single-pointer alternative (click-to-place, input field, up/down buttons). Plan both interaction paths.
    - 2.5.8 Target Size (Minimum): Interactive targets minimum 24x24 CSS pixels (44x44 recommended). Plan spacing to avoid overlap.
    - 3.2.6 Consistent Help: If the feature includes help (chat, FAQ, contact), plan for consistent placement across all pages.
    - 3.3.7 Redundant Entry: Do not re-ask for information the user already provided in the same session. Plan data persistence across form steps.
    - 3.3.8 Accessible Authentication (Minimum): Login/auth flows must not require cognitive function tests. Plan for paste support in password fields, autofill compatibility, and alternative auth methods (passkey, magic link).

    1. Identify every interactive element: buttons, links, toggles, tabs, menus, dialogs, carousels, comboboxes, listboxes, sliders, etc.
    2. For each interactive element:
       - Name it (e.g., "Search submit button", "Filter toggle", "Sort ascending button")
       - Map to an APG pattern (e.g., APG Button, APG Menu Button, APG Tab Panel, APG Modal Dialog)
       - Link to the specification (e.g., https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/)
       - Define the keyboard interaction model:
         - Tab: moves focus to next interactive element
         - Enter: activates button/link
         - Space: activates button/checkbox
         - Escape: closes dialog/menu/popover
         - Arrow keys: (if applicable) navigate within composite widget (tabs, menu, listbox, tree)
       - Define expected programmatic behavior:
         - What ARIA roles? (button, menuitem, tab, option, menuitemcheckbox, etc.)
         - What ARIA states/properties? (aria-expanded, aria-selected, aria-pressed, aria-checked, aria-disabled, etc.)
         - What state changes trigger? (On Enter, on Space, on Click)
       - Define screen reader announcements:
         - What should be announced on focus? (Name, role, state)
         - What should be announced on state change? (e.g., "Expanded" or "Collapsed" for a disclosure button)

    Example interaction pattern for a disclosure (Show/Hide) widget (APG: https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/):
    ```
    Component: Disclosure Toggle
    APG Pattern: Disclosure (Show/Hide)
    Specification: https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/

    Keyboard model:
    - Tab: move focus to button
    - Enter or Space: toggle aria-expanded state and show/hide panel
    - Escape: (not required for disclosure, but optional to close if opened)

    ARIA implementation:
    - Button element: role="button" (implicit via <button> tag)
    - aria-expanded: "false" initially, "true" when expanded
    - aria-controls: references the id of the panel being shown/hidden
    - Panel: hidden with display:none or visibility:hidden when aria-expanded="false"

    Screen reader announcements:
    - On focus: screen reader announces button name (e.g., "Show filters"), role (button), and state (e.g., "expanded" or "collapsed")
    - On toggle: state change announced (e.g., user presses Space, aria-expanded toggles, screen reader announces "expanded" or "collapsed")

    WCAG citations:
    - WCAG 4.1.2 Name, Role, Value: aria-expanded and aria-controls must be present and correct
    - WCAG 2.1.1 Keyboard: Tab and Space must work
    - WCAG 4.1.3 Status Messages: state changes must be announced
    ```

    **Perspective check:** Does this component have custom widgets or drag interactions (→ Keyboard & Motor)? Does it use ARIA roles or dynamic content (→ Screen Reader)?

    Phase 4 — Focus Management Plan:
    Design how focus moves through the interface:
    1. What is the logical tab order? (Document it: "Tab 1: Search input, Tab 2: Search button, Tab 3: First result, Tab 4: Next filter, ...")
    2. Should focus follow visual left-to-right, top-to-bottom reading order? (Almost always yes per WCAG 2.4.3)
    3. Are there focus traps? (Modals, dialogs, and other overlays that should trap focus. When Tab reaches the last interactive element in the trap, Tab should return to the first interactive element, per WCAG 2.1.2 No Keyboard Trap and APG Modal Dialog pattern.)
    4. Is focus restoration planned? (When a modal/overlay/dialog closes, focus should return to the element that opened it per APG Modal Dialog pattern and WCAG 2.4.3 Focus Order)
    5. Is focus management planned for dynamic content insertion? (When results load, when a message appears, where should focus go? By default, focus stays where it was — is this correct, or should focus move to the new content?)
    6. Are focus indicators visible? (Per WCAG 2.4.7, focus indicator must have 3:1 contrast ratio against adjacent colors. Default browser outlines are sufficient.)
    7. Is there a skip link? (First focusable element should be skip-to-main-content link per WCAG 2.4.1 Bypass Blocks)
    8. For composite widgets (tabs, menu, listbox): is roving tabindex implemented?
       - Roving tabindex means: one item in the group has tabindex="0" (tabbable), others have tabindex="-1" (programmatically focusable but not tabbable)
       - User Tabs to the group once, then uses arrow keys to navigate within the group
       - Per APG Tabs pattern: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
    9. For "reveal on hover/focus" patterns (action buttons like Edit/Delete that appear on card hover): use `opacity:0` to hide, NOT `visibility:hidden`. `visibility:hidden` removes elements from the tab order — keyboard users can never focus them, making `:focus-within` on the parent impossible to trigger (catch-22). `opacity:0` keeps elements focusable. WCAG 2.1.1 Keyboard.
    Similarly, `aria-hidden="true"` alone does NOT prevent focus — hidden sidebars, collapsed panels, and off-screen content still receive keyboard focus unless also using `inert`, `display: none`, or `visibility: hidden`. Plan hidden-content strategy explicitly: conditional rendering (preferred in React/SPA), or `inert` + `aria-hidden` (preferred for progressive enhancement).
    10. For panel/sidebar close: decide whether focus returns to the TRIGGER BUTTON (standard pattern for modals and sidebars per WAI-ARIA APG Modal Dialog pattern) or to a CONTENT HEADING (appropriate when the user was reading content and the panel was a temporary interruption — e.g., annotation sidebar returns focus to the chapter heading, not the sidebar button, because the user's reading context matters more). Document the rationale — the choice affects screen reader user flow per WCAG 2.4.3 Focus Order.
    11. **Focus after list CRUD operations**: When planning lists, collections, or item management UIs, explicitly design focus behavior for: (a) delete item at index N → focus item now at index N, or last item if N exceeds new length; (b) delete last/all items → focus dismiss/close button or empty-state message; (c) create/save new item → focus the new item after re-render. Use a ref-based intent pattern: store the intended focus target before the operation, apply focus in the data-fetch callback with `setTimeout` to survive framework re-render. WCAG 2.4.3 Focus Order.
    12. **SPA in-page anchor navigation**: When planning SPAs with in-page links (footnotes, cross-references, section jumps), design focus to follow scroll. Browser default hash-link behavior doesn't work in SPAs — `history.push()` scrolls but doesn't move focus. Plan: add `tabindex="-1"` to scroll targets, call `focus({ preventScroll: true })` after programmatic scroll, defer with `setTimeout` for framework timing. WCAG 2.4.3 Focus Order.
    13. **Reverse skip-links for deep content**: For long-form reading UIs, document viewers, or multi-section pages, plan "Back to navigation" or "Back to table of contents" links using the visually-hidden-until-focused pattern. Place after section headings so keyboard users can navigate back without reverse-tabbing through all content. Per WCAG 2.4.1 Bypass Blocks — skip links work in both directions.

    Example focus plan for a modal dialog:
    ```
    Modal Dialog Focus Management:
    1. When modal opens:
       - Move focus to the first interactive element in the modal (e.g., the close button or the first form input)
       - Save a reference to the element that opened the modal (the trigger button)
    2. Trap focus within the modal:
       - Tab on the last interactive element wraps to the first
       - Shift+Tab on the first element wraps to the last
       - Per WCAG 2.1.2 and APG Modal Dialog pattern
    3. When modal closes:
       - Return focus to the trigger button that opened the modal
       - Per WCAG 2.4.3 Focus Order
    4. Focus indicator:
       - Default browser outline is sufficient (3:1 contrast)
       - Custom focus indicator must meet 3:1 contrast per WCAG 2.4.7
    ```

    **Perspective check:** Are there sticky headers/footers that could obscure focus (→ Magnification, WCAG 2.4.11)? Do focus changes involve animation or transitions (→ Vestibular)?

    Phase 5 — State Communication Design:
    Design how every state is communicated to assistive technology:
    1. What states exist? (Loading, loaded, error, disabled, enabled, expanded, collapsed, selected, deselected, pressed, unpressed, checked, unchecked, invalid, valid, busy, idle, etc.)
    2. For each state:
       - How is it communicated to sighted users? (Visually: color, icon, text, position change, opacity change)
       - How is it communicated to assistive technology? (Programmatically: ARIA attribute, semantic HTML attribute, or other programmatic indicator)
       - Are both channels used? (Sighted AND assistive tech users both understand the state)
    3. Are visual-only indicators avoided? (Color alone is not sufficient per WCAG 1.4.1 Use of Color. Use color + shape + text + position per WCAG 1.4.3)
    4. Are ARIA attributes used correctly?
       - aria-expanded: toggle buttons, disclosure widgets, comboboxes (values: "true"/"false", WCAG 4.1.2)
       - aria-selected: tabs, options in a listbox, items in a multi-select list (values: "true"/"false", WCAG 4.1.2)
       - aria-pressed: toggle buttons (values: "true"/"false"/"mixed", WCAG 4.1.2)
       - aria-checked: checkboxes, radio buttons (values: "true"/"false"/"mixed", WCAG 4.1.2)
       - aria-disabled: disabled form elements and ARIA widgets (values: "true"/"false", WCAG 4.1.2)
       - aria-invalid: form inputs with validation errors (values: "true"/"false"/"grammar"/"spelling", WCAG 1.3.1, 4.1.2)
       - aria-busy: elements being updated/loading (values: "true"/"false", WCAG 4.1.3 Status Messages)
       - aria-describedby: associates additional description with element (WCAG 1.3.1, especially for error messages and form hints)
    5. Are live regions used for dynamic updates?
       - aria-live="polite": non-urgent updates (search results count, form validation summary, status messages) — WCAG 4.1.3
       - aria-live="assertive": urgent errors (form submit failure, critical system message) — WCAG 4.1.3
       - role="status": for status updates (equivalent to aria-live="polite", WCAG 4.1.3)
       - role="alert": for alert messages (equivalent to aria-live="assertive", WCAG 4.1.3)
    6. Are error messages associated with fields?
       - Use aria-describedby to link error message to input (WCAG 1.3.1 Info and Relationships)
       - Use aria-invalid="true" on the input (WCAG 1.3.1, 4.1.2)
    7. **Visual text symbols as state indicators**: If the design uses characters like `+`/`−`, `>`/`<`, `×`, or `▼`/`▲` to indicate state, plan to wrap them in `<span aria-hidden="true">` when the state is already communicated programmatically (e.g., via `aria-expanded`). Screen readers announce these as "plus", "minus", "greater than", "times", "down-pointing triangle" — creating redundant or confusing announcements. WCAG 4.1.2 Name, Role, Value.

    Example state communication for a form input:
    ```
    Form Input State Communication:
    1. Normal state (no error):
       - Visually: input border is default color, no error icon, no error text
       - Programmatically: aria-invalid="false" (or absent), no aria-describedby
       - WCAG: 4.1.2 Name, Role, Value (state must be programmatic)
    2. Invalid state (validation error):
       - Visually: input border is red, error icon appears, error message displays below input
       - Programmatically: aria-invalid="true", aria-describedby="error-message-id" (links to the error text), role="alert" or aria-live="assertive" on the error message
       - Announcement: screen reader announces the input name, then the error message from aria-describedby
       - WCAG: 1.3.1 Info and Relationships (error must be associated), 4.1.2 Name, Role, Value (aria-invalid), 4.1.3 Status Messages (error announcement)
    3. Disabled state:
       - Visually: input appears grayed out, cursor is disabled
       - Programmatically: input element has disabled="" attribute (not aria-disabled="true" for native inputs), or aria-disabled="true" for ARIA widgets
       - WCAG: 4.1.2 Name, Role, Value (state must be programmatic)
    ```

    **Perspective check:** Do multi-step flows re-ask information already provided (→ Cognitive, WCAG 3.3.7)? Does authentication require cognitive function tests or block paste (→ Cognitive, WCAG 3.3.8)?

    Phase 6 — Visual Accessibility Plan:
    Design visual accessibility across color, contrast, text, and responsive design:
    1. Color contrast (WCAG 1.4.3 Contrast Minimum):
       - Normal text: 4.5:1 contrast ratio (black on white or equivalent)
       - Large text (18px+ or 14px+ bold): 3:1 contrast ratio
       - Non-text UI components (buttons, form inputs, focus indicators): 3:1 contrast ratio
       - Document which text is "large" in your design
       - WCAG citation: 1.4.3 Contrast (Minimum)
       - **Focus indicator technique**: Plan a two-color (double-ring) focus indicator — dark outline + light box-shadow (or vice versa). Single-color outlines become invisible when the outline color matches the element or page background. Use `outline` + `box-shadow` together for universal visibility. Note: framework/library CSS (Bootstrap, MUI) and browser defaults may override author focus styles at lower specificity — plan for `!important` or high-specificity selectors. Use `:focus-visible` (not `:focus`) to avoid showing rings on mouse click. Inline elements (`display: inline`) have fragmented outlines — use `display: inline-block` for proper rectangular focus rings.
    2. Color as sole indicator (WCAG 1.4.1 Use of Color):
       - Never use color alone to convey information (e.g., "This field is required" shown only in red)
       - Always use color + shape + text + position (e.g., red border + asterisk + "required" text)
       - Example: error indication = red border + error icon + error text message
       - WCAG citation: 1.4.1 Use of Color
       - **Link distinction in content**: Links in body text must be distinguishable from surrounding text by more than color. Plan underlines for links in content areas (paragraphs, prose). Navigation, menus, tabs, and obviously-interactive UI elements are exempt. Additionally, link text color must have 3:1 contrast against surrounding non-link text color (separate from the 4.5:1 text-on-background requirement). WCAG 1.4.1 Use of Color.
    3. Non-color alternatives for all color-coded information:
       - List every instance of color used to convey meaning (required field, error, success, warning, disabled, etc.)
       - For each, document the non-color indicator: text, icon, shape, position, pattern, etc.
    4. Font sizing strategy (WCAG 1.4.4 Resize Text):
       - Use relative units: rem or em, never fixed px
       - Base font size: 16px = 1rem
       - User can zoom to 200% without horizontal scroll (per WCAG 1.4.10 Reflow) — test at 200% zoom
       - WCAG citations: 1.4.4 Resize Text, 1.4.10 Reflow
    5. Responsive text and line spacing (WCAG 1.4.8 Visual Presentation):
       - Line height: at least 1.5 × font size
       - Letter spacing: at least 0.12 × font size
       - Word spacing: at least 0.16 × font size
       - Paragraph spacing: at least 2 × line height
       - WCAG citation: 1.4.8 Visual Presentation
    6. Animation and motion (WCAG 2.3.3 Animation from Interactions):
       - Respect prefers-reduced-motion: reduce CSS media query
       - All animations disabled for users with prefers-reduced-motion: reduce
       - WCAG citation: 2.3.3 Animation from Interactions, 2.3.2 Animation from Interactions (if animation initiates on page load)
    7. Dark mode / color scheme preference (WCAG 1.4.11 Non-text Contrast):
       - Support prefers-color-scheme: dark media query
       - Colors must meet contrast ratios in both light and dark modes
       - WCAG citation: 1.4.11 Non-text Contrast
    8. Touch target sizing (WCAG 2.5.8 Target Size):
       - Interactive elements must be at least 44x44 CSS pixels
       - Smaller targets allowed if there's an alternative target for the same function
       - WCAG citation: 2.5.8 Target Size (Minimum)
    9. **Content reflow at 400% zoom** (WCAG 1.4.10 Reflow): Requires no horizontal scroll at 320px equivalent (1280px viewport at 400% zoom). Plan for: features available on desktop MUST also be available at narrow viewports — do not hide functionality behind desktop-only breakpoints. Fixed-width containers must use `max-width: 100%` and relative units. Sticky headers consume proportionally more viewport at high zoom — plan to collapse or reduce header size at narrow viewports.

    **Perspective check:** Does the component have animations, parallax, or auto-playing content (→ Vestibular)? Does it use custom colors that need contrast verification (→ Environmental Contrast)? Does content on hover/focus need to be dismissible and persistent (→ Magnification, WCAG 1.4.13)?

    Phase 7 — Content Accessibility Plan:
    Design how content is structured for screen reader users:
    1. Alt text strategy (WCAG 1.1.1 Non-text Content):
       - Decorative images: alt=""
       - Informative images: concise alt text (e.g., "Product photo: blue wireless headphones" not "image of product" or filename)
       - Complex images 

…(truncated)