Physical keyboard Enter and Space double trigger a clicked button in Microsoft Edge

Move focus from Hint to the actual guess-entry control after the hint action completes, and submit guesses through the form’s submit event rather than intercepting Enter globally.

A focused native <button> is expected to activate on Enter or Space; that behavior is essential for keyboard accessibility, not an Edge-specific action to suppress.^1^ ^2^

Preferred implementation

If players type into a real input, make that input the next focus destination after Hint:

<form id="game-form">
  <label for="guess">Your guess</label>
  <input id="guess" autocomplete="off" maxlength="7">

  <button id="hint" type="button">Hint</button>
  <button type="submit">Submit guess</button>
</form>

<script>
const form = document.querySelector("#game-form");
const guess = document.querySelector("#guess");
const hint = document.querySelector("#hint");

hint.addEventListener("click", () => {
  showHint();
  guess.focus();
});

form.addEventListener("submit", event => {
  event.preventDefault();
  submitGuess(guess.value);
});
</script>

Important details:

• Keep Hint as a native <button> so Tab, Enter, Space, touch, and assistive technology continue to work.
• Use type="button" for Hint so it does not submit the form.
• The click handler covers mouse and native keyboard activation. Consequently, both input methods produce the same post-action focus state, as recommended for consistent focus management.^3^
• After showHint() completes, focus moves to the guess input because entering the next guess is the logical next task.
• Let the form’s submit event handle Enter from the guess input.

Do not call blur() without assigning focus somewhere meaningful. That can leave keyboard and screen-reader users without a clear interaction point.

If the game board is the typing surface

If guesses are not entered through a real input, the board must be an intentionally focusable interaction target with a visible focus indicator:

<div id="board" tabindex="0" aria-label="Guess entry area"></div>
<button id="hint" type="button">Hint</button>

<style>
#board:focus-visible {
  outline: 3px solid Highlight;
  outline-offset: 4px;
}
</style>

<script>
const board = document.querySelector("#board");
document.querySelector("#hint").addEventListener("click", () => {
  showHint();
  board.focus();
});
</script>

Use this model only when the board really owns keyboard entry. Avoid creating an otherwise meaningless extra tab stop. Edge guidance expects controls to be reachable by Tab and to expose a visible indication of focus.^4^

Secondary safeguard for global keyboard handlers

If the game also has a document- or window-level keydown listener, ignore events while another interactive control owns focus:

window.addEventListener("keydown", event => {
  if (event.target.closest(
    "button, input, textarea, select, a[href], [contenteditable]"
  )) {
    return;
  }

  handleBoardKey(event);
});

This prevents the game handler and an interactive control from processing the same key. It is only a safeguard: by itself, it would leave Hint focused, so Enter or Space would still correctly reactivate Hint. The focus transition to the guess input or board is what prevents that unwanted reactivation.

Do not globally cancel Enter or Space, and do not add duplicate keydown activation logic to native buttons.

Validate in Edge

Test these distinct paths:

1. Click Hint, type a guess, and press Enter.
   • Hint runs once.
   • Focus moves to guess entry.
   • Enter submits only the guess.
2. Tab to Hint and press Enter or Space.
   • Hint remains keyboard-operable.
   • After activation, focus moves to guess entry.
3. Tab through every control.
   • Focus remains visible and follows a logical order.
4. If event ordering remains unclear, open Edge DevTools Console and run:

monitorEvents(window, "key");

This displays keyboard events and their targets.^5^

References

1. Designing accessible websites
2. Making actions keyboard accessible by using the
3. Developing a Keyboard Interface | APG | WAI | W3C
4. Check for keyboard support by using the Tab and Enter keys
5. Monitors all keyboard-related events on the window object by specifying the 'key' event type, logging these events to the console.