accessibility-audit

Audit web UI accessibility through automated scans, keyboard traversal, and visual inspection.

1|Updated Sep 11, 2026
One-click install
npx skills add https://github.com/rebuildup/my-web-2026 --skill accessibility-audit-rebuildup
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: accessibility-audit
Source: https://github.com/rebuildup/my-web-2026/tree/main/skills/accessibility-audit
Command: npx skills add https://github.com/rebuildup/my-web-2026 --skill accessibility-audit-rebuildup

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Web interfaces often pass automated lint checks while still blocking keyboard users, hiding focus states, or failing contrast requirements. This Skill provides a structured audit workflow that combines automated scanning with real keyboard, visual, and semantic inspection so accessibility issues are found and fixed by severity. ## Core Features & Use Cases - Multi-layer inspection: Runs automated scans (axe-core or equivalent), then verifies keyboard traversal, visual contrast, focus visibility, and DOM/accessibility-tree semantics. - Severity-based fixing: Classifies findings from P0 (blocks task completion) to P3 (polish) based on actual task impact rather than WCAG criterion numbers alone. - Re-test gate: Re-runs the same conditions after fixes, including 200% zoom, 320px reflow, reduced-motion, and mobile viewport checks. - Use Case: Before shipping a new checkout flow, audit the rendered pages to confirm keyboard-only users can complete purchase, focus is visible, and form errors are announced, then fix P0/P1 issues and re-verify. ## Quick Start Audit the accessibility of the checkout page using automated scan, keyboard navigation, and visual inspection, then report findings by severity.

Frequently Asked Questions about accessibility-audit

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

FAQPage Schema
How do I audit a web page for accessibility issues?

Run an automated scan with axe-core or an equivalent tool, then manually verify keyboard traversal, visible focus, contrast, and semantic structure in the rendered page. Automated scans alone miss keyboard traps, focus visibility, and many interaction-level barriers.

How to test keyboard accessibility of a web UI?

Complete the primary workflow without a mouse and check logical tab order, visible focus, Enter/Space activation, Escape dismissal, and focus trapping in dialogs. Compare custom interactions against the keyboard behavior expected by platform and ARIA patterns.

Does passing an axe-core scan mean a page is accessible?

No. Automated scans only catch machine-detectable issues like missing labels, invalid ARIA, and some contrast failures. Keyboard operability, focus visibility, screen reader quality, and zoom reflow require manual inspection of the rendered interface.

How should accessibility findings be prioritized?

Prioritize by actual task impact: P0 blocks task completion or access, P1 is a major barrier like pervasive contrast failure, P2 degrades usability, and P3 is polish. WCAG criterion numbers alone should not determine severity.

What should be re-tested after fixing accessibility issues?

Re-run the same conditions: automated violation comparison, keyboard traversal, screenshots of focus and error states, a mobile viewport, 200% zoom, 320px/400% reflow, and reduced-motion behavior where applicable.