accessibility

Audit and improve web accessibility following WCAG 2.2 guidelines.

Updated Mar 24, 2026
One-click install
npx skills add https://github.com/samline/forms --skill accessibility-samline
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: accessibility
Source: https://github.com/samline/forms/tree/main/example/.agents/skills/accessibility
Command: npx skills add https://github.com/samline/forms --skill accessibility-samline

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Web interfaces often exclude users with disabilities due to missing alt text, poor keyboard support, low contrast, and incorrect ARIA usage. This Skill provides WCAG 2.2-based guidance and copy-paste-ready code patterns to audit and fix accessibility issues in HTML, CSS, and JavaScript. ## Core Features & Use Cases - WCAG 2.2 Coverage: Organized by the POUR principles (Perceivable, Operable, Understandable, Robust) with conformance levels A, AA, and AAA, including all criteria new in 2.2 such as target size, dragging movements, and accessible authentication. - Ready-Made Code Patterns: Reference implementations for modal focus traps, skip links, form labels, error announcements, ARIA tabs, live regions, and dragging alternatives. - Testing Guidance: Automated testing commands (Lighthouse, axe-core) plus a manual checklist covering keyboard navigation, screen readers, zoom, and reduced motion. - Use Case: When asked to make a checkout form accessible, apply the form label and error handling patterns, verify color contrast ratios, and confirm keyboard operability against the WCAG 2.2 criteria reference. ## Quick Start Audit this page's HTML for WCAG 2.2 accessibility issues and suggest fixes for any violations found.

Frequently Asked Questions about accessibility

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

FAQPage Schema
How do I make a website WCAG 2.2 compliant?▼

WCAG 2.2 compliance requires meeting success criteria across four principles: Perceivable, Operable, Understandable, and Robust. Target Level AA, which covers contrast ratios of 4.5:1, keyboard accessibility, visible focus indicators, and form labels, then verify with Lighthouse or axe-core audits.

How to test web accessibility with automated tools?▼

Run npx lighthouse with the accessibility category or use the axe-core CLI against a URL to detect violations automatically. Automated tools catch roughly a third of issues, so supplement with manual keyboard navigation and screen reader testing using VoiceOver or NVDA.

What color contrast ratio is required for WCAG AA?▼

WCAG Level AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (18px or 14px bold and above). UI components and graphical objects need at least 3:1 against adjacent colors.

Does the native dialog element handle focus trapping?▼

Yes, the native HTML dialog element manages focus trapping automatically when opened as a modal, so manual Tab and Shift+Tab cycle logic is unnecessary. Use a custom focus trap pattern only when browser support requires a non-native implementation.

What changed between WCAG 2.1 and WCAG 2.2?▼

WCAG 2.2 removed criterion 4.1.1 Parsing and added nine new criteria, including Focus Not Obscured, Dragging Movements, Target Size minimum of 24 by 24 CSS pixels, Consistent Help, Redundant Entry, and Accessible Authentication at levels A through AAA.

Why is my icon button failing accessibility audits?▼

Icon-only buttons fail audits because they lack an accessible name for screen readers. Add an aria-label attribute or visually hidden text inside the button, and mark the icon SVG with aria-hidden="true" to resolve the violation.