accessibility

Audit and improve web accessibility following WCAG 2.2 guidelines.

Updated Jun 30, 2026
One-click install
npx skills add https://github.com/kaitoartz/dotfiles --skill accessibility-kaitoartz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: accessibility
Source: https://github.com/kaitoartz/dotfiles/tree/main/dot_agents/skills/wcag-accessibility
Command: npx skills add https://github.com/kaitoartz/dotfiles --skill accessibility-kaitoartz

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 color contrast, keyboard traps, and incorrect ARIA usage. This Skill provides concrete WCAG 2.2 guidance and code patterns to find and fix these issues. ## Core Features & Use Cases - WCAG 2.2 Audit Guidance: Covers all four POUR principles with conformance levels A, AA, and AAA, including new 2.2 criteria like target size, focus not obscured, and accessible authentication. - Code-Level Fix Patterns: Provides before-and-after HTML, CSS, and JavaScript examples for alt text, focus states, keyboard handling, live regions, form labels, and error handling. - Testing Workflow: Includes automated testing commands (Lighthouse, axe-core) and a manual checklist covering keyboard navigation, screen readers, zoom, and reduced motion. - Use Case: When asked to run an a11y audit on a checkout page, the Skill guides identification of critical issues like missing form labels and low contrast, then supplies the exact markup to remediate them. ## Quick Start Audit this page for WCAG 2.2 accessibility issues and suggest fixes for any violations you find.

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 addressing the four POUR principles: perceivable, operable, understandable, and robust content. Key steps include adding alt text to images, ensuring 4.5:1 color contrast, making all functionality keyboard accessible, and labeling form inputs programmatically.

How to test web accessibility with Lighthouse and axe-core?▼

Run npx lighthouse with the --only-categories=accessibility flag for an automated audit, or use the axe-core CLI against a URL. Automated tools catch common violations, but manual testing with keyboards and screen readers like VoiceOver or NVDA is still required.

What color contrast ratio is required for WCAG AA?▼

WCAG 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, and AAA raises normal text to 7:1.

Should I use ARIA roles or native HTML elements?▼

Native HTML elements like button, a href, and input are preferred because they provide keyboard activation, focus, and semantics automatically. Only add ARIA roles and manual keyboard handlers when a native element cannot be used, to avoid double-triggering and broken behavior.

What are the new accessibility criteria in WCAG 2.2?▼

WCAG 2.2 adds criteria including focus not obscured (2.4.11), minimum target size of 24x24 CSS pixels (2.5.8), dragging movement alternatives (2.5.7), consistent help (3.2.6), redundant entry (3.3.7), and accessible authentication without cognitive tests (3.3.8).