Accessibility Best Practices

Where do I find component-specific accessibility guidance?

Every component doc now exposes an Accessibility section that spells out the props, ARIA state, and helper text required for that component. Treat those sections as the source of truth before introducing custom attributes.

How do I catch accessibility regressions while developing?

Run the axe-core browser extension (or axe CLI) against each screen as you build it to surface color contrast, landmark, aria, and keyboard issues early.

What is the fastest way to provide labels and IDs correctly?

Most components auto-generate ids and map aria-labels accordingly. When overriding, always expose a visible label for interactive elements; when the label is visually hidden, wire aria-label or aria-labelledby to the appropriate id prop.

How should I keep ARIA state synchronized with the UI?

Mirror component state into ARIA: aria-pressed/aria-selected for toggles and options, aria-expanded + aria-controls for disclosure triggers, aria-current for navigation, and aria-invalid whenever validation fails.

Where should helper text and landmark descriptions live?

Attach helper, error, and status copy through aria-describedby on the control or group wrapper, and mark key sections as role="region" with meaningful aria-labels so screen readers can navigate directly to them.

What should I remember when wiring overlays and detached surfaces?

Popovers, drawers, modals, and tooltips must declare the correct role (dialog, alertdialog, tooltip), reference headings via aria-labelledby, and include a deterministic close control that announces what will close.

Where can I get deeper guidance or help?

Refer to Deque University’s axe rules for authoritative references, and reach out to the Platform-UI Team here if you need implementation support.