A common accessibility failure hides inside otherwise polished products. A customer enters a shipping address on one checkout step, reaches billing, and has to type the same address again. A candidate fills out a multi-step job application, then re-enters contact details on the review screen. An employee completes a benefits form, moves to the next step, and finds that previously entered information wasn’t carried forward.
Teams often treat that as a minor UX annoyance. It isn’t. It creates avoidable friction in high-intent flows, and under WCAG 2.2 it can also create a clear compliance problem when the process forces users to manually repeat information without an allowed exception. For product leaders, this is a conversion issue. For legal and compliance teams, it’s a preventable Level A failure. For engineering, it’s usually fixable with straightforward design and session-handling decisions if it’s caught early enough.
Why Redundant Entry Is a Conversion Killer and a Legal Risk
The fastest way to lose a user in a form is to make them feel the system isn’t paying attention. If someone already gave you their name, email, address, or account details during the same process, asking them to type it again adds drag at the worst possible moment. That’s especially damaging in checkout, onboarding, claims, healthcare intake, and financial workflows where users are already balancing complexity, time pressure, and trust concerns.
This is more than convenience. Repetitive entry can create a real barrier for users with cognitive disabilities, memory limitations, attention-related impairments, and motor impairments. Re-typing the same data increases effort, increases the chance of mistakes, and turns a manageable task into a frustrating one.
Practical rule: If the user already told the system something in the same activity, the default assumption should be reuse, not repetition.
The legal angle matters because WCAG 3.3.7 Redundant Entry is a Level A success criterion in WCAG 2.2. That means this isn’t an edge-case enhancement or an aspirational UX improvement. It sits in the basic conformance layer, which makes it harder to dismiss during audits, procurement reviews, and dispute response.
The costly part is that redundant entry failures often cross team boundaries. Product may approve the flow, design may document the screens, engineering may build each step correctly in isolation, and QA may validate the fields. Yet the process still fails because nobody tested the full workflow from a user’s perspective. That’s why these issues frequently survive to production and why manual accessibility review catches problems that field-level checks don’t.
What Is WCAG 3.3.7 Redundant Entry
WCAG 3.3.7 Redundant Entry says that when users enter information once during the same activity, they shouldn’t be forced to enter it again unless a specific exception applies. The formal requirement in the W3C understanding document is direct: previously entered information that must be entered again must be either auto-populated or available for the user to select, with exceptions for cases where re-entry is essential, needed for security, or when the previous information is no longer valid in W3C’s WCAG 2.2 understanding for Redundant Entry.
The rule in plain English
Imagine a competent assistant. If you already gave them your contact details earlier in the conversation, they don’t ask you to repeat everything from scratch two minutes later. They either remember it, or they show it back to you so you can confirm it.
On the web, that usually means one of two implementation patterns:
- Auto-populate the repeated field so the user can review and edit if needed.
- Offer a direct selection mechanism such as “Use shipping address for billing” or “Use saved contact details.”
The W3C explanation also points teams toward a useful implementation detail. If information is made available for selection, it should ideally appear on the same page and be closely associated with the field. That’s a practical design standard, not just a legal one.
Where teams get the scope wrong
The most common misunderstanding is treating this as a browser problem. It isn’t enough to hope browser autocomplete fills the gap. The product itself must provide the reuse mechanism when the same information is requested again in the same process.
Another mistake is stretching the exceptions too far. The exceptions are narrow:
- Essential means re-entry is required by the nature of the task.
- Security covers cases like confirming a new password or other protective checks.
- No longer valid applies when the earlier value can’t safely be reused.
A review screen that repeats contact fields for editing isn’t a failure if the earlier values are already present or easy to select. A blank screen that asks the user to type everything again usually is.
Success and Failure Examples in Practice
Compliance becomes much easier when teams stop treating this as an abstract standard and start mapping it to actual user journeys. The same rule can look obvious in one flow and invisible in another.
Checkout and billing flows
The classic failure is an eCommerce checkout that collects shipping details and then presents an empty billing address form on the next step, even when the addresses are often the same. That forces manual repetition in the same transaction.
A compliant pattern is familiar because it works. The billing step includes a checked-by-default or clearly visible option such as “Billing address is same as shipping,” and selecting it fills the address fields or lets the user choose the prior address. The user can still edit if needed, but they aren’t forced to start over.
A simple comparison makes the distinction clearer:
| Flow | Failure pattern | Better pattern |
|---|---|---|
| Checkout | Blank billing fields after shipping step | “Same as shipping” option with populated values |
| Donation form | Donor enters contact info, then retypes on payment step | Payment step reuses entered contact data |
| Event booking | Attendee details entered, then blank review form repeats fields | Review step shows saved values for confirmation |
Registration and account management
Multi-step registration flows often fail on summary screens. A user enters name, email, phone, and organization on early steps. The final step asks for the same information again because the development team modeled the summary page as a new form instead of a review state.
A compliant version does one of two things well. It either displays the previously entered values inline with edit controls, or it pre-fills the final form fields using the earlier entries.
Here are patterns I’d flag quickly in an audit:
- Likely failure: A loan application asks for employer information on step one, then asks for the same employer fields again on step three without prefill or selection.
- Usually acceptable: A password reset flow requires a new password to be entered again for confirmation because the second entry serves a security purpose.
- Needs scrutiny: A profile editor asks for a phone number again because the system failed to preserve session data between steps. That’s often an implementation defect, not an exception.
Teams should review the whole task, not each page separately. Redundant entry failures often live in transitions between steps.
How to Test for Redundant Entry Compliance
Automated testing helps with many accessibility checks, but WCAG 3.3.7 redundant entry is mainly a workflow problem. You have to move through the process as a user would and observe whether the product reuses information appropriately. That’s why this criterion belongs in manual QA, design review, and accessibility audit scope.
A useful starting point is this visual checklist.
A manual test that actually works
Run the test on every multi-step activity, not just on forms that look complex.
- Map the activity
Identify complete user flows such as checkout, account creation, application submission, support intake, onboarding, and profile updates. - Track data points
As you complete the flow, note each piece of user-supplied information. Focus on names, addresses, phone numbers, email addresses, account identifiers, and preference selections. - Look for repeated requests
When the same information appears later in the activity, ask one question. Does the product auto-populate it or make it available for the user to select? - Check for an allowed exception
If the answer is no, determine whether the re-entry is essential, security-related, or required because the previous data is no longer valid. - Document the exact step transition
Don’t write “checkout has redundant entry.” Write “Shipping address entered on step two is requested again as empty billing fields on step three.”
Later in the review, compare your findings with other testing methods. A good reference point is this roundup of accessibility testing tools and where they help, especially if your team is relying too heavily on scanner output.
After the checklist, validate the behavior with real interaction.
Why scanners miss this issue
Most automated tools inspect pages, code patterns, labels, ARIA usage, contrast, and structural errors. They don’t reliably understand that a user entered a mailing address on step one and had to manually repeat it on step three in the same activity.
That limitation matters in procurement and legal review. A clean automated scan doesn’t tell you much about transaction usability. Teams that only run scanners often miss process-level failures, then get surprised when a manual auditor flags the form flow as nonconforming.
Use this quick audit note when triaging findings:
- High priority: Repeated entry in checkout, payment, healthcare, government, or employment flows.
- Moderate priority: Repeated entry in lower-risk profile or preference updates.
- Still worth fixing: Repeated entry in internal enterprise tools, especially when employees complete forms regularly.
Remediation Patterns and Code-Level Solutions
The best fixes are boring in a good way. They reduce user effort, align with existing product patterns, and don’t introduce clever but fragile behavior. If you need a rule of thumb, preserve data once, reuse it intentionally, and always leave the user in control.
Reliable UX patterns
The strongest pattern is often the simplest one on the screen:
- Same-as controls: “Billing address is same as shipping” remains one of the clearest ways to let users reuse prior data.
- Review and edit screens: Show the information already captured, then let users edit specific fields instead of re-entering everything.
- Saved selections: In authenticated experiences, let users choose from previously entered values that are relevant to the current task.
If your form design is already struggling with labeling, grouping, or repeated prompts, solve those problems at the same time. Redundant entry often appears alongside other form defects, and guidance on form field labeling issues such as multiple labels can help teams clean up the broader interaction model.
Good remediation doesn’t just satisfy the criterion. It makes the form feel calmer and more predictable.
Client-side and server-side implementation options
For lightweight multi-step forms, client-side persistence can work well during a single session. sessionStorage is often a practical choice when you want values to survive navigation between steps but not persist indefinitely.
<label for="shippingAddress">Shipping address</label>
<input id="shippingAddress" name="shippingAddress" />
<label>
<input type="checkbox" id="sameAsShipping" />
Billing address is same as shipping
</label>
<label for="billingAddress">Billing address</label>
<input id="billingAddress" name="billingAddress" />
<script>
const shipping = document.getElementById('shippingAddress');
const billing = document.getElementById('billingAddress');
const same = document.getElementById('sameAsShipping');
shipping.addEventListener('input', () => \{
sessionStorage.setItem('shippingAddress', shipping.value);
if (same.checked) billing.value = shipping.value;
\});
same.addEventListener('change', () => \{
if (same.checked) \{
billing.value = sessionStorage.getItem('shippingAddress') || '';
\} else \{
billing.value = '';
\}
\});
window.addEventListener('load', () => \{
const saved = sessionStorage.getItem('shippingAddress');
if (saved) shipping.value = saved;
\});
</script>For regulated workflows, authenticated products, or anything involving sensitive state management, server-side session handling is usually more dependable. The server stores the earlier values for the current activity and renders later steps with the known data already available. That approach tends to be more resilient across devices, page refreshes, validation cycles, and partial saves.
Choose the implementation based on risk and architecture:
| Approach | Best fit | Common risk |
|---|---|---|
| Client-side session storage | Simple multi-step public forms | Data loss if the script fails or state handling is incomplete |
| Server-side session state | Checkout, healthcare, fintech, enterprise apps | More engineering coordination across backend and frontend |
| Database-backed draft save | Long applications and authenticated workflows | Overbuilding when a simpler session solution would work |
Implications for Product Legal and VPAT Reporting
This criterion sits at the intersection of usability, conformance, and documentation. Product teams influence whether the flow is smooth. Legal and compliance teams care whether the issue creates exposure. Procurement teams want accurate reporting that doesn’t overstate support.
What each team should own
Product should treat redundant entry as a workflow defect, not a copy tweak. If a key form asks users to repeat data, the team should capture that in acceptance criteria and user journey testing.
Legal and compliance should pay attention because Level A failures are hard to defend when they appear in public-facing transaction flows. The risk gets more complicated when form design intersects with privacy, consent, and recordkeeping requirements. For teams reviewing data practices alongside accessibility, Formbricks has a practical summary of latest GDPR compliance requirements that helps frame how form handling choices affect broader compliance obligations.
Procurement and sales engineering should make sure accessibility claims match actual behavior. If the product supports the criterion only in some flows, the documentation should say that plainly.
VPAT wording you can actually use
A vague VPAT entry creates procurement friction fast. Use language that maps to observed behavior.
If the product supports the criterion across relevant multi-step activities:
Supports. In multi-step processes, information previously entered by the user is auto-populated in subsequent steps or made available for selection when requested again within the same activity, except where re-entry is essential, required for security, or the prior information is no longer valid.
If support is partial:
Partially Supports. Some multi-step workflows reuse previously entered information through prefilled fields or user-selectable options. Other workflows require manual re-entry of information previously provided in the same activity. Remediation is needed in identified transaction flows.
If the product does not support the criterion:
Does Not Support. In one or more multi-step processes, users are required to manually re-enter information previously provided in the same activity without an available auto-population or selection mechanism, outside allowed exceptions.
If your team is budgeting for documentation, review what affects VPAT cost and scope before promising turnaround dates to customers or government buyers.
Frequently Asked Questions About WCAG 3.3.7
Is browser autocomplete enough
No. Browser autocomplete may help some users, but it isn’t the same as the product providing the information again within the same activity. The safer interpretation is that the site or application needs its own reuse mechanism.
How is this different from other form-related WCAG requirements
This criterion focuses on whether users must repeat information they already supplied during the same process. It is not the same as error identification, label quality, or error prevention. A form can have excellent labels and still fail if it needlessly asks users to type the same information twice.
When is re-entry allowed
Re-entry can be acceptable when it is essential to the task, required for security, or necessary because the prior value is no longer valid. Password confirmation is the easiest example of a security-related exception. Teams shouldn’t treat convenience or technical debt as an exception.
If the real reason for re-entry is “we didn’t persist the state,” that’s usually a bug, not a defense.
Does a review page violate the criterion
Not by itself. Review pages are often good accessibility practice because they let users confirm what they entered. The problem starts when the review page turns into a blank re-entry form rather than showing stored values with edit options.
What should QA write in a defect
Be precise. Name the activity, step, field, and expected behavior. For example: “During account creation, the email address entered on step one is requested again as an empty field on step three. Expected result: the email should be prefilled or available for selection unless an exception applies.”
How should this affect an ADA compliance program
It should change how teams scope testing. Don’t isolate accessibility to single screens or component libraries. Include complete user journeys, especially high-risk transactions and form-heavy flows. That’s where Level A failures often hide, and it’s where legal exposure and lost business tend to overlap.
A practical program also treats this as cross-functional work. Product writes the requirement, design exposes the reuse pattern, engineering persists the data, QA tests the entire activity, and compliance validates the outcome. If any one of those handoffs fails, redundant entry issues slip through.
If your team needs a defensible review of form flows, checkout paths, or VPAT language, ADA Compliance Pros can help with manual accessibility audits, remediation guidance, and procurement-ready documentation grounded in real testing.