Native HTML Controls for Keyboard Accessibility

Using native HTML controls such as buttons, links, and form elements gives users built-in keyboard interaction and accessibility semantics. Prefer these elements before recreating their behavior with generic containers and JavaScript.

Native HTML controls communicate their purpose to the browser and assistive technologies through their semantics. Elements such as `button`, `a`, `input`, `select`, and `textarea` have established interaction models that browsers implement for you.

A native `button` can receive focus and be activated from the keyboard, while a link can be reached with `Tab` and activated with the keyboard. Form controls also expose their roles, values, and states through platform accessibility APIs.

A generic element such as `div` does not automatically acquire these behaviors when it is given a click handler. Adding `tabindex`, ARIA attributes, and keyboard event handlers can approximate some behavior, but it creates additional code and opportunities for inconsistencies.

For keyboard-accessible interfaces, start with the correct semantic element and only add custom interaction when the native control cannot express the required behavior. This reduces implementation work and helps preserve expected browser and assistive-technology behavior.

Key points

• Prefer semantic controls such as `button`, `a`, `input`, and `select` over clickable `div` or `span` elements.
• Native controls provide established keyboard interaction and accessibility semantics.
• A `div` with `onclick` does not automatically become keyboard accessible.
• Use `tabindex` and ARIA only when needed; they do not automatically reproduce every native behavior.
• Choose an element based on its meaning and expected interaction, not only its visual appearance.

Interview questions

Why should you use a native `button` instead of a clickable `div`?

A native `button` already has the semantics and keyboard interaction users expect from a button. Browsers make it focusable and support keyboard activation without extra event-handling code. A clickable `div` only responds to whatever behavior the developer implements. Recreating the native behavior requires additional accessibility work and can still miss important details.

Does adding `tabindex="0"` make a `div` accessible as a button?

No. `tabindex="0"` makes the element reachable through sequential keyboard focus, but it does not give the element button semantics or automatically implement button activation behavior. A custom control may also need appropriate semantics and keyboard event handling. A native `button` is generally preferable because these behaviors are already defined by the platform.

When should you use a link instead of a button?

Use a link when activating it navigates to another resource or URL. Use a button when the interaction performs an action in the current interface, such as opening a dialog or submitting an operation. This distinction gives users and assistive technologies an accurate interaction model. Styling can make either element look similar, but the semantic choice should follow the behavior.

What accessibility problems can arise from building custom controls with generic HTML?

Generic elements do not automatically provide the role, focus behavior, keyboard interaction, or state management expected from native controls. Developers may need to implement all of those pieces themselves, increasing complexity and the chance of inconsistent behavior. Assistive technologies may also receive incomplete or incorrect information. Using the closest native element usually avoids these problems.