accessible-components

Implement accessible interactive UI components with WCAG 2.2 compliance.

1|Updated Jul 26, 2026
One-click install
npx skills add https://github.com/yogvidwankhede/vishwakarma --skill accessible-components
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: accessible-components
Source: https://github.com/yogvidwankhede/vishwakarma/tree/main/.claude/skills/accessible-components
Command: npx skills add https://github.com/yogvidwankhede/vishwakarma --skill accessible-components

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This skill addresses the common failure of creating undifferentiated or inaccessible interactive components by providing a rigorous framework for focus management, ARIA implementation, and WCAG 2.2 compliance.

Core Features & Use Cases

  • Focus Management: Provides robust patterns for focus traps, roving tabindex, and aria-activedescendant to ensure keyboard navigability.
  • Compliance Verification: Offers a checklist for WCAG 2.2 criteria including focus visibility, target size, and content dismissal.
  • Use Case: When building a custom modal or combobox, use this skill to ensure the component correctly traps focus, handles Escape key dismissal, and provides appropriate ARIA roles without breaking the accessibility tree.

Quick Start

Use the accessible-components skill to audit the keyboard interaction and focus management logic of the current dialog component.

Frequently Asked Questions about accessible-components

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

FAQPage Schema
How do I implement focus management in custom UI components to meet WCAG 2.2 compliance?

Focus management in accessible UI components requires robust patterns like focus traps, roving tabindex, and aria-activedescendant to ensure keyboard navigability and WCAG 2.2 compliance. These techniques guarantee proper focus visibility and content dismissal.

What is the correct way to apply ARIA attributes when building custom interactive widgets like dialogs and menus?

Correct ARIA attribute application in custom widgets involves providing appropriate ARIA roles without breaking the accessibility tree. This ensures native HTML element usage is maintained while delivering proper screen-reader support for dialogs and menus.

How do I ensure keyboard navigation works properly in a custom combobox or modal dialog?

Keyboard navigation in custom comboboxes and modals requires implementing focus traps, handling Escape key dismissal, and applying roving tabindex patterns. This ensures complex keyboard interactions meet accessibility standards for interactive components.

Does my custom UI component need native HTML elements to be accessible, or can I rely entirely on ARIA?

Accessible custom UI components should prioritize native HTML element usage alongside correct ARIA attribute application. Relying entirely on ARIA without native semantics risks breaking the accessibility tree and failing WCAG 2.2 compliance verification.

What's the best way to audit an existing dialog component for accessibility and keyboard interaction issues?

Auditing a dialog component for accessibility involves checking focus management logic, verifying keyboard interaction patterns, and validating proper ARIA roles. A WCAG 2.2 compliance checklist ensures focus visibility, target size, and content dismissal criteria are met.

When should I use aria-activedescendant instead of roving tabindex for keyboard navigability?

Aria-activedescendant is used for keyboard navigability when managing focus within complex composite widgets without moving actual DOM focus, while roving tabindex shifts focus directly among elements. Both patterns ensure robust focus management in accessible UI components.