rc-a11y

Review and build web UI against WCAG 2.2 AA accessibility guidelines.

19|1|Updated Jun 27, 2026
One-click install
npx skills add https://github.com/rodolfochicone/rc-project --skill rc-a11y-rodolfochicone
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: rc-a11y
Source: https://github.com/rodolfochicone/rc-project/tree/main/skills/misc/rc-a11y
Command: npx skills add https://github.com/rodolfochicone/rc-project --skill rc-a11y-rodolfochicone

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Building accessible web interfaces requires knowing WCAG 2.2 AA rules for semantic HTML, ARIA, keyboard navigation, focus management, and contrast — and most accessibility defects slip through because teams lack a concrete checklist when writing or reviewing UI code. ## Core Features & Use Cases - Task-Routed Guides: Routes work to one of three reference guides — foundations (semantic HTML, alt text, page language), interactive patterns (forms, modals, tabs, focus management), and testing (keyboard-only navigation, screen readers, axe/Lighthouse, contrast ratios). - Acceptance Checklists: Each guide ends with a concrete checklist covering landmarks, heading hierarchy, labels, focus traps, ARIA APG keyboard patterns, and contrast ratios (4.5:1 / 3:1). - Use Case: When reviewing a pull request that adds a modal dialog, use this Skill to verify it has role="dialog" with aria-modal, a focus trap, Esc-to-close behavior, and focus return to the trigger element. ## Quick Start Review this form component for WCAG 2.2 AA accessibility issues and list what needs fixing.

Frequently Asked Questions about rc-a11y

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

FAQPage Schema
How do I make a modal dialog accessible?▼

Use role="dialog" with aria-modal="true" (or the native <dialog> element), label it with aria-labelledby pointing to its title, trap focus inside while open, close on Esc, and return focus to the triggering element when closed.

How do I review a web page for WCAG accessibility issues?▼

Combine three methods: navigate the full flow with keyboard only, run an automated scan with axe DevTools or Lighthouse, and test with a screen reader like VoiceOver or NVDA. Automated tools catch only about 30-40% of accessibility problems.

When should I use ARIA attributes versus native HTML?▼

Use native HTML elements like <button>, <dialog>, and <select> whenever they provide the needed behavior. ARIA only changes announced semantics, not browser behavior, so adding role="button" to a div without keyboard handling is worse than no ARIA.

What contrast ratio does WCAG AA require for text?▼

WCAG AA requires 4.5:1 for normal text (under 18px, or under 14px bold), 3:1 for large text, and 3:1 for UI components like input borders and informative icons. Verify with the DevTools color picker or axe DevTools.

Can accessibility be fully verified without a real browser?▼

No. Client-rendered SPAs can hide screen reader issues in DOM that only exists after JavaScript runs. Without browser access, review markup statically and explicitly state that screen reader and axe verification remains pending.