Fixing Forms: Redundant Entry, Accessible Authentication, and Frictionless UX

Forms are where conversions happen—or don't. Signup forms, login flows, checkout processes, and account management all depend on users successfully entering information and completing multi-step interactions. For users with disabilities, forms are frequently the most significant barriers. WCAG 2.2 introduced new criteria specifically addressing authentication and redundant entry, acknowledging that accessible forms require more than just proper labels.

The WebAIM Million study consistently finds that form-related issues are among the most common accessibility failures. Missing labels, poor error handling, inaccessible validation, and confusing multi-step processes prevent users from completing tasks that are critical to business outcomes.

This guide covers what WCAG 2.2 requires for accessible forms and authentication, practical implementation patterns that work, and how to balance security requirements with accessibility needs.

What WCAG 2.2 Says About Forms and Authentication

Accessible Authentication (3.3.7 and 3.3.8)

WCAG 2.2 introduced Accessible Authentication (Minimum) at Level AA and Enhanced at Level AAA. These criteria address cognitive barriers in authentication.

The core requirement: Authentication processes must not require users to transcribe something, recognize objects, or solve cognitive puzzles—unless alternatives are available.

What this means in practice:

CAPTCHAs are problematic. Traditional CAPTCHAs that ask users to identify objects, solve puzzles, or transcribe distorted text create barriers for users with cognitive disabilities. If you use CAPTCHA, you must provide alternatives (like audio CAPTCHA, or better, invisible CAPTCHA techniques that don't require user interaction).

Password managers must work. Don't block paste in password fields. Users with cognitive disabilities often rely on password managers to generate and store complex passwords. Blocking paste forces them to type complex strings from memory or from another screen—exactly the cognitive load the criterion aims to eliminate.

Object recognition tests are barriers. "Select all images with traffic lights" tests exclude users who can't visually distinguish objects reliably due to cognitive disabilities, low vision, or other impairments.

Transcription requirements are barriers. Requiring users to type SMS codes from their phone into a desktop browser is a transcription task. Consider alternatives like push notifications, email links, or security keys.

Redundant Entry (3.3.7)

WCAG 2.2's Redundant Entry criterion requires that users not have to re-enter information they've already provided in the same session.

The core requirement: If a user provides information once (like their email address), they shouldn't have to provide it again in the same process—unless re-entry is essential for security, accuracy verification, or the previous value is no longer valid.

What this means in practice:

Don't ask for email twice. The classic "email" and "confirm email" pattern violates this criterion unless you can justify it as essential accuracy verification. For most signup flows, it's not—display what the user entered and let them correct if wrong.

Auto-populate from earlier steps. Multi-step forms should carry information forward. If step 1 collected billing address, step 3 shouldn't ask for it again for shipping without at least offering "same as billing."

Remember information within sessions. If a user entered preferences or profile information, those values should pre-populate in subsequent forms within the same session.

Cart and checkout persistence. Information entered during cart configuration should persist to checkout without re-entry.

Common Form Accessibility Failures

Beyond the WCAG 2.2 criteria, forms have long-standing accessibility requirements that many implementations fail.

Labels and Instructions

Missing labels. Every form field needs a programmatically associated label. Placeholder text is not a label—it disappears when users start typing, leaving them wondering what they're filling in. Use <label for="fieldId"> or aria-label.

Unclear instructions. Required field indicators, format expectations (like date formats), and character limits should be clearly communicated in the label or associated instructions—not discovered only when validation fails.

Grouped fields without context. Radio button groups and checkbox groups need a <fieldset> with <legend> so screen reader users understand what the options relate to. Without grouping, users hear individual options without context.

Error Handling

Errors without identification. WCAG Success Criterion 3.3.1 requires that errors be identified in text and that the problematic field be identified. "There was an error" without specifying what error or where fails this requirement.

Errors not associated with fields. Error messages should be programmatically associated with their fields using aria-describedby or similar techniques. Screen reader users navigating field-by-field should hear error messages in context.

Color-only error indication. Turning the field border red helps sighted users—but fails users who can't perceive color differences. Add icons, text, and programmatic association.

No error summary. For forms with multiple errors, provide a summary at the top that lists all errors with links to problematic fields. Users shouldn't have to hunt through the form to find what needs correction.

Keyboard and Focus

Broken tab order. Users should be able to Tab through form fields in logical order, matching visual layout. CSS or JavaScript that reorders elements visually without adjusting focus order creates confusion.

Missing focus indicators. When users Tab to form fields, they need visible indication of where they are. Default browser focus styles are often sufficient; custom styles that remove focus outlines without replacement are accessibility failures.

Form submission traps. Users should be able to review before submitting. Automatic form submission on field blur (when user leaves a field) surprises users who are still reviewing.

Date picker disasters. Calendar widgets for date selection are frequently inaccessible—mouse-only operation, no keyboard navigation, poor screen reader support. Either use native HTML date inputs (improving but inconsistent) or implement truly accessible custom components following ARIA date picker patterns.

Building Accessible Authentication Flows

Password Fields

Allow paste. This is non-negotiable for WCAG 2.2 compliance. Password managers improve security—don't undermine them.

Provide show/hide toggle. Allow users to reveal their password while typing. Users with cognitive disabilities benefit from verification; users with motor disabilities may make more typing errors and need to check their input.

Clear password requirements upfront. Don't make users discover requirements through trial and error. State "Passwords must be at least 12 characters with one number" before they start typing.

Inline validation that helps. If you validate password strength as users type, ensure the feedback is accessible—announced to screen readers, not just visual color changes.

Multi-Factor Authentication

Offer choice. Different MFA methods have different accessibility profiles. SMS codes require transcription; security keys require physical dexterity; biometrics require specific hardware. Offering multiple options serves more users.

Push notifications over codes. If possible, offer "tap to approve" push notifications as an alternative to code entry. This eliminates transcription entirely.

Email links as alternative. "Click the link in your email to verify" moves authentication from code transcription to a link click—often simpler for users with cognitive disabilities.

Hardware security keys. WebAuthn security keys offer excellent security with simple physical interaction. Support them as an option for users who can use them.

Account Recovery

Don't stack barriers. Password reset flows often combine security questions (memory test), CAPTCHA (cognitive test), and new password creation (complexity requirements). Each barrier is manageable alone; combined, they can completely block some users.

Security question alternatives. If you use security questions, offer alternatives for users who struggle with memory-based verification. Email verification links may be more accessible.

Communicate clearly throughout. Reset flow steps should explain what's happening, what's next, and what the user needs to do. Uncertainty adds cognitive load.

Multi-Step Form Best Practices

Progress and Navigation

Show clear progress. Multi-step forms need progress indicators showing current step, total steps, and step names. Make progress accessible—not just visual, but announced to screen readers and available to keyboard users.

Allow backward navigation. Users should be able to return to previous steps to review or change information. Trapping users in forward-only flow creates stress and prevents correction.

Preserve entered data. If users navigate back to previous steps, their previously entered information should persist. Losing work is frustrating and disproportionately impacts users who navigate more slowly.

Step Validation

Validate at step completion. Don't let users proceed to step 3 with errors in step 2. But present errors clearly and helpfully—not as punishment for clicking Next.

Field-level validation where appropriate. Immediate feedback on format errors (invalid email format, phone number) helps users correct issues immediately. But don't over-validate—marking fields as errors before users have finished typing is annoying.

Focus management on errors. When validation fails, move focus to the first error or to an error summary. Don't leave users unsure of what happened or where to look.

Reducing Cognitive Load

One question per screen (when possible). For complex forms, breaking into more steps with fewer fields per step can reduce cognitive load. Tradeoff: more steps means more navigation.

Save and continue. For lengthy forms, allow users to save progress and return later. Users who need frequent breaks shouldn't lose work.

Review before submission. The final step should show all entered information for review. Users should be able to edit any section before final submission.

TestParty for Form Accessibility

TestParty helps identify and fix the form accessibility issues that drive conversion problems.

Detecting common failures. TestParty's automated scanning catches missing labels, improper error associations, contrast issues in form elements, and missing fieldset/legend groupings—the issues that block users before they can even attempt your forms.

Code-level remediation. Beyond detection, TestParty provides specific fixes. When we identify a missing label, we show how to add it. When error handling is inadequate, we provide the ARIA patterns to fix it.

Continuous monitoring. Forms change as products evolve. TestParty's ongoing monitoring catches accessibility regressions in forms before they affect users.

Authentication flow testing. Login, signup, and account recovery flows are critical user journeys. TestParty's ability to scan authenticated experiences means your protected forms get the same accessibility attention as your public pages.

Conclusion – Forms as Conversion Gates

Accessible forms and accessible authentication aren't nice-to-haves—they're conversion necessities. Every form that blocks users with disabilities is a conversion you didn't get. Every authentication flow that demands transcription or object recognition is a user who couldn't log in.

WCAG 2.2's new criteria on authentication and redundant entry reflect what users have long known: forms are hard, and unnecessary difficulty is exclusionary. Building forms that work for everyone means:

• Proper labels and instructions so users know what to enter
• Clear error handling that identifies problems and explains solutions
• Keyboard operability throughout all form interactions
• Authentication without cognitive barriers (no CAPTCHA without alternatives, paste allowed in password fields)
• No redundant data entry within the same session
• Multi-step forms with progress, navigation, and data preservation

The reward for getting forms right is users who can complete the tasks your business depends on—signups, purchases, account management. The penalty for getting forms wrong is invisible: users who couldn't complete your forms and went elsewhere.

Ready to see where your forms stand? Get a free scan and identify the form accessibility issues blocking your conversions.

Related Articles:

• Automated Accessibility Remediation: Everything You Need to Know
• WCAG 2.2 for Product Teams: What Changed and What to Do in 90 Days