Redundant Entry: The Retyping Tax WCAG 2.2 Finally Names

Redundant entry is the criterion that names the most common checkout annoyance in plain language: a form that asks you to type the same information twice. WCAG 2.2 success criterion 3.3.7, Level A, says information previously entered by the user should be available for re-entry, unless security dictates otherwise. The metric is simple, and the failure is everywhere.

The criterion, in plain terms

WCAG 2.2 added nine success criteria and removed one, and six of the new ones are Level A or AA. Redundant entry, 3.3.7, is Level A, and it is the most human of the six: information previously entered by or provided to the user should be auto-populated or available for the user to select, unless re-entering it is essential, or the information is required for security purposes. The classic example is a checkout that asks for the billing address after the shipping address, with no copy option, and no memory of what the user just typed.

The exception is narrow. A password, a card security code, and a one-time code are information that should not be auto-populated, because re-entering them is essential for security. An address, a name, and a phone number are not security information, and the exception does not cover them. A form that hides behind security to justify asking for the address twice is a form that has not read the criterion.

The metric that makes it visible

Count the fields that ask for information the user already gave, divided by the total fields in the flow. That is the redundant entry rate, and it is the metric that makes the failure visible to a team that has never thought about it. A checkout that asks for the billing address after the shipping address, with no copy option, scores badly. A checkout that pre-fills it, or offers a same as shipping checkbox, scores zero, which is the target. The WebAIM Million 2026 report, an annual automated scan of the top one million home pages, shows that form failures are among the most common accessibility defects on the web, and redundant entry is the one that is easiest to fix and easiest to miss.

The metric also catches the multi-step form that asks for the email at account creation, then again at checkout, then again for the order confirmation. Three asks for the same information is a rate of three, and the fix is to auto-populate after the first entry. That is a day of work, and it is the cheapest accessibility fix in the whole checkout, because it is a data problem, not a design problem.

Why it matters beyond the criterion

Redundant entry is not just an accessibility failure. It is a conversion failure, because every field a shopper has to retype is a field they can abandon on. Baymard's research puts a too long or complicated checkout as a reason for abandonment, and a checkout that asks for the same information twice feels longer than it is, because the shopper notices the repetition. The shopper does not think in WCAG criteria. They think that the store is wasting their time, and they are right.

It is also a trust failure. A form that forgets what the shopper just typed is a form that does not look like it is listening, and a shopper who does not feel heard does not feel safe entering a card number. The fix is the same either way: auto-populate, offer a copy option, and stop asking for what you already have.

The test that catches it

Walk the checkout with a real order, and write down every field that asks for information you already gave. If the list is longer than zero, the flow fails 3.3.7, and the fix is to auto-populate or to offer a copy option. That is the whole test, and it takes one order to run.

Then do the same test on the account page and the returns flow, because they are often built separately and fail differently. The returns form that asks for the order number and the email, when the shopper is already logged in, is the same failure in a different flow, and the fix is the same: use what you already know.

Frequently asked questions

Which WCAG criterion covers retyping information?

WCAG 2.2 success criterion 3.3.7, Redundant Entry, Level A. It requires that information previously entered by or provided to the user is either auto-populated or available for the user to select, unless re-entering the information is essential, or the information is required for security purposes.

How do you measure redundant entry?

Count the fields that ask for information the user already gave, divided by the total fields in the flow. A checkout that asks for the billing address after the shipping address, with no copy option, scores badly. A checkout that pre-fills it scores zero, which is the target.

Is asking for the same email twice a redundant entry failure?

Yes, and it is the classic example. A checkout that asks for the email address at account creation, then again at checkout, then again for the order confirmation, is asking the user to retype the same information three times. Auto-populate it after the first entry.

What counts as an exception to redundant entry?

Security is the exception, and it is narrow. A password, a card security code, and a one-time code are information that should not be auto-populated, because re-entering them is essential for security. An address, a name, and a phone number are not security information, and the exception does not cover them.