Wcag: In the 'findable help' SC, the language of 'if one is available' is unclear, as is 'maintaining place in the flow of content'

Created on 12 Aug 2020  Â·  9Comments  Â·  Source: w3c/wcag

This SC, if I'm reading it correctly, seems to want to enforce two things:

  • if the authors of a website or SPA can offer one of the four 'higher' forms of help outlined, then they must offer at least one of those (he language of 'if one is available' doesn't feel definitive enough, and could be read as 'if one exists currently on the site/SPA'.)
  • when that help is offered, it must be done so consistently across the interface - this makes sense, but feels ripe for lots of different interpretation. For example, if what's in a
    changes across pages, so long as a 'contact us' link stays in the
    , does that pass? What if a website passes to a new url which hosts part of its website' s functionality, but it's impossible to contain the 'contact us' link in that site's
    ? Even if the 'contact us' link is present, does that then constitute a fail?

The examples and techniques seem to speak to 'types of help' and not about about 'circumstances in which the help made available passes or doesn't because of the additional requirement for 'consistency'.

3.2.6 Findable help Public Comment Surveyed - Left Open WCAG 2.2

Most helpful comment

I also find "if one of the following is available, then access to at least one option" very confusing. I did not interpret it as "if you can offer it, you must offer it"; I interpreted it as "if you do offer it, make it available in the same location on every page". Even so, the language is not quite right. I would rather have "if one or more of the following are available, then access to at least one is included..."

It would be good to have some clarity on what the requirement actually is and slightly rewrite the success criterion to better explain it.

All 9 comments

I also find "if one of the following is available, then access to at least one option" very confusing. I did not interpret it as "if you can offer it, you must offer it"; I interpreted it as "if you do offer it, make it available in the same location on every page". Even so, the language is not quite right. I would rather have "if one or more of the following are available, then access to at least one is included..."

It would be good to have some clarity on what the requirement actually is and slightly rewrite the success criterion to better explain it.

if the authors of a website or SPA can offer one of the four 'higher' forms of help outlined, then they must offer at least one of those

@EmanuelaGorla's interpretation was correct: If you offer one of the forms of help, then you must link to it (or at least one) from a consistent location.

Adding that proposed text would make it:
"For single page Web applications or any set of Web pages, if one or more of the following is available, then access to at least one option is included in the same relative order on each page:"

Proposed changes : #1356, #1357. Change "if one of the following is available" to "if one or more of the following is available"

For the second part of the original comment, the SC is intended so users have a consistent way of finding help on a web page or a set of webpages as defined in the understanding document, not the types of help depending on circumstances.

@camusamta please comment if we can follow the first change on a duplicate issue here and close this issue. Thank you

We are now seeing a number of people commenting on how difficult this SC is for people to understand. @littlea11ywidget said a similar thing in #1314. It makes you wonder just how much confusion there will be amongst the developers and managers who try to apply it once it goes live!

To my mind, even with the amendments proposed so far it is still going to be one of the most incomprehensible SCs around!

Also I don't think @camusamta's point above has been answered properly. The Understanding says nothing about his point of other web pages, and the phrase "set of web pages" is so vague, even after looking it up in the glossary, as to be meaningless. So we now have pages of this site hosted on another site as @camusamta mentioned (for instance where a company's intranet includes a page from their main site, or where a third party's page is included). Someone a while back also asked about copies of a web page created on a website specifically to be printed (where typically the main menu and other header details may not be included.) Also Terms and Conditions pages which often don't show the main menu or other header details. And no doubt other cases I haven't thought of. These are all real life situations that need to be discussed and clarified in the Understanding document.

This is the part in the understanding document that covers PDFs and other static pages

It is not the intent of this Success Criteria to require authors to provide help information on PDFs or other static documents that may be available for viewing/download from the Web pages. It is also not the intent to require contact information if:

A Web site is not supported,
Content is archived, or
When finding help would invalidate the activity such as in a testing situation.

I wonder,would it help to have a wireframe to support the text?

On Tue, Sep 1, 2020, 12:06 PM scha14 notifications@github.com wrote:

This is the part in the understanding document that covers PDFs and other
static pages

It is not the intent of this Success Criteria to require authors to
provide help information on PDFs or other static documents that may be
available for viewing/download from the Web pages. It is also not the
intent to require contact information if:

A Web site is not supported,
Content is archived, or
When finding help would invalidate the activity such as in a testing
situation.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1287#issuecomment-684964649, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHGRTWRHISDRYXIWDRDJWPTSDULW3ANCNFSM4P3ZLWCA
.

Oh scratch that. I just went back and reread the thread :)

On Tue, Sep 1, 2020 at 9:17 PM caroline woodward.caroline@gmail.com wrote:

I wonder,would it help to have a wireframe to support the text?

On Tue, Sep 1, 2020, 12:06 PM scha14 notifications@github.com wrote:

This is the part in the understanding document that covers PDFs and other
static pages

It is not the intent of this Success Criteria to require authors to
provide help information on PDFs or other static documents that may be
available for viewing/download from the Web pages. It is also not the
intent to require contact information if:

A Web site is not supported,
Content is archived, or
When finding help would invalidate the activity such as in a testing
situation.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1287#issuecomment-684964649, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHGRTWRHISDRYXIWDRDJWPTSDULW3ANCNFSM4P3ZLWCA
.

Hi everyone, we discussed this in a meeting and whilst agreeing with the substance of the comment, it's a hard terminology problem.

We tried: adding 'option' to both ends, and tried the terms mechanism, method, feature, means and ways. Each of these, particularly mechanism/method/feature imply things we do not intend.

We'd like to propose going with this as the first part of the SC text:

For single page Web applications or any set of Web pages, if one or more of the following ways of finding help is provided, then access to at least one way of finding help is included in the same relative order on each page:

Also given the discussion here, does resolve the issue you raised?

Closing this to address in the issue #1242, where all issues are combined. Please reopen if this remains unaddressed. Thank you!

Was this page helpful?
0 / 5 - 0 ratings