How can a click handler support a keyboard-operated page control?

A click event can result from mouse, touch, keyboard, or assistive technology input, but keyboard-generated clicks apply to elements that have a default key handler. Simply making another element focusable does not give it that behavior. [S1]

For an ordinary action, use a native button rather than a generic element styled to look like one. Native interactive elements have built-in interaction behavior, and the accessibility guidance recommends them for ordinary actions. [S2] For example:

<button type="button" id="save">Save</button>

document.querySelector('#save').addEventListener('click', saveChanges);

This keeps the action in one click handler while using a control with built-in behavior. If your control is for navigation, choose a link instead of a button. [S2]

No. The guidance notes that an element with an onclick handler can be made focusable with tabindex="0", but keyboard operation then requires an appropriate keyboard event handler. [S2] Focusability and activation are separate: tabindex="0" lets keyboard users reach the element, while your code must also handle the intended keyboard interaction.

A useful structure is to send both pointer activation and the custom keyboard handler to the same action function:

const control = document.querySelector('#custom-save');

function activate() {
  saveChanges();
}

control.addEventListener('click', activate);
control.addEventListener('keydown', (event) => {
  // Handle the activation key or keys defined for this control.
  // Call activate() when the intended key is received.
});

This is a structure, not a complete widget recipe: the key handling must match the specific control. The cited guidance establishes the need for a suitable keyboard handler, but does not prescribe key mappings for every custom interaction. When possible, replacing the custom element with a native button reduces the behavior you need to supply. [S2]

First identify what the control does. If it performs an ordinary action, use a button; if it navigates, use a link. Those native choices are preferred for ordinary actions because they provide built-in interaction behavior. [S2] Keep the action logic in one function so the click handler and any custom keyboard handler call the same action, rather than maintaining separate copies.

Then check the actual page: move focus to the control using the keyboard, activate it using the keyboard behavior intended for that control, and confirm the same action occurs as with a pointer. For a custom element, check both that it can receive focus and that its keyboard handler activates it. These are practical checks, not proof by themselves of full accessibility.

For the example, a suitable first revision is to replace the styled div with <button type="button">Save</button> and retain the click handler. Keep a custom element only when there is a specific need the native control does not meet, and define its intended keyboard behavior before implementing it.

No. Keep the action itself in one function, then have the click handler and the appropriate keyboard handler call it. That avoids maintaining two versions of the action. The keyboard handler still has its own responsibility: recognize the activation behavior intended for this particular control. [S2]

For example, the activate() function in the earlier pattern contains the action, while the event handlers decide when to call it. Do not assume that making an element focusable or adding a generic key listener automatically gives it the behavior of a native control. If you do not have a specific reason to build a custom interaction, use the corresponding native button or link instead. [S1][S2]