Search topics
Checkout forms that ask for the same address twice
A two-step checkout takes the delivery address, then asks for it again as the billing address, with every field empty and nothing to reuse what was just typed.
The problem
People for whom typing is slow, tiring or error-prone have to type an address they gave a minute ago, again, from memory.
A shop's checkout has two steps. The first, Delivery, asks for a full name, a street address and a postcode. The person fills them in and presses Continue to payment. The second step asks for the card, then for a billing address: full name, street address and postcode, the same three fields, all empty. For most people the billing address is the delivery address, so they type it again, line by line, from memory or after going back a step to look.
The same thing happens across many processes:
- A guest checkout asks for an email at the start, then asks for it again on the last step to "create an account".
- A booking takes the names of everyone travelling, then asks for the lead traveller's name again on the payment step.
- A "Confirm email" field refuses paste, so the address has to be typed twice.
- A form empties itself when a card is declined, or when the person goes back a step to fix something.
Success criterion 3.3.7, Redundant Entry, is level A and new in WCAG 2.2. When a process asks again for information the person entered or was given earlier in it, that information must be either filled in already or available to select. The billing fields are neither.
The browser's autofill doesn't count. It depends on what the person's browser happens to have saved, so the site itself has to offer the earlier answer. "Available to select" is broad: a checkbox that reuses it, a choice from a list, or the value shown on the same page so it can be copied. Three exceptions apply: re-entry that is essential, as in a memory game; re-entry for security, such as confirming a new password that isn't shown; and an earlier value that is no longer valid, such as an expired card.
The criterion covers one process, not every visit. It doesn't ask a site to remember last week's address, but a process can cross pages and even domains, as a hosted payment page does.
On a phone the cost doubles: the on-screen keyboard covers half the form, and the delivery step is no longer on screen to copy from.
4 of 10 groups affected
- No vision (affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities People with memory difficulties may not recall the exact street and postcode they typed a minute ago, and each retyped line is another chance of a mistake that gets the card declined.
- Limited reach and strength People for whom each keystroke takes effort or causes pain type the whole address a second time.
- Limited manipulation People who use voice input, a switch or an on-screen keyboard dictate or pick out every character again, which is slow and easily goes wrong.
- Without vision Screen reader users can't glance back at the delivery step to check what they typed, so they retype from memory or go back a step to listen to it again.
Each page is fine on its own. Every field has a label and an autocomplete token, so axe and other scanners pass both steps. The repeat only shows to someone who goes from the first step to the second. EaseWeb's audit reports a field that asks again on the same page and refuses paste, and flags forms that ask for a billing address for a person to check, but it can't follow a checkout through. A code assistant asked to "add a billing address" adds empty fields, and asked to fix 3.3.7 it often adds autocomplete tokens, which help autofill but don't meet this criterion.
Try it
Keep the delivery address or change it, then choose Continue to payment.
On the payment step, look at what the billing address asks of you. The panel under the form counts the lines you would type again.
Broken Can you fix this?
The fix
Reuse what people already gave: a ticked same-as box, or the fields filled in.
- 1Never leave a field empty for a value given earlier in the same process.
- 2Reuse it with a ticked same-as box, fill it in, or at the least show it on the same page.
- 3Never block paste, and keep entered values after going back and after an error.
<!-- Step 2 of 2: Payment --><fieldset> <legend>Billing address</legend> <label for="bill-name">Full name</label> <input id="bill-name" name="bill-name" autocomplete="billing name"> <label for="bill-street">Street address</label> <input id="bill-street" name="bill-street" autocomplete="billing street-address"> <label for="bill-postcode">Postcode</label> <input id="bill-postcode" name="bill-postcode" autocomplete="billing postal-code"></fieldset>A same-as-delivery checkbox, ticked by default
<label> <input type="checkbox" id="billing-same" name="billing-same" checked aria-describedby="delivery-address"> Billing address is the same as delivery address</label><p id="delivery-address">Sam Rivera, 12 Elm Street, AB1 2CD</p><fieldset id="billing" hidden disabled> <legend>Billing address</legend> <label for="bill-name">Full name</label> <input id="bill-name" name="bill-name" autocomplete="billing name"> <label for="bill-street">Street address</label> <input id="bill-street" name="bill-street" autocomplete="billing street-address"> <label for="bill-postcode">Postcode</label> <input id="bill-postcode" name="bill-postcode" autocomplete="billing postal-code"></fieldset>The fields are labelled and declare their purpose, so they pass 1.3.5. But the delivery address from step 1 is nowhere on this page: not in the fields, not as a choice, not even as text to copy.
People whose billing address matches have nothing to type: the box is already ticked, and the address it reuses is shown beside it and read with it. People whose address differs untick it and get empty fields, which is new information, so 3.3.7 doesn't apply to it. While the box is ticked the fieldset is hidden and disabled, so its fields are skipped by Tab, by screen readers and by the browser's validation, and none of them is sent. On the server, a ticked box means the delivery address.
All three pass 3.3.7. Use the ticked checkbox: people whose addresses match, who are usually most, have nothing to type or check, and people whose addresses differ get empty fields rather than a copy to clear field by field. Fill the fields in when the design can't take another control, or when the two addresses tend to differ in only one line, such as a company name. Showing the address to copy is a first step for a payment form whose fields you can't change but whose page you can; replace it with one of the other two when you can.
Keep a process's answers on the server, in the checkout session, not only in the page's script. Then a reload, the Back button or a failed submission doesn't lose them, and every later step can read from the same record instead of asking. After a declined card, keep everything but the card's security code, which may be asked again for security.
A "Confirm email" field asks for the same address twice. It passes 3.3.7 only while paste works, since the first answer is on the same page to copy. It is better to remove it, and to show the address back on the review step with a link to change it. A field that cancels paste fails, and EaseWeb's audit reports one that asks again and refuses an empty test paste. Confirming a new password is allowed under the security exception, but blocking paste there fails 3.3.8; offer a "Show password" button instead of the second field where you can.
When a process has more than one earlier answer to offer, such as several recipients' addresses, offer them as radio buttons with "A different address" as the last choice. That is available to select, as a checkbox is.
Keep the autocomplete tokens on every field, with the billing and shipping prefixes. They don't meet 3.3.7, but they let autofill fill the fields when someone does give a different address; see form fields that block or break autofill.
When the checkbox hides the fields, disable them too. A hidden required field that isn't disabled still blocks the submission, and the browser can't move focus to it to say why.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
6 checks, no mouse.
Test with: Keyboard, Screen reader, Touch
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the checkout's steps or its shared form components change.
Limits
This is a starting pattern, not a guarantee for every process. The example is a two-step checkout; sign-up flows, bookings and applications need the same walk-through, step by step. Payment fields inside a provider's frame are the provider's to fix, but the page around them is yours. The criterion doesn't require remembering details between visits, and saved addresses are a separate feature with their own privacy questions. Test the complete process with the people and tools your users rely on.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.