Glossary / Semantic controls
Semantic controls
Semantic controls are native HTML elements whose role, state, keyboard behavior, focus behavior, and accessible name are understood by browsers and assistive technologies. A <button> is a button; an <a href> is a link; an <input> is a form control. Choosing the element that matches the action gives keyboard and assistive-technology behavior largely for free. A clickable <div> only looks interactive unless the developer recreates its semantics and behavior, which is error-prone.
What to know
- Use a button to perform an action in the current page and a link to navigate to a resource or location. Avoid styling one as the other while retaining misleading behavior.
- Native buttons support keyboard activation with Space and Enter, focus, disabled state, and platform accessibility APIs. Links have navigation semantics and open-in-new-tab/context-menu behavior.
- Use native form controls (
input,select,textarea,fieldset,legend) before custom widgets. Native validation and input types can improve mobile keyboards and browser behavior. - A custom widget must supply an appropriate role, accessible name, state/value, focusability, keyboard model, and state updates. ARIA changes accessibility-tree semantics; it does not implement interaction.
disabledandreadonlyare different: disabled controls are generally unavailable and omitted from form submission; readonly values remain focusable/readable and are submitted for applicable controls.- Semantic structure helps screen-reader navigation, voice control, automation, and maintainability, even when the visual design is identical.
Implementation and review
Prefer <button type="button">Save</button> for an action; set the type explicitly inside forms to avoid accidental submission. Prefer <a href="/settings">Settings</a> for navigation. Do not add role="button" to a native button; it is redundant. For custom controls, follow the WAI-ARIA Authoring Practices keyboard pattern and test with keyboard and target assistive technologies. Check that focus is visible, the control has an accessible name, state changes are announced or discoverable, and pointer activation has an equivalent keyboard operation.
Interview questions
- Why prefer native HTML to ARIA? Native elements already implement semantics and browser interaction; custom ARIA widgets require correct behavior and state synchronization.
- When is a link preferable to a button? When the main effect is navigation to a URL or fragment; buttons trigger an action.
- Does
role="button"make adivbehave like a button? No. It supplies a role, but the developer still needs focusability, Space/Enter activation, disabled behavior, and other expected behavior. - What does a custom widget need? Correct role/name/state/value, keyboard and pointer operation, focus management, and reliable state exposure.
- How would you audit a design system? Inventory interactive components, replace fake controls with native elements where possible, define keyboard contracts, and test all states and input methods.