Does the help have to be accessible?

[JAWS-test]

In many WCAG audits I find that the linked help is excluded from the audit process because

• it is not part of the application or
• it is hosted on a separate domain or
• it cannot be influenced by the developer (e.g. in the case of frameworks) or
• it is in a different format and is not a web document, but for example a PDF or Word, or
• it would be too time-consuming.

This has always been problematic, but to my knowledge it is common practice. But now with WCAG 2.2 we will have the SC 3.2.6 "Findable Help" and I wonder what the SC will help if the help is then not accessible and is not checked for accessibility.

What are your experiences with this?

My suggestion:

• Include a note in Understanding SC 3.2.6 that the help must be accessible or
• New test criterion for accessible help or
• Create a new Conformance Requirement or
• make Website Accessibility Conformance Evaluation Methodology (WCAG-EM) a part of the WCAG, because the test of help is already defined there or
• consider the problem with WCAG Silver.

[alastc]

My personal experience is that, where help is separate, it can be useful to treat separately as it is created by a different system and usually by different people. It should be covered, but might need a separate testing report and calls etc.

How testing is scoped is not currently covered by the core WCAG 2.x spec, and the doc we do have (WCAG-EM) does suggest including help pages.

It is something to feed into Silver, I've tagged it as such.

[JAWS-test]

It should be covered, but might need a separate testing report and calls

I think that's fine too, but I think that in practice this hardly ever happens. The clients who order a WCAG audit will not order two tests (if only for reasons of cost and time), so they will always focus on the actual page or application and not on the help. This way the help is usually forgotten...

[guyhickling]

Of course this doesn't just apply to Help pages. Lots of other functions get incorporated into a website using add-ons from some third party. Online chat facilities (very important to users for getting specific help), newsletters, surveys. And often more critical functions as well that are absolutely necessary to use a website - bank card payment in shopping carts being the obvious example, and even they are often not accessible though you would have thought the big banks would have managed that one by now! Sometimes, of course, the website may be using an out of date version that they added 10 years ago and they just need to update.

What I do when auditing (especially for critical pages like payments) is to assign one issue for that third party page. I provide a quick summary of everything wrong with it (it's usually a long list!), but without providing detailed solutions (since the client is obviously not going to be able to remediate the page themselves).

I then add a strong paragraph about how they must either find a different third party supplier or bring the programming of that page in house. (I don't usually suggest contacting the third party supplier asking for them to make their add-on compliant because you can wait forever and a day for that to not happen!) And if it is a US website in scope of the ADA I lay it on the line that if their users can't make payments or something important like that, they can be taken to court for their own website not working even though it is a third party page that is at fault.

So I test such a page briefly, and report the results, but it is down to the client to do the right thing.

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.