Focus Lost
The Focus Lost check verifies that keyboard users can always tell where they are on a page. When someone presses Enter, Space or another activation key on a button, link or checkbox, the browser's focus indicator must stay on a visible, meaningful element.
If focus disappears — it lands on something hidden, jumps to the top of the page, or vanishes entirely — keyboard and screen reader users lose their place. This check reports every control where that happens.
WCAG criterion: 2.4.3 Focus Order (Level AA)
Why it matters
Losing focus is disorienting in a way that is hard to appreciate with a mouse. The user pressed a button, something happened, and now the highlight is gone. There is no way to know where the next Tab press will land — often it means starting again from the top of the page.
How the check behaves
The tool visits every interactive control on the page and, for each one:
- Scrolls to it and confirms it is visible.
- Presses the key that control is expected to respond to.
- Waits for the page to settle.
- Checks whether a visible element still holds the focus.
- Restores the page to its original state before moving on.
A second pass then handles controls that only exist after something is opened. Some buttons reveal hidden controls when activated — a Menu button that opens a navigation panel containing a Close button, for example. Those cannot be found on the initial page, so the tool activates each remaining visible button, compares which buttons are on screen before and after, and tests any newly revealed ones. It also checks whether the triggering button itself loses focus, which happens with things like a video play button that hides itself once clicked.
Keys tested per control
| Control | Keys |
|---|---|
| Button | Enter, Space |
Same-page link (#, javascript:) | Enter |
| Checkbox | Space |
| Radio button | Space |
| Dropdown | Enter, Space |
Custom button (role="button") | Enter, Space |
Custom checkbox (role="checkbox") | Space |
What the check covers
| Control | Notes |
|---|---|
| Buttons | Standard clickable controls |
| Same-page links | Links that do not navigate away from the page |
| Checkboxes and radio buttons | Form controls |
| Custom ARIA controls | Widgets using role="button", role="checkbox" and similar |
| Controls revealed in overlays | Close or dismiss buttons inside menus and modals |
What it skips, and why
| Skipped | Reason |
|---|---|
| External links | They navigate away from the page — that is expected |
<main> or role="main" | Receiving focus here is the correct behaviour for a skip link |
| Disabled controls | They cannot be activated |
| Invisible elements | They cannot be interacted with |
| Native dialogs | They capture focus by design |
Common false positives
| Scenario | Why it is not a real problem |
|---|---|
A skip link moves focus to <main> | Explicitly excluded — this is what a skip link is for |
An anchor pointing at a valid #id | Allowed |
| A button opens a browser alert | Not measurable on the page |
| A button opens a native dialog | Detected and skipped |
| An external link loses focus | Expected behaviour |
How to verify it by hand
- Tab to the control in question.
- Press Enter or Space.
- Look at where the focus outline is now. If nothing on screen is highlighted, or the highlight is on something you cannot see, that is a focus loss.
WCAG reference
Success Criterion 2.4.3 Focus Order (Level A)