a11y-audit

Run WCAG 2.2 AA audits on generated UI and post PR comments.

23|7|Updated Feb 14, 2026
One-click install
npx skills add https://github.com/kinncj/MAPLE --skill a11y-audit-kinncj
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: a11y-audit
Source: https://github.com/kinncj/MAPLE/tree/main/template/.opencode/skills/a11y-audit
Command: npx skills add https://github.com/kinncj/MAPLE --skill a11y-audit-kinncj

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Run WCAG 2.2 Level AA accessibility audits against generated UI to surface accessibility issues before they reach production.

Core Features & Use Cases

  • Automated accessibility testing using axe-core (via @axe-core/cli) or pa11y.
  • Automated reporting of violations as PR comments to streamline reviews.
  • Merge gating with a11y rules to block merges on critical/serious violations.
  • Manual fallback audit guidance when tooling is unavailable.

Quick Start

Run the a11y-audit workflow against a story with ui:true to generate a report and post PR comments.

Frequently Asked Questions about a11y-audit

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

FAQPage Schema
How do I run a WCAG audit on UI components before merging pull requests?

You can run WCAG 2.2 AA accessibility audits on UI components marked ui:true during development and PR reviews. This identifies violations early and blocks merging if critical or serious accessibility issues are found.

What is the best way to automate pa11y or axe-core accessibility testing in a CI workflow?

Automating accessibility testing in CI involves running axe-core or pa11y audits against UI stories marked ui:true. Findings are posted directly as PR comments to streamline reviews and gate merges on critical violations.

Can I block pull request merges when serious WCAG 2.2 AA violations are detected?

Yes, you can block pull request merges when critical or serious WCAG 2.2 AA violations are detected. Merge gating rules prevent non-compliant UI components from reaching production until accessibility issues are resolved.

How do I report axe-core accessibility violations directly in pull request comments?

Reporting axe-core accessibility violations in PR comments is handled automatically by running the audit workflow against UI stories marked ui:true. The tool posts findings directly as PR comments to streamline reviews.

What should I do for manual WCAG auditing when automated tooling is unavailable?

For manual WCAG auditing when automated tooling is unavailable, follow provided manual fallback audit guidance. This ensures UI components are still reviewed for accessibility compliance when axe-core or pa11y cannot run.

Does pa11y support testing against the WCAG 2.2 AA standard?

Yes, pa11y supports testing against the WCAG 2.2 AA standard. You can run these audits against generated UI stories marked ui:true to identify accessibility issues and ensure component compliance before merging.