accessibility

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

Updated May 14, 2026
One-click install
npx skills add https://github.com/jesusprodriguezUnir/bracketMundial --skill accessibility-jesusprodriguezunir
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: accessibility
Source: https://github.com/jesusprodriguezUnir/bracketMundial/tree/main/.agents/skills/accessibility
Command: npx skills add https://github.com/jesusprodriguezUnir/bracketMundial --skill accessibility-jesusprodriguezunir

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 a structured WCAG 2.2 audit framework with copy-paste-ready code patterns to find and fix accessibility issues. ## Core Features & Use Cases - WCAG 2.2 Coverage: Organized by the POUR principles (Perceivable, Operable, Understandable, Robust) with all new 2.2 criteria like 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, and live regions. - Testing Guidance: Automated testing commands (Lighthouse, axe-core) plus a manual checklist covering keyboard navigation, screen readers, zoom, and reduced motion. - Use Case: Before launching a new checkout flow, run an a11y audit to verify form labels, error handling, focus visibility, and 24x24px minimum target sizes, then apply the provided patterns to fix violations. ## Quick Start Audit this page 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?▼

Audit against the four POUR principles: perceivable, operable, understandable, and robust. Fix critical issues first such as missing form labels, missing alt text, insufficient contrast, keyboard traps, and invisible focus indicators, then verify with automated and manual testing.

How to test web accessibility with automated tools?▼

Run Lighthouse with the accessibility category or use the axe-core CLI against your pages. Automated tools catch roughly a third of issues, so follow up with manual keyboard navigation, screen reader testing, and 200 percent zoom checks.

What is the minimum color contrast ratio for WCAG AA?▼

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

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, 24x24 pixel minimum target size, consistent help, redundant entry, and accessible authentication at AA and AAA levels.

Should I use ARIA roles or native HTML elements?▼

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

Why is my modal dialog not trapping keyboard focus?▼

Focus trapping requires intercepting Tab and Shift+Tab to cycle through the modal's focusable elements and closing on Escape. The native dialog element handles this automatically, so prefer it over manual JavaScript implementations when browser support allows.