web-a11y-web-components

Applies accessibility guidance to custom elements and Shadow DOM components.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Building accessible web components is hard because Shadow DOM breaks common ARIA assumptions, focus behavior becomes ambiguous, and automated scanners have inconsistent Shadow DOM coverage. This Skill provides concrete rules and a checklist for making custom elements and design-system primitives accessible. ## Core Features & Use Cases - Accessibility Rules for Custom Elements: Enforces progressive enhancement, light DOM fallbacks, correct slot ordering, and intentional focus delegation. - ARIA and Shadow DOM Guidance: Prevents brittle cross-root ARIA references and documents ElementInternals considerations. - Audit Checklist: Provides a ready-to-use checklist covering fallbacks, reading order, required labels, focus behavior, and manual testing. - Use Case: When building a design-system button or dialog as a custom element, use this Skill to verify keyboard operability, screen reader compatibility, and documented accessibility contracts before shipping. ## Quick Start Audit my custom element for accessibility issues covering Shadow DOM focus behavior, ARIA usage, and keyboard support.

Frequently Asked Questions about web-a11y-web-components

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

FAQPage Schema
How do I make web components accessible with Shadow DOM?▼

Make accessible usage the easiest component API, provide a usable light DOM fallback, keep slot order aligned with semantic reading order, and delegate focus intentionally. Validate required labels and relationships at runtime and verify with keyboard and screen reader testing.

How to handle focus delegation in custom elements?▼

Focus delegation behavior must be intentional and documented as part of the component contract. Decide whether focus lands on the host or an internal element, then verify the behavior manually with keyboard navigation since automated tools may miss Shadow DOM focus issues.

Does ARIA work across Shadow DOM boundaries?▼

ARIA relationships that reference elements across shadow roots are unreliable and should be avoided. Do not depend on cross-root ID references; instead keep relationships within one root or use ElementInternals where supported.

Why do accessibility scanners miss Shadow DOM issues?▼

Automated scanners vary widely in Shadow DOM coverage, so they can miss focus, labeling, and reading-order problems inside components. Pair automation with manual keyboard checks and screen reader smoke tests for reliable results.

What should an accessible web component checklist include?▼

Include a usable fallback or failure mode, slot order matching semantic reading order, documented and enforced accessibility inputs, intentional focus delegation, no unsupported cross-root ARIA, and manual keyboard plus screen reader verification.