This is the first in a series of articles, looking at how to test each of 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.2.6 Consistent Help is about the consistent placement of information that provides general help to users, including points of human contact, and automated help mechanisms. It would include things like a telephone number or email address, or an embedded chat window, where users can get help with the site, or with the company’s service in general.
This SC does not require that such things be provided, only that if they are provided, they can be found in a consistent location. Whether this amounts to a direct mechanism (e.g., chat window), or direct information (e.g., phone number), or is just a link to another page on which those things can be found, is not significant; the requirements of 3.2.6 apply to the information or link as it’s presented.
This is helpful for all users, but may particularly benefit some users with cognitive or memory impairments. When the location of a help mechanism is consistent throughout the site, users who are looking for help should be able to find it more easily.
Normative requirements
If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
The same relative order
is a key term here, which refers to the serialized order, not the visual order. Ideally, the serialized order and visual order would be the same, however this is not required for conformance with 3.2.6. The serialized order can be tested by inspecting the source code, or by viewing the page with CSS disabled.
More specifically, it means the same order relative to other content which is also repeated on every page. In the case of a global header, for example, only content that’s always in the header needs to be considered. Something like an ad-hoc promotional link, which only appears on one page and changes the relative order of the help mechanism on that single page, can be ignored.
When the site has a responsive design, the breakpoints might produce layout variations in which the content order is different. Ideally, the content order would be the same at every breakpoint, however for the purposes of this SC, consistency is only required within a single breakpoint.
The same consideration applies when a site uses more than one template, for example, if there’s a public area and a members area, each with a completely different layout. Consistency between these layouts is not required, because each of them constitutes a different set of web pages
.
Practical ambiguities
This SC is largely concerned with contact information that’s a channel for getting help, but in plain language, contact does not imply help. However, since the normative requirements explicitly define a help mechanism
in terms of contact
, it must be inferred that all points of human contact constitute a help mechanism, even if the site owner didn’t intend them to be a channel for getting help.
One relevant example here would be a company’s corporate address in the footer, which might only be there for administrative or legal reasons. But since it is a point of human contact, it should still be considered a help mechanism for the purposes of 3.2.6, and therefore subject to the requirements of this SC.
The concept of relative order
also doesn’t specify how much other page content
is embraced by it. In the case of a global header, for example, is it all the repeated content in the header, or just the previous and next elements, or what? The understanding docs explain it like this:
When testing this Success Criterion, it is the help item which is relative to the rest of the content. When testing a page, other content that is present across the set of web pages and is before the help item should be before the help item on this page. Items which are after the help item on other pages should be after the help item on this page.
Which doesn’t really answer the question. But it can’t be locked-down any more precisely than that, because too much precision can lead to loopholes or false-negatives, where the technical definition might conflict with intuitive expectations. So this is one of those “common sense” kind of things, that you can evaluate with broad judgments — once a user knows where to look for the help mechanism, it’s then always in the same place, such as, always at the end of the header, or always after the search field, something like that.
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 deeply ironic, but ultimately unavoidable.
But in this case, there are no apparent barriers to testing. Testing can be done by inspecting the source code, or by reading the content in serialized order, neither of which imply any specific limitations or barriers.
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 test whether the same content is present on multiple pages.
But even if they did, they can’t reliably identify the same content on different pages anyway. It could only identify that by scanning the markup. However two pieces of markup on different pages might have incidental variations, such as slightly different class names or other attributes. This means that automation cannot unambiguously determine when two pieces of markup are the same functional content.
Advances in LLM (Large Language Model) analysis might make this possible in future.
Manual testing
The manual testing steps are quite straightforward:
- Identify the presence of a help mechanism on more than one page.
- Verify that it appears in the same relative position on every page.
- If the design is responsive, repeat the testing steps for each responsive breakpoint.
Yielding one of three expected results:
- Pass: The relative position of repeated help mechanisms is consistent on all pages within the set of web pages.
- Fail: The relative position of a repeated help mechanism is inconsistent between pages.
- Not Applicable: There are no repeated help mechanisms.
