WCAG 3.3.7: Redundant Entry

What This Rule Means

WCAG 3.3.7 Redundant Entry is a Level A success criterion introduced in WCAG 2.2. It states: "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." In plain terms, if a user has already typed their email address, shipping address, date of birth, or any other piece of information during a session, your interface must not make them type it again within the same process or flow.

The criterion applies broadly to any multi-step form, checkout process, registration wizard, appointment booking flow, or similar sequence where data collected in one step may be needed again in a later step. The affected behaviors include text inputs, dropdowns, checkboxes, radio buttons, and any other form control that collects user-provided data. When the same piece of information is required again, it must either be pre-filled automatically using the previously supplied value, or it must be offered as a selectable option so the user can confirm rather than re-enter it.

A pass for this criterion looks like: a billing address form that is pre-filled with the shipping address the user entered on the previous screen, or a confirmation step that displays the user's previously entered email address in a read-only field. Another passing pattern is a checkbox labeled "My billing address is the same as my shipping address" that, when checked, copies the values over automatically. A fail looks like: a multi-step registration flow that asks for an email address on step 1 and again on step 3 without pre-populating the second field, or an insurance claim form that asks the claimant's name and policy number on multiple separate screens with no auto-fill.

WCAG 3.3.7 defines two official exceptions. The first exception applies when re-entering the information is essential to the process — for example, a "Confirm your new password" field intentionally asks users to type the same password twice as a safeguard against typos, and this is considered an essential security check. The second exception applies when the previously entered information is no longer valid — for instance, if a session has expired or a product went out of stock and the user must restart a process with fresh data. Outside these exceptions, redundant entry is a conformance failure.

Why It Matters

Redundant entry disproportionately burdens users whose conditions make typing slow, painful, error-prone, or cognitively taxing. Understanding who is affected helps developers and designers appreciate why this criterion is more than a convenience feature — it is a genuine barrier for many people.

Users with motor impairments, such as those with tremors, spinal cord injuries, or conditions like ALS or multiple sclerosis, may rely on switch access, mouth sticks, eye-tracking software, or voice control to enter text. For these users, typing even a short address can take several minutes and significant physical effort. Being required to repeat that input is not merely annoying — it may cause physical pain or make the task practically impossible in a single session.

Users with cognitive disabilities, including dyslexia, attention deficit disorders, traumatic brain injury, and dementia-related conditions, may struggle to remember what they entered three steps ago. Transcribing information accurately from memory or from a paper document multiple times greatly increases error rates and abandonment. According to the World Health Organization, over 1 billion people worldwide live with some form of disability, and cognitive disabilities represent one of the largest and most underserved segments in accessibility planning.

Users with upper limb differences, including those who were born with or have acquired limb differences, type far more slowly and may use alternative input devices. Each additional required keystroke multiplies the burden on these users.

Consider a real-world scenario: a user with rheumatoid arthritis is booking a medical appointment through a hospital's online portal. On screen 1 they enter their national ID number, name, date of birth, and contact phone number. On screen 3 the portal asks for their name and date of birth again to confirm the patient record. This user must laboriously re-type information they provided just two screens ago, risking typos that could mismatch records, and experiencing unnecessary physical strain. A simple pre-fill or auto-population of those fields would remove the barrier entirely.

Beyond accessibility, eliminating redundant entry improves conversion rates, reduces form abandonment, and decreases support tickets caused by data entry errors — delivering measurable business value alongside inclusive design.

Related Axe-core Rules

WCAG 3.3.7 is a criterion that requires manual testing. No automated axe-core rule currently exists that can reliably detect redundant entry violations, because automated tools cannot understand the semantic relationship between data entered across multiple steps or pages in a dynamic process. They have no awareness of what information was collected in a previous step, what information is being requested in the current step, or whether those two pieces of information are logically identical. Only a human tester who walks through the complete flow can observe and evaluate whether the same data is being requested twice without pre-population.

• Manual testing required (WCAG 2.2 new): axe-core and other automated accessibility scanners analyze the DOM of a single page state at a time. They cannot track user-entered values across multiple page loads or form steps, cannot compare field labels across steps to identify semantic duplication, and cannot evaluate whether a pre-fill mechanism is functioning correctly. Testers must manually walk through multi-step processes, record what data they enter at each step, and verify at each subsequent step whether previously provided data is either auto-populated or selectable. Any tool claiming to automatically detect 3.3.7 violations would produce an extremely high false-negative rate and should not be relied upon as the sole testing method.

How to Test

1. Automated scan as a starting point: Run axe DevTools, Lighthouse, or the Accsible auditor on each individual step of your multi-step process. While these tools will not flag 3.3.7 violations directly, they will surface related issues such as missing autocomplete attributes, unlabeled form fields, and other 3.3.x criterion failures that often co-occur. Document every form field you find on each step.
2. Map the data requirements across steps: Before manual testing, create a simple table or spreadsheet listing each step in the process and all data fields it collects. Then identify any field label or data type that appears in more than one step. This mapping exercise surfaces candidate violations before you even open a browser.
3. Manual walkthrough — desktop: Using a standard mouse and keyboard, complete the entire multi-step process (e.g., checkout, registration, claim submission). Enter realistic values in every field. When you arrive at a step that appears in your map as a duplicate field, check whether the field is pre-filled with your earlier entry, or whether a selectable option presenting your earlier entry is available. If neither is the case, record a failure. Repeat this test with a screen reader (NVDA with Firefox, JAWS with Chrome, VoiceOver with Safari) to confirm that pre-filled values are properly announced and that selection controls for previously entered values are reachable by keyboard.
4. Manual walkthrough — mobile: Complete the same flow on iOS (VoiceOver + Safari) and Android (TalkBack + Chrome). Pay attention to whether native autocomplete or autofill features are suppressed by the application, which could inadvertently create redundant entry barriers even if the developer intended autocomplete to help.
5. Test the exceptions: Identify any fields that intentionally ask for duplicate entry (e.g., password confirmation, re-enter email). Verify these qualify as essential security or validation checks under the WCAG exception and are not simply redundant fields that should be removed or pre-filled.
6. Test with autocomplete disabled: Some users disable browser autocomplete for privacy reasons. Test whether the application's own pre-fill mechanism (server-side or JavaScript-driven) still functions correctly when browser autocomplete is turned off, ensuring the criterion is met independently of browser behavior.

How to Fix

Multi-step checkout — same address required on two screens — Incorrect

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Multi-step checkout — same address required on two screens — Correct

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Registration wizard asking for email twice with no justification — Incorrect

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Registration wizard — email pre-filled from session data — Correct

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Appointment booking — patient details asked again in summary step — Incorrect

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Appointment booking — date of birth shown as read-only confirmation — Correct

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Common Mistakes

• Building multi-step forms as independent pages with no shared session state, so there is no mechanism to carry forward values entered in earlier steps — the most fundamental architectural mistake leading to 3.3.7 failures.
• Providing a "same as shipping" checkbox but not actually populating the billing fields when it is checked, forcing users to still type address details manually even after indicating they should match.
• Pre-filling fields on page load but then clearing them on validation error, so a user who makes a mistake on a later step must re-enter all previously provided data when they return to correct it.
• Storing session data insecurely and choosing to disable it rather than fix the security issue, resulting in a broken pre-fill experience that technically constitutes a 3.3.7 failure.
• Using the password confirmation exception as justification for making users re-enter email addresses, when email confirmation is not an essential security check and does not qualify under the WCAG exception.
• Failing to pass carried-over values through hidden inputs in server-side rendered forms, causing pre-filled values to be lost when a user navigates back and forward through steps using browser history buttons.
• Relying solely on browser autofill to satisfy this criterion, without implementing application-level pre-fill — users who disable autofill for privacy reasons then have no conformant path through the process.
• Pre-filling a field but setting it as disabled rather than readonly, which causes the value to be excluded from form submission in most browsers, breaking the process and potentially forcing re-entry.
• Not testing the complete end-to-end flow with users who use voice input software such as Dragon NaturallySpeaking, where redundant fields may require repeating the same verbal dictation command multiple times, a significant burden that is easy to overlook in developer testing.
• Treating this criterion as only applicable to address fields, when it applies equally to any repeated data including names, phone numbers, national ID numbers, policy numbers, dates, and any other user-provided information requested more than once in the same process.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, mandates web accessibility conformance for a broad range of public and private entities operating in Turkey. WCAG 3.3.7 Redundant Entry is a Level A criterion under WCAG 2.2, and Level A conformance is the mandatory baseline under this circular. This means that any covered entity operating a website, web application, or digital service must not require users to re-enter information they have already provided within the same process — without exception — or risk non-compliance.

The circular establishes a phased implementation timeline: public institutions must achieve conformance within one year of the circular's publication, while private sector entities in the covered categories have two years to comply.

The entity types covered by the circular are extensive and include e-commerce platforms and marketplaces, all public institutions and government agencies, banks and financial service providers, hospitals and healthcare portals (both public and private), telecommunications companies with 200,000 or more subscribers, licensed travel agencies, private transportation companies, and private schools authorized by the Ministry of National Education (MoNE). For all of these entities, multi-step digital processes — checkout flows on e-commerce sites, patient registration on hospital portals, account opening on banking platforms, enrollment forms on school websites — must be audited and corrected to eliminate any instance of redundant entry.

In practice, this regulation places WCAG 3.3.7 compliance squarely in the scope of procurement, product, and legal teams across Turkey's digital economy. For example, a Turkish e-commerce platform operating a multi-step checkout that asks for a delivery address on one screen and a billing address on the next without offering a pre-fill or copy option is in direct violation of both WCAG 2.2 Level A and the Presidential Circular. Similarly, a state hospital's appointment booking portal that asks patients to re-enter their identity number or date of birth across multiple screens is non-compliant. Organizations subject to the circular should prioritize an end-to-end audit of all multi-step processes as part of their conformance roadmap, treating redundant entry elimination as a required engineering task, not an optional enhancement.