Links activate with Enter; buttons respond to Enter and Space

What it is

On a keyboard, a focused link activates with Enter; Space’s default is page scroll. A focused button activates with both Enter and Space, and Space follows press-on-keydown / fire-on-keyup timing, so sliding off during hold cancels. This split is a platform contract, not a shortcut preference. A div pretending to be a button that only listens for Enter feels broken to Space users. A link dressed as a button that ignores Space is still a link; if it is actually a submit, Space users cannot submit.

Why it happens

Space is page-down in reading. Links live in the document flow, so Space must keep scrolling, or a focus stop on a link freezes reading. Buttons are controls; Space is yielded for activation and inherits a physical key’s down/up: keydown enters pressed, keyup fires, and leaving focus in between cancels. Enter is immediate fire for both, with no cancel gesture. A fake control that submits on keydown cannot be cancelled by sliding off; one that binds only click does nothing after Tab. Mismatch shows up as “mouse works, keyboard doesn’t” or as “Space scrolled the page and also fired the action.”

Studying it

Walk a keyboard protocol: Tab to a link, Space versus Enter; Tab to a button, same two keys; then hold Space and move focus away. Compare native controls with a fake div.

Independent variables: true role, which keys are listened for, fire on keydown versus keyup. Dependent variables: whether it activates, whether the page scrolls, whether it is cancellable, whether it is isomorphic with a native button.

Automation that only calls click() will go green. Real keyboard events are required.

Where it stops holding

Comboboxes and menu items have their own arrow-key contracts; do not copy button Space onto them. Touch has none of these keys. Some screen readers swallow Space in browse mode and only hand it to the control in focus mode—test both. On Mac some controls do not activate on Enter (Enter clicks the default button); that system-level default-button logic coexists with “links eat Enter only.”

Applying it

• Use native <a href> for links and <button> for buttons; do not bind a partial key set by hand.
• If an ARIA button is unavoidable, handle both Enter and Space, fire Space on keyup, and allow cancel.
• Do not intercept Space on a link as activation; that kills paging.
• Verify submit by keyboard only. Enter works, Space works, Space-then-Tab-away does not submit. Any miss means the activation contract is wrong.

Related

• Within the group: E1.16.2 Screen readers speak link and button roles, not only the label · E1.16.3 Open-in-new-tab in the context menu is meaningful only for links · E1.16.4 Visited state belongs to links; buttons have no visited concept
• Adjacent: E1.08 Links versus buttons · J3.01 Keyboard access · J3.02 Focus order and focus traps
• Search terms: Space key · Enter key · button activation