Edit comment LC-757 for Accessibility Guidelines Working Group

Quick access to

Previous: LC-730 Next: LC-758

Comment LC-757: Comment Shortname:; Commenter: Jessica Enders <jessicae@hiser.com.au> on behalf of The Hiser Group; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

This Criterion states that \"Context-sensitive help is available for text input\". The accompanying advice on how to meet this criterion seems to suggest that such help must be available for ALL text input fields.
If it is sufficient, to meet this criterion, to have clear labels for all text input fields, then you can ignore my comments here. However, if the guidelines are suggesting that there needs to be specific help text for every text-entry field, AS WELL AS a clear label, then please read on!
As a professional and experienced questionnaire designer, I feel this is unreasonable and may in fact hinder usability for all users, not just those with a disability, and reduce data quality.
It is well documented that providing examples for a question can, in fact, reduce the accuracy of the response because users tend to limit their thinking to just those provided examples. Moreover, good form design notes that the information required to provide a response should ideally be located with the label for that response field (ie don\'t separate instructions from the relevant questions). As such, authors should be incorporating all the information that is needed into the label/question, rather than providing some information in a separate area.

Add to this the fact that there isn\'t much useful help that can be added to many text fields. For example, what help would you give for your own text field \"Proposed Change\" below? Adding text along the lines of \"Please type here a description of the change that you think we should make\" is superfluous, patronising and degrades the user experience. Please let us not return to the bad old days where even fields such as \"Family Name\" had an instruction that consequently made users feel like idiots, and contributed to the instruction blindness that is prevalent today.

Proposed Change:

Reword the criterion or its associated documentation to make it clear that:
- in all cases, the label for the text entry field must clearly communicate what sort of information should be provided in the field
- additional context-sensitive help need only be provided where it is reasonably required to explain what is to be entered, or to minimise the burden on the user.; Related issues: (space separated ids); WG Notes: [TEAMC] Cynthia: She has a good point. I can't see how we can add a test for obviousness without making the checkpoint untestable. However, I think we could clarify some things in how-to-meet. I'd add her two bullet, plus something like: - in most cases, context sensitive help should not be placed in the form itself, but should instead be available to users when they request it. For example, by linking to a separate help file. Discussed in the 08 February 2007 telecon: Accepted by unanimous consent. http://www.w3.org/WAI/GL/2007/02/08-wai-wcag-minutes.html {partial accept} DONE Add to the Intent of 2.5.4 "Context-sensitive help need only be provided when the label is not sufficient to describe all functionality. In most cases, context sensitive help should not be placed in the form itself, but should instead be available to users when they request it, e.g., by linking to a separate help file." Internal WD updated 02 March 2007. Response from commenter: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0127.html; Resolution: We have added clarification of this to the How to Meet document. It reads: Context-sensitive help only needs to be provided when the label is not sufficient to describe all functionality. In most cases, context-sensitive help should not be placed in the form itself, but should instead be available to users when they request it (e.g. by linking to a separate help file). Note: Reviewer response to this issue has been picked up as issue #1930 in WCAG Bugzilla.; (Please make sure the resolution is adapted for public consumption)