a11y-dev

Guide front-end developers to implement accessible UI components with semantic HTML and ARIA.

Updated Feb 26, 2026
One-click install
npx skills add https://github.com/jens-wedin/a11y-skill --skill a11y-dev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: a11y-dev
Source: https://github.com/jens-wedin/a11y-skill/tree/main/a11y-dev
Command: npx skills add https://github.com/jens-wedin/a11y-skill --skill a11y-dev

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps front-end developers write accessible code from the start by prioritizing native HTML, then ARIA, and finally custom solutions.

Core Features & Use Cases

  • Enforces semantic HTML usage to improve accessibility and keyboard support.
  • Demonstrates practical ARIA patterns and when to apply them to forms, modals, and interactive widgets.
  • Provides comprehensive guidance on focus management, skip links, and keyboard navigation for complex UI.

Quick Start

Follow the principle: native HTML first, ARIA second, then custom solutions last when implementing any interactive UI element.

Frequently Asked Questions about a11y-dev

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

FAQPage Schema
How do I implement accessible keyboard navigation for custom front-end components?

Accessible keyboard navigation is implemented by prioritizing native HTML semantics first, using ARIA attributes second, and building custom solutions last. This approach ensures proper focus management, skip links, and keyboard support for interactive widgets.

When do I need to use ARIA attributes instead of semantic HTML for accessibility?

ARIA attributes are needed when native semantic HTML cannot represent your interactive widget, such as complex modals or custom UI components. You should always use semantic HTML first and apply ARIA patterns second to fill gaps in forms and dynamic widgets.

What is the best way to manage focus for accessible modals and interactive widgets?

The best way to manage focus for accessible modals is following the native HTML first, ARIA second principle. Comprehensive guidance on focus management, skip links, and keyboard navigation ensures complex UI components remain operable for all users.

Does this accessibility guidance work across different modern front-end frameworks?

Yes, this accessibility guidance applies to writing and reviewing UI components across modern front-end frameworks. It enforces semantic HTML, restrained ARIA usage, and accessible patterns regardless of your specific development environment.

Why should I avoid overusing ARIA roles when building accessible forms?

Overusing ARIA roles should be avoided because native semantic HTML already provides robust accessibility and keyboard support. ARIA is best applied sparingly as a secondary enhancement when HTML semantics are insufficient for your interactive widgets.

Can I use this approach to audit existing UI components for accessibility issues?

Yes, you can use this approach to review existing UI components for accessibility issues. The guidance includes checklists and examples that help evaluate semantic HTML, ARIA usage, focus management, and keyboard navigation in current implementations.