web-a11y-authoring

Implements accessible frontend UI with semantic HTML, ARIA states, and keyboard support.

Updated Sep 8, 2026
One-click install
npx skills add https://github.com/pedropenha/project-skills --skill web-a11y-authoring-pedropenha
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: web-a11y-authoring
Source: https://github.com/pedropenha/project-skills/tree/main/.agents/skills/web-a11y-authoring
Command: npx skills add https://github.com/pedropenha/project-skills --skill web-a11y-authoring-pedropenha

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Frontend interfaces often ship with inaccessible markup: divs used as buttons, missing accessible names, broken keyboard navigation, and unmanaged focus. This Skill guides the implementation and refactoring of UI components so they work correctly with keyboards, screen readers, and other assistive technologies. ## Core Features & Use Cases - Semantic HTML First: Enforces native controls before ARIA, correct link-versus-button usage, and meaningful page structure with landmarks and headings. - Interaction Patterns: Provides concrete markup patterns for dialogs, toggles, disclosures, icon-only controls, and download links in the companion PATTERNS.md file. - Non-Text Content Decisions: Classifies images, icons, and SVG as decorative, informative, or functional, with correct text alternatives or accessibility-tree hiding. - Use Case: When building a settings modal, use this Skill to produce a dialog with aria-modal, a labelled title, contained keyboard focus, and focus restoration on close, plus a manual test plan. ## Quick Start Use the web-a11y-authoring skill to review and refactor this checkout form component for accessibility, including keyboard support and accessible names.

Frequently Asked Questions about web-a11y-authoring

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

FAQPage Schema
How do I make a custom dialog accessible in HTML?▼

Use role="dialog" with aria-modal="true" and aria-labelledby pointing to the dialog title. Move focus into the dialog on open, contain keyboard interaction while open, and restore focus to the trigger on close.

When should I use a link versus a button?▼

Use a link (<a href>) for navigation to another page or location, and a <button> for actions that change state or trigger behavior. Avoid divs with click handlers or anchors with href="#" acting as buttons.

Should I use ARIA attributes or native HTML elements?▼

Prefer native HTML controls first, since they provide built-in roles, states, and keyboard behavior. Use ARIA only to supplement semantics that cannot be expressed natively, such as aria-pressed on a toggle button.

How do I handle decorative images and SVG for screen readers?▼

Classify each image or SVG as decorative, informative, or functional. Hide decorative ones from the accessibility tree, and give functional or informative ones a clear accessible name describing the action or content.

What are the limitations of ARIA for fixing inaccessible components?▼

ARIA adds semantics but does not add behavior; keyboard handling, focus management, and state synchronization must still be implemented in JavaScript. Overriding native elements with ARIA often breaks built-in functionality.