Don’t Make Shoppers Re-Enter Information: WCAG 2.2’s Redundant Entry Rule for E-Commerce Checkout

Quick answer: WCAG 2.2’s SC 3.3.7 Redundant Entry (Level A) says information a user already entered or was already given, and that’s required again later in the same process, must be either auto-populated or made available for the user to select — not re-typed from memory. It applies unless re-entry is essential, needed for security, or the earlier information is no longer valid. For e-commerce checkout, the W3C’s own worked example is a “same as shipping” billing-address checkbox — exactly the pattern most sites already have, and the one most get subtly wrong.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.2 Level A requires and how to meet it, not whether a specific site carries legal risk.

SC 3.3.7 Redundant Entry (Level A), in the W3C’s own words

The Understanding doc states the criterion directly:

Information previously entered by or provided to the user that is required to be entered again in the same process is either: auto-populated, or available for the user to select.

Three exceptions:

1. Essential — re-entry is inherent to the task (the doc’s own example: a memory game that would be pointless if previous answers were pre-filled).
2. Security — a password shouldn’t be auto-displayed or auto-copied, and requiring a user to type a new password twice to confirm it (since the system itself can’t validate an unseen string) is allowed.
3. No longer valid — if the previously entered information has expired or changed, asking again is fine.

The stated goal is cognitive load, not convenience: “some people with cognitive disabilities have difficulty remembering what they entered before,” and the Understanding doc notes that “all users experience a natural gradual mental fatigue as they proceed through steps in a process” — a multi-step checkout is exactly that kind of process.

One clarification worth sitting with, because it’s easy to get backwards: browser autofill does not satisfy this criterion. The Understanding doc is explicit about why — “the autocomplete feature of browsers is not considered sufficient because it is the content (the website) that needs to provide the stored information for a redundant entry.” SC 3.3.7 is a requirement on the site’s own logic, not a pass because a browser happens to remember what a shopper typed last time.

The e-commerce example is the W3C’s own, not ours

The Understanding doc’s Examples section gives this scenario directly, described exactly as an e-commerce pattern:

A form on an e-commerce website allows the user to confirm that the billing address and delivery address are the same address.

And Technique G221 (Provide data from a previous step in a process), one of the criterion’s own listed sufficient techniques, gives the implementation as its first worked example:

An e-commerce site provides a checkbox that triggers the shipping address to be pre-populated based on the billing address the user had entered in a previous step.

That’s a checkbox nearly every checkout flow already has. The failure mode isn’t usually “we don’t have this feature” — it’s a checkbox that’s visually present but broken for the users this criterion protects: unlabeled (a screen reader announces “checkbox, not checked” with no indication of what it does), or one that toggles a visual copy of the address text without actually populating the underlying form fields, so a keyboard or screen reader user who unchecks it later finds empty fields instead of their real data.

A working pattern:

<fieldset>
  <legend>Delivery address</legend>
  <!-- delivery address fields: ship-address, ship-city, ship-zip, etc. -->
</fieldset>

<fieldset>
  <legend>Billing address</legend>
  <label>
    <input type="checkbox" id="billing-same-as-shipping" checked>
    Billing address is the same as delivery address
  </label>

  <div id="billing-fields" hidden>
    <label for="bill-address">Street address</label>
    <input type="text" id="bill-address" name="bill-address" autocomplete="billing street-address">
    <!-- remaining billing fields -->
  </div>
</fieldset>

const sameAsShipping = document.getElementById("billing-same-as-shipping");
const billingFields = document.getElementById("billing-fields");

function syncBilling() {
  billingFields.hidden = sameAsShipping.checked;
  if (sameAsShipping.checked) {
    // Copy real values into the billing inputs, not just hide them --
    // the fields still need to hold the correct data for form submission.
    document.getElementById("bill-address").value = document.getElementById("ship-address").value;
    // ...repeat for each paired field
  }
}

sameAsShipping.addEventListener("change", syncBilling);
syncBilling();

The checkbox has a real <label> (satisfies SC 4.1.2 Name, Role, Value on its own), and — critically for 3.3.7 — the billing fields are actually populated with the shipping values, not merely hidden. If the user later unchecks it to enter a different billing address, they see the pre-filled values they can edit, not a blank form asking them to retype an address they already gave. This is the same autocomplete token approach covered in our form labels and error messages article (SC 1.3.5) — that article covers identifying each field’s purpose so browsers and password managers autofill correctly; this criterion is about the site itself carrying data from one step to the next, which is a different (and, per the Understanding doc above, non-substitutable) requirement.

Checkout errors: don’t clear the form on a mistake

The Understanding doc’s second relevant example is just as common a checkout failure:

A user submits a checkout form with an incorrect credit card number in it. The page updates, showing an error message. Submitted information, such as credit card number, is not cleared from the form.

This is the flip side of error handling covered in our checkout error-identification guidance (SC 3.3.1) — that article is about describing the error in text; this criterion is about not punishing the correction by wiping out everything else the shopper already typed. A checkout page that clears the entire card form (or worse, the whole checkout form) after a single failed field forces a full re-entry for one typo — a disproportionate cost for users with memory or motor impairments, and a straightforward way to lose a sale for everyone else.

The fix is unglamorous: on a server-side validation failure, re-render the form with every previously submitted value intact except the field(s) that actually need correcting. This is usually a template/state-management detail rather than new markup, which is likely why generic accessibility checklists skip it — but it is a genuine WCAG Level A requirement.

Multi-step checkout and third-party payment providers

The same rule applies across a shipping → payment → review flow, not just within one form — a name or email collected at step one shouldn’t be re-requested blank at step three. The Understanding doc frames “process” broadly enough to include this, and explicitly extends it past your own domain:

A process is defined on the basis of an activity and is not applicable when a user returns after closing a session or navigating away. However, a process can run across different domains, so if a check-out process includes a 3rd party payment provider, that would be in scope.

Handing off to a third-party payment processor doesn’t exempt the checkout from this criterion. If the provider’s embedded form re-asks for a name, email, or address already collected on the merchant’s own pages, that’s still a redundant-entry failure from the shopper’s perspective — worth checking directly with a payment integration rather than assuming an iframe boundary is also a scope boundary.

Three things this criterion doesn’t require

• Storing data between sessions. A returning shopper starting a new order isn’t owed pre-filled fields from a prior order under this criterion — persistent address-book features are a product choice, not a WCAG requirement.
• Password fields. The Understanding doc is explicit: “This success criterion does not impact Accessible Authentication (Minimum), for which allowing auto-filling of passwords is a sufficient technique.” Login and OTP entry are governed by WCAG 2.2’s SC 3.3.8 instead.
• Uploaded documents. If a user provides information by uploading a file, this criterion doesn’t apply to that data.

FAQ

Does relying on browser autofill satisfy SC 3.3.7? No. The Understanding doc is explicit that browser-level autocomplete “is not considered sufficient” — the site itself has to carry the data forward, whether by auto-populating a field or offering it as a selectable option (like a checkbox).

Is asking a user to type their password twice to confirm it a violation? No — that’s the security exception, named directly in the Understanding doc: since the system can’t validate a password it isn’t allowed to store or display in plain text, requiring re-entry to confirm a new one is permitted.

What’s the fastest fix if I can only do one thing? Fix the billing/shipping checkbox so it actually copies field values instead of only hiding the billing section visually — it’s the criterion’s own named e-commerce example, it’s usually already half-built, and it’s a JavaScript fix rather than a new feature.

An automated scan won’t catch most of this

A scanner can confirm a checkbox has an accessible name. It can’t tell you whether checking it actually populates the underlying billing fields, whether a failed checkout submission wiped a shopper’s card-number entry, or whether a third-party payment iframe re-asks for an email address already collected on your own page — all of that requires actually running the flow and watching what happens to the data, not just parsing the DOM. That gap is why Quietramp pairs an automated scan with a manual review pass that walks through flows like checkout end to end. See a sample report or check pricing — $890 for a one-time audit, $99/month for ongoing re-checks after fixes ship.

---

This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.2 does not guarantee legal compliance with the ADA or any other law. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.