Possible keyboard trap

Why does it matter?

A script that cancels the Tab key can leave keyboard users stuck on one element with no way forward. For someone who cannot use a mouse, that ends their visit: the rest of the page, including the way out, is out of reach.

Who it affects: Keyboard, screen reader and low-vision users — every visitor meets the page title, language, landmarks, keyboard focus, target sizes and zoom settings on every page.

What does Lumtera flag?

Found by the keyboard walk (review mode's Keyboard tab, "Check keyboard access"): a script cancelled the Tab key twice on the same element and focus stayed there, outside any open modal dialog. Scripted key presses are not a real keyboard, so each one is for review, up to five per page.

Check ID page-focus-trap, as shown in review mode and saved results.

How do I fix it in WordPress?

Press Tab and Shift+Tab on the element yourself to confirm. Do not cancel the Tab key unless focus is kept inside an open modal dialog on purpose, and then let Escape close it. Widgets such as code or text editors should say how to leave them. If a plugin adds the widget, check its settings or ask its author.

Example

field.addEventListener( "keydown", ( e ) => {
  if ( e.key === "Tab" ) e.preventDefault();
} );

// Tab is left alone; only an open modal dialog keeps focus inside,
// and Escape closes it.
dialog.addEventListener( "keydown", ( e ) => {
  if ( e.key === "Escape" ) dialog.close();
} );

How do I check the fix?

1. Reload the page in review mode and run the Keyboard tab again (or Test menus and pop-ups for menus, dialogs and tabs). The finding disappears once the page passes.
2. Load the page and press Tab: a "Skip to content" link should appear first, and you should always see where focus is, even under a sticky header. Pinch-zoom on a phone, and check the browser tab shows a meaningful title.