Skip to main content
WCAGrules
Quick navigation
3.3.7Level AUnderstandableNew in WCAG 2.2

Redundant Entry

New in WCAG 2.2, and it says you cannot make somebody type the same thing twice inside one process. Either fill it in for them, or put the earlier answer somewhere on the same page where they can pick it up. It covers information you gave them as well as information they gave you, so a reference number you issued counts. The scope is the process rather than the session, and a process can cross domains, so a checkout that hands off to a payment provider is still one process. Three exceptions lift the duty. Where re-entering is essential to what the thing is, such as a memory game. Where the re-entry is what keeps the content secure, which is why confirming a new password is allowed. And where the earlier answer is no longer valid.

Why it matters

For most people, retyping an address is an eye-roll. For somebody using switch control or voice input it is the whole job again, and there is no shortcut through it. W3C names the mechanism plainly, which is that people tire as they move through a process, and that holding something in working memory so it can be retyped makes them tire faster. Users with memory impairments may not have the earlier answer to give back at all, since they cannot see what they typed the first time. Your session already knows the answer. Asking for it again is asking somebody to pay for your convenience.

Who this rule protects

People with motor disabilities, including anybody using switch control or voice input, pay for every keystroke twice. People with memory and cognitive disabilities have to rebuild an answer they already gave, sometimes with no way to check what it was. And anybody deep in a long process is more tired at step five than at step one, which is exactly when the form asks them to do it all again.

How to check it yourself

  1. Complete a multi-step flow yourself and write down every field that asks for something you already entered in that flow.
  2. Check the site supplies the answer, through a prefilled value or a same-as option, rather than leaving it to the browser. Browser autofill does not count here, and that is the commonest way to test this rule and get it wrong.
  3. If the answer is offered to select rather than filled in, check it is on the same page as the field. Telling somebody their details are on their account page does not satisfy this.
  4. Submit a form with one bad field and see what comes back. Clearing the entries that were correct is a failure of this rule, and it is W3C's own worked example of one.
  5. Leave the real exceptions alone. Confirming a new password, re-entering something that has since expired, and anything where retyping is the point are all excepted.

Failures we see most often

  • The billing address is demanded from scratch right after the shipping address, with no same-as option anywhere on the page.
  • A validation error clears the whole form, so the four fields that were right get typed again along with the one that was wrong. That is W3C's own example of this failure, and everybody reading this has met it.
  • A checkout hands off to a third-party payment page that asks for the address again. Different domain, same process, still in scope.
  • A multi-step quote wizard asks for the same email address a third time before it will finish.
  • The search results page comes back with an empty search box, so refining the search means retyping it.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

How to fix it

  • Add a same-as-shipping checkbox and carry the confirmed values forward through the rest of the flow.
  • Prefill from what the process already holds, and leave the value editable rather than locking it, since prefilled is not the same as final.
  • Keep every field the user got right when a submission fails, and mark only the one that needs attention.
  • Where you cannot prefill, put the earlier answer on the page and let it be selected, from a dropdown, a checkbox, or text the user can copy. It has to be on the same page as the field that needs it.
  • Store as little as you can and drop it when the process ends, because there is no exception here for personal data and a careless implementation of this rule leaks more than it saves.
Step-by-step fix guides (1)

Passes vs. fails

A general illustration of the pattern rather than a test of 3.3.7. Passes: one tap fills it correctly. Fails: autofill is locked out.

Passes

The billing address carries a Same as shipping checkbox, so a buyer whose addresses match never types the second one.

Fails

The buyer types their shipping address on step 2, and step 3 shows an empty billing address form asking for the identical information again.

In audits and lawsuits

This is a WCAG 2.2 addition, so it dates any audit written before the criterion existed. We find it most in checkout address flows and multi-step quote wizards. A same-as-shipping checkbox is one of the most conversion-positive fixes on any of our lists, because it removes work at the exact moment somebody is deciding whether to pay. One trap catches nearly everybody. Browser autofill does not satisfy this rule. The duty sits on the site to supply the previous answer, not on the user's browser to remember it. That is the clean line between this rule and 1.3.5, which is only about marking fields so a browser can fill them. A form can pass 1.3.5 perfectly and fail this one. There is no automated rule here either.

Go somewhere useful

Find tools, resources and your workspace.

29 destinations