Docs Accessibility (a11y)

Make the timepicker-ui documentation site (docs-app/, Next.js 16) usable by keyboard and assistive technology. This skill is a thin orchestrator: the real work is done by the docs-accessibility subagent. The skill exists to hold the approval gate the subagent can't run itself.

Standard: WCAG 2.2 AA. Scope is docs-app/ only - the library is /a11y.

Arguments (optional)

• A focus area narrows the run, e.g. /docs-a11y nav, /docs-a11y command-menu, /docs-a11y contrast, /docs-a11y headings, /docs-a11y keyboard. No argument = full audit.
• --apply-all skips the per-area approval prompt and applies the whole audited plan (still reports
  • verifies). Use only for an explicitly unattended run.

Workflow

Phase 1 — Audit (read-only)

Dispatch the docs-accessibility subagent (Task tool, subagent_type: docs-accessibility) in audit mode, with the focus area if given. Ask for a prioritized, file-level plan grouped into:

1. Structure & landmarks (one <main>, nav/header/footer, skip link, heading order)
2. Keyboard & focus (command menu, mobile sidebar, dialogs: trap/Escape/focus-return, visible focus, aria-expanded/aria-current)
3. Names, roles, contrast (icon-button labels, decorative aria-hidden, ≥4.5:1 text contrast in light AND dark)
4. Content & media (lang, descriptive links, labelled copy buttons, alt text)
5. Motion & responsiveness (prefers-reduced-motion, reflow at 320px / 400% zoom) Each finding cites its WCAG reference and the exact file + change. No edits.

Phase 2 — Present & approve (gate)

Relay the plan concisely (grouped, with references). Use AskUserQuestion to approve all, pick which groups/items to apply, or skip. Capture the approved set. Do not skip this gate unless --apply-all was passed.

Phase 3 — Apply

Dispatch docs-accessibility again in apply mode with the exact approved list. It implements fixes (landmarks, headings, aria-*, focus management, labels, contrast/markup) in docs-app's own TS/App-Router style and line endings, using native elements and the WAI-ARIA patterns correctly and adding no heavy deps.

Phase 4 — Verify & report

• Run npm run build / npm run lint inside docs-app/ (and an axe/Lighthouse a11y pass if the tooling is available), then /verify per HARD RULES §5. Report real output; never assume green.
• Summarize what changed, grouped by the five areas, with the file list.
• Give the manual checklist: keyboard-only walkthrough (header → command menu → sidebar → a docs page), Escape/focus-return on the menus, a screen-reader pass on one page, and a contrast check in both light and dark themes.
• Flag anything that's actually a library a11y bug (seen via a live demo) for /a11y, and any visual/content redesign for docs-site.

Guardrails

• docs-app/ only; never edit the library in app/ or dist/.
• Match docs-app conventions; docs-app files are CRLF like the library.
• Accessibility, not redesign; no new heavy a11y dependencies without flagging.
• This skill audits/fixes; git and deploy stay with the user.