fe-a11y

Guide semantic HTML, ARIA roles, labels, and keyboard navigation for React UI components.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/Conradmaker/copilot-cockpit --skill fe-a11y
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fe-a11y
Source: https://github.com/Conradmaker/copilot-cockpit/tree/main/.github/skills/fe-a11y
Command: npx skills add https://github.com/Conradmaker/copilot-cockpit --skill fe-a11y

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Frontend UI components often have accessibility gaps that block keyboard and screen-reader users from effectively interacting with interactive elements. This skill provides a framework of patterns, roles, labels, and ARIA states to help developers build accessible modals, tabs, forms, accordions, and other primitives.

Core Features & Use Cases

  • Guidance for semantic HTML usage, proper ARIA labeling, focus management, and live regions.
  • Patterns for modals, tabs, accordions, switches, checkboxes, radios, and interactive wrappers, with practical usage scenarios in React component design.
  • Use cases include auditing existing components, designing accessible primitives, and training teams on consistent a11y patterns.

Quick Start

Run an accessibility review of an interactive component and apply the core rules and patterns described here to fix labeling, roles, and focus management.

Frequently Asked Questions about fe-a11y

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

FAQPage Schema
How do I add ARIA roles and labels to React UI components?

To add ARIA roles and labels to React UI components, apply semantic HTML structures and use defined ARIA patterns for modals, tabs, and accordions to ensure screen-reader compatibility.

What is the best way to manage focus and keyboard navigation in frontend modals?

Managing focus and keyboard navigation in frontend modals requires trapping focus within the dialog and applying specific ARIA state patterns to ensure inclusive user experiences.

How do I audit existing design system primitives for accessibility gaps?

Auditing design system primitives for accessibility involves reviewing interactive elements like switches and checkboxes against established a11y patterns to fix labeling and focus management.

Does this accessibility guidance work for non-React frontend frameworks?

The accessibility guidance applies broadly to frontend UI components, using React scenarios as practical examples while the core semantic HTML and ARIA rules remain framework-agnostic.

When should I use live regions in frontend accessibility?

Live regions should be used in frontend accessibility when dynamic content updates occur, ensuring screen readers announce state changes without requiring the user to refresh the context.