search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.11k stars 251 forks source link

Findable Help SC3.2.6 - is one option enough? #1235

Closed JAWS-test closed 4 years ago

JAWS-test commented 4 years ago

SC 3.2.6 requires that, even if several help options are available, at least one is provided on each page. Is this sufficient? In the Understanding, for example, a telephone number is given as an option. This help is not accessible to deaf people. I suggest: All help options should be linked or mentioned on one page. And this central help page should be accessible from all other pages.

guyhickling commented 4 years ago

I second this, it seems a somewhat arbitrary requirement. The Understanding doc, for instance, mentions FAQs and support pages as a method of help. But many websites will only link to the FAQs page from certain other pages, not all of them, and the link may be buried randomly in the text, not in the same position. But this SC says that if you already show the phone number in the page header, or some other help link, then those references to the FAQs page can remain as they are. In other words this SC requires no change on most websites.

guyhickling commented 4 years ago

Of course most websites have a Contact Us link to a Contact page, and that invariably shows in either the page header or page footer. So that fulfills the SC for those websites.

The problem there is that, often, not everything is shown on the Contact Us page. You may have to look elsewhere for things like a link to a FAQs page or support function.

Likewise, a Chat facility may be shown on the Home page (often using a link fixed to the right hand margin of the viewport, which means keyboard users have no idea how to get to it, and frequently it has no keyboard focus indicator for them anyway). But the same Chat facility is not usually referenced from the Contact Us page. If it were accessible from the Contact page as an ordinary link, it would not be so serious when the one fixed to the Home page is not accessible (I'm not saying that shouldn't still be fixed, or course, I'm just saying the Contact page would provide a workaround when it hasn't been done right).

So having thought about this a bit more now, it seems to me that if the SC were to be rewritten to require that all the help methods, whatever methods the site uses, were displayed and accessible from a Contact Us or similar page (which 90% of sites have), that would help all users. (And if it were to mention, perhaps in the Understanding doc, that the Chat facility should be on that page as an ordinary link in the content, not one fixed to the window frame, that would also help.)

This would achieve the aim of the SC much more comprehensively than the current version. And, for most websites, it would involve little extra work since most of them already have a Contact page already. All they have to do is add a few extra links or content items to it!

The Contact Us page would become the standard place to find all help methods on all websites.

alastc commented 4 years ago

Just a couple of initial thoughts:

SC 3.2.6 requires that, even if several help options are available, at least one is provided on each page. Is this sufficient?

Yes, what we were trying to avoid was requiring all help methods to be linked from every page, it would be unnecessary and counter-productive. E.g. Sites which provide more help methods could become noisy & overwhelming.

All help options should be linked or mentioned on one page.

Given how WCAG is scoped (by page, not by site), this is a tricky requirement to fulfil, and actually it would be a valid way of meeting the current SC. Other scenarios we need to consider are intranets, stand-alone tools which might have different help into compared to the rest of a site, and so on. Because WCAG can be used for pages/sections/sites/apps that do not necessarily fit a standard 'site' model, I'm not sure how that could be scoped.

guyhickling commented 4 years ago

what we were trying to avoid was requiring all help methods to be linked from every page

That's why we are advocating holding all the help methods (or links to them) on one page. And the Contact Us page, which most websites and apps already have, is made for the purpose. It already contains human contact details if any, and the human contact form where you type a query and submit it (and that can't be anywhere else but the Contact page - and there is no means of linking to that in the page header. You can't display a link to a form, only to a whole page.)

Placing all help in a central place would be really useful to everyone. It really only needs one or more links added on the Contact page, to whatever FAQs or other support page the site may have, and we are there. No need to ask developers to do anything they aren't already doing.

And for intranets, if they want to call that central page something other than Contact Us, that's fine as well. Just so long as it contains links to or instances of all the help methods the site has.

Given how WCAG is scoped (by page, not by site)

Do you meaning mandating linking from one page to another? I don't see why that should be a problem. There is no reason why we can't ask one page to link to another - that's what websites are all about. Pages are made up of links to other pages. Anyway, we already ask this in existing SCs. For instance 2.4.5 Multiple Ways - we say one recommended solution is a site map to link to other pages.

But the idea of having just one out of several help methods shown in the footer or header is useless to all those who either can't use that method, or want to use one of the other methods because of the kind of question they have, or because it's outside human support hours. This could be a useful SC, but I don't think it is in its present form.

scha14 commented 4 years ago

Draft response :

My understanding of this SC is that users should have at least one way to consistently access help from each page, if help is available. It doesn't prevent the addition of other help mechanisms in context of the content, or having all options in one place. The understanding document encourages contextual help with examples such as human help directing to the part of the organization that can help with the content in question. The more complex and large a website, the more FAQs or help methods it is likely to have. Requiring all methods of help in one place for all sites can be confusing and disorienting for a user, defeating the purpose of the SC to provide a consistent and cognitively easy way to access help from all pages. It would be nice to be able to say exactly which of the available methods make most sense in a given context for a user, but is likely too nuanced to be in scope of the SC.

alastc commented 4 years ago

This response was accepted by the group 8th Aug 2020:

Requiring all sites to have a dedicated page for all help options, especially for bigger sites, can be confusing and disorienting for a user defeating the purpose of the SC to provide a consistent and cognitively easy way to access help from all pages. It will also fail on smaller or single page applications with only 1-2 help options.

It would be nice to be able to say exactly which of the available methods make most sense in a given context for a user, but we would like to keep the success criteria fairly flexible in how organizations can fulfill it.