Skip to main content :::
:::

ARIA Patterns for Developers: Use Native HTML First

ARIA can add semantics for complex components, but bad ARIA is worse. Use W3C APG Patterns for tabs, dialogs, accordions, menu buttons, and related widgets.

Summary

  • No ARIA is better than Bad ARIA.
  • Use native HTML first, and add ARIA only when native semantics are not enough.
  • When following APG Patterns, implement keyboard behavior, focus management, and state updates together.

Use native HTML first, then add ARIA only when needed

The first rule of ARIA is straightforward: use native HTML before adding ARIA. Elements such as button, a, input, select, details, and summary already carry semantics and keyboard behavior that browsers and assistive technologies understand.

If a div or span is used to recreate a button, menu, or tab interface, the team must implement name, role, state, keyboard behavior, and focus management manually. That is usually more error-prone than using native elements.

Do not copy only the role

ARIA changes the semantics exposed to assistive technologies. It does not add interaction behavior. role="button" does not make a div support Enter or Space automatically, and aria-expanded="true" does not open content or manage focus by itself.

Incorrect ARIA can make the visual interface look fine while exposing the wrong signal to assistive technologies. That is harder to debug because the issue often appears only in screen reader, voice control, or keyboard workflows.

When using APG patterns, implement the whole contract

W3C APG Patterns are useful references for complex components, but teams should not copy only one or two attributes. Tabs, dialogs, accordions, menu buttons, and comboboxes each have a full contract: keyboard behavior, focus position, accessible names, roles, states, and DOM relationships need to work together.

  • Name: the control name users hear or see is clear.
  • Role: the role matches the component’s actual purpose.
  • State: expanded, selected, checked, disabled, and similar states update immediately.
  • Keyboard: Arrow keys, Enter, Space, Escape, and Tab follow the expected pattern.
  • Focus: after opening, closing, or switching content, focus lands in a reasonable place.

Common mistakes

ARIA issues often appear in custom components, design system components, and third-party widgets. Once those components are reused, the same defect spreads across many pages, so the fix should usually happen at the component layer.

  • Adding a role without implementing keyboard behavior.
  • Using aria-label in a way that overrides clearer visible text.
  • Using aria-hidden on content that can still receive focus or be operated.
  • Failing to sync aria-expanded, aria-selected, aria-current, and similar states with the visual state.
  • Dialogs, menus, or tabs appear usable visually but manage focus in unexpected ways.

Where DevCheck and UI Kit fit

DevCheck can help find some ARIA and semantic issues on the current page, including after interaction. But it cannot guarantee that a pattern is fully implemented, because keyboard behavior, focus management, and content understanding still require real-flow review.

UI Kit addresses the component layer. For common components, the earlier native HTML, ARIA, keyboard, and focus rules are built into the foundation, the less likely each page is to repeat the same defects.

Related pages