ARIA Patterns

ARIA (Accessible Rich Internet Applications) patterns are reusable accessibility recipes published by the W3C that describe how to implement complex interactive components — tabs, dialogs, comboboxes, accordions — so they’re usable by screen reader and keyboard-only users, defining the roles, states, and keyboard behaviors expected of each pattern.

Why patterns matter

• Custom interactive components built without ARIA patterns are routinely unusable for assistive technology — even when they pass automated accessibility checks.
• The patterns codify expectations: a user who hits Tab inside a tablist should reach all tabs, but only one should be in the tab order.
• Following the patterns means screen reader users encounter familiar behaviors, not bespoke interactions to relearn per site.

The trap

“Sprinkling ARIA attributes” on incorrect markup makes things worse, not better. WAI-ARIA’s first rule is to use native HTML elements whenever possible — a <button> is more accessible than a <div role="button">, every time. ARIA patterns are for the cases where native HTML genuinely can’t handle the interaction.

How we use them

• Default to native HTML for buttons, links, form fields, headings, lists.
• Reach for ARIA patterns only for genuinely custom widgets (faceted filters, custom carousels, multi-step forms with complex state).
• Test every custom widget with screen readers (NVDA, JAWS, VoiceOver) and keyboard-only navigation before launch.
• Document the patterns we ship so future engineers don’t break the contract.