[WCAG 2.2 Draft Feedback] Success Criterion 3.2.6 Findable Help

[dshoukry]

“Success Criterion 3.2.6 Findable Help (Level A): For single page Web applications or any set of Web pages, if one of the following is available, then access to at least one option is included in the same relative order on each page:

• Human contact details;
• Human contact mechanism;
• Self-help option;
• A fully automated contact mechanism”

We kindly request significant changes to this SC. The SC requirement seems more aligned to help being available in the same "relative spatial position" rather than "same relative order". We also recommend ordering the affordances to meet this requirement to prioritize asynchronous help options that can happen at the user's preferred time, rather than human contact that may be restricted to business hours and time zone limitations. Additionally, some companies and customer service agents might not be trained to help people with disabilities, know the etiquette in speaking with PWDs, or be familiar with assistive technology. It may be beneficial to expand the help requirements and provide tips or examples of what might constitute effective self-help options, automated help options, and human help mechanisms.

Please find detailed specifics covered in our 3.2.6 Findable Help (Level A) Google Doc

Edit: As requested, I've just replaced the Google Doc link with a version with expanded access (didn't make any content changes). Sorry for the access issues with the previous link.

[alastc]

The group accepted this response:

---

Please note, some changes to the success criteria text have been made that should help address your comments. Please take a look at the new draft when it is announced.

Comment 1:

Is the intended meaning more aligned to "relative spatial position" or situations where help might appear after a list of dynamic length?

Clarifying that might prevent some misinterpretation. For example, would it be an issue if fields have the same heading level across all pages but different visual presentations?

Relative spacial position on the web is a tricky concept as it is so malleable, considering responsive design and other methods of adjusting the layout of pages. Therefore we decided to use the previous concept in WCAG of same relative order from 3.2.3.

Comment 2:

Can you please clarify in the text if the help options should be in the same relative spatial position across mobile and web versions of a product?

That depends on things outside the scope of this success criterion, primarily the conformance model, which goes by page (URL). So if the mobile version is a separate version, with separate URL, then they would not be the same page for conformance purposes. If they were the same URL, e.g. a responsive version, the intent is that it would maintain the same order.

For page-variations (the term we use in the conformance that covers different layouts for response versions/break-points), the intent is that it is the same order per-page-variation, not that it has to be the same order across page-variations. This is outlined in the understanding document lower down.

Change 1: Replace "a consistent location across pages" with "a perceivable and readily accessible location across pages".

There is no requirement in the SC for how perceivable or readily accessible the help mechanism is, so it would seem to be confusing to add that here.

Comment 3, on the 'same location' text in paragraph 3:

Does this mean that all help options need to be listed in same position of the page or under a help grouping, such as a help menu?

Would it be helpful to have help options in multiple locations like a chat icon and a chat link in a help menu?

It is up to the author/site how they display and/or link things, so long as there are help mechanisms in the same location (relative to other content) on each page.

Change 2: In paragraph 3, add "change" to the end of: "remain in the same location throughout the size change".

I see there's a problem here, but it doesn't quite make it right, I suggest that sentence is: "The location in a smaller viewport may be different than in a larger viewport but the mechanism or link will remain in the same location across pages of the same size."

Comment 4, regarding "The location should remain consistent both visually and programmatically"

What exactly is meant by this? It appears in a consistent location in the DOM?

Yes, which is the same meaning from 3.2.3.

Comment 5:

If a business decides to pursue the mechanism in the first bullet point (human contact details), does that bullet require all three of the provided examples are included, or only one?

In other words, is the recommendation that the details for the hours of operation for chat, SLAs for responses to emails, and general hours of operation all be listed? Or only one of those?

That is up to the site, it is an any or all situation. This area of the document is not normative, the requirement comes from the SC text.

Comment 6:

Were site maps or some sort of site index considered as a potential self-help mechanism?

Sitemaps / indexes were not considered, the idea is to link to help type material rather than all other areas of the website. Also, that requirement is already covered by 2.4.5 multiple ways.

Comment 7:

Can you please provide more examples of what does/doesn't qualify as sufficient "How Do I" and "Support" pages? Should these direct users to general or accessibility-specific pages?

The requirement is that people link through to whatever it is consistently, the SC is not specifying what is 'sufficient' help. As the first line of the intent says, it is for "help for completing tasks on a Web site", not accessibility specific.

Comment 8:

Does this mean that chatbots have to be identified as chatbots, rather than a chat function?

The bullet two lines up include chat functions (assuming with people), this line says "such as a chatbot" to cover the automated versions.

Comment 9:

As we mentioned in our second comment in this SC, this could be risky as it doesn't define how or require that the self-help option be sufficiently helpful, but rather just a description of what help options are available.

What if the link contains outdated or disconnected contact methods, or in an extreme example just says "no help is available"? Seems like this could be a loophole for sites to abuse and claim conformance, so long as the link to that page was placed consistently.

We had some long discussions about requiring certain forms of help, or just requiring a help mechanism. However, there are too many scenarios where some form of help many not be feasible, therefore we decided not to include such a requirement.

Comment 10 and 11:

Is there a recommendation on how to measure the proficiency of the chatbot? How do we determine if the chatbot is working correctly to be considered accessible?
...
Should there be a suggestion that X number of misspelled words or key phrases are accurately recognized?

The lines below are some indications, but it is not an area we can give guidelines for at this time.

Comment 12:

Can this SC (Findable Help) cite some of the techniques from Success Criterion 3.3.1 on Error Identification, since errors are so key to the help experience?

Also, can other techniques previously mentioned be added/expanded upon here in the Sufficient Techniques section?

Techniques are intended to be small units that fulfill a particular requirement, overlapping as little as possible with other criteria / requirements. It is something we can cross-reference, but including other SCs is not something we can support.

I'm not sure what you mean about 'techniques previously mentioned'? I couldn't see anything above that would become a technique, could you provide an example?

A small PR for some of the simple text updates will be created soon.

[alastc]

The response above was accepted by the group.