Redundant entry and consistent help in WCAG 2.2

WCAG 2.2 added two Level A criteria. Under 3.3.7 Redundant Entry, a process must not make people type again what they already gave you. Under 3.2.6 Consistent Help, help that appears on several pages stays in the same place relative to the rest of the content.

3.3.7 is tested by walking a process and 3.2.6 by comparing pages, and a checkout exercises both, which is why this post takes them together.

Our checklist has failing and passing examples for 3.3.7, and for 3.2.6.

Redundant entry (3.3.7)

The criterion reads: “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.”

Three exceptions apply:

• Essential: re-entering it is essential, as in a memory game.
• Security: it is needed for security, such as typing a new password a second time to confirm it, when the password is not shown on screen.
• No longer valid: the earlier information is no longer valid.

A process, in WCAG’s words, is a “series of user actions where each action is required in order to complete an activity”, such as a checkout or an application. It can cross domains, so a payment step run by another company is part of the process. It does not cover a new visit: nothing has to be remembered once someone closes the session or navigates away and comes back.

“Available to select” is not one fixed pattern. A drop-down of earlier answers, a “same as delivery address” checkbox, or the earlier value shown on the page so it can be copied all count. It must be on the same page, though it can sit in a section that opens and closes.

Browser autofill is not enough on its own: the W3C’s guidance is that the site has to provide the information again, or not ask for it. Setting the right autocomplete values still helps people fill fields faster, and it is a separate criterion, 1.3.5 Identify Input Purpose, at Level AA.

3.3.7 is one of the two Level A criteria among the nine WCAG 2.2 added.

Walking a checkout

1. Basket. If the basket asks for quantities, it shows the ones already chosen.
2. Delivery. The customer enters a delivery address.
3. Billing. The billing address step offers the delivery address instead of asking for it again.
4. Payment. If the card number is rejected, everything the customer entered, including the card number, stays in the form so it can be corrected.
5. Review. Changing an answer reopens it with the earlier value filled in. Showing the answers for checking before paying is one way to meet a different criterion, 3.3.4 Error Prevention (Legal, Financial, Data), at Level AA.

Step 3 is the classic failure: a blank billing address form after the customer has just typed the same address. A checkbox fixes it:

<fieldset>  <legend>Billing address</legend>  <label>    <input type="checkbox"           name="billing-same" checked>    Same as delivery address:    12 Harbour Street, Aarhus  </label>  <!-- fields appear if unticked --></fieldset>

Step 4 fails when a rejected card clears the form. The fix is to render the form again with what was submitted:

<label for="name">Name on card</label><input id="name" name="name"       autocomplete="cc-name"       value="Mette Jensen">​<p id="num-error">The card number is too  short. Check it and try again.</p><label for="num">Card number</label><input id="num" name="num"       autocomplete="cc-number"       value="4929 1234 5678"       aria-invalid="true"       aria-describedby="num-error">

The W3C’s own example keeps even the rejected card number, so the customer can correct it rather than type it again. If the checkout asks the customer to sign in partway through, that step has its own criterion: see what 3.3.8 asks of passwords and codes.

Consistent help (3.2.6)

The criterion applies to four kinds of help, when one of them repeats across a set of pages:

• Human contact details, such as a phone number or an email address.
• A human contact mechanism, such as a contact form or a chat with a person.
• A self-help option, such as an FAQ or a help centre.
• A fully automated contact mechanism, such as a chatbot.

Each has to appear in the same order relative to the other content that the pages share. The order is the order of the content in the markup, the serialised page that a screen reader follows, not its position on the screen. Help can be on the page itself or one direct link away.

The criterion does not require you to offer help at all. It applies to a set of web pages with a shared purpose and author, so another set of pages, such as an app beside its marketing pages, or a downloadable PDF, can place help differently. A change the visitor causes is excepted: zooming or a narrower window may move help in a responsive layout. Following a link to another page is not such a change, and logging in or out usually is not either.

How to test both

1. Walk each key process from start to finish, entering real-looking data.
2. Note every value you enter. When a later step asks for one again, check that it is filled in or offered to select, or that one of the three exceptions applies.
3. Trigger an error at each step and check that the other answers survive.
4. On one page of each template in the set, list the help mechanisms and what comes before and after each, at the same zoom and window width. Compare the lists.

Neither has an automated check of ours. A rule can compare repeated navigation across pages, but telling whether a later field asks for the same information as an earlier one, or whether a link is help, takes a person.