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

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

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 21:18:56 -0700
Message-ID: <824e742c0711032118j38f89a73jb51829ddf363e8f6@mail.gmail.com>
To: "Cynthia Shelly" <cyns@exchange.microsoft.com>
Cc: public-comments-WCAG20@w3.org

Dear Cynthia Shelly,

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

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.


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: The relationship between labels and names is not clear enough.
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0263.html
(Issue ID: 2093)
Original Comment:

When do you need a name, when do you need a label, when do you need both?

I believe that you always need a name, if you have a label it should
be programatically associated (making it a label), but that labels are
optional.  Is that correct?  Need to be more clear in the guidelines.

Response from Working Group:

You are absolutely correct. Success criterion 4.1.2 requires a
programmatically determinable name for all user interface components.
Occasionally the name must be visible as well in which case it becomes
a label.  Whenever this is required it is specifically called out in
the guidelines by saying that a "label" is required.  Both terms are
defined in the glossary.

We will add the following to the intent section of 4.1.2 as a note.

"NOTE: Success Criterion 4.1.2 requires a programmatically
determinable name for all user interface components. Names may be
visible or invisible. Occasionally, the name must be visible, in which
case it is identified as a label. Refer to the definition of name and
label in the glossary for more information."

If you have additional suggestions as to how we could make it clearer
feel free to send them in as well.

Comment 2: The parenthetical phrase is confusing
Original Comment:

The parenthetical note in the title "(for example spoken aloud,
simpler layout, etc.)" is confusing.  It seems to me that the
subsections below 1.3 define "presented in different ways" whereas the
parenthetical note (particularly with the "etc.") leaves room for
misinterpretation.  For example, Does different ways mean I need to
allow for different reading levels?  I don’t think that is the
intent but the parenthetical note could allow for that.

Proposed Change:
Remove the parenthetical phrase.

Response from Working Group:

We have accepted your suggestion.

Comment 3: Should Icons be included in contrast requirements?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0265.html
(Issue ID: 2095)
Original Comment:

I know that we decided not to include diagram due to the difficulty of
determining the correct contrast for varying line thicknesses and
such.  However, icons have a great role in determining usability of a
site than general diagrams do.

Proposed Change:
Include icons in contrast requirements.  Define "icon" and define what
sufficient contrast would look like for an icon.

Response from Working Group:

The problem with ICONS is that most are mini pictures with shading
etc.  it would be hard to determine what is the foreground and what is
the background.  For simple icons this would be a good idea.

We are adding an advisory technique:

"Making icons simple line drawings that meet the contrast provisions
for text" to 1.4.3 and 1.4.5

Comment 4: Which sc covers frame names?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0267.html
(Issue ID: 2097)
Original Comment:

A collegue thought that frame names should be covered under 2.4 rather
than 4.1.  Many people may not think of frames as UI elements, and
might not be able to find them.

Proposed Change:
Is there anything we can do to make it more clear that frames are
covered under 4.1.2?

Response from Working Group:

H64: "Using the title attribute of the frame and iframe elements" is
listed as a sufficient technique for two success criteria: 2.4.1 and
4.1.2, so the issue is covered in a number of places where the working
group felt that authors might find themselves using frames.

Comment 5: Not clear that it's ok to provide directions once for a site.
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0268.html
(Issue ID: 2098)
Original Comment:

It's not clear from either the text or the techniques that it's
sufficient to provide the explanation once for a site or application.

Proposed Change:
Add a technique about providing it on the first page encountered, one
for providing it in help, and one for providing it as part of training
for a site that will be used in a closed environment.

Response from Working Group:

We have added the following general technique and failure:

G147: Providing instruction about change of context due to change of
input setting ahead of such encounter

F76: Failure of 3.2.2 due to providing instruction material about the
change of context by change of setting in an user interface element at
a location that users may bypass.

Comment 6: Does HTML using pt or px meet this with today's user agents?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0272.html
(Issue ID: 2102)
Original Comment:

Since you can zoom in Internet Explorer 7 and Opera, and since FireFox
allows resizing of pt and px fonts, can we consider HTML resizable?
If so, we need techniques for pt and px fonts to ensure that there
isn't truncation or overlap when fonts resize.

Proposed Change:
1) Add techniques for preventing truncation and overlap when using pt
and px fonts.

2) Add user agent notes about zoom vs. font-size in IE.

3) Add techniques about not using images of text

4) Add something (not sure where, maybe in understanding, maybe
techniques) about technologies that don't support resizing.  One of
the questions we seem to get a lot is why we need this SC if all text
is resizable works in HTML.

5) Consider adding a minimum font size for text rendered in an image
or other technology that doesn't support resizing.

Response from Working Group:

1) The use of pt and px in Firefox is covered under "F69: Failure of
SC 1.4.4 and 1.4.7 when resizing visually rendered text up to 200
percent causes the text, image or controls to be clipped, truncated or
obscured."  Authors using these units must test their content
according to the procedure outlined in that failure.

2)  The Zoom functionality in IE 7.0 does not always scale uniformly
when absolute positioning is used and the page is scaled smaller.
Microsoft Internet Explorer 7.0 supports both Zoom and Text Size
changes for fonts set with %, em or named sizes.

3) We have added an advisory technique
"Avoiding the use of text in raster images"

4) We have clarified the need for this success criterion in the intent
section of Understanding 1.4.4

5) We have added an advisory technique for minimum font size.
"Ensuring that text in raster images is at least 18pt"
Received on Sunday, 4 November 2007 04:19:13 UTC

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