WCAG 3.3.7 — Redundant Entry

What this requires

Information previously entered by or provided to the user that is required to be entered again in the same process is either auto- populated or available for the user to select. Exceptions: when re-entering the information is essential (a password confirmation), when the information is no longer valid (an expired card), or when the information is required for security purposes.

How AI coding tools fail this

When asked to build a multi-step checkout, AI tools generate independent forms per step with no shared state. The user enters their email at step 1; step 4 asks for it again. Each step has the same fields with empty values.

The second pattern: shipping address fields with no "Same as billing" shortcut. The user copies the address by hand into a second form.

The third: form errors that reset all fields on submission failure. The user retypes everything because the validation error cleared the other ten fields they had filled correctly.

Failing examples

Two address forms with no copy mechanism:

<fieldset>
  <legend>Billing address</legend>
  <input name="billing-street" />
  <input name="billing-city" />
</fieldset>

<fieldset>
  <legend>Shipping address</legend>
  <input name="shipping-street" />
  <input name="shipping-city" />
</fieldset>

Passing examples

A "same as billing" toggle that populates the shipping fields:

<fieldset>
  <legend>Billing address</legend>
  <input
    name="billing-street"
    value={billing.street}
    onChange={(e) => setBilling((b) => ({ ...b, street: e.target.value }))}
  />
  {/* ... */}
</fieldset>

<label>
  <input
    type="checkbox"
    checked={shippingSameAsBilling}
    onChange={(e) => setShippingSameAsBilling(e.target.checked)}
  />
  Shipping address is the same as billing
</label>

<fieldset hidden={shippingSameAsBilling}>
  <legend>Shipping address</legend>
  <input
    name="shipping-street"
    value={shippingSameAsBilling ? billing.street : shipping.street}
    onChange={(e) => setShipping((s) => ({ ...s, street: e.target.value }))}
  />
  {/* ... */}
</fieldset>

Multi-step forms with persistent state across steps:

// Use a form context or URL/state persistence so step 4 reads from
// the same store step 1 wrote to.
const form = useFormStore();

<input value={form.email} onChange={(e) => form.setEmail(e.target.value)} />

Edge cases

Security exception. Re-entering a password to confirm a change is essential. Two-factor codes are also exempt.
No-longer-valid data (an expired payment method) reasonably requires re-entry, but the form should still offer to populate the other fields (name, billing address) from the previous entry.
autocomplete attributes help the browser populate fields from saved data — orthogonal to but complementary to this criterion.
Multi-step forms need persistent state. Local storage, URL params, or a server-side draft all work.
"Same process" is the wording. Across sessions, the criterion doesn't apply (re-entering on a new visit is fine), but within a single checkout it does.

How Jeikin handles this

The scanner identifies multi-step forms and looks for repeated field names across steps. The dashboard records each repetition and asks the reviewer to confirm whether auto-population or copy-from-previous is provided.

References

W3C — Understanding 3.3.7 Redundant Entry (opens in new tab)