Skip to content
Pandus

WCAG 3.3.7 Redundant Entry

Updated October 14, 2026 · 3 min read

Level
A · WCAG 2.2 (new in 2.2)
EN 301 549
9.3.3.7 Only in V4.1.1 (WCAG 2.2); the harmonised V3.2.1 does not contain it yet.
What the checker tests
Manual review: an automated tool cannot check this criterion reliably.
Official text
Understanding 3.3.7 Redundant Entry (W3C, in English)

Success criterion 3.3.7 is new in WCAG 2.2. It reduces the effort of multi-step forms for people with cognitive disabilities, memory difficulties and motor disabilities, for whom every field typed again is extra work and an extra chance of error. In a shop, the classic case is checkout: delivery address, billing address, contact details. It is level A and appears in EN 301 549 as clause 9.3.3.7.

What the criterion requires

Information previously entered by or provided to the user that is required again in the same process must be either:

  • auto-populated, or
  • available for the user to select.

A process is a series of user actions where each action is required to complete an activity, such as checkout or registration. A process can span several domains, for example a shop and a third-party payment page.

Exceptions — re-entry may be required when:

  • re-entering the information is essential;
  • it is required to ensure the security of the content (for example, typing a new password twice);
  • the previously entered information is no longer valid.

W3C notes that browser autocomplete is not sufficient on its own, and that the criterion does not require storing data between sessions.

Typical failures on an online shop

  • the billing address must be typed again even though it is the same as the delivery address;
  • the email entered in step 1 of checkout must be typed again in step 3;
  • after a validation error, the form is cleared and all fields must be filled in again;
  • a returns form asks for the order number the customer just selected on the previous screen;
  • a search term or filter selection is lost when the user moves to the next page of results in the same task.

How to check it

Automated: our checker has no rule for this criterion. It does not walk through multi-step processes, so this needs a manual check.

By hand: complete the checkout, registration and returns flows with test data. Note every field you are asked for. Whenever the same information is asked for twice in one flow, check whether it is pre-filled or offered as a choice. Trigger an error on purpose and confirm your entries are kept.

How to fix it

  • Add a "Billing address is the same as delivery address" checkbox, ticked by default where it makes sense.
  • Carry data between steps (email, name, address) and show it pre-filled but editable.
  • Keep the user's entries when validation fails.
  • Offer saved addresses as a list to select from within the same flow.

Frequently asked questions

Is a "billing address same as shipping" checkbox enough?

Yes, W3C gives it as an example. The user can confirm the address is the same instead of typing it again.

Does browser autofill satisfy 3.3.7?

No. W3C says browser autocomplete is not sufficient, because the site itself must auto-populate the data or make it available to select.

Do I have to remember data between visits?

No. 3.3.7 applies within one process, such as a single checkout. It does not require storing information between sessions.

When may I ask for the same information again?

When re-entering it is essential (for example, a memory game), when it is needed for security (such as confirming a new password), or when the earlier information is no longer valid.