WCAG 2.2 Demo Suite

3.3.3 Level AA Guideline 3.3 Input Assistance Added in WCAG 2.0 Not detectable automatically

Error Suggestion

If an input error is detected and a correction is known, the suggestion is provided to the user, unless it would jeopardise security or the purpose of the content.

Who this affects

Users with cognitive disabilities, who may not deduce the fix from a bare rejection. Everyone benefits from being told what a valid value looks like rather than being told only that theirs is not.

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.3.3

Open the failing example in a new tab

fail.html — the problem

<h1>Book an event ticket</h1>

<form id="f" novalidate>
  <div class="field">
    <label for="em">Email address</label>
    <input type="email" id="em" aria-describedby="em-e" value="anna.example.org">
    <!-- FAILURE 1: identifies the error (so 3.3.1 passes) but suggests nothing.
         The user knows something is wrong and not what would be right. -->
    <p class="err" id="em-e" hidden>Invalid.</p>
  </div>

  <div class="field">
    <label for="dt">Event date</label>
    <input type="text" id="dt" aria-describedby="dt-e" value="3rd March">
    <!-- FAILURE 2: the required format is never stated, before or after. -->
    <p class="err" id="dt-e" hidden>Error in field.</p>
  </div>

  <div class="field">
    <label for="pw">Choose a password</label>
    <input type="password" id="pw" aria-describedby="pw-e" value="abc">
    <!-- FAILURE 3: the rules are known to the system and withheld from the
         user, who now has to guess. -->
    <p class="err" id="pw-e" hidden>Password not accepted.</p>
  </div>

  <button type="submit" class="button">Book ticket</button>
</form>

Meets 3.3.3

Open the passing example in a new tab

pass.html — the fix

<h1>Book an event ticket</h1>

<form id="f" novalidate>
  <div class="field">
    <label for="em">Email address</label>
    <input type="email" id="em" autocomplete="email" aria-describedby="em-e" value="anna.example.org">
    <!-- FIX 1: says what is wrong AND offers the correction. Where the system
         can work out what the user probably meant, offer it. -->
    <p class="err" id="em-e" hidden></p>
  </div>

  <div class="field">
    <label for="dt">Event date</label>
    <!-- FIX 2: the format is stated BEFORE the user types, which prevents most
         of these errors happening at all. 3.3.3 handles the ones that slip
         through; 3.3.2 stops them being made. -->
    <p class="hint" id="dt-h">Use the format DD/MM/YYYY, for example 03/03/2026.</p>
    <input type="text" id="dt" aria-describedby="dt-h dt-e" value="3rd March">
    <p class="err" id="dt-e" hidden></p>
  </div>

  <div class="field">
    <label for="pw">Choose a password</label>
    <p class="hint" id="pw-h">At least 8 characters, including one number.</p>
    <input type="password" id="pw" autocomplete="new-password" aria-describedby="pw-h pw-e" value="abc">
    <!-- FIX 3: the message says which rule failed, not just that one did. -->
    <p class="err" id="pw-e" hidden></p>
  </div>

  <button type="submit" class="button">Book ticket</button>
</form>

<!-- The exception: you may withhold the suggestion where giving it would
     jeopardise security or defeat the purpose of the content - "your password
     is wrong" must not become "your password should have been hunter2", and a
     quiz must not suggest the right answer. -->

How to test it

Trigger each validation error. "Invalid date" fails; "Enter the date as DD/MM/YYYY, for example 05/09/2026" passes. Where a value is close to a valid one, suggest it.

  • Automated

    Requires reading each error message and judging whether it is actionable.

    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