Skip to content

A11y 101 – 3.3.7 Redundant Entry

Last updated on August 11, 2026

You’re shopping online at your favorite store. You set up an account for future visits. You fill out your name, email, shipping address, billing info, card details. You save the info.

You start shopping and add some items to the cart. The checkout form asks for all that information again. Name, email, address, card. All of it. Fresh blanks.

You stare at the screen. “Didn’t you already know this?”

That’s redundant entry. It’s annoying for anyone. For users with disabilities—motor impairments, cognitive challenges, slow input methods—it’s exhausting. And it’s exactly what WCAG 3.3.7: Redundant Entry is designed to eliminate.

What’s Expected

If a user has entered data, that data must be available for reuse in subsequent inputs on the same session, unless:

  1. The data is essential for security (like authentication verification. I’ll get into this in the next article.)
  2. User-provided data would compromise security
  3. The data is required by law and can’t be stored (rare)
  4. The user can’t store data (session expires without saving option)

In other words: if you collect it once, offer to fill it again. Autocomplete, saved profiles, persistent sessions—all count as compliance.

Don’t Make Me Type What You Already Have

close up of padlock with code
Photo by Modun Studio on Pexels.com

Why This Is New (And Why It Matters Now)

This criterion didn’t exist in WCAG 2.1. It arrived with 2.2 because browser capabilities, identity management, and user expectations have shifted dramatically.

Today, users expect sites to remember them. They sign in once and don’t re-enter credentials everywhere. They fill checkout once and trust it stays for next time. When a site doesn’t honor that expectation, it feels broken—not just inconvenient.

For people with disabilities, this isn’t just about convenience. It’s about feasibility.

Someone using voice control needs to dictate “John Smith, 123 Main Street” once, not thirty times. Someone with a tremor who takes ten seconds to tap each digit shouldn’t re-enter a credit card number six times in a day. Someone with memory impairment who forgot what they typed last week shouldn’t need to hunt down old emails to verify their address.

Redundant entry creates barriers that accumulate with every repetition.

Common Scenarios (And Fixes)

I see this break in a few predictable patterns:

Scenario 1: Multi-Step Checkout

  • Problem: User enters shipping info on step one. On step three, billing form asks for address again.
  • Fix: Auto-populate billing from shipping. Or provide a checkbox: “Use same address for billing.”

Every field you save them from filling is a barrier you remove.

Scenario 2: Cross-Session Persistence

  • Problem: User fills a profile form. Returns next week. Fields are blank.
  • Fix: Store data securely and repopulate fields on return. Use autocomplete attributes.

Scenario 3: Login Recovery

  • Problem: Forgot password flow asks for email, then phone number, then mother’s maiden name, then first pet’s name.
  • Fix: Use fewer verification steps. Remember verified contact info from previous sessions.
<!-- GOOD: Using autocomplete for persistent data --> 
<form> 
<label for="fullname">Full Name</label> 
<input type="text" id="fullname" name="fullname" autocomplete="name"> 
<label for="email">Email</label> 
<input type="email" id="email" name="email" autocomplete="email"> 
<label for="address">Address</label> 
<input type="text" id="address" name="address" autocomplete="street-address"> 
<label for="city">City</label> 
<input type="text" id="city" name="city" autocomplete="address-level2"> 
<label for="postal">Postal Code</label> 
<input type="text" id="postal" name="postal" autocomplete="postal-code"> 
<button type="submit">Save</button> 
</form>

Those autocomplete values aren’t decoration. They’re programmatic hints to browsers that the user’s stored data can be offered. Screen readers announce them. Voice assistants use them. Every assistive tech benefits.

The Security Caveat

There are legitimate exceptions where data can’t be persisted:

  • Passwords (don’t save them, but allow pasting and autocomplete)
  • One-time verification codes
  • Sensitive data that exceeds legal retention requirements

But even there, you can minimize redundancy. If you asked for email verification in step one, don’t ask for it again in step three. If you verified their phone number earlier, use that verification token instead of re-sending a code.

The burden is on the site to justify why data can’t be reused—not on the user to prove why they shouldn’t have to re-enter it.

Where I See This Fail

Most failures are silent. No error messages. No crashes. Just repeated blank fields that drain patience.

  • No Saved Profiles: User accounts let you update settings, but don’t pre-fill forms with that data.
  • Expired Sessions That Clear Everything: Session timeout resets progress and wipes all entered values.
  • Cross-Device Breakdown: Data saved on desktop doesn’t sync to mobile version.
  • Third-Party Forms Embedded: Widget on your site doesn’t inherit your existing profile data.

Each one adds friction. Friction adds drop-off. Drop-off adds revenue loss. And for disabled users, friction can add impossibility.

Reality Check

Redundant entry is often justified as “security” or “accuracy.” Let me be blunt: those are excuses.

Preventing disabled users from completing the security requirements independently reduces the overall security of the platform.

True security uses tokens, not re-entry. True accuracy validates existing data before re-using it. Requiring users to type what you already have isn’t protection; it’s distrust.

And for disabled users, that distrust translates into real-world consequences. Extra time spent re-typing means slower task completion. More keystrokes means more opportunity for errors. Higher cognitive load means exhaustion.

Every field you save them from filling is a barrier you remove. Every autocomplete value you enable is a signal that you respect their effort.

The Bottom Line

If you’ve collected it before, don’t make them type it again.

Use saved profiles. Leverage browser autofill. Persist sessions securely. Sync data across devices. Build systems that remember.

Your users aren’t trying to trick you. They’re trying to complete a task. Help them do it without repeating themselves.

Because, remembering what your users told you yesterday isn’t advanced tech. It’s essential baseline courtesy.

Have thoughts on this? Find me on LinkedIn and BlueSky to discuss!

Updated due to a reminder from Eric Eggert that this focuses on a single process, not revisiting a site later.


Discover more from Nat Tarnoff

Subscribe to get the latest posts sent to your email.

Published ina11ya11y 101accessibilityblindcognitiondevelopmentEAAEN 301 549humanityphysical impairmentTestingW3CWCAGWeb Content Accessibility Guidelines

Comments are closed.