Native HTML Semantics vs ARIA

Native HTML elements usually provide more complete and dependable accessibility behavior than recreating equivalent controls with ARIA. Use semantic HTML first, and add ARIA when native semantics cannot express the required meaning or state.

Native HTML elements communicate meaning to browsers and assistive technologies through built-in semantics and behavior. For example, `<button>` is understood as a button and supports keyboard interaction without requiring you to recreate that behavior manually.

ARIA (Accessible Rich Internet Applications) adds roles, states, and properties that expose accessibility information when HTML alone is insufficient. Examples include `aria-expanded`, `aria-selected`, and `role="dialog"`.

ARIA generally changes how an element is exposed to accessibility APIs; it does not automatically turn a generic element into a fully functioning native control. A `` may expose a button-like role, but developers still need to implement appropriate keyboard interaction, focus behavior, activation, and other expected behavior.

A useful rule is to prefer the native element that already represents the intended control. ARIA should supplement semantic HTML or provide semantics that have no suitable native HTML equivalent, rather than replacing native controls merely for convenience.

Incorrect ARIA can make an interface less accessible by exposing inaccurate roles or states. Therefore, accessibility work should verify both the semantic information and the actual interaction behavior with keyboard testing and appropriate assistive technology.

Key points

• Prefer native semantic HTML when an appropriate element exists.
• ARIA supplies accessibility roles, states, and properties; it does not automatically provide complete widget behavior.
• A `div` with `role="button"` still needs appropriate keyboard, focus, and activation behavior.
• Use ARIA to supplement HTML or express semantics that native HTML does not adequately provide.
• Incorrect or conflicting ARIA can produce misleading accessibility information.

Interview questions

Why should you prefer native HTML elements over ARIA when possible?

Native elements already have established semantics and browser behavior that assistive technologies can consume. They also reduce the amount of custom accessibility behavior developers need to implement. Using native controls therefore lowers the chance of missing keyboard, focus, or state behavior. ARIA is useful when native HTML does not adequately express the required semantics.

Does adding `role="button"` make a `` behave like a button?

No. The role can expose the element as a button to accessibility APIs, but it does not by itself provide all of the behavior users expect from a native button. Developers must handle appropriate focusability, keyboard activation, and state or interaction logic as needed. A native `<button>` is normally preferable when a button is what the interface represents.

What does the rule 'No ARIA is better than bad ARIA' mean?

The principle means that incorrect accessibility information can be worse than leaving an element's semantics unchanged. An inaccurate role, state, or property can cause assistive technologies to announce information that does not match the interface. Developers should therefore use ARIA only when they understand the intended semantic result and can keep it accurate. Native HTML is usually the safer starting point when it provides the needed semantics.

What is the difference between an ARIA role and an ARIA state or property?

A role communicates what an element is intended to represent, such as a button, dialog, or tab. States and properties provide additional information about that element, such as whether an expandable control is currently expanded. These values are exposed through accessibility APIs so assistive technologies can understand the interface. The application still has to maintain those values consistently with the actual UI.

How would you approach making a custom interactive widget accessible?

First, I would check whether an existing native HTML element or established native pattern can represent the widget. If not, I would select the appropriate ARIA pattern and implement its required keyboard, focus, interaction, and state behavior. I would keep ARIA states synchronized with the real UI and test the result with keyboard navigation and relevant assistive technologies. I would also verify that the accessibility tree reflects the intended structure rather than assuming that adding attributes is sufficient.