a11y-audit

Build and audit frontend UI for accessibility with semantic HTML, keyboard, and focus checks.

3|Updated Apr 2, 2026
One-click install
npx skills add https://github.com/OktayCopurlu/ai-shared --skill a11y-audit-oktaycopurlu
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: a11y-audit
Source: https://github.com/OktayCopurlu/ai-shared/tree/main/.github/workflows/skills/a11y-audit
Command: npx skills add https://github.com/OktayCopurlu/ai-shared --skill a11y-audit-oktaycopurlu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Accessibility issues are often discovered late, when retrofitting fixes is far more expensive than building them in. This Skill guides both the implementation of accessible UI components and the auditing of existing interfaces, so keyboard users and assistive-technology users are not blocked by missing labels, broken focus, or incorrect ARIA. ## Core Features & Use Cases - Accessible Implementation Guidance: Choose semantic elements first, then add keyboard support, focus management, labels, error handling, and reduced-motion behavior while writing components, forms, dialogs, and menus. - Structured Audits: Test keyboard-only interaction, inspect focus behavior and ARIA usage via browser tools or code review, and report findings with severity levels (critical, high, medium, low) and concrete fixes. - Evidence-Matched Reporting: Distinguish verified results from partial code reviews, avoid unmeasured color-contrast claims, and list testing gaps explicitly. - Use Case: While building a checkout form, use this Skill to ensure every input has a proper label, errors are announced to screen readers, and the entire flow works without a mouse. ## Quick Start Ask the AI to audit the current page or component for accessibility issues, including keyboard navigation and focus behavior, and report findings by severity.

Frequently Asked Questions about a11y-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?▼

Identify the main user flow, test it with keyboard-only interaction, check focus behavior and interactive states, then inspect suspicious markup or ARIA usage. Report findings with severity levels and concrete fixes, and note anything that was not verified.

How to make forms and dialogs accessible for screen readers?▼

Start with semantic HTML elements, then add labels, accessible names, states, and error messages that assistive technology can understand. Use ARIA only as a last resort, since incorrect ARIA is worse than none.

Should I use ARIA attributes or semantic HTML for accessibility?▼

Prefer semantic HTML first because it provides built-in keyboard support and assistive-technology compatibility at no cost. ARIA is a fallback for cases where native elements cannot express the behavior, and wrong ARIA creates new barriers.

Can automated accessibility scans find all issues on a page?▼

No, automated tools catch roughly 30% of accessibility issues. Manual keyboard-only testing and focus verification are essential, and audit reports should always list what was not verified.

Can I claim color contrast compliance from a code review?▼

No, exact color-contrast compliance should only be claimed when it was actually measured. Code review alone is partial evidence, and the audit output should state that contrast was not verified.