audit-a11y

Audits frontend codebases for WCAG compliance using multi-agent accessibility review.

4|Updated Mar 14, 2026
One-click install
npx skills add https://github.com/VoxTechnologies/transmute-framework --skill audit-a11y-voxtechnologies
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: audit-a11y
Source: https://github.com/VoxTechnologies/transmute-framework/tree/main/skills/audit-a11y
Command: npx skills add https://github.com/VoxTechnologies/transmute-framework --skill audit-a11y-voxtechnologies

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Frontend codebases often ship with accessibility violations — missing alt text, broken keyboard navigation, insufficient color contrast — that block WCAG compliance and create legal risk. This Skill runs a structured multi-agent audit that finds and fixes these violations against your BRD/PRD requirements. ## Core Features & Use Cases - Multi-Agent WCAG Audit: Spawns three parallel auditors covering semantic HTML/landmarks, keyboard navigation and focus management, and text alternatives, contrast, and motion sensitivity. - Automated Verification: Runs axe-core E2E tests after manual fixes and produces a compliance report with a PASS / CONDITIONAL PASS / FAIL gate decision. - Use Case: During Stage 6B of the Transmute pipeline, audit a Next.js frontend against WCAG 2.2 AA, fix violations like missing lang attributes and redundant ARIA on component-library elements, and generate ./plancasting/_audits/accessibility/report.md. ## Quick Start Ask the agent to run an accessibility audit of the frontend codebase against the WCAG requirements in the BRD and fix any violations found.

Frequently Asked Questions about audit-a11y

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a WCAG accessibility audit on my frontend codebase?

Invoke the audit to spawn three parallel auditors covering semantic structure, interactive elements, and content/media. It checks headings, landmarks, keyboard navigation, contrast, and motion preferences, fixes violations, and verifies results with axe-core E2E tests.

What WCAG version and conformance level does the audit target?

The audit reads the BRD and PRD to determine the target WCAG version and level, defaulting to WCAG 2.2 at Level AA when unspecified. If documents conflict, the more stringent requirement takes precedence.

Does the audit work with component libraries like Radix or shadcn/ui?

Yes. The audit checks whether components come from libraries with built-in accessibility such as React Aria, HeadlessUI, Radix, or shadcn/ui, and avoids adding redundant ARIA attributes that could break the library's internal handling.

Does this audit include screen reader testing with NVDA or VoiceOver?

No. Screen reader testing is explicitly out of scope and deferred to runtime verification in Stage 6V. This audit focuses on code-level accessibility: semantic HTML, ARIA attributes, keyboard navigation, and color contrast.

What happens when an accessibility violation cannot be fixed?

Unfixable violations are documented as REQUIRES HUMAN DECISION with evidence and a recommended approach. Unresolved WCAG Level A violations are recorded in unfixable-violations.md and escalated as potential launch blockers with a FAIL gate decision.