accessibility

Audit and improve web accessibility following WCAG 2.2 guidelines and ARIA patterns.

Updated Mar 14, 2026
One-click install
npx skills add https://github.com/Ishaq74/atomic --skill accessibility-ishaq74
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: accessibility
Source: https://github.com/Ishaq74/atomic/tree/main/.github/skills/accessibility
Command: npx skills add https://github.com/Ishaq74/atomic --skill accessibility-ishaq74

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 handling, ARIA tabs, live regions, and dragging alternatives. - Testing Guidance: Automated testing with Lighthouse and 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 checklist. ## Quick Start Audit this page for WCAG 2.2 accessibility issues and fix the critical violations.

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 automated and manual testing.

How to test web accessibility with automated tools?

Run Lighthouse accessibility audits via Chrome DevTools or the CLI, and use axe-core for rule-based violation detection. Automated tools catch roughly a third of issues, so supplement with manual keyboard navigation and screen reader testing using VoiceOver or NVDA.

What changed in WCAG 2.2 compared to 2.1?

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 AA and AAA levels.

What color contrast ratio is required for accessibility?

WCAG Level AA requires 4.5:1 contrast for normal text and 3:1 for large text of at least 18 pixels or 14 pixels bold. UI components and graphical objects need 3:1 against adjacent colors, while Level AAA raises normal text to 7:1.

When should I use ARIA instead of native HTML elements?

Prefer native HTML elements like button, input, and dialog because they include built-in keyboard support and semantics. Use ARIA roles and states only when no native equivalent exists, such as custom tablists or live region announcements.

Why is keyboard focus trapped inside my modal a problem?

A keyboard trap occurs when users cannot Tab away from a component, violating WCAG 2.1.2. Modals should intentionally cycle focus within the dialog while open and close on Escape; the native dialog element handles this focus trapping automatically.