WCAG 2.2 - All Success Criteria

Accessibility Checkpoints

Description

When any user interface component receives focus, it must not initiate a change of context. A change of context is a major change in the content of a web page that can disorient users if triggered unexpectedly, including changes such as opening a new window, moving focus to a different component, submitting a form, or significantly rearranging the page's content. This criterion ensures that focus alone - without an explicit user action such as a click or keypress - does not cause such disruptive changes.

How To Test

  1. Using only the keyboard (Tab, Shift+Tab), move focus through all interactive elements on the page: links, buttons, form fields, and custom widgets.
  2. Observe whether receiving focus on any element triggers a change of context, such as page navigation, a new window, a form submission, or a significant content change.
  3. Pay particular attention to <select> menus, custom comboboxes, and auto-suggest inputs - verify that focus alone does not submit or navigate.
  4. Check that modal dialogs, tooltips, and popups triggered by focus do not move focus away from the current control unexpectedly.
  5. Use a screen reader (e.g., NVDA + Firefox) and tab through the page, listening for unexpected announcements indicating a context change.

Testing Tools

Demo

On Focus demo

This markup auto-navigates the moment the user changes the <select> value - including when keyboard users press arrow keys to browse options, before they have made a choice.

<!-- Fail: context change triggered by input, not explicit action -->
<label for="country-fail">Choose a country:</label>
<select id="country-fail"
        onchange="window.location = this.value">
  <option value="/en/">English</option>
  <option value="/fr/">Français</option>
  <option value="/de/">Deutsch</option>
</select>
Code

Demo 2: Help Dialog on Focus

Help dialog on focus

A help dialog launches the moment a user tabs into or focuses on a form field, without any explicit activation. This blocks access to the field until the user closes the dialog.

<!-- Fail: Help dialog triggered by focus -->
<input id="email-fail"
       type="email"
       onfocus="showHelpDialog()">
Code

Fail Explanation

A common failure occurs when a <select> element or a custom dropdown automatically submits a form or navigates to a new URL as soon as a user tabs into it. Another failure is a pop-up dialog or new browser window that launches the moment a component receives keyboard focus. These behaviors are especially harmful for keyboard-only users and screen reader users, who cannot predict or prevent focus from triggering consequential actions and may become confused about where they are in the page or workflow.

Pass Explanation

A page passes when receiving keyboard focus on any interactive component merely highlights or visually indicates that component without triggering navigation, form submissions, new windows, or other context-shifting events. Any meaningful action should require an explicit activation step - such as pressing Enter, Space, or clicking - so that users retain full control over when changes occur.

Notes

There is an important distinction between a context change and a simple content update: appearing inline hints, expanding tooltips, or highlighting are generally not context changes and do not fail this criterion. The focus is on major, disorienting changes that interfere with the user's ability to predict the result of their navigation.

Techniques

WCAG techniques used in this demo: G107

Suggested Solutions & References

Curated from 5 real-world audit findings.