Join GitHub today
Labels and instructions #56
Current versions of SC and Definitions
Labels or Instructions
3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input (Level A).
@@3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. Labels and instructions:
Note: Information is known by the intended audience includes the user's name, phone number, address, date of birth and other information where user testing has shown that the information is known by the intended audience.@@.
Related Glossary additions or changes
user testing - this has been defined in other SC's
What Principle and Guideline the SC falls within.
Principle 3, Guideline 3.3.
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 prevent the user from making errors and provide support that helps users complete and check their task.
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.
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.
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:
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.
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.
This Success Criterion helps users who need help understanding what input data is expected. This supports users who have:
The use of conformant labels or instruction when input is required is particularly helpful for users with cognitive disabilities because:
Resources are for information purposes only. No endorsement is intended or implied.
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:
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.
Pass example: Calendar settings recognize locale and/or offer the ability to edit settings.
Failure example: Incorrect punctuation and poorly localized date layout.
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.
Pass example: Month is given in text with numbers for date and year.
Failure example: A series of numbers for the date.
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.
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.
Pass example: Numbers representing time can be read out accurately by text to speech engines.
Failure example: Numbers fail to be read out accurately by text to speech engines.
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.
Use symbols where appropriate for example, for weather the symbols used such as sun, snowflake, sun & cloud will give some indication.
Failure example: Failure to explain figures representing relative values. Temperature = 21℃/70℉
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.
It was decided that the original COGA Success Criteria below should be broken into three separate Success Criteria - Minimize User Errors (outlined above), Labels or Instructions, and Identify Charges.
Prevent the user from making errors
Was: Support is provided that help users complete and check their task, that includes
(may be provided via a standard personalization mechanism) (COGA Techniques 2.9 )
For legal and financial transactions
For all content
For completeness, adding my comments here from the November 2016 survey:
Additionally, having this as Level A seems...ambitious.
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.
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.
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”
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.
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.
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?
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.
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.
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.