Redundant Entry

In brief

Typing the same address twice in one checkout is a small annoyance for some people and a real barrier for others. People with memory or cognitive disabilities may not recall what they entered. People who type slowly, use switches or voice input, spend extra effort on every re-entry.

This criterion, new in WCAG 2.2, requires that information previously entered by or provided to the user, and required again in the same process, is either auto-populated or available for the user to select, except where re-entering is essential, needed for security, or the earlier information is no longer valid.

What does it cover?

• Same process: A series of user actions where each action is required to complete an activity, such as a multi-step checkout or sign-up. A process can span domains, for example a checkout that uses a third-party payment provider.
• Auto-populated: The information is filled in for the user in the later step.
• Available to select: The user can choose it, for example from a list, by copying text from the page, or by ticking a "same as" check box.
• Exceptions: Re-entry is essential (such as a memory game). Re-entry is needed for security, such as confirming a new password that is not displayed. The information is no longer valid.
• Browser autofill is not enough: The website itself must provide the data or avoid asking for it again. Autofill may help, but it does not satisfy the criterion alone.
• Not across sessions: The criterion does not require storing information between sessions.
• Out of scope: Identifying input purpose is 1.3.5. Accessible authentication is 3.3.8.

Who does it affect?

People with cognitive disabilities and short-term memory difficulties, who have less stress and fewer mistakes. People who have trouble forming or recalling memories. People with mobility impairments, including those using switch control or voice input, who need less text entry.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Less re-entry is part of "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.3.7 by reference and turns it into separate clauses for each kind of ICT.

Because this criterion is new in WCAG 2.2, it is not part of EN 301 549 V3.2.1. Check clauses 10 and 11 of V4.1.1 for the rows that apply to documents and software. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: Criterion 3.3.7 is new in WCAG 2.2, so it is not part of EN 301 549 V3.2.1, which is based on WCAG 2.1. It appears in EN 301 549 V4.1.1 (September 2026), the first version prepared specifically for the EAA. V4.1.1 has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. A "same as" check box (G221)

Let users reuse the billing address for delivery with one action.

<h2>Delivery address</h2>
<input name="street"> <input name="city"> <!-- asks again -->

<label><input type="checkbox" id="same"> Delivery address is the same as billing</label>
<script>
same.addEventListener("change", () => { if (same.checked) copyBillingToDelivery(); });
</script>

2. Pre-populate later steps

Carry data from an earlier step into the later form.

<!-- Step 2 asks for the company name entered in step 1 -->
<input name="company">

<input name="company" value="{{ saved.company }}">

3. Show earlier information to select

Let the user pick previously entered information instead of typing it.

<input name="shipTo" placeholder="Type the address again">

<label for="addr">Deliver to</label>
<select id="addr">
  <option>12 Example Street, Istanbul (billing)</option>
  <option>Enter a new address</option>
</select>

4. Keep form state across steps

Do not lose entries when users move between steps.

nextBtn.addEventListener("click", () => location.href = "/step2"); // step 1 data lost

nextBtn.addEventListener("click", () => {
  sessionStorage.setItem("checkout", JSON.stringify(readForm()));
  location.href = "/step2";
});

5. Email entered twice

Asking for the same email address again is redundant entry unless an exception applies. Ask once and show it for correction.

<label>Email <input name="email"></label>
<label>Confirm email <input name="email2"></label>

<label>Email <input name="email" type="email"></label>
<!-- Ask once. Offer a way to correct it later -->

6. The security exception

Confirming a newly created password that is not displayed is allowed. A "show password" option can make confirmation unnecessary.

<input type="password" name="pw"> <!-- and no way to check it -->

<label>New password <input type="password" name="pw" id="pw"></label>
<label>Confirm password <input type="password" name="pw2"></label>
<!-- Re-entry for a hidden new password is allowed -->

Code examples for mobile

In an app, carry data between screens of the same flow and let users select it rather than retype it.

iOS (SwiftUI)

import SwiftUI

struct CheckoutView: View {
    @State private var billing = "12 Example Street, Istanbul"
    @State private var sameAsBilling = true
    @State private var delivery = ""

    var body: some View {
        Form {
            TextField("Billing address", text: $billing)
            // The user selects "same as billing" instead of typing it again
            Toggle("Delivery address is the same as billing", isOn: $sameAsBilling)
            if !sameAsBilling {
                TextField("Delivery address", text: $delivery)
            }
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.Row
import androidx.compose.material3.*
import androidx.compose.runtime.*

@Composable
fun Checkout() {
    var billing by remember { mutableStateOf("12 Example Street, Istanbul") }
    var same by remember { mutableStateOf(true) }
    var delivery by remember { mutableStateOf("") }

    Column {
        OutlinedTextField(billing, { billing = it }, label = { Text("Billing address") })
        // The user selects "same as billing" instead of typing it again
        Row {
            Checkbox(checked = same, onCheckedChange = { same = it })
            Text("Delivery address is the same as billing")
        }
        if (!same) {
            OutlinedTextField(delivery, { delivery = it }, label = { Text("Delivery address") })
        }
    }
}

How to test

• Walk through each process: Complete multi-step flows such as checkout, sign-up and applications. Note every piece of information requested more than once.
• Check each repeat: Is it auto-populated, or can the user select it?
• Check the "same as" options: Can the user reuse an earlier address or name with one action?
• Apply the exceptions: Is re-entry essential, needed for security, or because the earlier information is no longer valid?
• Go back and forward: Move back to a previous step and forward again. Is the data kept?
• Check third-party steps: Does an embedded payment provider ask again for data you already collected?
• Use a checker as a starting point: Automated tools cannot detect repeated requests across steps. A person must walk through the process.

Common mistakes

• Asking for the address twice: Billing and delivery with no "same as" option.
• Email entered twice: A confirm email field with no exception applying.
• Data lost between steps: Going back clears the form.
• Relying on browser autofill: The page must provide the data itself.
• Re-asking for information the user gave earlier: In the same process, for example a company name.
• A third-party step that asks again: A payment provider that repeats the address.
• Confusing it with storage: The criterion does not require remembering data across sessions.
• Treating every repeat as security: Only genuine security needs qualify.

Sources

• Understanding SC 3.3.7: Redundant Entry (W3C), opens in a new tab
• G221: Provide data from a previous step in a process (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.