Level A

New in WCAG 2.2: if a process asks for the same information twice, it must be auto-populated or selectable -- not retyped

3.3.7 Redundant Entry

In Plain Language

[3.3.7 Redundant Entry, Level A, new in WCAG 2.2] says that information previously entered by or provided to the user, if it is required to be entered again in the same process, must be either auto-populated or available for the user to select[1]. A blank field the user has to refill from memory is a failure.

The normative text carves out three exceptions: re-entry is essential (a password confirmation, a memory test), the information is required to ensure the security of the content, or the previously entered information is no longer valid (an expired one-time code). Cognitive friction is not an exception -- "the user can just type it again" does not satisfy the criterion.

Why It Matters

  • The mechanism 3.3.7 targets is working-memory load across process steps. A checkout that collects a shipping address on step 2 and a billing address on step 3 with no "same as" control forces the user to hold the earlier answer in short-term memory and retype it verbatim. Users with cognitive and learning disabilities lose the thread, abandon the process, or submit a mismatched value that trips a later validation error.
  • Motor-impaired users and switch users pay the cost in keystrokes. Every re-entered character is another switch activation or another dwell-click. Auto-population collapses a 30-character address into zero interactions.
  • Screen-reader users navigate forms field by field. A re-entry field that could have been pre-populated is additional traversal, additional edit-mode time, and additional risk of a typo that only surfaces at the next step boundary.
  • The failure is not limited to disabled users -- it is an accessibility criterion because disabled users hit the wall first and hardest, but the mechanism (working-memory overload inside a multi-step process) is universal.

Examples

Do: Auto-populate shipping address from billing

Step 2: Shipping Address

✔ Address auto-populated from billing step -- user does not retype it

<!-- Step 2: Shipping Address -->
<label>
  <input type="checkbox" checked>
  Same as billing address
</label>
<label for="ship-addr">Address</label>
<input id="ship-addr" value="123 Main Street" readonly>
<!-- Address is auto-populated from Step 1.
     User can uncheck to enter a different one. -->
Don't: Force re-entry of address in every step

Step 2: Shipping Address

✘ User must retype the same address they entered in Step 1

<!-- FAILS: blank fields force re-entry -->
<h3>Step 2: Shipping Address</h3>
<label for="addr">Address</label>
<input id="addr" placeholder="Enter your address again">
<label for="city">City</label>
<input id="city" placeholder="Enter your city again">
<!-- User already provided this in Step 1 but must
     type it all over again with no auto-fill option -->
Do: Let users select from previously entered data

Emergency Contact

✔ Previously provided email is available for selection

<label for="contact-email">Email</label>
<select id="contact-email">
  <option>jane@example.com (from your profile)</option>
  <option>Enter a new email</option>
</select>
<!-- Previously entered email is pre-populated as a
     selectable option so the user does not retype it -->
Don't: Require re-entry of email across steps

Emergency Contact

Please enter the same email you used in Step 1.

✘ Tells the user to retype information instead of auto-populating it

<!-- FAILS: forces manual re-entry -->
<label for="email">Email Address</label>
<input id="email" placeholder="Enter your email address">
<p class="hint">Please enter the same email
  you used in Step 1.</p>
<!-- User must remember and retype their email
     instead of it being auto-populated -->

How to Fix It

  1. Persist earlier answers in process state. Keep previously entered values in server-side session state or a client-side store keyed to the process. Browser autofill is not a substitute -- it is unavailable in private browsing, inconsistent across devices, and outside the scope of what 3.3.7 asks the author to provide.
  2. Pre-populate the field with the previous value. The most direct path to conformance: render the input with value already set to what the user entered in an earlier step. Leave it editable so the user can correct it. A pre-populated field that the user can overwrite satisfies the "auto-populated" half of the criterion.
  3. Offer previous values as selectable options. Where auto-population is ambiguous (the user has three saved addresses and the process does not know which one applies), expose the earlier values in a <select>, a radio group, or a list of cards with an "enter a new value" option. This satisfies the "available for the user to select" branch.
  4. Use the "same as" pattern for parallel field groups. For shipping-vs-billing, delivery-vs-contact, and similar paired groups, a single checkbox that copies the whole group is the conventional solution and a valid technique under the W3C Understanding document[1].
  5. Set autocomplete on identifying fields. WCAG 2.1 SC 1.3.5 already asks for autocomplete tokens on inputs that collect user information; those same tokens help the browser surface the right value within and across sessions, which complements -- but does not replace -- explicit in-process persistence.
  6. Only invoke the exceptions when they apply. Password confirmation fields, memory-verification prompts, and expired-code re-entry are legitimate. "Our backend is easier to code this way" is not. If a field requires re-entry for security, the UI should state the reason so the user understands why the value they already gave is not being reused.

References

  1. [1] W3C (2023). Understanding Success Criterion 3.3.7: Redundant Entry. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html ↩ ↩