Your comments on WCAG 2.0 Public Working Draft of May, 2007

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