A customer enters a delivery address on step one of a checkout. Three steps later, the billing form shows empty fields and asks for the same address again. Most people sigh and retype it. For someone using a switch device, voice input, or who struggles with short-term memory, that second entry can be where the purchase ends.
WCAG 2.2 added a Level A criterion for exactly this: 3.3.7 Redundant Entry. It is easy to meet, easy to miss in design reviews, and it shows up in nearly every multi-step flow, from checkout to claims forms to onboarding.
What the criterion says
SC 3.3.7 requires that information a user has already entered, or was given, and has to provide again in the same process is either auto-populated or available for the user to select. Three exceptions apply:
- re-entering the information is essential
- the information is needed to protect the security of the content
- the previously entered information is no longer valid
The scope is “the same process”, meaning one multi-step task such as a checkout or an application. The criterion does not require you to store anything between sessions.
One point surprises many teams. The W3C notes that browser autocomplete alone does not satisfy this criterion. The site itself must carry the earlier answer forward or let the user pick it. Autofill is a useful extra, not the fix.
Who is affected
Retyping costs more than a few seconds for several groups:
- People with cognitive or memory disabilities, who rely less on recall when the form remembers for them.
- People who find it hard to form new memories, who cannot be expected to hold an answer in mind across several screens.
- Switch, voice and head-pointer users, for whom each extra character is slow and tiring.
- Screen reader users, who have to navigate and listen through every field again.
Where it fails in real products
These are the patterns that most often break the criterion:
- Billing and shipping. Two address blocks with no “same as delivery” option.
- Contact details. Email or phone asked on step one and again on the confirmation step.
- Cleared fields after an error. A validation failure reloads the page and wipes what the user typed, including long values like a card or policy number.
- Identifiers repeated across steps. An account, order or reference number typed in step two and requested again in step four.
- Return visits inside one process. The user goes back one step and finds the form empty.
How to fix it
Match the fix to the situation.
Offer a “same as” choice. For billing and shipping, a checkbox is the standard pattern. Keep the fields editable so people can still change them.
html
<label> <input type="checkbox" id="same-address" checked>
Billing address is the same as delivery address</label>
When the box is cleared, reveal the billing fields. When it is checked, do not make the user fill them in. Include the reveal in the tab order and make sure the change is exposed to assistive technology, for example by toggling the form group so it is no longer rendered or by hiding it properly.
Carry values forward. Store earlier answers in the form state (client-side state, session storage or the server session) and pre-fill later steps. This is the technique W3C lists as sufficient, “provide data from a previous step in a process”.
Keep input after errors. Re-render the form with what the user typed, and only flag the field that is wrong. This is also the friendliest behavior for everyone else.
Let users select rather than type. If an earlier value is needed later, such as one of several saved addresses, a select list or radio group satisfies the criterion just as well as pre-filling.
Add autocomplete tokens as a bonus. Using the correct autocomplete values such as street-address, email and tel helps browsers fill what the site asks for. It also supports SC 1.3.5 Identify Input Purpose. Treat it as an addition to the steps above, not a replacement.
When you may ask again
The exceptions are narrow, so use them honestly.
- Essential. A “confirm your email” field to catch typos, or a memory game where re-entry is the point.
- Security. Asking for a password again before a sensitive change.
- No longer valid. A coupon code that expired, or a delivery date that is no longer available.
“It was easier for our developers” is not an exception. If you are unsure, ask whether removing the repeat would weaken the process. If it would not, remove it.
How to test
You can check 3.3.7 in about ten minutes with one flow:
- Complete the process once, noting every piece of information you enter.
- Look at each later step. Is any of that information requested again? If so, is it pre-filled or selectable?
- Go back a step, then forward again. Are your answers still there?
- Trigger a validation error on purpose. Are the valid fields still filled?
- Repeat with keyboard only, then with a screen reader, to check that the “same as” control is reachable, labelled and announces its state.
If you already run pre-launch checks, add these steps to your list. Our guide to accessibility reviews before launch shows how to do that without a specialist on every release.
Where this fits with other form criteria
3.3.7 sits alongside the criteria that make forms workable end to end. Our post on accessible online forms covers labels, grouping and error handling, and WCAG 3.3.8 on accessible authentication covers the login step, where blocked paste and retyped codes create the same kind of burden. Long sign-up flows tend to hit all three at once, as in our onboarding case study.
Redundant entry is a design decision, not a technical limitation. Carry answers forward, offer a “same as” option, keep input after errors, and ask again only when you have a real reason.
If you want a second pair of eyes on a checkout, application or onboarding flow, book a call with an accessibility expert. We can walk through your forms and tell you what to fix first.