User must re-enter information already provided in the same process

What is this issue?

A form or multi-step process asks the user to manually provide the same piece of information more than once within a single task: the same email address on two separate steps, a shipping address duplicated into a billing address field with no way to copy it across. WCAG defines this as redundant entry: information the system already has, that it asks the user to supply again anyway, with no auto-populate mechanism and no simpler way to confirm “use the same value.”

The criterion carves out three narrow exceptions: when re-entry is essential to the process (confirming a password), when the previously entered information is no longer valid (an expired session), or when re-entry is required for security purposes.

Why does this matter?

Every field a user has to fill in is a chance to make a mistake, and every field that duplicates information already provided compounds that risk for no functional benefit: the two entries can now disagree with each other, and the user has no way to know which one the system trusts. For someone with a memory-related cognitive disability, recalling exactly what they typed three steps earlier, character for character, adds a task that has nothing to do with the actual goal of completing the form.

For someone with a motor impairment who finds typing physically effortful, or dyslexia that makes transcribing text from memory error-prone, unnecessary re-entry isn’t a minor annoyance; it’s added, avoidable friction on top of a task that was already harder for them than for most users. A checkout flow that asks for a shipping address and then a separate, manually-typed billing address with no copy option turns a two-minute purchase into a much longer one.

Who is affected?

• Cognitive disabilities: users with memory, attention, or processing differences may not reliably recall exactly what they entered on an earlier step, and re-entering from memory instead of from a stored value introduces a real risk of inconsistent, mismatched data.
• Motor impairments: every additional field to type is added physical effort for someone using a switch device, head pointer, or limited fine motor control, with no functional benefit over reusing a value the system already has.
• Low vision users: retyping a long value like an email address or a full postal address, rather than confirming a previously entered one, means re-reading and re-verifying character by character under screen magnification, which takes substantially longer than a single “same as above” checkbox.

What users experience

Grace has dyslexia and finds transcribing text from memory error-prone, so she relies on being able to copy or reuse information rather than retype it. She’s checking out on a retail site that collects her shipping address on one step and then presents a completely separate billing address form with no “same as shipping” option. She retypes her address a second time, transposes two digits in the postal code without noticing, and her order ships to the wrong address, a mistake that a single checkbox would have prevented entirely.

How do I fix it?

Auto-populate fields with data the user already entered earlier in the same process, wherever the value is genuinely still valid and reusable. This works because it removes the redundant task altogether: there’s nothing to re-verify or retype when the system already has a value it can safely reuse, so the risk of a mismatched re-entry disappears along with the extra effort.

Where auto-populating isn’t appropriate (for example, a billing address that’s often, but not always, the same as the shipping address), offer a clearly labelled option to reuse the previous value instead, such as a “Billing address is the same as shipping” checkbox that pre-fills the fields when checked. Either approach satisfies 3.3.7; what matters is that the user is never forced to manually retype something the system already collected, outside the criterion’s narrow exceptions for essential, invalid, or security-related re-entry.

Code Examples

<!-- Same email asked twice across two steps -->
<input type="email" name="email">

<!-- ...later, step 3 ... -->
<input type="email" name="confirm-contact-email">

<!-- No option to copy shipping to billing -->
<fieldset><legend>Shipping address</legend>...</fieldset>
<fieldset><legend>Billing address</legend>...</fieldset>

<!-- Method 1: don't ask twice - reuse the value already collected -->
<input type="email" name="email" autocomplete="email">
<!-- step 3 references the same stored value, no second input needed -->

<!-- Method 2: offer to reuse instead of forcing a retype -->
<fieldset><legend>Shipping address</legend>...</fieldset>
<label>
  <input type="checkbox" id="billing-same">
  Billing address is the same as shipping
</label>
<fieldset id="billing-fields">
  <legend>Billing address</legend>
  <!-- pre-filled from shipping fields when checkbox is checked -->
</fieldset>

Method 1 removes the redundant field outright: instead of asking for the email address a second time to “confirm” it, the process reuses the value it already has and validates it once. Method 2 keeps both address sections available for the (common) case where billing and shipping genuinely differ, but removes the forced retyping for the more common case where they’re the same, with one checkbox doing the work of an entire duplicate form.

Common Mistakes

Mistake: “Asking users to confirm their email by retyping it catches typos, so it’s good practice.” A second “confirm email” field only catches a typo if the user makes a different typo the second time; most people copy-paste or retype the same mistake identically, so the field mostly adds friction without reliably catching errors. A single email field with real-time format validation, or a confirmation link sent to the address, catches more real mistakes with less redundant typing.

Mistake: “This only applies to multi-page or multi-step forms.” The requirement applies to any process, including a single page that asks for the same piece of information in two separate sections; the number of pages involved doesn’t change whether the user is being asked to retype something the system already has.

Mistake: “Browser autofill already solves this for us.” Browser autofill only works if the user has previously saved that specific data in their browser, and it can’t reuse a value the user entered five minutes ago on an earlier step of the same process if the fields aren’t wired for it. The application itself needs to remember and reuse data within a session, independent of what the browser’s autofill happens to have stored.

Mistake: “Re-entering a password twice during signup is always a WCAG violation.” Confirming a password by retyping it falls under 3.3.7’s “essential” exception, since the redundancy is the verification mechanism for a value the user can’t see once typed into a masked field. It’s a legitimate exception, not a violation, though a visible show/hide toggle on the password field is often a better user experience than a second field.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. RedFlag’s coverage matrix records criterion 3.3.7 Redundant Entry under docs_only evidence. Detecting whether a multi-step form re-asks for already-supplied data would require tracking form state across multiple pages or steps of the same process, which RedFlag’s page-by-page scan does not do.

False negative: every occurrence is a false negative in the sense that nothing is ever automatically flagged: a multi-step form that repeats the same field with no auto-fill or reuse option passes every RedFlag scan silently. False positive: not applicable, since this check never raises an automated violation to begin with. Manual step: walk through the entire process end to end, noting every piece of information requested, and confirm nothing is asked for a second time without an auto-fill, a reuse option, or a genuine fit within the essential/invalid/security exceptions.

Manual Testing

1. Complete the entire multi-step form or process from start to finish, noting every piece of information you’re asked to provide.
2. Check whether any value (an email, a name, an address) is requested more than once across the steps.
3. For each repeated request, confirm whether it’s auto-populated, offered as a reuse option (like a “same as above” checkbox), or genuinely falls under one of the essential/invalid/security exceptions.
4. If a value is requested a second time with no auto-fill, no reuse option, and no exception that applies, the check fails.

Related WCAG Success Criteria

3.3.7 Redundant Entry: Information previously entered by the user in the same process must be either auto-populated or available for the user to select, rather than requiring re-entry, except where re-entry is essential, the information is no longer valid, or security requires re-entry. This rule is a direct check of that requirement across a full user process.

Related Issues

Form field autocomplete attribute is missing or invalid is closely related: a correctly set autocomplete attribute is one of the mechanisms that makes auto-populating a field, whether from the browser or your own application, actually work.

Form error is not clearly identified matters on the same multi-step forms this rule affects, since a process with fewer redundant fields still needs any remaining errors called out clearly when they do occur.

Accessible authentication requires cognitive function test shares this rule’s WCAG 2.2 goal of not adding unnecessary cognitive burden to a process: one targets login flows specifically, this one targets any multi-step form.

Dragging interaction has no pointer alternative is another WCAG 2.2 addition in the same “don’t add unnecessary friction” family, applied to pointer interaction rather than form re-entry.

Form input has no label is a foundational requirement worth checking on any form you’re auditing for redundant entry, since a field’s purpose has to be clear before you can even tell whether it duplicates an earlier one.

References

• W3C Understanding 3.3.7: Redundant Entry
• W3C WCAG 2.2: What’s New
• MDN: autocomplete attribute