WCAG 3.3.7: Redundant Entry
If a user already told you something in a process, don't make them type it again. This Level A criterion, new in WCAG 2.2, says information a user previously entered in the same process must be either auto-populated or available for them to select — unless re-entry is essential, needed for security, or the earlier value is no longer valid. It is one of the easiest wins in the whole standard, and it lowers errors and abandonment for everyone.
The success criterion, in full
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. Except when: re-entering the information is essential; re-entering the information is required to ensure the security of the content; or previously entered information is no longer valid.
Why redundant entry matters
Being asked to type the same information twice feels like a minor annoyance to many people. For others, it is a wall. A person with a cognitive or memory disability may not recall the exact value they entered three steps ago — the precise spelling of a street, the format of a reference number — and re-typing invites errors that can fail validation and stall the whole task. A person with a motor disability, using switch access or an on-screen keyboard, pays a real physical cost for every keystroke; re-keying a full address is not trivial, it is exhausting. A screen reader user must navigate back through earlier steps to find and re-copy a value, which is slow and easy to get wrong.
3.3.7 removes that barrier by making a simple demand: if the system already has the information, reuse it. Carry it forward, or give the user a one-tap way to select it. The payoff is broad — fewer typos, fewer failed validations, fewer abandoned checkouts and applications, and a faster path for every user, not only those with disabilities. It sits alongside the other Input Assistance criteria and, because WCAG 2.2 AA is the reference standard for the DOJ Title II rule and the European Accessibility Act, it is also a compliance target.
What counts as redundant entry
Redundant entry is any point in a multi-step process where the user is required to supply information they already gave you in that same process. The scope is the process — one checkout, one application, one onboarding flow — not the user's entire history with your site. Here is what typically trips it:
Re-typing an email or address across steps
A checkout that asks for a shipping address on step 2 and then demands the same address be typed again on step 4 is redundant entry. The information was already provided in this process, so it must be auto-populated or offered as a selectable value instead of retyped.
"Confirm your answer" fields that require memory
Asking a user to type a value on one screen and then reproduce it from memory on a later screen — outside of the allowed exceptions — is redundant entry. The earlier value should be shown or pre-filled so the user is not re-supplying information the system already holds.
Multi-page applications that forget earlier answers
A loan, benefits, or onboarding wizard that collects your name and date of birth on page 1 and then presents empty name and date-of-birth fields again on page 5 forces redundant entry. Carry the earlier answers forward.
Ignoring a value the user can obviously reuse
When billing and shipping are usually identical, forcing the user to key the same address twice with no 'same as shipping' shortcut is the textbook redundant-entry failure. Offer a way to reuse the value.
The three exceptions
A step that requires re-entry still passes 3.3.7 if one of these applies. Use them deliberately — they are narrow, and "we always ask twice" is not one of them.
1. Re-entering is essential
The re-entry is fundamental to the activity.
If asking for the information again is intrinsic to what the step does, it is allowed. A memory or recall game that tests whether you remember a value, or a step whose entire purpose is to confirm you can reproduce something, cannot pre-fill the answer without defeating itself.
2. Ensuring security of the content
Re-entry protects the security of the content.
A step may require re-entry when doing otherwise would undermine security. Asking the user to re-type a password to confirm a sensitive change, or to re-enter a code that must not be cached, is permitted because pre-filling it would weaken the protection the step exists to provide.
3. Previously entered information is no longer valid
The earlier information has expired or been invalidated.
If the value the user gave earlier is no longer valid — a one-time code that has expired, a session that has timed out, or data the system has since discarded — then asking for it again is not redundant, because there is nothing valid left to reuse.
Watch the "confirm" habit:a confirm-email or confirm-password field is only exempt when it genuinely rests on the security or essential exception. Many teams add them out of habit. Where a "show password" toggle or a verification email would do the job, dropping the confirmation field removes the redundant typing for everyone and is the stronger design.
Patterns that satisfy 3.3.7
The criterion offers two routes: auto-populate the value, or make it available to select. Both are compliant — pick whichever is clearer for the step.
Auto-populate
- Pre-fill a review screen with everything entered so far.
- Carry name, email, and address forward from an earlier step.
- Default billing to the shipping address, editable if needed.
- Persist answers in session while the wizard is in progress.
Available to select
- A "Same as shipping address" checkbox that fills the billing fields.
- A dropdown of addresses already entered in this flow.
- A "Use the email from step 1" button next to a field.
- A saved-values chooser the user picks from instead of typing.
Code examples
A "same as shipping" checkbox that reuses the earlier value
The most common redundant-entry fix: give the user an explicit, accessible control to reuse an address they already entered, rather than re-typing it. The checkbox has a real label, and toggling it fills (and disables editing of) the billing fields.
<fieldset>
<legend>Billing address</legend>
<label>
<input type="checkbox" id="same-as-shipping" checked />
Same as shipping address
</label>
<label for="billing-address">Street address</label>
<input id="billing-address" name="billingAddress"
autocomplete="billing street-address" />
</fieldset>
<script>
const box = document.getElementById("same-as-shipping")
const billing = document.getElementById("billing-address")
function sync() {
if (box.checked) {
billing.value = document.getElementById("shipping-address").value
billing.readOnly = true
} else {
billing.readOnly = false
}
}
box.addEventListener("change", sync)
sync() // apply on load
</script>Carrying an answer forward in a multi-step wizard
When a later step needs a value from an earlier one, pre-fill it from state you already hold. The field stays editable, but the user is not forced to reproduce it from memory.
// React: pre-fill step 3 from data collected in step 1
function ContactStep({ formData, onChange }) {
return (
<>
<label htmlFor="email">Email</label>
<input
id="email"
name="email"
type="email"
autoComplete="email"
// auto-populated from what the user entered earlier
value={formData.email}
onChange={(e) => onChange("email", e.target.value)}
/>
</>
)
}A review step that pre-fills every earlier answer
A confirmation screen should show what the user entered, editable in place — never present empty fields that ask them to type it all over again.
<h2>Review your details</h2>
<!-- Values are auto-populated from earlier steps -->
<dl>
<dt>Name</dt> <dd>Jordan Rivera</dd>
<dt>Email</dt> <dd>jordan@example.com</dd>
<dt>Address</dt><dd>221B Baker Street, London</dd>
</dl>
<a href="/checkout/details">Edit these details</a>Anti-pattern: empty fields that demand re-entry
This is the classic 3.3.7 failure — a later step that ignores what the user already provided and forces them to key it again.
<!-- DON'T: user already entered this on step 1 -->
<h2>Almost done — re-enter your address to confirm</h2>
<label for="addr">Street address</label>
<input id="addr" name="address" value="" />
<!-- No 'same as', no pre-fill, no security or essential
reason — this fails WCAG 3.3.7 -->Common mistakes
- Making users re-type their shipping address as the billing address with no 'same as' option.
- Presenting empty fields on a review or confirmation step instead of pre-filling what was already entered.
- Adding a 'confirm email' or 'confirm password' field out of habit, without a genuine security or essential justification.
- Losing earlier answers when a multi-step form validation error sends the user back a step.
- Forcing re-entry of the same reference number, order ID, or account number across pages of one process.
- Assuming 3.3.7 requires browser autofill — you can meet it by carrying values in session, no autofill needed.
- Auto-filling a value but locking it so the user cannot correct it when it is genuinely wrong.
- Treating a long, continuous application as separate 'processes' to dodge the requirement when it is clearly one flow.
How to test for 3.3.7
- 1
Map the whole process step by step
Write down every field the user fills across the entire flow — checkout, application, onboarding. Note which pieces of information appear more than once.
- 2
Flag every repeated field
For each value that is requested a second time, ask: is it auto-populated, or is there a clear way to select the earlier value? If the user has to re-type it, you have a potential failure.
- 3
Check each repeat against the three exceptions
A required re-entry only passes if it is essential to the activity, needed for security, or the earlier value is no longer valid. 'It's just how our form works' is not an exception.
- 4
Trigger a validation error and go back
Force a validation error partway through and navigate back. Confirm earlier answers are preserved and not wiped — losing them is a real-world 3.3.7 failure users hit constantly.
- 5
Test the reuse controls with a keyboard and screen reader
Operate every 'same as' checkbox, dropdown, or 'use previous value' button with the keyboard alone, and confirm a screen reader announces its label and state. The shortcut must itself be accessible.
Redundant entry is a manual, flow-level check that automated tools rarely catch — but you can pair it with a scan from the URL Accessibility Auditor and confirm assistive-technology behavior using the Screen Reader Testing Guide.
Related success criteria
3.3.8 Accessible Authentication (Minimum) — AA
The other new-in-2.2 sibling in this guideline: sign-in must not depend on a cognitive function test, the same cognitive-load philosophy applied to authentication.
3.3.2 Labels or Instructions — A
Clear labels and instructions make each field understandable — the foundation that redundant-entry reduction builds on.
3.3.3 Error Suggestion — AA
When a value is wrong, suggest the fix — the complement to not making users re-enter valid data they already provided.
1.3.5 Identify Input Purpose — AA
Tagging fields with the right autocomplete tokens lets browsers fill common personal data — a field-level partner to redundant-entry's flow-level rule.
Browse every criterion in the WCAG Success Criteria hub or work through the full WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 3.3.7 Redundant Entry require?
WCAG 3.3.7 requires that information a user has already entered in the same process is either auto-populated or available for the user to select, rather than requiring them to enter it again. It applies within a single multi-step process (like a checkout or an application wizard). It is a Level A success criterion, new in WCAG 2.2. Three exceptions apply: when re-entering is essential to the activity, when it is needed for security, or when the previously entered information is no longer valid.
Does 3.3.7 ban 'confirm password' and 'confirm email' fields?
Not automatically. A confirm-password field can fall under the security exception, and confirm-email fields are frequently justified as protecting against typos that would lock a user out of their account. That said, the accessible best practice is often to drop the confirmation field entirely and instead offer a 'show password' toggle or send a verification email — which removes the redundant typing for everyone. If you keep a confirmation field, lean on the security or essential exception and make sure it is intentional, not a habit.
How is 3.3.7 different from autocomplete (1.3.5 Identify Input Purpose)?
1.3.5 Identify Input Purpose (AA) is about tagging fields with the right autocomplete tokens so the browser and assistive tech can identify and fill common personal data — it is about a single field's metadata. 3.3.7 Redundant Entry (A) is about the flow: information the user gave you earlier in this same process must not be demanded again. You can satisfy 3.3.7 by auto-populating from the earlier step even for data the browser would never autofill (like a custom project name), and you can satisfy it without relying on browser autofill at all.
Does 3.3.7 require me to store personal data or use browser autofill?
No. 3.3.7 does not force you to persist data across sessions or to rely on the browser's autofill. It only concerns information already entered within the current process. You can meet it by carrying values forward in the page or server-side session for the duration of the flow, or by offering the earlier value as a selectable option — you do not have to save anything permanently, and you can honor it while respecting privacy.
Why is redundant entry an accessibility problem, not just an annoyance?
Re-entering data is a disproportionate barrier for people with cognitive disabilities (who may not remember the exact value), motor disabilities (for whom every keystroke is costly or painful), and people using screen readers or switch access (for whom navigating back to find and copy a value is slow and error-prone). What reads as a minor inconvenience for one user can be the difference between completing a task and abandoning it for another. Reducing redundant entry lowers errors and abandonment for everyone.
Does 'available to select' satisfy 3.3.7, or must the field be auto-filled?
Either satisfies it. The criterion is met if the information is auto-populated OR available for the user to select. A 'Same as shipping address' checkbox, a dropdown of previously entered values, or a review screen where earlier answers are pre-filled all count. You do not have to silently auto-fill everything — offering an explicit, easy way to reuse the earlier value is fully compliant and often clearer.
Does 3.3.7 apply across separate visits or only within one process?
Only within one process. The criterion scopes to 'the same process' — a single, continuous multi-step activity such as one checkout or one application. It does not require you to remember what a user typed last week or in a previous session. Once the process ends, or the earlier information is no longer valid (an expired code, a timed-out session), 3.3.7 no longer obliges you to reuse it.