Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

Dear Aurelien Levy,

Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
has reviewed all comments received on the December draft. Before we
proceed to implementation, we would like to know whether we have
understood your comments correctly and whether you are satisfied with
our resolutions.

Please review our resolutions for the following comments, and reply to
us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
you accept them or to discuss additional concerns you have with our
response. Note that this list is publicly archived.

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 10 March 2008 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to
3.3.2 of the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-comments-wcag20@w3.org. Formal objections will be reviewed
during the candidate recommendation transition meeting with the W3C
Director, unless we can come to agreement with you on a resolution in
advance of the meeting.

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: missing situations in SC 1.4.1
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0002.html
(Issue ID: 2379)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

I think there is a need of 2 more explicit situations :

If colors words is used to indicate information like click on the red
label, red is maybe not in red so the problem is not in the color of
the words itself

If background colors is used to indicate information for example two
block of information concerning rebate, one with a red background and
one with a yellow background, the yellow one is only for people who
have the membership special card and with no other distinction except
the background-color.

Proposed Change:
Add situation C If colors words is used to indicate information and D
If background colors is used to indicate information

---------------------------------------------
Response from Working Group:
---------------------------------------------

You are correct, we are missing the fact that something besides the
text itself may be colored.  (note that having the original word be
colored is not a problem since it is redundant with its meaning).  We
note that the techniques for the other situations would be the same as
what we have.  We have therefore broadened the Situation A.

We have changed the name of the first Situation to:

Situation A: If the color of particular words or backgrounds is used
to indicate information:

Thanks for catching that.

----------------------------------------------------------
Comment 2: contrast control available on or from the page
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0005.html
(Issue ID: 2382)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

Item Number: G18
Part of Item: Tests
Comment Type: general comment

I didn't see in the test procedure any indication concerning the note
one the wcag document :

Note: Success Criteria 1.4.3 and 1.4.6 can be met via a contrast
control available on or from the page.(same problem for G17)

By the way, can you be more specific what is exactly a contrast
control (for html is it alternative stylesheet ?)

---------------------------------------------
Response from Working Group:
---------------------------------------------

Because sufficient techniques are explanations of one possible way to
meet a success criterion, it would not be appropriate to include
references in the test procedure to other sufficient techniques.

Thank you however, for pointing out that we had not included the
techniques mentioned in the note in the Understanding draft. We have
added the following techniques to understanding 1.4.3 and 1.4.6:

For 1.4.3 (situations A and B):
Providing a control with at least a 5:1 contrast ratio that allows
users to switch to a presentation that uses sufficient contrast
(future link)

For 1.4.6 (situations A and B):
Providing a control with at least a 7:1 contrast ratio that allows
users to switch to a presentation that uses sufficient contrast
(future link)

Once these technique has been drafted, we will include links to it
from the related techniques section for G17 and G18 as well as other
techniques related to these criteria.

----------------------------------------------------------
Comment 3: color and pattern for background-image too ?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0003.html
(Issue ID: 2380)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

It's not clear if background image are concerned because CSS is not a
technology that support images. Image are not visible in the css
itself, it's the rendering of the technology through the user agent.

---------------------------------------------
Response from Working Group:
---------------------------------------------

Any image used to convey information or that interferes with conveying
information is covered by the guidelines. When selecting technologies
to use on the page, the way the technologies are treated by the user
agent must be taken into account. If it cannot be known how a
technology would be rendered then people generally don't use it. If
the rendering can result in a page that would not pass the Success
Criteria then it could not be used and conform at the level of the
failed success criterion/criteria.

----------------------------------------------------------
Comment 4: block sizing with absolute unit and text sizing with relative unit
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0006.html
(Issue ID: 2383)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

sorry it's the following comment of :

http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=2034

you say : We believe that this is covered by the second sufficient
technique. "Ensuring that text containers resize when the text
resizes" would address the problem of block sizing with absolute
units.

I disagree with you because I can use block sizing with absolute units
and text sizing with relative unit any without any loss of content or
functionality and without using Calculating size and position in a way
that scales with text size or Using liquid layout. In case use natural
growing of size when I don't specify any height, I can use float or
overflow technique


Proposed Change:
Add a technique :

- Ensuring that there is any loss of content or functionality when the
text resizes and block don't resize

---------------------------------------------
Response from Working Group:
---------------------------------------------

We presume you meant "not any loss" or "no loss" in the technique.

we have added

- Ensuring that there is no loss of content or functionality when the text
resizes and blocks don't resize (future link)

If you would like to write this technique up for us that would be great.

the URL for submitting new techniques is:
http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/



----------------------------------------------------------
Comment 5: very similar in color to the body text condition
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0001.html
(Issue ID: 2378)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

the "very similar in color to the body text" condition isn't enough
visible in the test procedure

Proposed Change:
Check that each link within text that is part of a sentence or
paragraph (or other area where they could be mistaken as non-linked
text) in the page is underlined or otherwise visually identifiable
(i.e. bolded, italicized, not similar color to the body text) as a
link without relying on color.

---------------------------------------------
Response from Working Group:
---------------------------------------------

That issue is already covered by the phrase "without relying on color".

If the author is not relying on color at all, then the link could be
similar in color or not similar in color and it wouldn't make any
difference since the color would be redundant with other cues.

----------------------------------------------------------
Comment 6: 5 is too much and missing exceptions
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0004.html
(Issue ID: 2381)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

5 is really too hard to succeed. We have tried to implement this value
in the French government accessibility guidelines but we have to down
it to 4 because otherwise every website fail this criteria.

There is a need for exceptions for :

Logo and image of text who is part of a Visual guideline or Corporate
identity guide done before the introduction of this new criteria
(nobody comply with the wcag 1.0 constrast guidelines except pure
black and white website)

logo or image of text that comes from company where Visual guideline
didn't comply with this criteria for example in a partner page

---------------------------------------------
Response from Working Group:
---------------------------------------------

We reviewed a variety of popular Web sites and we only found a few
places on a couple of pages where 5:1 was not met. Also note that
logos are already excepted. There is no need to worry about contrast
on logos when conforming (but it is nice of course if people create
logos that would pass).

----------------------------------------------------------
Comment 7: clarifications needed on SC 1.4.5
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0007.html
(Issue ID: 2384)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

What about the use of font like futura who are not basic web font but
near to them? did I need to replace it ?

What about image of text with a lot of different background, change of
size, colors etc who need a lot of html to reproduce it and css
positioning who lead to a lot of bugs ?

---------------------------------------------
Response from Working Group:
---------------------------------------------

With respect to your first question:
      What about the use of font like futura who are not basic web font but
      near to them? did I need to replace it ?

You are either using text, so you pass, or you need to use a font that
is not available. In this case, it would not be possible to achieve
the visual presentation with a font that was available, so you would
pass because the qualifying phrase " When the accessibility supported
technologies being used can achieve the visual presentation,"  would
not be true for you.

The best approach is to use a cascade, so that users who have the font
installed get it, and others get a similar font. (ex.
style="font-familiy: Futura, Helvetica, Arial, sans-serif")

With respect to your second question:
      What about image of text with a lot of different background,
      change of size,colors etc who need a lot of html to reproduce
     it and css positioning who lead to a lot of bugs ?

If you cannot achieve the needed appearance in a way that will work
(e.g. doesn't break with different browsers)  you would pass because
the qualifying phrase "When the accessibility supported technologies
being used can achieve the visual presentation,"  would not be true
for you.

Note that in both cases you should (but are not strictly required to)
consider whether the visual effect is in fact that important.

----------------------------------------------------------
Comment 8: alternative to text with external text ?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0009.html
(Issue ID: 2385)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

Can you tell me if in such situation videos need to have captions :

- there is a link to the text version and a link to an external video
(not embed in the web page). For example "read the interview of mister
X" (it can be online or file to download) and "download the interview
of mister X in video" with same informations in it

- there is a link to the text version and an embed video. For example
"read the interview of mister X" (it can be online or file to
download) and "see the interview of mister X in video" (embed  with a
flash video player) with same information in it.

If in that case video are not considered like alternative to text can
you explain me why and how it's changing the situation in an user
experience point of view in regard of the situation where the text is
directly in the page (and video embed or not)

---------------------------------------------
Response from Working Group:
---------------------------------------------

They would both require that the video have captions and description
if the video is more than a talking head, that is, the video actually
contains information.  If the video being linked to is on another
site, then it would be that site's responsibility.

----------------------------------------------------------
Comment 9: SC 1.4.8 - achieving all or one ?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0010.html
(Issue ID: 2386)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

The guidelines say :

"a mechanism is available to achieve the following:

* foreground and background colors can be selected by the user

* width is no more than 80 characters

* text is not aligned on both the left and the right

* line spacing is at least space-and-a-half within paragraphs, and
paragraph spacing is larger than line spacing


and the techniques say : "Each numbered item in this section
represents a technique or combination of techniques that the WCAG
Working Group deems sufficient for meeting this Success Criterion"

So, I understand that if I do only one of the techniques it sufficient
for meeting this success criterion but if I specify foreground and
background colors in CSS it's not resolving the problem of large
width, aligned on both left the right text, small line spacing,
scrolling when resizing

Proposed Change:
Each numbered item in this section represents a technique or
combination of techniques that the WCAG Working Group deems sufficient
for meeting a part of this Success Criterion. All the numbered item
must be satisfied for meeting this Success Criterion.

Otherwise change the guideline to :

"For the visual presentation of blocks of text, a mechanism is
available to achieve one of the following :"

---------------------------------------------
Response from Working Group:
---------------------------------------------

We have reformatted  "Techniques and Failures for Success Criterion
1.4.8" to contain numbered techniques for the diferent requirements,
and we say "Since this is a multi-part success criterion, you must
satisfy one of the numbered items for each of the requirements below."

----------------------------------------------------------
Comment 10: problem with example of change of context
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0012.html
(Issue ID: 2388)
Status: VERIFIED / ACCEPTED
----------------------------
Original Comment:
----------------------------

You say :

"Example of a Failure: A help dialog

When a field receives focus, a help dialog describing the field opens.
As a keyboard user tabs through the Web page, the dialog opens every
time the user attempts to tab past the field."

but in the same page we found : "Small changes in content, such as an
expanding outline or dynamic menu, do not change the context."

I don't see why the help dialog example didn't match that exception.
If it's a failure I don't understand that Using scripts to provide
context-sensitive bubble help (future link) is a sufficient technique
for Success Criterion 3.3.5

I think you need to be more explicit about what is exactly a change of context.

Furthermore, I agree with the technique F55 but is moving the focus
when focus is received a failure too ?

For example, an text field used for a date formating. When user focus
the input I move the focus to a calendar widget to let him choose his
date.

---------------------------------------------
Response from Working Group:
---------------------------------------------

This was meant to say that moving to a control caused a dialog window
to open that grabbed focus away from the window with the control. This
was not clear, so we have changed this to read as follows:

Example of a Failure: A help dialog
 When a field receives focus, a help dialog window describing the
field and providing options opens. As a keyboard user tabs through the
Web page, the dialog opens moving the keyboard focus away from the
control every time the user attempts to tab past the field.

Regarding your calendar application - the focus should not jump to the
calendar when the person tabs to the field - but if they hit the the
spacebar or enter, it might be appropriate.  Adding a control next to
the field would also be an option.

----------------------------------------------------------
Comment 11: SC 3.1.2 - "technical terms" definition and example
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0011.html
(Issue ID: 2400)
Status: VERIFIED / PARTIAL/OTHER
----------------------------
Original Comment:
----------------------------

I think there is a need of a definition and example of what you mean
behind technical terms.

---------------------------------------------
Response from Working Group:
---------------------------------------------

We have added the following to the Understanding document:

Most professions require frequent use of technical terms which may
originate from a foreign language. Such terms are usually not
translated to all languages.  The universal nature of technical terms
also facilitate communication between professionals.

Some common examples of technical terms include: Homo sapien, Alpha
Centauri, hertz, and habeas corpus.


----------------------------------------------------------
Comment 12: SC 3.1.2 - needs another exception
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0011.html
(Issue ID: 2401)
Status: VERIFIED / NOT ACCEPTED
----------------------------
Original Comment:
----------------------------

Furthermore, it need another exception for word who can be read in the
language of context without any lost. For example "podcast" can
perfectly be read by French screen reader. Sometimes this exception is
covering the case of technical terms.

---------------------------------------------
Response from Working Group:
---------------------------------------------

Words such as "podcast" would not require a new exception since they
are already covered by the existing exception, "...except for ...
words or phrases that have become part of the vernacular of the
immediately surrounding text."

We have added the following additional example to the Understanding
3.1.2 document:

À l'occasion de l'exposition "Energie éternelle. 1500 arts d'art
indien", le Palais des Beaux-Arts de Bruxelles a lancé son premier
podcast. Vous pouvez télécharger ce podcast au format M4A et MP3.

Received on Tuesday, 11 March 2008 00:18:48 UTC