Context Change on Focus Audit

When a keyboard user tabs to a control, the only thing that should happen is that the control receives focus. If focusing an element opens a new window, submits a form, steals focus, or navigates away, the user is thrown off course before they have decided to act. WCAG 3.2.1 On Focus forbids that class of behaviour.

Turning it on

This audit is experimental: it is off by default while we validate it against more real-world sites. To enable it, open a site’s Settings, and switch on Include experimental audits under Scan settings. The setting is per-site, and applies to every scheduled and manual scan of that site from the moment you save it.

How the audit works

This check piggybacks on the focus appearance Tab loop. As the loop presses Tab through focusable elements, an observer watches for side effects caused purely by focus arriving: a window.open call, an automatic form submission, focus being removed or redirected to an unrelated element, or a URL or navigation change.

Confident outcomes are reported as violations. Ambiguous cases, such as soft SPA URL changes or focus moving inside a related composite widget, are reported as incomplete.

Reading the results

Violations describe what happened when the element received focus, for example a page navigation or a new window. Incomplete results need human confirmation that the page’s meaning actually changed.

You can ignore individual elements you have reviewed and accepted using the same ignore feature you use for other issues.

Limitations

Showing a tooltip or expanding a menu on focus is not a change of context by itself, and the audit does not flag those. Effects that require activation (click or Enter) are out of scope. Delayed handlers that fire after the settle window, and content inside closed shadow roots, may be missed. If focusing an element navigates away, the scan recovers by returning to the original page so later steps still see the correct document.