ui-accessibility

Build and review accessible React UI components using Base UI primitives.

3|Updated Apr 20, 2026
One-click install
npx skills add https://github.com/langgenius/due-date-hq-jwl --skill ui-accessibility-langgenius
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ui-accessibility
Source: https://github.com/langgenius/due-date-hq-jwl/tree/main/.agents/skills/ui-accessibility
Command: npx skills add https://github.com/langgenius/due-date-hq-jwl --skill ui-accessibility-langgenius

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? React interfaces often ship with broken keyboard navigation, missing accessible names, incorrect ARIA usage, and overlays that trap or lose focus. This Skill provides concrete rules for building and reviewing UI that is semantic, keyboard usable, screen-reader understandable, and touch reachable. ## Core Features & Use Cases - Primitive Selection Guidance: Choose the correct Base UI React primitive for each task, such as Dialog versus Popover versus Tooltip, or Select versus Combobox versus Autocomplete. - Form and Field Rules: Enforce real form semantics with labels, descriptions, error relationships, invalid state, and correct controlled or uncontrolled contracts. - Accessibility Testing Standards: Write Testing Library tests that query by role, name, and label instead of test IDs, and verify overlay focus and dismissal behavior. - Use Case: When implementing a new settings panel with a drawer, form fields, and a destructive confirmation, use this Skill to pick the right primitives, wire accessible names, and validate keyboard and screen-reader behavior. ## Quick Start Review this React component for accessibility issues and rewrite it using proper Base UI primitives with correct labels, focus handling, and keyboard support.

Frequently Asked Questions about ui-accessibility

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

FAQPage Schema
How do I make React components accessible for screen readers?

Use native semantic elements like button and form fields, give every interactive control an accessible name via visible text, label, or aria-label, and compose headless primitives such as Base UI React for complex behavior instead of hand-writing ARIA.

When should I use Dialog vs Popover vs Tooltip in React?

Use Dialog for modal focus management and dismissal, Popover for interactive or rich content reachable by click and touch, and Tooltip only for short, non-interactive supplemental labels on a trigger that already has an accessible name.

How do I test accessibility with Testing Library?

Query elements with user-perceivable locators like getByRole with a name option, then getByLabelText or getByText. Test real interaction paths such as click, keyboard, and tab, and assert overlay role, focus behavior, and visible content rather than internal classes.

Should I use Base UI React or write custom ARIA for overlays?

Prefer Base UI React primitives, which provide portals, focus traps, dismissal, keyboard navigation, and roving tabindex out of the box. Hand-writing this behavior is error-prone and should only happen when a primitive already supplies the required semantics.

Why is my controlled React input not updating?

A component receiving a value prop must also receive the matching change handler, otherwise it stays frozen. Either pass both value and onValueChange for controlled mode, or use defaultValue for uncontrolled mode, and never mix the two contracts.