# Accessibility

Preserve the kit’s semantics and verify the application experience.

## Name controls and regions

Use visible labels where possible. FieldLabel connects to a field control; compound Select and other controls expose their own labeling parts. Icon-only buttons need an accessible name, even if a tooltip is also present. Give dialogs a title, tables an accessible name and row-header column, and collections an appropriate label.

Use headings and landmarks for application structure. Decorative icons should be aria-hidden. A visual badge does not automatically announce status; put changing feedback in a suitable status region when the update matters.

## Keep native behavior

Use the public trigger, close, item, and collection parts so Base UI or React Aria handles focus and keyboard behavior. When using render composition, retain ref forwarding, events, and the correct native element. Do not remove focus indicators or place interactive elements inside another interactive element.

## Validate real workflows

Check keyboard entry, arrows in composites, Tab/Shift+Tab, activation, Escape, and focus restoration. Try required and invalid submission, empty and loading states, disabled options, and long text. Confirm that a screen reader can identify the control and understand the outcome.

Inspect both themes and narrow layouts, including overlays and horizontally scrolling tables. Test zoom and reduced motion. Automated accessibility scans are useful evidence, but do not prove the complete keyboard or reading experience.

## Application responsibility

The kit supplies accessible components and styling, not a blanket conformance guarantee for every composition. Application labels, color overrides, business validation, async feedback, routing, and content order remain yours to verify. See [forms](/docs/guides/forms/), [overlays](/docs/guides/overlays/), and [known limitations](/docs/help/) for concrete integration boundaries.