WCAG 2.2 Demo Suite

3.2.1 Level A Guideline 3.2 Predictable Added in WCAG 2.0 Not detectable automatically

On Focus

When any component receives focus, it does not initiate a change of context — no automatic form submission, navigation, new window, or focus move elsewhere.

Who this affects

Keyboard and screen reader users, who move focus in order to read. If merely arriving at a control launches a new page, they can never reach the controls beyond it.

The failure and the fix

Each example below is a self-contained page, loaded in a frame so its markup cannot affect this page. Open either one on its own to test it with a keyboard or screen reader.

Fails 3.2.1

Open the failing example in a new tab

fail.html — the problem

<h1>Find a branch</h1>

<form>
  <!-- FAILURE 1: the select submits as soon as it receives focus. A keyboard
       user tabbing to it, or a screen reader user arrowing through the options
       to hear them, triggers navigation before they have chosen anything.
       They can never reach the option they actually want. -->
  <div class="field">
    <label for="branch">Branch</label>
    <select id="branch" onfocus="go()">
      <option>Riverside</option>
      <option>Old Town</option>
      <option>Hillgate</option>
    </select>
  </div>

  <!-- FAILURE 2: focusing the field opens a dialog, so focus is yanked
       somewhere else the instant the user arrives. -->
  <div class="field">
    <label for="date">Visit date</label>
    <input type="text" id="date" onfocus="openHelp()">
  </div>

  <!-- FAILURE 3: focus moves focus. Tabbing here throws the user to the
       bottom of the page, and everything between is unreachable by Tab. -->
  <div class="field">
    <label for="post">Postcode</label>
    <input type="text" id="post" onfocus="document.getElementById('end').focus()">
  </div>

  <button type="submit" class="button">Search</button>
</form>

<p id="log" role="status"></p>
<p><a href="#x" id="end">Last link on the page</a></p>
<p id="x">Target.</p>

Meets 3.2.1

Open the passing example in a new tab

pass.html — the fix

<h1>Find a branch</h1>

<form>
  <!-- FIX 1: focus does nothing. The user chooses, then activates an explicit
       Search button. Receiving focus is how a keyboard user READS a page - it
       must never be treated as an instruction. -->
  <div class="field">
    <label for="branch">Branch</label>
    <select id="branch">
      <option>Riverside</option>
      <option>Old Town</option>
      <option>Hillgate</option>
    </select>
  </div>

  <!-- FIX 2: help is available on demand, from a control the user activates.
       Hint text that is always visible is better still - it needs no
       interaction at all. -->
  <div class="field">
    <label for="date">Visit date</label>
    <p class="hint" id="date-hint">Use the format DD/MM/YYYY.</p>
    <input type="text" id="date" aria-describedby="date-hint">
  </div>

  <div class="field">
    <label for="post">Postcode</label>
    <input type="text" id="post" autocomplete="postal-code">
  </div>

  <button type="submit" class="button">Search</button>
</form>

<!-- Note the boundary: 3.2.1 forbids a CHANGE OF CONTEXT on focus - submitting
     a form, navigating, opening a new window, or moving focus elsewhere.
     It does not forbid every visible change. Showing a hint, highlighting the
     field, or expanding help text next to it are all fine, because the user
     stays where they are and keeps control. -->

<p><a href="#x" id="end">Last link on the page</a></p>
<p id="x">Target.</p>

How to test it

Tab through every control without activating anything. Nothing should submit, navigate, open a window, or move focus. Select elements that navigate on focus or change are a classic failure.

  • Automated

    Requires tabbing through and observing for unexpected context changes.

    No axe rule maps to this criterion. It has to be checked by a person.

  • Keyboard

    Unplug the mouse. Move through the page with Tab, Shift+Tab, Enter, Space and the arrow keys. See the keyboard testing script.

  • Screen reader

    Listen to both examples with NVDA, JAWS, VoiceOver or TalkBack and compare what is announced. See the screen reader cheat sheets.

  • Visual

    Zoom to 200% and 400%, narrow the viewport to 320 px, and apply the text-spacing overrides. See the visual testing procedures.

In the specification