← ClaudeAtlas

accessibility-auditlisted

Run a WCAG accessibility audit on UI changes at Stage 6b. Uses axe-core, pa11y, or Lighthouse to check affected pages and components. Produces pipeline/accessibility-report.md and writes the stage-06b gate. Use when a change touched frontend UI. Skip (with audit_skipped_reason) for backend-only or doc-only changes.
telus-labs/stagecraft · ★ 0 · AI & Automation · score 70
Install: claude install-skill telus-labs/stagecraft
# Accessibility audit Use this skill at Stage 6b (after QA) when the change touched UI. Audits the affected pages/components for WCAG violations using axe-core, pa11y, or Lighthouse. Produces `pipeline/accessibility-report.md` and writes `pipeline/gates/stage-06b.json`. ## When to use - Frontend changes shipped at Stage 4 (new component, modified flow, redesigned page). - Updates to forms, inputs, dialogs, navigation, or anything keyboard/screen-reader-relevant. - New routes/pages added to the app. ## When to skip (with `audit_skipped_reason` set) - Backend-only changes (no UI surface). - Doc-only changes. - Internal tools with no public/customer surface AND no a11y commitment in the brief. ## Procedure ### 1. Identify what to audit Read `pipeline/brief.md` and `pipeline/design-spec.md` for the scope. Cross-reference with the Stage 4 PR summaries (`pipeline/pr-frontend.md`) to find: - Specific routes / page URLs. - Specific React/Vue/Svelte components. - Any flows the brief flagged as keyboard-only or screen-reader-critical. If the change has no UI surface, write the gate with `audit_skipped_reason: "<reason>"`, `status: "PASS"`, all violations zero, and move on. ### 2. Pick a method | Tool | Best for | Output shape | |---|---|---| | **axe-core** (via `@axe-core/cli` or programmatic) | Most thorough; integrates with Playwright/Cypress | JSON with violations grouped by impact | | **pa11y** | Quick CLI sweep of URLs | HTML/JSON report per page | | **Lighthouse** (a11