Redundant Entry and Consistent Help in WCAG: applying 3.3.7 and 3.2.6 to your checkout

Redundant Entry (WCAG 3.3.7): what the criterion says

The W3C states the goal plainly: make it easier for users to complete multi-step processes. The practical rule fits in one line: don't ask for the same information twice in the same activity. The reason is just as direct: some people with cognitive disabilities have difficulty remembering what they entered before.

When information has to be entered again in the same process, the criterion gives you two ways to conform:

• auto-populate it;
• make it available for the user to select.

Why asking twice is a barrier

According to the W3C, information that must be remembered for input can be a significant barrier for users with cognitive or memory difficulties. All users experience natural, gradual mental fatigue as they move through the steps of a process, and that fatigue is accelerated by the stress of recalling information from short-term working memory. Users with learning and cognitive disabilities are highly susceptible to it.

The practical consequence: requiring people to recall what they already entered can make them give up, or re-enter the same information incorrectly. The W3C names three groups who benefit:

• users with short-term working memory difficulty, for whom not having to remember reduces stress and the likelihood of mistakes;
• users who have difficulty forming new memories or recalling information, who can complete processes without relying unnecessarily on memory;
• users with mobility impairments, for example using switch control or voice input, who have less text to enter.

Scope of 3.3.7: processes, sessions and browser autocomplete

Browser autocomplete is not enough. The W3C is explicit that the content, meaning the website, must provide the stored information or avoid asking for it again.

The criterion does not require storing information between sessions. A process is defined by an activity and does not apply when a user returns after closing a session or navigating away. A process can, however, span different domains: if your checkout includes a third-party payment provider, that step is in scope.

The criterion does not apply when the user provides data by a different method, such as uploading a résumé as a document. It contains no privacy-specific requirements or exceptions, but the W3C notes that authors should ensure data protection when storing information, even temporarily, during a process, since a poor implementation could leak additional personal data.

"Available to select" is deliberately not prescriptive, leaving room for techniques where auto-population isn't possible. The data does need to be on the same page, ideally visible by default and close to the input that needs it, though it can sit elsewhere on the page, including inside a show/hide component. In practice, it can mean letting the user:

• select a value to populate a field, including from a drop-down;
• select text on the page and copy it into an input;
• tick a checkbox to reuse previous values, such as "my billing address is the same as my shipping address".

The three exceptions to Redundant Entry

The criterion allows information to be requested again in three cases, each clarified by the W3C:

• Re-entry is essential: for example a memory game, which would be invalidated if previous answers were supplied.
• The information is required for the security of the content: for example preventing a password string from being shown or copied. If the system asks the user to manually create a password that is not displayed, having them re-validate the new string is allowed.
• The previously entered information is no longer valid: the user can then be asked to enter it again.

Redundant Entry examples in a checkout flow

The W3C examples map directly onto a purchase journey. On the address step, offer a way to confirm that billing and delivery addresses are the same. If a customer submits the payment form with an incorrect credit card number, the page shows an error message, but the submitted information, including the card number, is not cleared from the form.

Another cited case: a form for buying a new computer asks for the user's corporate ID in step one; in step three it shows the ID again, lets the user change it, but defaults to the one already entered. Likewise, a search results page pre-fills the search input with the term entered earlier in the same process.

The snippet below shows the "same address" checkbox: when ticked, it copies the shipping values into the billing fields. The W3C lists G221, provide data from a previous step in a process, as a sufficient technique, along with not requesting the same information twice as a potential future technique.

<fieldset>
  <legend>Billing address</legend>
  <input type="checkbox" id="same-address">
  <label for="same-address">Same as shipping address</label>

  <label for="bill-street">Street</label>
  <input id="bill-street" name="bill-street">
  <label for="bill-city">City</label>
  <input id="bill-city" name="bill-city">
</fieldset>

<script>
  // Values entered at the shipping step of the same process
  const shipping = JSON.parse(sessionStorage.getItem('shipping') || '{}');
  document.getElementById('same-address').addEventListener('change', (e) => {
    if (!e.target.checked) return;
    document.getElementById('bill-street').value = shipping.street || '';
    document.getElementById('bill-city').value = shipping.city || '';
  });
</script>

Consistent Help (WCAG 3.2.6): keep help in the same place

SC 3.2.6 aims to make help and support easier to find. If a page contains one of the listed help mechanisms and that mechanism is repeated on multiple pages within a set of web pages, it must occur in the same order relative to other page content, unless a change is initiated by the user. The mechanism can be on the page itself or a direct link to another page containing the information.

"The same order" can be thought of as how content is ordered when the page is serialized. When testing, look at the help item relative to the rest: content present across the set of pages that comes before the help item on other pages should come before it on this page, and content after it should stay after it. Help that sits in a different visual location but in the same serial order is not helpful to users, yet it does not fail the criterion. The W3C lists four types of mechanism, in no order of priority, with typical examples:

• human contact details, for example: phone number, email address, hours of operation;
• human contact mechanism, for example: messaging system, chat client, contact form, social media channel;
• self-help option, for example: up-to-date FAQ, How Do I page, Support page;
• a fully automated contact mechanism, such as a chatbot.

Consistent Help exceptions and good practice

The criterion does not require you to provide help: it only applies to pages that include it, and missing help on some pages is not a violation. It does not cover PDFs or other static downloadable documents, does not require a human to be available at all times, and lets distinct sets of pages (for example an app and its marketing site) use different locations, although the W3C considers it best to stay as consistent as possible even among related sets of pages.

The "change initiated by the user" exception covers changes such as zoom level, orientation or viewport size, so help may sit elsewhere on a small screen, although the W3C notes that a consistent location, both visually and programmatically, is the most usable. Navigating between pages is not such a change, and logging in or out typically isn't either, unless logging in presents a distinct set of web pages.

In your checkout, if you show a Contact link or customer service number on the cart, shipping and payment steps, keep it in the same position relative to other content, for example in the header. The sufficient technique cited is G220, provide a contact-us link in a consistent location; the documented failure is an inconsistent help location. Finally, in an advisory section the criterion does not require, the W3C notes that chatbots can work well, particularly for people with cognitive disabilities, if they recognize misspelled words, provide human contact details when they can't give a satisfactory response after 3 attempts, and can be dismissed with a single interaction and recalled with a link or button.

Frequently asked questions

Further reading on Conformly

• Understanding the RGAA 5 framework
• Accessibility for e-commerce websites
• RGAA criterion 11.12 in detail

Sources

This article relies on the official sources listed at the end of the page.

• W3C — Comprendre 3.3.7
• W3C — Comprendre 3.2.6