Accessible Controls

Accessible controls let all users operate interactive UI reliably, including people using keyboards, screen readers, or other assistive technology. Prefer semantic controls, give them accessible names, preserve keyboard and visible-focus behavior, and expose important state changes.

Use native HTML controls such as `button`, `a`, `input`, `select`, and `details` when they match the interaction. Native elements provide established semantics, keyboard behavior, focus handling, and browser accessibility integration, reducing the amount of custom code you must maintain.

Every interactive control needs an accessible name that communicates its purpose. Visible text usually supplies the name for buttons and links; an associated `<label>` names form controls. For icon-only controls, provide an accessible name with visible text when possible or an appropriate `aria-label` when there is no visible label.

Keyboard users must be able to reach and operate controls without requiring a mouse. Do not remove the browser's focus indicator unless you replace it with an equally clear alternative. Custom widgets should implement the keyboard interaction expected for their pattern rather than merely responding to pointer events.

When a control has meaningful state, expose that state programmatically. Attributes such as `aria-expanded`, `aria-pressed`, `aria-selected`, and `aria-disabled` can communicate states when native semantics do not already provide them. Dynamic updates that require the user's attention may also need an appropriate live-region mechanism, but unnecessary announcements can make a UI harder to use.

ARIA should supplement correct HTML rather than replace it. A clickable `div` with several ARIA attributes can still be inferior to a real `button` because the native element already provides much of the required behavior and semantics.

Key points

• Prefer native semantic interactive elements over generic elements with custom behavior.
• Give every interactive control a clear accessible name.
• Ensure controls work with the keyboard and retain a visible focus indicator.
• Expose meaningful dynamic states such as expanded, pressed, or selected.
• Use ARIA to fill semantic gaps, not as a substitute for native HTML.

Interview questions

How do you make an icon-only button accessible?

The button needs an accessible name that describes its action, such as `Close`, `Search`, or `Delete`. If there is no visible label, an appropriate `aria-label` can provide that name. The control should still be a native `button` and must remain keyboard accessible with visible focus. The icon itself should not be the only source of meaning for assistive technology.

Why should you prefer a native button over a clickable div?

A native `button` already has the correct interactive semantics and participates in the browser's keyboard and focus behavior. A clickable `div` is not automatically an equivalent control for keyboard or assistive-technology users. Recreating the missing behavior correctly requires additional code and careful handling of semantics, focus, and keyboard input. Therefore, the native element is normally the simpler and more reliable choice.

What does `aria-expanded` communicate?

`aria-expanded` communicates whether an associated expandable region is currently expanded or collapsed. It is useful for controls such as disclosure buttons, menus, and accordions when the applicable accessibility pattern calls for it. The value should stay synchronized with the actual UI state. It does not itself create the keyboard behavior or show and hide the controlled content.

How would you test an accessible custom control?

I would first test the control using only the keyboard, including reaching it, activating it, and observing focus. I would inspect its accessible name, role, and state with browser accessibility tooling or a screen reader. I would also verify that state changes are exposed consistently and that focus is not lost unexpectedly. Finally, I would test common interaction paths with an actual screen reader where practical rather than relying only on automated checks.

When should ARIA be used instead of native HTML?

ARIA is appropriate when native HTML does not adequately express the semantics or state required by a component. It should generally complement native elements rather than replace them with generic containers. Adding ARIA does not automatically provide keyboard interaction, focus management, or the behavior associated with a native control. A good implementation therefore treats semantics, interaction, focus, and state as separate responsibilities that all need to be correct.