Continuing our series of articles on how to test the new Success Criteria (SC) in WCAG 2.2.
Detailed conformance and testing information can also be found in KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Essentials or Enterprise tier subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.
Success Criterion 3.3.7 Redundant Entry is about preventing users from having to re-enter duplicate information, within the same process, in order to reduce cognitive load. For example, a multi-page application form might ask for the user’s name and address in more than one place. In such cases, the information they’ve already entered must either be auto-populated in the form, or available for them to select, unless that information is no longer valid or applicable.
Multi-step processes can be mentally tiring, and this is exacerbated when the process requires the user to recall or transcribe information. Users with learning or cognitive disabilities are particularly susceptible to mental fatigue, since they generally have reduced working memory or increased cognitive load to begin with. So this SC may be particularly beneficial for such users, and also for users with mobility impairments who rely on voice-recognition or switch controls, for whom data entry can be extremely laborious.
Normative requirements
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.
Except when:
- re-entering the information is essential,
- the information is required to ensure the security of the content, or
- previously entered information is no longer valid.
Browser autocomplete doesn’t count as a means of avoiding redundant entry. The user might have their name and address saved in their browser, for example, but the availability of that is not sufficient to pass this SC. It’s the site itself that needs to provide the functionality.
The exceptions to this SC cover a broad range of situations where repeating the information might be necessary. Some examples of this would be a password confirmation field, which asks you to enter the same value twice to verify they’re the same, or a credit card field that asks you to re-enter your card details, when a prior payment attempt was declined.
This SC does not apply in cases where the previously entered information was in a different format. For example, if an online application requires the user to upload their resume in a document format, and also requires them to enter their employment history in a web form. The site wouldn’t be able to reliably identify and extract this information from a PDF or Word document, and therefore the requirements of this SC don’t apply.
Practical ambiguities
Information being “available to select” is not rigidly defined, it just means that there’s some way for the user to enter previous information without having to recall or re-type it. This might be a dropdown from which they can select previous input, or it might something like a checkbox for “Use my billing address as my shipping address”, or it might just be static text that the user can copy and paste from. Whatever means is provided, it must be on the same page, but it’s not required to be programmatically associated with the form.
The term “same process” also means same session, but doesn’t include persistent storage of data between sessions. If the user is part-way through a multi-step form, then closes their window and comes back to it later, this doesn’t count as the same process, even if all the session data was preserved, because the user has navigated away from the site. However a process can still include steps from another site, if they’re clearly part of the same process, such as a checkout flow that redirects to a third-party payment processor, before returning to the original site.
Testing barriers
Some SCs can’t be tested by engineers with particular disabilities, such as those concerned with the visual appearance of content, which can’t be tested by someone who’s blind. This is unfortunate and ironic, but ultimately unavoidable.
But in this case, there are no apparent barriers to testing. Testing can be done just by working through the process as a user would, which doesn’t imply any specific limitations or barriers (assuming that the workflow itself is sufficiently accessible).
Automated testing
This SC can’t be tested by automation.
Automation suites generally don’t hold memory between page views, they test single pages, and don’t hold previous snapshots in order to compare multiple pages. But even if they did, the automation wouldn’t be able to assess exceptions, such as whether the duplication is necessary, since that requires a human judgment call.
Auto-population, or information available to select, could potentially be identified, if the automation has access to session data. But it might require complex text analysis to determine whether the data is the same as previously entered information, since it wouldn’t necessarily be character-by-character identical (e.g., if the postal address you entered was reformatted to a regional convention, and then re-populated in the new format).
This kind of text evaluation isn’t something that automation suites typically do, although LLM analysis might make it practical in future.
Manual testing
Manual testing can be performed in the following steps:
- Identify the presence of form fields, within the same process and session, that ask for redundant (previously entered) information.
- Ignore those where (either):
- previous information was in a different format (e.g., word document);
- duplicate entry is required for verification (e.g., confirming password);
- duplicate entry is required for security (e.g., re-entering your name for digital signing);
- duplicate information is no longer valid (e.g., updating card details when payment was declined);
- duplicate information is essential (e.g. memory game).
- Verify that redundant information is (either):
- auto-populated (not including browser autocomplete);
- available for the user to select, for example:
- a dropdown with previous information that auto-fills on selection;
- a checkbox such as “use my billing address for shipping”;
- text on the same page that can be copy-pasted.
Yielding one of three expected results:
- Pass: All redundant entry is either auto-populated or available for the user to select, or an exception applies in cases where it isn’t.
- Fail: Some redundant entry is neither auto-populated nor available for the user to select, and no exceptions apply.
- Not Applicable: There are no form fields that require redundant entry.
Glossary
Resources
- Understanding SC 3.3.7: Redundant Entry (Level A)
- Accessibility Testing with WCAG 2.2 (Webinar Video)
- Accessibility Testing with WCAG 2.2 (Webinar Transcript)
- New Success Criteria in WCAG 2.2
Image credit: JD Hancock.
