web-accessibility

Implements WCAG 2.1 accessibility practices for building and fixing user interfaces.

Updated Dec 20, 2023
One-click install
npx skills add https://github.com/Thiago-Cruz-eng/Hibrygame --skill web-accessibility-thiago-cruz-eng
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: web-accessibility
Source: https://github.com/Thiago-Cruz-eng/Hibrygame/tree/main/.claude/skills/web-accessibility
Command: npx skills add https://github.com/Thiago-Cruz-eng/Hibrygame --skill web-accessibility-thiago-cruz-eng

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Web accessibility gaps prevent keyboard-only users and screen reader users from understanding and completing core tasks, and they can also create compliance risk when products don’t meet WCAG expectations.

Core Features & Use Cases

  • Semantic-first UI guidance: Use appropriate HTML structure (landmarks, headings, form labels) so assistive technologies interpret the page correctly.
  • Keyboard interaction patterns: Ensure all functionality works with Tab/Shift+Tab, Enter/Space, arrow navigation, and ESC to close dialogs/menus.
  • ARIA and state communication: Add accurate roles/attributes (e.g., dialog, aria-live, aria-labelledby/describedby) for dynamic content and clear labeling.
  • Visual accessibility and testing: Apply WCAG contrast and focus-visible styles, then verify with axe/Lighthouse plus manual keyboard/screen-reader checks.

Quick Start

Create an accessibility checklist and updated component code so a React modal supports focus management, ESC-to-close, and properly labeled screen reader content, targeting WCAG 2.1 AA.

Frequently Asked Questions about web-accessibility

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

FAQPage Schema
How do I make a React modal accessible with keyboard navigation and screen reader support?

To make a React modal accessible, implement keyboard handlers for ESC-to-close and focus management, use semantic HTML with appropriate ARIA attributes like aria-modal and aria-labelledby, and validate the interactive semantics against WCAG 2.1 AA standards.

What WCAG 2.1 AA contrast and focus-visible requirements do I need for web accessibility?

WCAG 2.1 AA web accessibility requires sufficient color contrast ratios and visible focus indicators. You apply focus-visible styles to interactive elements and verify visual accessibility compliance using testing tools like axe and Lighthouse alongside manual checks.

When do I need ARIA attributes like aria-live and aria-modal in semantic HTML?

You need ARIA attributes like aria-live and aria-modal for dynamic content updates and dialog patterns when semantic HTML alone cannot communicate state changes. They ensure screen readers announce dynamic updates and properly interpret interactive dialog regions.

How do I test web accessibility using axe and Lighthouse?

Test web accessibility by running axe and Lighthouse to validate ARIA usage, contrast ratios, and keyboard navigation. Follow automated validation with manual keyboard-only navigation and screen reader testing to ensure robust WCAG 2.1 compliance.

Why does my keyboard navigation fail on dynamic UI components?

Keyboard navigation fails on dynamic UI components when they lack robust keyboard handlers for Tab, Shift+Tab, Enter, Space, arrow keys, and ESC. Fix this by ensuring correct interactive semantics and managing focus properly within the component.

Can I use this web accessibility guidance for non-React projects?

Yes, you can apply these web accessibility practices to non-React projects. The WCAG 2.1 guidance covers semantic HTML structure, ARIA labeling, and keyboard interaction patterns that are platform-agnostic and work across any web framework.