W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > May 2007

Response to feedback on my comments on WCAG 2.0 Last Call Draft of April 2006

From: Enders, Jessica (Hiser) <jessicae@hiser.com.au>
Date: Fri, 18 May 2007 11:15:01 +1000
Message-ID: <B747FCB83A68844999AD4A35EF8365300D12A1@melex01.ap.serco.com>
To: <public-comments-WCAG20@w3.org>

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

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."


Kind regards

Jessica Enders
Senior Consultant - The Hiser Group
Ph: +61 (0)3 9648 4331 :::  Fax: +61 (0)3 9648 4390
18/535 Bourke Street, Melbourne, VIC, 3000, AUSTRALIA
www.hiser.com.au  |  jessicae@hiser.com.au
-----Original Message-----
From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] 
Sent: Friday, 18 May 2007 9:37 AM
To: Enders, Jessica (Hiser)
Cc: public-comments-WCAG20@w3.org
Subject: Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Jessica Enders ,

Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the
interest that you have taken in these guidelines.

We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.

This message contains the comments you submitted and the 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 updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.

PLEASE REVIEW the decisions  for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org to say whether you are
satisfied with the decision taken. Note that this list is publicly

We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ for more information about the current review.

Thank you,

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:

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
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
- 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

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).

Comment 2:

Source: http://www.w3.org/mid/20060607043715.D7685DAF30@w3c4-bis.w3.org
(Issue ID: LC-758)

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

In the previous version of these guidelines there was a very specific
criterion regarding placement of labels and their associated fields
(10.2). There doesn\'t seem to be any mention of this in the current
guidelines, yet I would have thought that placement significantly
impacts on accessibility. For example, a screen reader experience with
a label to the left of a field versus to the right would be quite

Proposed Change:

Suggest the ideal orientation of labels in reference to their
associated fields, based on your knowledge of screen readers and
related mechanisms people with disabilities use to navigate through

Response from Working Group:

Assistive technology has advanced since the WCAG 1.0 guidelines were
released.  As long as the label is explicitly associated with a field,
the assistive technologies can present the information to the user in
an understandable manner. A technique which describes how to associate
labels with fields already exists, see, H44: Using label elements to
associate text labels with form controls.  However, since visual
positioning can be important, especially for pages translated into
other languages, we have added an advisory technique to Success
Criterion 1.3.1 and Guideline 3.2 titled "Positioning labels to
maximize predictability of relationships."  In addition, the
Comparison of WCAG 1.0 to 2.0  document provides some information
about where the label requirement exists in WCAG 2.0.

Comment 3:

Source: http://www.w3.org/mid/20060607045024.8AE0966368@dolph.w3.org
(Issue ID: LC-759)

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

This criterion states that \"when text requires reading ability more
advanced than the lower secondary education level, supplemental
content is available that does not require reading ability more
advanced than the lower secondary education level.\" I don\'t see why
this need apply when the content uses a controlled vocabulary and has
a very specific target audience. For example, on a medical website
used only by surgeons and describing new surgical research, why does
there need to be a version of this text that someone at the lower
secondary education level can understand? Certainly have diagrams etc
to aid comprehension is important, for all users, but this may not be
possible in many cases.

Proposed Change:

Modified criterion to allow specific exception for web content with
specific target audiences utilising a widely accepted controlled

Response from Working Group:

Even specific target audiences may contain people who can understand
the subject matter but have disabilities that make it difficult to
deal with complex text. While reducing the complexity of the text will
help all such people, the success criterion only requires additional
supplementary material that will assist some of those users.

This email and any attachments may contain confidential and/or privileged material and/or material subject to copyright; it is for the intended addressee(s) only. If you are not a named addressee you shall not use, retain or disclose such information.

The views expressed in this email are those of the originator and do not necessarily represent the views of The Hiser Group or its parent company, Serco Group Pty Ltd. Nothing in this email shall bind Hiser or Serco in any contract or obligation.

Hiser cannot guarantee that the email or any attachments are free from viruses or errors and will not be responsible for loss or damage resulting either directly or indirectly from any such virus or error.

If this is a commercial electronic message within the meaning of the Spam Act, you may indicate that you do not wish to receive any further commercial electronic messages from us by sending an email to mailto:nospam@hiser.com.au

The Hiser Group Pty Ltd. Incorporated in NSW, November 1990.  ACN 050 327 716 
Registered office: Level 10, 90 Arthur Street, North Sydney, NSW 2060, Australia
Received on Friday, 18 May 2007 01:15:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:43 UTC