Enter and Space Activation

Custom interactive controls must support the keyboard activation patterns users expect, including Enter and Space for button-like controls. Whenever possible, use native `<button>` elements so the browser supplies correct semantics, focus behavior, and keyboard interaction automatically.

A native `<button>` is already keyboard accessible: it can receive focus, exposes button semantics to assistive technology, and supports the expected keyboard activation behavior. This makes it preferable to a clickable `<div>` or `<span>` styled to look like a button.

When a custom element must behave like a button, it should expose an appropriate semantic such as `role="button"`, be reachable with the keyboard, and implement the expected activation keys. For a button-like control, both Enter and Space should be supported rather than relying only on a mouse `click` handler.

Keyboard handling should also preserve normal browser behavior where appropriate. In particular, Space normally scrolls a page, so a custom button generally needs to prevent that default behavior while handling Space activation. Focus should remain visible so keyboard users can identify the active control.

A semantic role alone does not create native behavior. `role="button"` tells assistive technology what the element represents, but developers remain responsible for keyboard interaction and other relevant behavior when using a non-native element. This is one reason native controls are generally the simpler and more robust choice.

Key points

• Prefer native `<button>` elements for button actions.
• Button-like custom controls should support both Enter and Space.
• A WAI-ARIA role provides semantics but does not supply native keyboard behavior.
• Ensure custom controls are keyboard focusable and retain a visible focus indicator.
• Avoid implementing button behavior with mouse-only event handling.

Interview questions

Why should you use a native `<button>` instead of a clickable `<div>`?

A native button already has the correct interactive semantics and standard keyboard behavior. It can receive keyboard focus and is exposed to assistive technology as a button. A clickable div requires additional work for semantics, focusability, keyboard activation, and focus styling. Therefore, native controls reduce both implementation complexity and accessibility bugs.

Which keyboard keys should activate a button-like control?

A button-like control should support the expected activation behavior for Enter and Space. The implementation should account for the different event behavior of these keys rather than simply attaching one generic keyboard handler. Space also requires care because its normal browser action can scroll the page. Native buttons are preferred because the browser already implements the expected interaction.

Does `role="button"` make a div behave like a native button?

No. The role communicates the element's intended semantics to accessibility APIs, but it does not automatically provide all native button behavior. Developers still need to make the element keyboard reachable and implement the appropriate keyboard interaction. They also need to consider focus styling and other behavioral details. This is why using an actual `<button>` is normally preferable.

How would you test a custom button for keyboard accessibility?

I would first navigate to the control using only the keyboard and verify that it receives a visible focus indicator. I would then test activation with both Enter and Space and confirm that the same intended action occurs as with a pointer interaction. I would also verify that Space does not cause an unintended page scroll and that the control exposes appropriate semantics to assistive technology. Finally, I would test the behavior across the relevant browsers and input methods.

What problems can arise when replacing a native button with a custom element?

A custom element can lose several pieces of native behavior, including keyboard interaction, focus management, semantic exposure, and established browser behavior. Developers may also accidentally introduce inconsistent event handling, broken focus indicators, or differences between pointer and keyboard activation. ARIA can communicate semantics but does not replace the full behavior of a native control. I would first question whether the custom element is necessary and otherwise implement the required interaction as closely as possible to the native pattern.