Redundant Entry
Information the user already supplied in the same session must not be required again — it should be auto-populated or selectable from a list, unless re-entry is essential (e.g. confirming a password). New in WCAG 2.2.
What it asks
When a process requires the user to enter the same information more than once within a session (typically in a multi-step flow), the page must either auto-populate the value or let the user choose from previously entered values. Asking the user to retype the same email address, address, or name in step 3 that they already entered in step 1 is a failure — unless the re-entry serves an essential purpose, such as confirming a password.
The SC applies within one session and one process. Asking the user for the same data again next month, or on a different flow, is out of scope.
How to meet it
- In checkout flows, pre-fill billing address with the shipping address (and offer a “Same as shipping” checkbox).
- In account-creation flows, carry the name and email through every subsequent step.
- For government / insurance forms, propagate household member info between sections.
- When the user must retype something for a genuine reason (typing a confirmation code, re-entering a password for security), explain why.
- Persist partially completed form data in client state or session storage so a back/forward navigation does not lose values.
Common failures
- Multi-step checkout forms that ask for email on the contact step and again on the payment step.
- Booking flows that ask for the lead traveller’s name and then the same name again as the cardholder, with no auto-fill.
- Account-recovery flows that ask for the email, then the username separately, then the same email again on a “confirm” screen.
- Long government forms with sibling sub-sections that each ask for the same primary applicant info.
Why it matters
This is one of the new WCAG 2.2 Level-A criteria, added to address cognitive accessibility. Re-entry is a high cost for users with memory impairments, dyslexia, ADHD, motor disabilities (where every keystroke matters), and switch / voice-control users (where every form field is a slow operation). Users with anxiety around forms may also abandon a flow when they hit redundant entry, assuming the system has lost their data.
The fix is almost always trivial — propagate session state — but it requires that form design be coordinated across steps rather than treating each step as an isolated form. Expect 3.3.7 to be flagged frequently in 2.2 audits of multi-step flows.