Labels and instructions

[lseeman]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• SC in full draft guideline

  Labels or Instructions

          <h3>Current:</h3>
      <p><strong>3.3.2 Labels or Instructions:</strong> Labels or instructions are provided when content requires user input (Level A).</p>
          <h3>Proposed:</h3>
          <p >@@<strong>3.3.2 Labels or Instructions: </strong>Labels or instructions are provided when content requires user input. Labels and instructions:</p>
                <ul>
                    <li>Fully describe the input's function</li>
                    <li>Use the default format and standards for localized content in the location of the user and allow for changes of format on labels and user input. An exception is provided where any standard format is accepted.</li>
                    <li>Explain where to get the required information. An exception is provided where the information is known by the intended audience. </li>
                </ul>
                <p>Note: Information is known by the intended audience includes the user's name, phone number,  address, date of birth and other information where <em>user testing</em> has shown that the information is known by the intended audience.@@.</p>
      <h2>Related Glossary additions or changes</h2>

  user testing - this has been defined in other SC's

      <h2>What Principle and Guideline the SC falls within.</h2>
      <p>Principle 3, Guideline 3.3.<br>
        Update to 3.3.2</p>
      <h2>Description</h2>
      <p>The intent of this success criterion is not only to have content authors implement instructions or labels when content requires user input but for these instructions or labels to be implemented in a way that is beneficial to users with cognitive disabilities. The success criteria is intended to let users know what input data is expected. Implementing labels or instructions that fully describe an input's function alleviates ambiguity. Clear labels and instructions <strong>prevent the user from making errors</strong> and <strong>provide support</strong> that helps users complete and check their task. </p>
      <p>For example, when asking for a passport number, provide an image of a passport (with alternative text) that highlights where you can find this number in your passport. Without this information many users will not know how to find the passport number and will be unable to complete the task.</p>
      <p>To fully describe an input's function, the wording on the label needs to be unambiguous so that the function is clear.  For example if there are more than one forms on a page, having more than one labeled "go" is not clear and the user is likely to make a mistake and go to the wrong place. The label should: clearly identify the full function preventing the user from making mistakes or; the scope of the task should be completely clear via a technique such as adding an instruction in a tooltip or help icon.</p>
            <p>Another example would be an international ecommerce website which accepts multiple currencies. Product pricing includes the currency symbol in addition to the associated standardized text. For example:</p>

  • € 234,56 Euro
  • £ 234,56 British Pounds
  • $ 234,56 US Dollars

            <p>Using the default format for localized content based on the location of the user is also beneficial to users with cognitive disabilities. For example, currently many Web based calendars require settings to be changed to suit the locale. Users may not be aware of the start of the week in the locale, e.g. Sunday in the Middle East, and may be unable to take appropriate actions to suit their needs.</p>

In some cases a full description of an input's function maybe not be possible for example, if the description would be too verbose or if additional explanation is needed. Explaining where to get the required information can also be helpful for users with cognitive disabilities, giving them a point of reference to the required input. For example, an assignment in an e-learning course may require students to write essays using the "MLA Format for Essays and Research Papers" and provide an indication for this requirement along with a link on how to write in this format along with an example.

        <h2>Benefits</h2>
         <p>This Success Criterion helps users who need help understanding what input data is expected. This supports users who have:</p>
         <p>

• Intellectual disabilities
• Focus and attention related disabilities including attention with details
• Memory related disabilities
• Language related disabilities

</p>
<p>The use of conformant labels or instruction when input is required is particularly helpful for users with cognitive disabilities because:</p>
<p>
<ul>
    <li>In many case users  will not understand how to complete a form and where to find information therefore making the task impossible to complete</li>
    <li>Ambiguous labels and lack of instructions result in user errors. With this success criteria errors can be mitigated before they happen therefore reducing the number of errors which occur during a task. Manual error correction is both difficult and frustrating. Multiple errors and the manual correction of errors results in the likelihood of loss of focus, and/or abandonment of a task. </li>
        <li>Reducing the number of errors will also reduce the number of error notifications. Multiple error notifications can distract users who have difficulty remaining focused from engaging and completing the primary task.</li>
    <li>The use of default values shows meaningful results with helping users who are challenged by attention to detail. </li>     
</ul>
          </p>        
        <h3> Related Resources</h3>
            <p>Resources are for information purposes only. No endorsement is intended or implied.</p>
            <p>
                  <ul>
                  <li>Research carried out by Neil Milliken with web users who have dyscalculia - <a rel="nofollow" href="https://w3c.github.io/wcag/coga/user-research.html">Background research document</a>.. </li>
                  <li><a href="https://rawgit.com/w3c/coga/master/gap-analysis/table.html">User Needs Table 3: Entering data, error prevention &amp; recovery</a></li>
                  </ul>
                  </p>
                  <p>See also:</p>
                  <ul>
                    <li>ISO 4217 Currency Codes <a href="http://www.xe.com/iso4217.php">http://www.xe.com/iso4217.php</a></li>
                    <li>WCAG 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A) WCAG advises providing symbol before the number as part of the W3C working draft on <a href="http://www.w3.org/TR/2013/NOTE-UNDERSTANDING-WCAG20-20130905/content-structure-separation-programmatic#content-structure-separation-programmatic-intent-head">http://www.w3.org/TR/2013/NOTE-UNDERSTANDING-WCAG20-20130905/content-structure-separation-programmatic#content-structure-separation-programmatic-intent-head</a></li>
                    <li>Mathematical Markup Language (MathML) Version 3.0 2nd Edition W3C Recommendation 10 April 2014 <a href="http://www.w3.org/TR/MathML/">http://www.w3.org/TR/MathML/</a></li>
                    <li>Making Mathematics Accessible <a href="http://ww.dessci.com/en/reference/accessibility/">http://www.dessci.com/en/reference/accessibility/</a></li>
                    <li>Math on the web <a href="http://www.dessci.com/en/reference/webmath/">http://www.dessci.com/en/reference/webmath/</a></li>
                    <li>Nielson -aging</li>
                    <li>Deque blog <em>Why Don't Screen Readers Always Read What's on the Screen? Part 1: Punctuation and Typographic Symbols</em> <a href="http://www.deque.com/blog/dont-screen-readers-read-whats-screen-part-1-punctuation-typographic-symbols/">http://www.deque.com/blog/dont-screen-readers-read-whats-screen-part-1-punctuation-typographic-symbols/</a></li>
                    <li>ISO 8601 Date and Time format <a href="http://www.iso.org/iso/home/standards/iso8601.htm">http://www.iso.org/iso/home/standards/iso8601.htm</a> - Please note the example provided on the ISO page namely 2012-09-27 is read aloud by Microsoft Word TTS as 'two thousand and twelve, two hundred and nine minus twenty-seven and on the web page the dashes are read as dashes by Acapela voice </li>
                    <li>2.5m ticket sales lost every year due to inaccessible booking sites - report <a href="http://www.musicweek.com/news/read/uk-music-industry-loses-out-on-2-5m-tickets-sales-per-year-due-to-inaccessible-booking-systems-for-deaf-and-disabled-customers-r/057407">http://www.musicweek.com/news/read/uk-music-industry-loses-out-on-2-5m-tickets-sales-per-year-due-to-inaccessible-booking-systems-for-deaf-and-disabled-customers-r/057407</a></li>
                    <li>W3C Date and Time Format <a href="http://www.w3.org/TR/NOTE-datetime">http://www.w3.org/TR/NOTE-datetime</a></li>
                    <li>Kuhn, M., (1995) <em>A summary of the international standard date and time notation.</em> last modified 2004-12-19 - <a href="http://www.cl.cam.ac.uk/~mgk25/iso-time.html">http://www.cl.cam.ac.uk/~mgk25/iso-time.html</a> (Accessed June 1st 2015)</li>
                  </ul>
        <h2>Testability</h2>
        <p>Identify where the  content requires user input. For each element that requires input confirm that there are labels and instructions so that each of the following are true:</p>
            <ul>
              <li>Check that the label  fully describes the input's function. If it is not fully described confirm that the full information is easily available such as via a help icon or other WCAG technique.</li>
              <li>Use the default format and standards for localized content in the location of the user and allow for changes of format on labels and user input. An exception is provided where any standard format is accepted and it conforms to the technique on standard formats</li>
              <li>When the user is required to input information other then the user's name, phone number,  address or date of birth confirm one of the following is true:
                <ul>
                  <li>You have explained where to get the required information or</li>
                  <li>user testing that includes people with cognitive disabilities has shown that how to get the information is known by the intended audience. (such as  an employees badge number which all employees need to wear could be known by all employees)</li>
                </ul>
              </li>
            </ul>
        <h2>Techniques</h2>
            <ul>
                <li>Providing clear labels that fully describe the input's function</li>
                <li>Providing instructions where labels are not enough</li>
                <li>Providing instructions via COGA semantics</li>
                <li>Using aria-label</li>
                 <li>Removing ambiguity by giving  pointers to users to give context - such as tool tip, clear headings or help </li>
                 <li>Providing instructions describing where to get the required information</li>
                 <li>Failure: Using an unclear ambiguous label</li>
                 <li>Failure: Not providing instructions for finding information</li>
                  <li>Calendars and dates</li>
                        <ul>
                          <li>Any standard format is accepted</li>
                          <li>Use terms that describe the present past and future days rather than just using numbers or dates. By using terminology such as <em>today</em>, <em>tomorrow</em> or <em>travel now</em> in the appropriate language for the locale, the user has a clear understanding of the timeliness of the event, booking or occasion. </li>
                          <li>Display long form of <strong>dates</strong> with punctuation, e.g., June 1st, 2015 or 1st June, 2015. This offers a clear understanding of the date. Punctuation helps the text to speech API read the date in a way that is easier to follow.</li>
                          <li>When using numbers for time - check use of appropriate punctuation between numbers when providing times as these may be read inappropriately by text to speech engines.</li>
                        </ul>
                        <li>Temperature</li>
                        <ul>
                          <li>Allow reading of long form temperature. Reading the values long form rather than using figures is helpful for the same reasons outlined in the dates and calendar section.</li>
                          <li>Advisory: Reinforce with non-numerical values, e.g., Very Cold, Cold, Cool, Mild, Warm, Hot, Very Hot. These are subjective values and may not always be helpful especially when dealing with weather and ambient temperature (due to reasons such as variances in regional average temperature - what is considered hot in UK is considered cool in India or Thailand). It may be possible to use look up tables and JSON to query relative average temperature based upon locale and adjust temperature ranges accordingly. </li>
              </ul>
              </ul>
<h3>Examples:</h3>
<p>Currently many web based calendars require settings to be changed to suit the locale.  Users may not be aware of the start of the week in the locale, e.g. Sunday in the Middle East, and be unable to take appropriate actions to suit their needs.</p>
                        <p><strong>Pass example: </strong>Calendar settings recognize locale and/or offer the ability to edit settings.</p>
                        <p><strong>Failure example: </strong>Incorrect punctuation and poorly localized date layout.</p>
 <p>In USA the month appears before the day which is reversed in UK e,g 06/01/2015 or 01/06/2015. Dyslexic users and other user groups will not often confuse the order.</p>
              <p><strong>Pass example:</strong> Month is given in text with numbers for date and year.</p>
              <p><strong>Failure example: </strong>A series of numbers for the date.</p>
 <p>The international standard notation for the time of day is hh:mm:ss but this can be hard for those with cognitive impairments to fully comprehend - 10:30:10  may be read out as 10 hours, thirty minutes and 10 seconds by most text to speech engines but may be too long to remember.  The ISO advises the 24 hour clock for example 13:30 as opposed to 01.30pm - the latter is localized for English speakers but may help those with learning disabilities along with symbols to represent the period in the day such as suggest under calendars. </p>
              <p>Being able to hear the numbers for time repeatedly read out aloud accurately with text to speech technologies can help comprehension and memory.  Developers need to be aware of how these technologies react to time formats.  This feature can provide those with dyscalculia, dyslexia and attention deficit disorder and those who may be under high cognitive load or situationally disabled with a better understanding of the concepts.</p>
              <p><strong>Pass example: </strong>Numbers representing time can be read out accurately by text to speech engines.</p>
              <p><strong>Failure example:</strong> Numbers fail to be read out accurately by text to speech engines. </p>
    <p>Even with all of the above in place a person may not be able to associate the concept of the temperature with the numbers so giving additional hints may help provide the connection to whether something is hot or cold.</p>
      <p>Use symbols where appropriate for example, for weather the symbols used such as sun, snowflake, sun &amp; cloud will give some indication. </p>
      <p>Pass example: The Temperature is Five Degrees Centigrade (Cold) <img src="https://rawgit.com/w3c/coga/master/techniques/img/SnowFlake.png" height="67" width="61" alt="snowflake" style="margin: 0px auto;"> hint: It's hat and scarf weather. </p>
      <p>Failure example: Failure to explain figures representing relative values. Temperature = 21&#x2103;/70&#x2109;</p>
      <p>The Temperature is Thirty Degrees Centigrade (Very hot) <img src="https://rawgit.com/w3c/coga/master/techniques/img/sun.png" height="62" width="62" alt="sun" style="margin: 0px auto;"> hint: The weather is appropriate for wearing shorts</p>  

Working groups notes

Lisa: I took out the following example as I do not think it is the primary intent. .....it is common for a feedback or contact form to include a text area input field which is used by the user to enter the message he or she would like to submit. Often users are directed to the same contact form regardless of the reason for their communication. For example, someone wanting to get more information about site membership or registration may be directed to the same form as someone who has a question about one of the products or services offered on the site. There may be a label such as "message" associated with the input field however if there are not selectable options to indicate the type of message or the reason the user is sending the message users with cognitive disabilities may not remember the reason for their intended communication or may be confused about the function of the text area field.

<p>It was decided that the original COGA Success Criteria below should be broken into three separate Success Criteria - <strong>Minimize User Errors</strong> (outlined above), <strong>Labels or Instructions</strong>, and <strong>Identify Charges</strong>.
</p>
      <h4><strong>Prevent the user from making errors</strong></h4>
                            <p><strong>Was:</strong> Support is provided that help users complete and check their task, that includes</p>
      <p>(may be provided via a standard personalization mechanism) (COGA Techniques 2.9 ) </p>
                <p>In forms</p>
                <ol>
                  <li>Use <a>known techniques</a> to prevent errors that are relevant to the content. All standard ways of representing information are accepted as input formats, such as different ways of writing a phone number and date formats. </li>
                  <li>Documented <a>common input errors</a> can be corrected automatically. (example spelling mistakes)</li>
                  <li>Enable and identify the default format and standards of locale and allow for change of format on labels and user input (removed use the default format and standards of locale and allow for change of format)</li>
                  <li>Clear visual indicators are provided that identify what information is essential, and non-essential information is clearly differentiated from <a>essential information</a>. </li>
                  <li>Instructions are provided if there is not a label  that fully describe the control or if it is not clear were to get the required information. Instructions should explain the purpose and usage of the control. (Graphics with a text alternative may be sufficient) ( A clear instruction or information is on where 99% of your target audience understand immediately what to do) </li>
                </ol>
                <p>For legal and financial transactions</p>
                <ol>
                  <li>Options that may disadvantage the user are only selected at the users specific request. </li>
                  <li>All types of charges must be clear at the start of a transaction task. </li>
                  <li>When a <a>minimum is known for a type of charge</a> it must be be made clear at the start of the transaction task. (from support the user)</li>
                </ol>
                <p>For all content</p>
              <ol>
                  <li>Non native content and sponsored content are clearly marked and visually differentiated by standardized techniques </li>
                  <li> Clearly differentiate between facts and less substantiated opinions. Was rewritten from "Clearly differentiate between opinions and facts "</li>
              </ol>

[patrickhlauke]

For completeness, adding my comments here from the November 2016 survey:

• "Fully describe the input's function" - does this mean that even standard, inputs, and how the user interacts with them, need to be explained? E.g. for a <select>, explain that the user can set focus on the control, use ALT+arrow down to open it, etc? And, as standard controls will vary in how they're operated in different contexts (e.g. on a mobile touchscreen device vs a desktop keyboard environment), how can this be achieved?

• "Use the default format and standards for localized content in the location of the user and allow for changes of format on labels and user input." This would require either some potentially very complex client- or server-side scripting implementation (to ascertain the user's locale, and adapt the output accordingly), and the "and allow..." essentially makes it a requirement for any site with inputs to offer settings/customisation options. Also, in terms of testing, would an auditor be required to somehow set their test environment to all possible locales, in order to ascertain if the site then adapts to this correctly?

• "Explain where to get the required information." the exceptions are vague at best, and the note talks about "where user testing has shown that the information is known by the intended audience". who is supposed to do the user testing to inform if something's a pass or fail? are multiple auditors, doing different user testing sessions, likely to then come to the same conclusion? this is likely highly subjective.

Additionally, having this as Level A seems...ambitious.

[jspellman]

All of the symbol examples need to be moved to Issue 50, Extra Symbols.

[jspellman]

Issue 45 Extra help (beginner's help) also covers much of this SC. What is the difference between instructions and beginners help? The overlap is confusing. The Pass Fail Examples are examples of personalization and not of labels and instructions. They should be moved to Issue 6. They may be residuals from the SC being split as noted in the Working Group comments. Patrick's comments on the testing, the challenges of localized content in a global Web, required information, and the complexity of code required for the enhancements being proposed are quite valid. I think this present 3.3.2 should continue as it currently written, and (possibly) reference Issue 45 on beginner's help. The Techniques to be written for Beginner's Help could be applied to 3.3.2 to give developers greater guidance on how to write instructions.

[mbgower]

While I have never liked how 2.4.6 and 3.3.2 intermingle, I believe how this guidance has been modified here does not improve the situation. In the current 2.0 form, 3.3.2 is primarily concerned with the existence of labels or instructions for inputs. 2.4.6 is primarily concerned with the meaning of the label. Yes, one could make the argument that they are backward, regarding whether they enable operation or understanding. But if the changes here are to be considered, I think a matching revision of 2.4.6 would be necessary. As I’ve noted elsewhere, something that substantially changes existing 2.0 guidance is going to make it very hard to transition or report to both 2.0 and 2.1 and any standards based on them.

---

Proposed

Fully describe the input's function

I have significant concerns about the inclusion of “fully” here. It seems to directly contradict the principle of clear and brief guidance in 2.4.6. With this guidance, will some users believe that it is appropriate and encouraged to replace the label “First name” with “Type your first given name in the textbox” On a related matter, perhaps one thing worth revisiting is the idea of separating labels and instructions. A label uniquely and meaningfully designates an input. Instructions contain additional information on its purpose or input requirements.

Use the default format and standards for localized content in the location of the user and allow for changes of format on labels and user input. An exception is provided where any standard format is accepted.

I find this problematic, or at least unclear. Are you saying that the user preference for default locale should be adopted? For example, I live in Canada, and there are 3 common date formats: US (mm-dd-yy), British (dd-mm-yy) and international (yyyy-mm-dd). I have the third chosen on my OS. Some software apps adopt this. Others allow me to alter it in a user preference in the app. There is no default ‘locale/location’, unless you mean the default chosen by the OS at installation.

Explain where to get the required information

It’s hard to know how literal this is. Where is the list of what information is known by an intended audience, and by “known” what exactly do you mean? Do you mean memorized? Common?

Instructions on how to get information, depending on the context, may be incredibly complex or simple. Many people may not know their cellphone numbers. Do I have to include directions on how to look that up for each OS? How would you include info on how to get a postal code? Alternately, does one need to include information on how to find a driver’s licence number on a field that asks for a driver’s licence?

Does all such guidance need to be in the UI? You can see how this could become a real design mess. What about options for a supporting or accompanying document, such as one gets for tax completion. The tax form itself contains no explanation. The user looks up guidance if required in the supporting document.

This bullet just seems to be incredibly variable, and I don’t see how it can be enforced/verified/adopted.

---

Description

For example, when asking for a passport number...

So, here is an example of the complexity this poses for a UI designer. Do I have to include an image for every nationality passport that is a potential audience? How about versions of passports? Do I need to include passport cards as well?

To fully describe an input's function, the wording on the label needs to be unambiguous so that the function is clear. For example if there are more than one forms on a page, having more than one labeled "go" is not clear and the user is likely to make a mistake and go to the wrong place.

This is already covered by Consistent Identification for multiple pages. It is also inferred on 2.4.6. I would advocate that the concept of not using the same label for items that result in different actions should be made explicit in the existing SC. This is a different concept, to me, than “fully describe”. All it need state is that where the same label occurs, it must describe the same control and function; two different functions should not be labelled the same.

the scope of the task should be completely clear via a technique such as adding an instruction in a tool tip or help icon.

I think this whole rewrite of 3.3.2 would benefit significantly from a clearer division between labels and instructions. Labels should provide clear designation. Instructions should provide context and elaboration. If you look at how the current techniques are formed, there is a technique for G131 Providing descriptive labels, and then many ancillary techniques for adding info about the field. But there is not a lot of clear guidance on instructions. I believe tactically it makes sense to introduce a few key Instruction techniques that cover what you are advocating here, and provide that guidance inside the technique more than inside the SC.

For example, an assignment in an e-learning course...

This example seems to have no bearing on the first part of the paragraph.

---

I have a lot of feedback on the Testability and Techniques sections I could provide, but I think this is sufficient feedback for now.