search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Finding help #43

Closed lseeman closed 7 years ago

lseeman commented 7 years ago

Current versions of SC and Definitions

Finding Help

            <p> Help content, support page or support function is reachable with one user action. 
            When human help is available the correct contact information or help is reachable within 
            one user action for voice menus and a maximum of two user actions in other modalities. 
            </p>
            <h2>Suggestion for Priority Level: AA  </h2>

AA

            <h2>Related Glossary additions or changes</h2>
            <p> <b> user action:</b> the intentional interaction taken by the user to manipulate the content of the page. </p>
            <h2>Principle and Guideline</h2>
            <p> <span id="docs-internal-guid-9beb1966-7e1e-2237-1842-37b1f5028a79">Principle 2 Operable, Guideline 2.4 </span><a href="https://www.w3.org/TR/WCAG20/#navigation-mechanisms">Provide ways to help users navigate, find content, and determine where they are.</a> </p>
            <p>or</p>
            <p>Principle 3, Guideline 3.5 'Help' or Principle 3, Guideline 3.1 'Readable' </p>
            <h2>Description</h2>
            <p> Help content enables a user to conveniently access information needed to understand how to use the website effectively. 
            Users who need help content are usually already confused. The existence of the help content or support page and support function 
            should be obvious to the user and reachable within one user action whenever they require it. 
            </p>
            <p>
            When human help is available the correct contact information or help is reachable within one user action for voice menus and a maximum 
            of two user actions in other modalities. Human help includes:
            <li> Live help option. Note: It must be easy and clear to close the window. </li>
            <li> A phone number that will automatically call via an interoperable Voice over IP specification. </li>
            <li> A simple contact us form. </li>
            <li> Use available standards to get human help such as using the 0 digit on voice menu systems. </li>

Benefits

            <p> This Success Criterion enables users to: 
            <li> access quick answers to  questions </li>
            <li> easily get human help when available </li>
             </p>
            <h3 id="resources2">Related Resources (optional)</h3>
            <p> Resources are for information purposes only, no endorsement implied. </p>
            <p> 
            <li> <a href= "https://rawgit.com/w3c/coga/master/gap-analysis/#table-4-help-and-support"> Gap analysis Table 4: Help and support</a></li>
            <li> <a href="https://rawgit.com/w3c/coga/master/gap-analysis/table.html">User needs Tables</a> Table 3: Entering data, error prevention &amp; recovery</li>
            <li><a rel="nofollow" href="https://w3c.github.io/wcag/coga/user-research.html">Background research document</a></li>
            <li><a rel="nofollow" href="https://w3c.github.io/personalization-semantics/">Semantics for adaptive interfaces</a>                </li>
            <li><a href="https://rawgit.com/w3c/coga/master/issue-papers/personalization-preferences.html">Personalization and Preferences</a></li>
            <li><a href="https://rawgit.com/w3c/coga/master/issue-papers/voice-menus.html">Voice Menu Systems</a></li>
            <li><a href="https://rawgit.com/w3c/coga/master/techniques/index.html">COGA Techniques</a></li>
            </p>

Testability

            <h3>Procedure</h3>
            <ol>
            <li>Check that help content, support page or support function exist and is reachable with one user action.</li>
            <li>When human help is available the correct contact information or mechanism should be reachable within two user interactions. </li>
             </ol>
            <h3>Expected Results</h3>
            <ul> <li> All checks above are true </li> </ul>
            <h2>Techniques</h2>
            <ul>
  • Making the help content reachable with one user action.
    •               <li> Making the human help reachable within two user interactions. </li>
              <li> Providing a link to help content in the header and footer, especially on long pages and the home page.</li>
              <li>Using COGA semantics to enable extra help on standard controls</li>
              <li>Using COGA semantics to enable symbols</li>
  • using personalization to make help easily available
    •             </ul>

    working groups notes (optional)

    LJWatson commented 7 years ago

    This feedback is based on a collective review by @SteveFaulkner @PatrickHLauke @JSpellman @Sarah-Horton and @LJWatson

    Enabling people to find help easily is important, but it isn't clear exactly how this SC could be met.

    What is a "user interaction"? If a single key press constitutes one user interaction, it seems this SC cannot be met for keyboard users?

    If user interaction is defined more loosely (two key presses for example), it might be possible to meet this SC but it would be at the risk of negatively impacting usability for keyboard users. It would be necessary to introduce help triggers within one tab stop of every piece of content (where help might be required). This risks introducing a large number of additional tab stops to the overall document.

    The SC seems to allow for a help trigger to be included only in the header and/or footer. This would avoid the risk of additional tab stops, but would introduce a discoverability problem. People using screen readers and screen magnification may be unaware that either trigger exists - and the act of discovering them would require many more than a single user interaction.

    The intention of this SC is admirable, but we feel it would be difficult to meet it within the framework of WCAG and suggest it is moved to the Silver TF for future consideration.

    jspellman commented 7 years ago

    Since the problem seems to be the "one user action" I recommend removing that part (admirable though it is, it causes too many problems for keyboard users) and just saying that a prominent link to help content, support page or support function is provided.

    Recommended change: Finding help: Provide help content, support page, or support function that is prominent (e.g. inline instructions in a contrasting color, a link in the footer to a support page with a bright ? symbol, a floating control in the right margin for a chat window). (Level AA)

    Definition for Prominent (hopefully used elsewhere) Prominent: A heuristic measure of how likely users are to notice a user interface component in a user interface that they are operating. Prominence can be measured in comparison with other, similar user interface components. Prominence is affected by numerous factors, including: the number of navigation steps required, the reading order position, and visual properties (e.g. size, spacing, color). [re-phrasing of the ATAG definition]

    inclusiveThinking commented 7 years ago

    We also had "one user action" come up in a conversation around the glossary definition of help in another SC and removed it there as well earlier.

    mapluke commented 7 years ago

    I really don't like this change at all, because I think that "Prominent" is way too subjective and untestable.

    We really need to get this fixed as I think that there may be many SCs (see below) where we want to require that vital functionality that needs to be easily and quickly accessed should not be hidden as a buried menu item.

    Maybe "one user action" may need careful definition to make it clear that performing that intentional action may require multiple lower-level actions,

    I've proposed the following for #48: Glossary entries:

    A more precise concept that was used in Europe for EN 301 549 (our Section 508 equivalent), and that was accepted by industry, disability bodies and those procuring ICT. It said that controls to activate/de-activate captions:

    so maybe some variant of that could be used?

    lseeman commented 7 years ago

    +1 to MG.

    jspellman commented 7 years ago

    Hi Mike, I agree that this is a bear to define. ATAG worked on it for many months before coming up with Prominent. It is testable -- possibly even able to be automatically tested -- because it is a iterative comparison with the other controls or components on the site. Actually, it is more flexible than EN 301 because "prominent" also allows visual highlighting. However, I'm ok with the EN 301 definition (I'm always in favor of harmonization). How about "easily available: controls or information provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the secondary navigation or equivalent." -- I'm ok with putting at primary navigation level, but I think secondary will have better acceptance.

    mapluke commented 7 years ago

    I just quickly checked the ATAG usage and I think their definition works well in the "at least as prominent" usage. I think there might be some posay something say something similar here, but I'm not in a good place at the moment to propose a perfect solution (waiting in a busy hospital outpatients area - luckily I'm not the patient).