3.3.7 Redundant Entry
- Level A
- Understandable
- New in WCAG 2.2
Summary
If a user has already given you a piece of information during a process, do not make them type it again later in that same process. Either fill it in for them (auto-populate) or let them pick it from what they entered earlier (available to select). This criterion is new in WCAG 2.2 at Level A, which makes it a baseline requirement, and it exists because re-entering data is disproportionately costly for some users: people with cognitive or memory impairments who may not recall what they typed three screens ago, and people with limited dexterity or fatigue for whom every extra field is genuine physical effort.
Three exceptions narrow the scope. Re-entry can be required when it is essential to the task (confirming a new password by typing it twice), when it is there to secure the content (a card security code that must never be stored), or when the earlier information is no longer valid. Most audit disputes turn on two questions: whether the repeated ask sits inside the same process, and whether one of the exceptions genuinely applies.
Official wording
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.
EN 301 549 mapping
This success criterion is new in WCAG 2.2. EN 301 549 V3.2.1, the harmonised European standard currently in force, references WCAG 2.1 and contains no clause for it. A revision aligned with WCAG 2.2 is in progress; until it is published and cited in the Official Journal of the EU, this criterion is not part of the harmonised standard.
Checked against EN 301 549 V3.2.1 (2021-03).
In practice
Web
The classic sites of failure are multi-step flows: checkouts, quote funnels, insurance applications, registration wizards, and any form journey spanning several pages. The canonical pass is the checkout that collects a shipping address and then offers "billing address same as shipping" as a checkbox or a selectable option at the payment step. The canonical fail is the funnel that asks for an email address on step one and presents an empty email field again on step four.
Scope the "same process" carefully. A process is a continuous task within a session: the checkout you are working through now, the application you are completing this sitting. It is not a return visit next week, a separate task started fresh, or a new session after logging out. Asking for an address again in a brand new order placed days later is not a failure of this criterion.
Test by walking the journey end to end and keeping a running list of everything the user is asked to provide. Each time a later step asks for something already on that list, check whether the field is pre-filled or the value is offered for selection, and if neither, whether an exception applies. Note that the criterion also covers information provided to the user, such as a reference number shown on one page that a later page demands be typed in.
iOS
Apply the same journey walkthrough to multi-screen flows in the app: onboarding sequences, in-app checkouts, booking flows, and account setup wizards. The expected behaviour is that the app carries state forward, so a delivery postcode captured on screen two is pre-filled or selectable when screen five needs it again.
Platform autofill does not satisfy this criterion. The W3C's understanding material is explicit that browser autocomplete "is not considered sufficient because it is the content (the website) that needs to provide the stored information": the obligation sits with the app or site, not the user agent. An iCloud Keychain or contact-based suggestion popping up above the keyboard is welcome, but it does not excuse a flow that demands the same data twice. Grade the re-asking itself: if the app's own content does not pre-populate the value or offer it for selection, it fails, however helpful the platform happens to be on the device you tested.
Android
The walkthrough is identical: traverse each multi-screen flow, log every requested value, and flag repeated asks that arrive as empty fields. In View-based apps the state should travel via the activity or a shared ViewModel; in Compose, hoisted state or a navigation-scoped ViewModel should carry earlier answers to later steps.
One Android-specific fail mode is worth testing deliberately: process death. If the system reclaims the app mid-flow (or the user briefly switches apps on a memory-constrained device) and the app restores to a later step with earlier answers wiped, the user is forced to re-enter information they already gave in the same process. That is a real-world failure auditors should report honestly, not an edge case to wave away. Backgrounding the app and killing the process from the developer settings before resuming is a quick, repeatable check on whether saved-state handling actually preserves entered data.
Pass and fail examples
Passes:
- A checkout collects the shipping address, then offers a "billing address same as shipping" checkbox at the payment step: the earlier information is available to select.
- A mortgage quote funnel pre-populates the applicant's name and date of birth on the declaration page from the details step.
- A booking app shows the lead passenger's details as a selectable option when adding contact information later in the same booking.
Fails:
- An email address is typed on step one of a sign-up funnel and an empty email field appears again on step four of the same funnel.
- A reference number displayed on the confirmation screen must be manually copied into the very next screen of the same process.
- An app loses all entered form data after process death mid-flow and presents empty fields on restore.
Not a fail under this criterion:
- Typing a new password twice to confirm it: re-entry is essential to catch typos.
- Re-prompting for the card security code at payment: required to ensure the security of the content, and storing it would be worse.
- Being asked to log in again when returning the next day to place a new order: that is a new process, not the same one.
Commonly confused with
- Identify Input Purpose, SC 1.3.5. That criterion is about programmatically declaring what a field collects so browsers and assistive tech can autofill it. Redundant Entry is about the flow itself not asking twice. A form can mark up every field perfectly and still fail 3.3.7 by re-asking.
- 3.3.8 Accessible Authentication (Minimum). Both are new in WCAG 2.2 and both target cognitive burden, but the boundary is clean: re-entering credentials at login belongs to 3.3.8; re-entering form data within a process belongs here.
- Error Prevention (Legal, Financial, Data), SC 3.3.4. That criterion asks whether users can review, correct, or reverse important submissions. A review step that displays earlier answers is good practice for 3.3.4 and does not offend 3.3.7, because displaying is not re-asking.
- 3.2.6 Consistent Help. Not a true confusion, but commonly reviewed together: the same multi-step form journeys you walk for Redundant Entry are where you check that help mechanisms stay in a consistent place.
How AUDITSU tests this
AUDITSU's audit walkthrough treats Redundant Entry as a journey-level check rather than a single-screen one. As you review the screens of a flow, the walkthrough prompts you to record what each step asks the user to enter, then asks whether any later screen in the same process requests information already captured, and if so whether it is auto-populated, selectable, or covered by the essential, security, or validity exceptions. Each answer records a pass, fail, or not applicable result with evidence attached, so the finding lands in your report tied to the exact step where the repeated ask occurs.
Because EN 301 549 V3.2.1 does not yet include this criterion, AUDITSU tracks it under WCAG 2.2 conformance. When your audit targets the European Accessibility Act, the walkthrough treats 3.3.7 as forward guidance until the revised harmonised standard adopts WCAG 2.2.
For the full guided workflow, see the audit platform.