Frontend A11y

This is the accessibility checklist you wish you had before your first code review flagged missing form labels and broken ARIA. It covers the patterns that actually come up in React and Next.js work: connecting labels to inputs with htmlFor, linking error messages with aria-describedby, making custom dropdowns keyboard navigable, and knowing when aria-label beats aria-labelledby. The examples are practical, like a complete login form with proper required field handling and a dropdown with arrow key navigation. It won't make you an a11y expert, but it will stop the most common violations before they hit PR comments. Activate it when building forms, modals, or anything interactive that isn't a plain button or link.

skills.sh installs: 5.8K
GitHub stars: 300.3K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add affaan-m/ecc --skill frontend-a11y --agent claude-code

Installs into .claude/skills of the current project.

Files

Frontend Accessibility Patterns

Practical accessibility patterns for React and Next.js. Covers the issues most commonly flagged in code review: missing form labels, incorrect ARIA usage, non-semantic interactive elements, and broken keyboard navigation.

When to Activate

Building or reviewing form components (<input>, <select>, <textarea>)
Creating interactive elements (modals, dropdowns, tooltips, tabs)
Using <div> or <span> with onClick
Adding aria-* attributes to any element
Implementing keyboard navigation or focus management
Receiving accessibility feedback from code review tools (CodeRabbit, ESLint a11y)
Building components that must support screen readers

Form Accessibility

Missing htmlFor / id pairing and disconnected error messages are the most common issues flagged in code review.

Label Connection

// BAD: label has no connection to input — screen readers cannot associate them
<label>Email</label>
<input type="email" />

// GOOD: htmlFor matches input id
<label htmlFor="email">Email</label>
<input id="email" type="email" />