WCAG 2.2 Redundant Entry and Consistent Help: Smoother Multi-Step Forms

## The short answer

Two WCAG 2.2 Level A criteria target the friction of multi-step processes. **3.3.7 Redundant Entry** says that information a user has already entered (or that was provided to them) in the same process must not be required again, unless re-entering it is essential. **3.3.6 Consistent Help** (numbered 3.2.6) says that if help mechanisms - a contact link, phone number, chat widget, or help page link - appear on multiple pages, they must appear in the **same relative order** on each. Both are Level A, the baseline tier, so they apply even to minimal compliance efforts. Together they make checkouts, onboarding wizards and account setup less taxing, especially for people with cognitive or memory impairments.

## Redundant Entry: don't ask twice

Long forms often ask for the same information more than once - a billing address that repeats the shipping address, an email confirmed on one step and requested again on another, a name collected at signup and again at profile setup. For someone with a memory impairment, dyslexia, or who simply has many browser tabs open, retyping is error-prone and exhausting.

3.3.7 requires that within a single process, previously entered information is either:

- **Auto-populated**, so the user does not retype it; or

- **Available to select**, for example a 'same as shipping address' checkbox or a dropdown of previously entered values.

### What counts as the same process

A process is a sequence of steps to accomplish a task - a checkout, a multi-page application, an account setup wizard. The rule applies within that process and session. It does not force you to remember data across unrelated visits.

### The essential exceptions

Re-entry is allowed when it is genuinely necessary:

- **Security confirmation**, such as re-entering a password to confirm it, or re-authenticating before a sensitive change.

- **Where the previous value is no longer valid**, for example a one-time code that has expired.

- **Where the entry is the point of the step**, such as a memory or attention check that exists deliberately.

Outside these cases, asking again is a failure.

### Implementation patterns

- 'Same as above' checkboxes for repeated addresses.

- Pre-filling later steps from earlier answers.

- Showing a read-only summary the user confirms rather than re-types.

- Offering previously entered values in a selectable list.

## Consistent Help: put help in the same place

3.2.6 Consistent Help addresses a subtler issue: people who need help should not have to hunt for it. If your help mechanisms appear on multiple pages, they must keep the **same relative order** across those pages. If your header shows 'Search, Help, Account' on one page, it should not show 'Account, Search, Help' on the next.

### What counts as a help mechanism

- Human contact details (phone, email, postal address).

- A contact form or link to one.

- A self-help link, such as an FAQ or help centre.

- A fully automated contact mechanism, such as a chatbot.

The criterion does not require you to *provide* help - only that, if you do, its placement is consistent. The order is what matters, not pixel-identical positioning, so a help link can move within a responsive layout as long as its relative order among other items is preserved.

### Why order, not exact position

Responsive design legitimately moves things around between breakpoints. The criterion is pragmatic: it asks for a predictable relative order so users build a reliable mental model, while allowing layouts to reflow. The simplest way to comply is to render help links from a single shared component used on every page.

## Common failure patterns

- Billing forms that re-ask for the shipping address with no copy option.

- Multi-step applications that lose earlier answers and force re-entry.

- Help links that appear in the header on some pages and only in the footer on others, in a different order.

- Chat widgets that float in different corners on different pages.

## How we approach it

Both criteria are best solved structurally. When we build enterprise-grade products at neart.ai, multi-step flows share a single form-state store so later steps can pre-fill from earlier ones automatically, and the help affordances render from one shared layout component so their order is identical everywhere by construction. That turns two compliance criteria into a side effect of good architecture rather than a manual checklist.

## Testing it

- Walk through every multi-step flow and note any field that asks for something already provided. Each one needs auto-fill, a copy option, or a documented essential reason.

- Confirm a 'same as' option exists wherever addresses or contact details could repeat.

- Audit every page that shows help mechanisms and verify their relative order is stable.

- Check the help widget's position across templates, including responsive breakpoints.

## Practical takeaway

Inside any multi-step process, never ask for the same information twice - pre-fill it or offer a 'same as' option, reserving re-entry for security confirmations. Render help links and contact options from one shared component so their order is identical on every page. Both are Level A, so they belong in your baseline, not your wish list.