- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:46:33 -0700
- To: "Jessica Enders" <jessicae@hiser.com.au>
- Cc: public-comments-WCAG20@w3.org
Dear Jessica Enders, Thank you for your comments on the 17 May 2007 Public Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0 http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group has reviewed all comments received on the May draft, and will be publishing an updated Public Working Draft shortly. Before we do that, we would like to know whether we have understood your comments correctly, and also whether you are satisfied with our resolutions. Please review our resolutions for the following comments, and reply to us by 19 November 2007 at public-comments-wcag20@w3.org to say whether you are satisfied. Note that this list is publicly archived. Note also that we are not asking for new issues, nor for an updated review of the entire document at this time. Please see below for the text of comments that you submitted and our resolutions to your comments. Each comment includes a link to the archived copy of your original comment on http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may also include links to the relevant changes in the WCAG 2.0 Editor's Draft of May-October 2007 at http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/ Thank you for your time reviewing and sending comments. Though we cannot always do exactly what each commenter requests, all of the comments are valuable to the development of WCAG 2.0. Regards, Loretta Guarino Reid, WCAG WG Co-Chair Gregg Vanderheiden, WCAG WG Co-Chair Michael Cooper, WCAG WG Staff Contact On behalf of the WCAG Working Group ---------------------------------------------------------- Comment 1: Context-sensitive help only needs to be provided when the label is not sufficient Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0127.html (Issue ID: 1930) ---------------------------- Original Comment: ---------------------------- This issue is based on the working group's repsonse to LC-757 [1]. The original issue, WG response and reviewer's response are included below. [1] http://www.w3.org/WAI/GL/WCAG20/issue-tracking/viewdata_individual.php?id=757 ---------------------------------------------------------- Comment 1: Source: http://www.w3.org/mid/20060607043119.1B4CBDAF30@w3c4-bis.w3.org (Issue ID: LC-757) 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. ---------------------------- Response from Working Group: ---------------------------- 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). ---------------------------- Response from Reviewer: ---------------------------- Dear WCAG Working Group Thank you for responding to my comments on the WCAG 2.0 Last Call Draft of April 2006. I am 100% satisfied with the Working Group's responses to Comment 2 and Comment 3. I am mostly satisfied with the Working Group's response to Comment 1. Your proposed modification to the document 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)." I agree with the first sentence but I disagree with the second sentence. I do not think the guidelines should stipulate /where/ the context-sensitive help should be placed. I feel that placement should be done in such a way to maximise usability within the particular context (whilst not creating accessibility issues, of course). For example, some context-sensitive help may be best placed as a tip beside or underneath the field label (e.g. "In whole dollars - do not include cents") whereas other context-sensitive help may be more appropriately placed in a separate help file (e.g. if there is a considerable amount of descriptive information associated with a product). Moreover, removing the help from the form itself usually means the /existence/ of such help is less obvious to the user. It may also make it seem like the help is general, not context-sensitive (e.g. if a "Help" icon is provided as part of the header to a page). ~~~~~~~~~~~~~~~~~~~~~~~~ Suggested refinement: "Context-sensitive help only needs to be provided when the label is not sufficient to describe all functionality. The existence of context-sensitive help should be obvious to the user and they should be able to obtain it whenever they require it." ~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------- Response from Working Group: --------------------------------------------- We have updated the intent section of 3.3.5 as proposed.
Received on Sunday, 4 November 2007 04:46:45 UTC