Redundant entry (WCAG 3.3.7) in multi-step forms
You enter your delivery address and click “Continue.” The billing step opens with another set of empty address fields. Your billing address is the same, but there’s no way to use the address you already entered. If you miss the postal code, the form also clears the street you just typed.
When a form needs the same information again within one process, WCAG 2.2’s Redundant Entry criterion (3.3.7, Level A) requires the site to fill it in or make it available to select, subject to three exceptions. A “Use the delivery address for billing” checkbox is one way to do that. Keep that choice and the entered values as people move between steps or correct an error.
When does a form ask for information twice?
Follow the task from start to finish. Look for information the person already entered or that the site already gave them. A checkout might ask for a delivery address again at billing. An application might give the applicant a reference number and ask them to enter it on the next screen. A form can also force repeat entry by clearing valid fields after a validation error.
The rule follows the same process. A payment page on a different domain can be part of the same checkout. WCAG 3.3.7 places no requirement on saving data between sessions. Re-entry is allowed when it is essential, needed to ensure the security of the content, or the information is no longer valid. W3C explains the scope and exceptions.
Reuse the delivery address at billing
When billing usually uses the delivery address, offer a labelled checkbox. Show the resulting address on the review step and give people a way to change it. When they uncheck the box, show the separate billing fields after it in the tab order. Keep focus on the checkbox so they can continue with Tab. If they already entered a separate billing address, restore it.
An editable prefilled field works when there is one likely value. An address picker can work when the person has several addresses to choose from. Make each option distinguishable and show which one is in use. W3C describes ways to provide earlier entries.
Browser autofill can help with the first entry. A token such as autocomplete="shipping postal-code" identifies a field’s purpose. To reuse an address from this checkout, the site itself needs to provide that address or avoid asking for it again. See the guide to labels and input purpose for the role of autocomplete in WCAG 1.3.5.
Keep valid entries when people go back or correct an error
Keep the values and the billing choice in the checkout’s draft. While reuse is selected, use the latest delivery address as the billing address. Test what happens when someone goes back to change it. If they chose a separate billing address, editing the delivery address should leave it alone.
Derive the address for review and submission from that choice:
const billingAddress = useDeliveryAddress ? deliveryAddress : separateBillingAddress;
The same principle applies to email. Show the entered address on the review step and offer “Edit email address.” If a postal code is missing, keep the street address and let the person correct just the missing field. The GOV.UK check answers pattern shows how to make a value easy to review and change.
Try the two versions of this fictional three-step checkout. Start with “Fill in sample details.” At billing, try reusing the delivery address, or enter a separate street and leave the billing postal code empty.
Before: enter the same details again
After: reuse details from this checkout
Compare what happens in each version:
- Billing address. Before, there was no reuse option. After, Space toggled the checkbox, and the review step showed the delivery address. After going back to edit that address, review showed the updated value.
- Validation. Before, a missing billing postal code cleared the billing street. After, the street stayed in place and the error link took focus to the postal code.
- Email. Before, the form required a second email entry on the review step. After, it showed the existing email, offered an edit control and let the person finish without typing it again.
In a manual check of the German teaching example, VoiceOver read the billing error summary and the messages for the street address and postal code after an empty submission. During navigation, VoiceOver identified the buttons and focus followed the form as expected. VoiceOver also announced the current step when reading the step list.
Give each step a heading and a clear focus target
When “Continue” replaces one step with another on the same page, try moving focus to the new step’s heading. Give that heading tabindex="-1" and focus it after the new content renders. That makes it possible to focus the heading from code while keeping it out of the normal Tab sequence. Check where the next Tab goes and whether the heading remains visible. WCAG 2.4.3 describes the focus-order requirement.
If validation keeps the person on the same step, focus the error summary if the form uses one. Let its links take them back to the fields they need to correct. Try the pattern in Making form error messages clear and accessible.
Mark the current step and show progress
Give the heading a name such as “Billing (step 2 of 3).” On a multi-page form, include the step in the page title too. If the page shows a list of steps, use an ordered list and mark the current item with aria-current="step". For example:
<ol aria-label="Checkout steps">
<li>Delivery</li>
<li aria-current="step">Billing</li>
<li>Review</li>
</ol>
W3C describes progress in the multi-page forms tutorial and defines the current-step marker in WAI-ARIA. When a screen reader reaches the step list, the marker can identify the current item. For a successful transition, check what the heading communicates when it receives focus. If the page instead keeps focus in place and adds a separate progress message, check whether that message is conveyed as a status update. The status messages guide shows how to test that pattern.
Check the path from delivery to review
- Start with a fresh checkout. Make a note of what the site asks for and what information it gives you.
- Try billing with the delivery address and with a different one. Check what appears on the review step in each case.
- Trigger a validation error. Follow the error link with the keyboard, correct the field and see which other values stayed in place.
- Use the form’s Back control and browser Back where supported. Change the delivery address and check the review step again.
- Repeat with a screen reader. Record where focus lands, what you hear after “Continue,” and how the current step is conveyed when you read the step list.
Scan the initial page and the states you reach after continuing, going back and submitting an error. Record the states the scan actually reached. Automated findings can point to issues such as a missing label on a later step. To assess 3.3.7, walk through the process and check whether the same information is required again and how the site makes it available. See navable Audit and the website testing guide.