accessibility

Audit web pages for WCAG 2.2 accessibility barriers and generate prioritized fixes.

1|Updated May 24, 2026
One-click install
npx skills add https://github.com/gavin100305/traffic --skill accessibility-gavin100305
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: accessibility
Source: https://github.com/gavin100305/traffic/tree/main/agents/.agents/skills/accessibility
Command: npx skills add https://github.com/gavin100305/traffic --skill accessibility-gavin100305

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Accessibility gaps prevent people with disabilities from using websites effectively, leading to poor usability and non-compliance with WCAG 2.2 requirements.

Core Features & Use Cases

  • WCAG 2.2 audit guidance: Covers key success criteria across text alternatives, color contrast, keyboard access, focus management, language, forms, error handling, and robust ARIA practices.
  • Actionable fixes and patterns: Provides practical examples for screen-reader-friendly labeling, live regions, skip links, focus traps, and accessible authentication flows.
  • Testing checklist and issue triage: Includes automated and manual testing steps plus a “common issues by impact” prioritization to help teams fix what matters first.
  • Use case: You have a production web page with frequent icon-only controls and a modal dialog; use this skill to verify accessible names, keyboard behavior, focus visibility, and focus not obscured behavior, then apply targeted remediations.

Quick Start

Use the accessibility skill to audit the site for WCAG 2.2 issues and generate a prioritized list of concrete fixes for keyboard navigation, contrast, focus behavior, and screen-reader semantics.

Frequently Asked Questions about accessibility

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

FAQPage Schema
How do I audit a web page for WCAG 2.2 accessibility issues?

To audit a web page for WCAG 2.2 accessibility issues, you review UI components against success criteria for keyboard navigation, color contrast, focus visibility, and ARIA correctness. This process identifies barriers and generates a prioritized list of concrete fixes.

What is the best way to fix keyboard navigation and focus traps in a modal dialog?

Fixing keyboard navigation and focus traps in a modal dialog requires applying accessible patterns for focus management, ensuring focus visibility is not obscured, and verifying screen-reader semantics. Targeted remediations ensure operable and robust behavior for all users.

How do I make dynamic status messages and live regions accessible to screen readers?

Making dynamic status messages accessible to screen readers involves implementing ARIA live regions correctly. This ensures that screen-reader announcements are triggered properly, satisfying WCAG 2.2 requirements for robust and perceivable dynamic content updates.

Can I use this to check color contrast and target size for web accessibility compliance?

Yes, you can check color contrast and target size for web accessibility compliance. The audit covers key WCAG 2.2 success criteria including text alternatives and target size, verifying that perceivable and operable requirements are met.

Why does my accessible authentication flow fail keyboard access and screen reader tests?

Accessible authentication flows fail keyboard access and screen reader tests when ARIA correctness and focus management are improperly implemented. Auditing these UI components identifies missing labels and focus visibility issues, providing actionable fixes for compliance.

Do I need automated testing tools to perform a WCAG 2.2 a11y audit?

An a11y audit uses both automated and manual testing steps to identify accessibility barriers. While automated tools catch basic errors, manual testing is required to verify keyboard behavior, screen-reader semantics, and complex dynamic content like live regions.