Keyboard Accessible and Activatable

A component is « keyboard accessible » when you can select it with Tab, and « activatable » when you can trigger its action with Enter or Space. Native HTML elements like <a>, <button> and <input> are by default. A <div> with an onclick, is not.

A <span> with an onclick works with the mouse. On the keyboard, nothing happens. No focus, no activation, no feedback. The user navigating without a mouse is blocked.

#Two distinct concepts

The RGAA distinguishes two things :

• Accessible : the user can reach the component with the Tab key (focus acquisition).
• Activatable : the user can trigger the action with Enter or Space.

Native HTML elements (<a>, <button>, <input>, <select>) meet both conditions without any effort. The WCAG 2.1.1 criterion (level A) requires that all functionality be usable via the keyboard, except when it depends on tracing a movement (such as freehand drawing).

#The classic mistake : the fake button

Here is a component inaccessible via keyboard :

<!-- ❌ Inaccessible via keyboard -->
<span onclick="validate()">Validate</span>

The mouse works. The keyboard does not. The element does not receive focus and does not respond to Enter.

The simplest fix :

<!-- ✅ Natively accessible and activatable -->
<button type="button" onclick="validate()">Validate</button>

If you must use a <div> (rare case), you need to recreate all the behavior :

<!-- ⚠️ Possible, but fragile -->
<div role="button" tabindex="0" onclick="validate()" onkeydown="if(event.key==='Enter'||event.key===' ')validate()">
  Validate
</div>

Three attributes and an event handler to reproduce what a <button> does in one line.

#Visible focus and keyboard trap

Making an element focusable is not enough. Two other requirements complete the picture.

Focus must remain visible. Removing outline: none in CSS without providing an alternative removes visual landmarks for a keyboard navigation user. The WCAG 2.4.7 criterion requires it at level AA.

Focus must never be trapped. If a user enters a modal or menu and cannot exit it with Tab or Escape, this violates the WCAG 2.1.2 criterion. Chrome Lighthouse tests this automatically.

#In summary

Use native HTML elements. They are already keyboard accessible and activatable. If you build a custom component, add tabindex="0", the appropriate ARIA role and a keydown handler. Test with Tab, Enter, Space and Escape, without touching the mouse.