Avoid redundant data entry and meet WCAG Success Criterion 3.3.7 (Redundant Entry). This guide explains how to avoid common conformance mistakes and build more inclusive multi-step forms, plus tips, fixes, and real-world testing advice for dev and QA teams.
WCAG Principle: Understandable
Guideline 3.3: Input Assistance (Help users avoid and correct mistakes)
Conformance Level: A (Minimal Requirement)
What is Success Criterion 3.3.7 (Redundant Entry)?
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.
Except when:
- re-entering the information is essential,
- the information is required to ensure the security of the content, or
- previously entered information is no longer valid.
This success criterion ensures that users don’t have to type the same information twice during a multi-step process, unless there’s a valid reason.
For example, if a user provides their name, ID or address in step 1, they should not have to input the same details in step 3. Instead, the webpage should auto-fill it, let them confirm it, or offer a quick way to reuse it.
Note: This only applies within the same session. It doesn’t require storing data across logins or visits.
Why this matters for accessibility
If users have to retype the same information, especially long or complex entries, they may get frustrated, make mistakes, or abandon the process. Such repetition may increase mental fatigue for users with cognitive disabilities. It also demands extra effort from users with mobility impairments which they may be unable to easily manage.
By reusing data the user already provided on your website, you make it easier for them to complete forms correctly with less stress. This improves the overall user experience for everyone, not just users with disabilities.
How to Meet Success Criterion 3.3.7 (Redundant Entry)
Common errors on websites:
- Users lose all previously entered non-sensitive info when the page refreshes or they click “Back,” even though they’re still in the same session.
- No “Use same as previous” checkbox for clearly repeatable information.
- Logged-in users are shown blank forms, even when their profile contains the exact data being requested, like name, email, or saved addresses.
- Forms request the same information twice but with different labels (e.g. “Workplace” in one step, “Company name” in another), causing unnecessary re-entry.
- If the user fails CAPTCHA or skips a required field, the entire form resets, and they have to re-enter every non-sensitive input from scratch.
- Common fields (like name, email, and address) are missing autocomplete attributes, blocking browsers and assistive technologies from helping users auto-fill safely.
How to fix these errors:
- Use session storage, cookies, or server-side logic to retain and auto-fill data across form steps or multi-step processes.
- Implement saved profiles, dropdown menus, or “use saved information” checkboxes to let users select previously entered data.
- Store data in local storage or a database to allow users to resume partially completed forms without losing progress. Use “Save and
- Ensure re-entry is only required when essential, security-related, or for data validation. Auto-populate or provide selection options when possible
- Organize forms to preserve meaningful sequence, reduce duplicate fields and ensure seamless data flow between steps.
- Use HTML autocomplete attributes (e.g., autocomplete=”name”, autocomplete=”email”) to enable browser autofill for fields like name, email, and phone number.
Helpful tips for developers:
- If re-entry is technically required (e.g., confirming updated info), don’t show the entire form again. Instead, reveal only the changed field or ask for confirmation (e.g., “We’re using the same address you entered earlier. Want to update it?”).
- Track how often users re-enter the same data on multi-step forms using custom analytics events. If a user inputs their email twice manually, flag that as a failure and fix it.
- Build APIs that serve up temporary user data scoped to the current session, not long-term profiles. That allows pre-fill to work even for unauthenticated users without compromising privacy and is ideal for guest checkout, job applications, or support forms.
- In Single Page Applications (SPAs) or component-driven frameworks (like React or Vue), form state can get lost during route changes or state resets. Create a memory layer or context provider that carries forward inputs regardless of what component or page the user is on to ensure continuity.
How to test if your site meets this requirement
- Manually go through your multi-step form and check if users are asked to re-enter the same info (like name or address) more than once.
- Turn off browser autofill or test in incognito mode to confirm the website (not the browser) remembers and reuses user input.
In flows like checkout, job applications, or registrations, check if earlier inputs appear again later without auto-fill or selection options. - Navigate back and forth between steps to see if the form retains previous inputs. If fields reset, that’s a WCAG failure.
- Watch for repeated non-sensitive fields being required again with no real justification, like asking for an email twice without reason.
- Test the process as a guest user. If data isn’t carried forward for unauthenticated users, the issue isn’t solved.
- Use a screen reader to verify that any pre-filled or selectable data is announced and usable, not just visually visible.
- Open browser DevTools to inspect whether session storage, cookies, or in-memory state is being used to persist form data between steps.
- Purposely trigger an error or reload mid-way through the form. If the user has to start over from scratch, the form isn’t accessible.
Bad and Good Examples (Code Snippets)
Code example that fails success criterion 3.3.7 (redundant entry)
<!-- Step 1 -->
<label for="email">Email</label>
<input type="email" id="email" name="email" required><!-- Step 3 -->
<label for="confirm-email">Confirm Email</label>
<input type="email" id="confirm-email" name="confirm_email" required>In this example, the user is asked to re-enter their email in a later step of the same process without any option to reuse or confirm the value entered earlier. The field isn’t auto-filled, and there’s no checkbox or visual cue that the system remembers the input.
Since there’s no valid reason for the re-entry (like security or validation), this pattern fails WCAG 3.3.7. It adds friction where none is needed, which directly impacts accessibility for users with cognitive or motor impairments.
Code example that meets success criterion 3.3.7 (redundant entry)
<!-- Step 1 -->
<label for="email">Email</label>
<input type="email" id="email" name="email" value="user@example.com" required><!-- Step 3 -->
<label for="confirm-email">Confirm Email</label>
<input type="email" id="confirm-email" name="confirm_email" value="user@example.com" required>
This example uses the value from step 1 to auto-fill the email field in step 3. It doesn’t force the user to recall or retype it manually. The system retrieves the previously entered information and inserts it directly into the input field.
By doing this, the form reduces the memory and effort required to complete the process. It supports users who may struggle with cognitive load, attention, or motor control by eliminating unnecessary repetition.
Frequently Asked Questions
Does WCAG success criterion 3.3.7 (redundant entry) apply across different user sessions?
No. This success criterion only applies within the same session. You don’t need to persist data after the user closes the browser or returns at a later time. The requirement focuses on avoiding redundant input during a single, continuous process.
Can I rely only on browser autofill to meet this success criterion?
No. Autofill is a browser-controlled feature, not a reliable accessibility solution. Because behavior varies by browser, device, and user settings, you cannot depend on it for compliance. Your site must provide access to previously entered data within the same session using auto-filled fields, dropdowns, or selectable options.
Does WCAG SC 3.3.7 require support for guest users?
Yes. The criterion applies to all users, including those who aren’t logged in. You must preserve input data during the session using session storage, cookies, or in-memory logic to avoid making guests re-enter the same information.
Does WCAG SC 3.3.7 apply to third-party services in a multi-step flow?
Yes. If your user journey includes a third-party service (like a payment gateway) as part of a multi-step process, the requirement still applies. You are responsible for ensuring that previously entered data remains available throughout the entire session, even across different domains.
What is a valid exception under WCAG SC 3.3.7?
An example of a valid exception under WCAG 3.3.7 (redundant entry) is requiring users to retype their password for confirmation. This step ensures security and accuracy, and qualifies as essential under the criterion’s exceptions.
