ARIA cannot add keyboard behavior an element does not already have

What it is

Put role="button" or role="slider" on a div and the accessibility tree will introduce it as a button or a slider. The keyboard does not appear. Enter, Space, arrows, Home/End remain whatever the host already did — nothing, for a div. ARIA does not add keyboard behavior: ARIA changes semantic mapping, not event listeners. Keys in the role contract have to be written by the author, or supplied by switching to an element that already has them.

This is not a selection slogan. It is a split in the pipes: semantics in one, behaviour in the other, no bridge.

Why it happens

The user agent registers keys for native controls. <button> dispatches activation on Enter and Space; <input type="range"> eats arrows to change value; <select> jumps on characters. ARIA roles do not enter that registry. In focus mode the reader hands keys to the control; if the control’s listeners are empty, the key falls through to page scroll or is claimed by browse mode. The more complete the role on the tree, the more specific the expectation, and the larger the drop when listeners are empty: the user hits Space, thinks they pressed a switch, and the page flips.

The second layer is focus. Many native controls are focusable by default; a div is not. A role without tabindex never even arrives, let alone fulfils a key contract. tabindex="0" solves arrival only and still does not create activation. Authors treat “role looks right in the inspector” as operable; the inspector never tests whether Space has a listener.

Studying it

Pair a native button with a div role="button" in three cells: no tabindex; tabindex only; plus Enter/Space listeners. Keyboard-only: can it be Tabbed to, do Space/Enter fire, who consumes the key in the reader’s focus mode. Repeat for slider, tabs, menu as “role only / role plus handwritten keys.” Test NVDA focus mode and VoiceOver “interact with the control,” because the moment keys are handed over differs.

Independent variables: whether the host is native, focusability, presence of key listeners, role kind. Dependent variables: arrival, activation, value change, whether the key bubbles into page scroll.

Where it stops holding

Some frameworks bind keys when they detect certain roles, which looks like “ARIA started working” and is actually scripted behaviour that vanishes in a runtime without that kit. Pointer input does not use this contract: a click listener on the div can succeed with a mouse while the keyboard stays empty, so a mouse pass is not keyboard evidence. Browse-mode shortcuts (H, B) are reader behaviour, not widget behaviour; “H lands on this heading” does not prove a div role="button" activates.

Applying it

• For the keyboard contract of buttons, links, sliders, and tabs, start with the host element; when custom, write Enter/Space/arrows into the component and into tests, and do not stop at role.
• tabindex is arrival only. After arrival, still run activation and value change from the keyboard.
• Do not treat a correct inspector role as operable; operable means the control consumed the key and state changed.
• How to check: unplug the mouse, Tab to the control, press Space and Enter, then the arrows the role contract names. Nothing, or the page scrolls: semantics changed, behaviour is still a div. Repeat in NVDA focus mode so browse-mode key capture is not a false pass.

Related

• Same group: J5.11.1 Relationship attributes must point at elements that actually exist · J5.11.2 Misused live regions interrupt speech with secondary noise · J5.11.3 ARIA overrides native semantics and can conflict rather than supplement
• Nearby: J3.01 Keyboard access · J5.03 ARIA supplement
• Search terms: ARIA does not add keyboard behavior · role=button · keyboard contract