Keyboard navigation

Tab moves forward through focusable elements, Shift+Tab backwards.

Enter activates a link or a button; Space activates a button and toggles a checkbox.

Arrow keys move within a composite widget — a select, a radio group, a tab list, a menu — rather than between widgets.

Escape closes a dialog, a menu or a popover and returns focus to whatever opened it.

These are conventions users rely on. A custom control that ignores them is operable in principle and unusable in practice.

Unreachable controls: a `div` with a click handler and no `tabindex`, which a pointer can use and a keyboard cannot reach at all.

A focus trap: a dialog or a widget that focus enters and cannot leave. The user has no way out short of reloading the page, and it is a WCAG level A failure.

Focus lost after an action: opening a dialog without moving focus into it, or closing one without returning focus, leaving focus on a removed element and effectively at the top of the document.

A fourth, closely related: an invisible focus indicator, which makes navigation possible and unusable for anyone who can see.

A fifth: a control reachable only after a hover has revealed it, where the keyboard path never triggers the hover and the control never appears.

Move focus into the dialog when it opens, to the first control or to the dialog container.

Keep focus inside while it is open — a deliberate trap, which is the one legitimate case.

Close on Escape.

Return focus to the element that opened it on close.

The native `<dialog>` element with `showModal()` provides all four, which is a strong argument for using it rather than reimplementing it.

Put the mouse away and use Tab, Shift+Tab, Enter, Space, the arrow keys and Escape to complete a real task on the site.

Watch that the focus indicator is always visible and that it moves in reading order.

Open and close every dialog, menu and dropdown, checking where focus goes each time.

Complete a form, including submitting it with an error, and check that focus moves to the message.

Five minutes of this finds more than most automated runs, because it tests behaviour rather than markup.

Repeat the test at a narrow viewport. A menu that becomes a collapsible panel on mobile is a different widget with a different keyboard contract, and it is usually the one that was never tested.