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:09:39 -0700
Message-ID: <824e742c0711032109t7f9fa1b7q3cf70c96a4cb0fe2@mail.gmail.com>
To: "Aurelien Levy" <aurelien.levy@free.fr>
Cc: public-comments-WCAG20@w3.org

Dear Aurelien Levy,

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: Switching languages within an attribute
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0206.html
(Issue ID: 2021)
Original Comment:

what about lang in attribute value like an English alt attribute in a
french page and what about attribute value who mix the language

Response from Working Group:

If the language of an alt attribute is different from the surrounding
text, the  element should be given a lang attribute to indicate the
language of the alt attribute.

HTML provides no mechanism for marking up language changes within an
attribute. In such a situation, another technique may be needed that
provides this support. For instance, longdesc could provide a link to
a web page in which the language changes could be marked up

This is awkward and only works for images. For other attributes, mixed
languages could not be used and still conform to this particular SC.

Comment 2: F44 is failure of 2.4.3, not 2.4.4
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0201.html
(Issue ID: 2022)
Original Comment:

This is a 2.4.3 failure not 2.4.4

Proposed Change:
*F44: Failure of SC 2.4.3 due to using tabindex to create a tab order
that does not follow relationships and sequences in the content

Response from Working Group:

We have corrected this error in the Failure title.

Comment 3: F63 is a failure of 2.4.4, not 2.4.6
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0202.html
(Issue ID: 2023)
Original Comment:

this is a 2.4.4 failure

Proposed Change:
F63: Failure of SC 2.4.4 due to providing link context only in content
that is not related to the link

Response from Working Group:

We have corrected this error in the failure title.

Comment 4: contextual alternative
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0148.html
(Issue ID: 2027)
Original Comment:

i didn\'t see anywhere that i can have an empty alt attribut on an
image when the text alternative is next to the image tag like :

<img alt=\"\" src=\"cars.pjg\">A nice racing car

What about image replacement technique like here

for me the last technique is perfectly accessible

Response from Working Group:

The use of an empty alt tag on images is reserved for decorative
images, not for images that are redundant with text elsewhere on the
page.  If an image is described on the page, there is a sufficient
technique that allows one to put a short phrase in the image that
points to a description in the text.  For example
alt="Picture of car described in text immediately following this image".

If, however the image and text were enclosed within the same link (ex.
Products page) then the empty alt attribute value could be used. Refer
to technique H2: Combining adjacent image and text links for the same
resource (http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/H2.html) for
more information.

Regarding the image replacement technique you referenced, since the
use of non-text content in the Shea Enhancement example would be
considered decorative and the "alternative" is available to AT, then
this technique would be sufficient to meet 1.1.1. To clarify this, we
have added an example to C9: Using CSS to include decorative images.

Comment 5: level of SC 1.2.3
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0149.html
(Issue ID: 2028)
Original Comment:

I really think this success criteria must be in AAA because of his
cost, and difficulty to be integrated in an industrial production of

On the other hand I don't understand why the live audiodescription in
not included in the document even at a AAA level. If it was include it
must be at the same level as the live captioning

Response from Working Group:

Captioning of live material is both important and possible today.  For
material that is professionally broadcast on the Web the cost would be
much less than the production cost. For informal, non-professional
live productions, we agree that this criterion would be difficult to

Audio description of live material is not possible without
significantly delaying the material except in the few cases where the
material is a play or other pre-scripted activity. The describer
simply doesn't know when the gaps in audio will occur or how long they
will be.

Comment 6: contextual caption and summary
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0150.html
(Issue ID: 2029)
Original Comment:

What about data table without caption and summary but textual
information just before the table who actually is the caption or
summary information. For example, if i do shopping cart with a table
element and just before the table use something like <h3> Your
shopping cart</h3> <p> in every line of your shopping cart who will
find, the production name, it's price and the quantity you want</p>

Response from Working Group:

The example provided in your comment would lack the characteristic of
programmatically exposing the relationship between the table and
header / summary provided before it. Users navigating from table to
table might not easily find this information, as they would if the
information were directly associated with the table. Therefore, it
would be an example in which the HTML techniques for caption and
summary would be preferred. That said, it may still be a judgement
call about what information should appear as in your example and what
would need to be directly associated with the table, and it may be
most appropriate to duplicate some information, such as providing the
summary both in the paragraph before the table and in the summary
attribute of the table itself.

Comment 7: missing information on SC 1.3.3 common failures
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0151.html
(Issue ID: 2030)
Original Comment:

What about the use of shape to convey information by itself for
exemple a two parts document the first part is in a square shape and
the others is in a rounded square shape. The distinction between the
two part is just a visual distinction based on his shape.

Response from Working Group:

If shape were used to convey information in the absence of any
instructions, then it would be a failure of 1.1.1 or 1.3.1.

If there were instructions that depended on the shapes - then it would
be a failure of 1.3.3. For example, for text content styled with CSS
to generate containers with different shape in a page where
instructions rely on the shape of these containers, there would be a
failure of SC 1.3.3.

However, if the different shapes are just used to make the different
sections more distinct visually, but the actual shape does not convey
information - then this would not violate the success criterion - nor
success criterion 1.1.1.

Comment 8: Use of color information for contextual distinction
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0152.html
(Issue ID: 2031)
Original Comment:

make sure clearly define : Ensuring that when text color is used to
convey information, the text style is visually differentiated without
color (future link) for example is this a failure :

- Use a different color scheme between two category of a website

- Use background color to show what is the currently visited page in a
navigation bar

Currently, the background color of an element to give information is
not treated at all.

Furthermore, without color is equal to turning off color only or style too ?

I think the G111 technique can't be achieve in every case specially in
maps, you must add the text information case like G111: Using color
and pattern or textual information.

If I have a map with two road to go to a point, I can use two
different colors for the two roads put I can identify road in text
like road 1 and road 2

Finally , I think the F73: Failure of SC 1.4.1 due to creating links
that are not visually evident without color vision must me more clear
to directly identify that it's just for links within text that is part
of a sentence or paragraph.

Even with that I'm not sure it's a good point because bold or
italicized text can be hard to read in some case so the only way i
have is to underline the link.

I think the link must be visually different but i think color
difference can be sufficient if the color difference is sufficient.

Exemple: red link and black text pass the test, dark grey link and
black text fail. People who actually didn't see the red still see a
color difference.

Response from Working Group:

We have changed the success criteria and the Failure to allow more
types of 'non-color coding' including differences in luminance such as
you suggested. (see below)

G111 may not always be applicable but it is not required. It is one
technique.  We have also added another technique:

"Conveying all information in text that is conveyed in color"

SC 1.4.1 has been reworded as: Color is not used as the only visual
means of conveying information, indicating an action, prompting a
response, or distinguishing a visual element.

In F73, the following note has been added to the Description: If the
link is a different color and bold it would not fail because the
boldness is not color dependent.

Comment 9: Contrast value and background problem
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0154.html
(Issue ID: 2032)
Original Comment:

First I think the 5:1 value is too difficult to achieve currently
something like every website will fail (even the w3 website actually),
a 4:1 value seen to be more realistic to me.

The document must be more clear about how to handle text hover
background or gradient image, the G18 technique must be more explicit
how to test it. For example, how many pixel must have the halo to
validate ?

The success and failure technique must repeat (and images of text) in
there wording like in the criterion itself to more clear.

For the h21 and f24 I'm ok for most of the part but I think their is a
case where the user must specify there need correctly. For example, if
the author specify white background color on body element and the user
has modified is UA to have black background, the user must change the
text color too, it's nonsense to just modify the background color.

Futhermore, it's to UA to propose alternate style sheet (like opera
browser do) and option to render webpage with user preference in every

Finally, there is case where even with good color contrast a text is
still difficult to read look at this example :


Response from Working Group:

We have added information to make it clearer how to handle text over a
background including:

H21: Not specifying background color, not specifying text color, and
not using CSS that changes those defaults (HTML)

F24: Failure of SC 1.4.3 and 1.4.5 due to specifying foreground colors
without specifying background colors or vice versa

We have added  "(and images of text) " to the techniques.

We are staying with 5:1 at Level AA based on the rationale in the
Understanding 1.4.3.  We have no contrast required at Level A since
high contrast system highlighting and simple color shifting assistive
technology can address the problem there.

Comment 10: Please choose your side, UA bug or not ?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0158.html
(Issue ID: 2034)
Original Comment:

Can you give me a case where this criteria is failed, with the current
sufficient technique I can pass every time since html support zoom and
opera zoom can render perfectly in every case. Otherwise define what
is commonly available.

And this one :

3. Providing controls on the Web page that incrementally change the
size of the text (future link)

Please tell me that it's not javascript widget width some 10pxX10px
image to increase or decrease the text size of part of the page. If it
case the case, it was just another way to say everybody will pass this

So please, choose your side, it's an UA problem or it's not. If it's
not, the only way to pass the test must be that the page render
correctly when the user increase the text size to 200% with the UA
features (if it don't resize at all, like IE with pixel, it's an IE
bug not accessibility issue from the author, otherwise add a criteria
about use off %, keyword or em value for text sizing)

Response from Working Group:

This success criterion includes a heavy interaction with user agent
functionality. The goal is to ensure that, between the user agent and
the author, a way is provided to the user to resize text. It is
important to remember that this success criterion is not just about
HTML. Other technologies have their own user agents with varying

The author cannot rely on the user agent to satisfy SC 1.4.4 for HTML
content if users do not have access to a user agent with zoom support.
For example, if they work in an environment that requires them to use
IE 6 or Firefox.

If the author is using a technology whose user agents do not provide
zoom support, the author is responsible to provide this type of
functionality directly or to provide content that works with the type
of functionality provided by the user agent. If the user agent doesn't
provide zoom functionality but does let the user change the text size,
the author is responsible for ensuring that the content remains usable
when the text is resized.

The working group anticipates that, over time, this success criterion
will be satisfied by user agents and not by authors directly.

Comment 11: G21: UA bug on object
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0182.html
(Issue ID: 2043)
Original Comment:

I think the G21 technique is partially wrong because for most of the
case it's an UA, plugin or  AT manufacturers problem not an author

For example, actually Firefox don't provide a way to navigate with
keyboard trough a Flash object. the only way to achieve this is to
click on it with the mouse and then click outside the flash to get the
focus out.

It's a Firefox bug not an author mistake, yes the author can hack this
bug by providing a link before the flash and then use javascript and
actionscript to move focus in and out of the flash element but what if
javascript is turned off ?

Yes the users must not be trapped in the content, but for me it's just
applicable in the case where the plugin or UA provide a way to access
it (in and out) with the keyboard. So, it's more : don't break the UA
or plugin feature to access plugin element otherwise the user can be
trapped in the element.

For exemple, at this time, for Flash element, it's equal to test that
with IE the user can go trough the flash element without be trapped,
with other browser i haven't to test it because they don't provide a
way to trough the flash element with keyboard without the mouse (for
Firefox, Safari and Opera at least)

Response from Working Group:

We have fixed the technique to be more accurate and clear.  "If the
author uses a technology that does not allow users to exit the
sub-content by default (i.e. it is not a feature of the web content
technology or its user agents) then, in order to implement this
technique the author would build such a capability into their content
or not use the technology."

This captures the dependency that all web content techniques have on
user agent and assistive technology support. The user will be trapped
in the content just as badly, whether the error is in the authored
content or the user agent. The author must choose techniques and
technologies for which WCAG can be satisfied.

Comment 12: Frame technique promote old fashion web
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0183.html
(Issue ID: 2044)
Original Comment:

Please remove the H70 technique even with title attribute frame is
painful to use, it's no a good example to promote accessible web.

Yes, this way I can skip them easily but I can't use , access the
content of the frame easily.

Don't promote old fashion web

Response from Working Group:

H70 says that the technique of using frames to group repeated material
is only appropriate when framesets are already used to organize the
content of the page, and that other techniques are preferred.

Assistive technology support for frames has improved, so we feel this
is a sufficient technique for SC 2.4.1.

Comment 13: F63: direct context or DOM context
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0205.html
(Issue ID: 2051)
Original Comment:

I disagree with this failure because link can't be used out of context
and there is always a DOM context, it's an AT missing feature to have
an easy way to read full parent element, next sibling or preview

For your example :


<p>A British businessman has racked up 2 million flyer miles and plans to
travel on the world's first commercial tourism flights to space.</p>

<p><a href="ff.html">Read More...</a></p>


the user must be able to read the brothers element of the a element
(in this case empty), or read the brothers element of his parent
element (in this case the content of the previous p element, or read
the content of his grandfather (in this case the whole div element)

In definition list, dd go whis dt so if i read an a element in a dd i
must be able to access to content of the previous dt element and
brothers dd elements

Furthermore, if there is a title attribute with a title longer than
the content of the a element and explaining the purpose of the link, i
think the test must passed.

Make your choice, stay in the wcag 1.0 position and say the link must
be understandable out of context or just say ok it's nearly
impossible, so if you can't do it, use the title attribute to do so
(or act that it impossible at all).

Response from Working Group:

It is true that there is always some context that explains the purpose
of the link. Otherwise, no one would know what it meant, which would
be a usability problem rather than an accessibility problem.

However, a blind user must be able to find the relevant context in a
supported way. It is not sufficient to expect the user to search the
entire page for the relevant context, or start searching arbitrarily
in the DOM "near" the link to find the important context. This is why
the success criterion say that the context is programmatically

Comment 14: F15: Invalid test procedure
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0211.html
(Issue ID: 2054)
Original Comment:

F15: Failure of SC 4.1.2 due to implementing custom controls that do not use...

Since, the AT have different support of non html technology like java
and flash i can\'t use it to test this and sometimes i can\'t have
access to source code or have the commercial product to open that
code. Not everybody as a PC with Jaws 8 and Flash installed on it.

So, the result of this test is not Yes or No but more "Maybe in some
case it's accessible and maybe in some others it's not"

Response from Working Group:

Content like Flash can be evaluated without having the source code.
There are tools which are available (usually free) from the company
that created the API(e.g. Microsoft) that will allow you to check the
way the content has implemented the API to see if it is implemented
completely and properly by the content. Flash can also be evaluated
using the Flash authoring tool. Testing with screen readers is also
good but as you say not everyone has one.   There are services such as
Narrator in Windows and Voiceover for Macintosh however that are free
and will also voice things that implement the Microsoft or Apple APIs.

Comment 15: SC 3.3.3: more ergonomic problem than accessibility problem
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0214.html
(Issue ID: 2056)
Original Comment:

i think that this success criterion is more an ergonomic problem than
accessibility problem, everybody can do mistake and everybody need to
have a way to correct it. I am not sure that people with disability
have more trouble than others people so i think a AAA level is better

Response from Working Group:

While it is true that everyone can make mistakes, users with
disabilities may be more likely to make mistakes and may have a more
difficult time recovering from mistakes, as discussed in Understanding
SC 3.3.3. This Level AA success criterion is a more restricted version
of the Level AAA success criterion 3.3.6; it applies only to actions
where an error has particularly serious consequences. For this reason,
the working group feels that Level AA is appropriate.

Comment 16: common failure and Sufficient Techniques matching
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0215.html
(Issue ID: 2057)
Original Comment:

there is numbers of case where the common failure did not match the
Sufficient Techniques like in 2.2.1, 3.2.1

Response from Working Group:

Common failures are situations that are known to fail the success
criterion. We list them because they are examples of content found on
the web that cause accessibility problems. By listing them as
failures, we make clear that the failure behavior is violating the
success criterion.

The list of sufficient techniques does not include every way to pass
the success criterion. So it is possible that there is not yet a
matching sufficient technique for every failure. We welcome
contributions of additional sufficient techniques that we could add to
the Understanding WCAG document.

Comment 17: 3.2 SC need more explanation and examples
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0216.html
(Issue ID: 2058)
Original Comment:

I think this success criterion

* Understanding Success Criterion 3.2.1 (On Focus)

* Understanding Success Criterion 3.2.2 (On Input)

* Understanding Success Criterion 3.2.5 (Change on Request)

need a lot more example, technique, common failure and explanation to
be clearly understand. Specially, what about ajax features like auto
completion, on blur partial validation and other stuff like that?

Response from Working Group:

We agree that more examples, techniques, and explanation are always
helpful. We would particularly welcome submissions of Ajax techniques
and failures, using the  Techniques for WCAG 2.0 submission form at
http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/ .

We are not sure what you are asking about auto completion and onblur
partial validation without more details about their behavior. Auto
completion does not cause a change in context. If onblur partial
validation causes a change in context,  it would violate SC 3.2.5.
Depending on the details of the functionality, it may also violate SC

Comment 18: better but still dommageable concept
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0217.html
(Issue ID: 2059)
Original Comment:

I think the concept of accessibility supported technologies is far
better than the baseline concept in term of wording. It's much more
understandable but there is still big problems with lake of definition
of some element like : widely-distributed user agents and
widely-distributed user plugins, purchase in a way that does not
disadvantage people with disabilities (purchase disadvantage
everybody, as far as i know AT vendor didn't not sell different
version for disabled or not person, and if it's about cost
disadvantage at what price it make it a disadvantage)

There is question with no response like how many platform, AT,
language need to support a technology to be concidered like

One of the most problematic part is : Authors, companies or others may
wish to create and use their own lists of accessibility-supported

For me it's clearly means that for example Adobe can say Flash is an
accessible technology because it's work when you use Flash 7 or more,
IE and a PC and a "widely distributed" plugin. But what about Mac and
Linux Users,  what about jaws 6 and firefox users.

At this time validate the fact, that only HTML (and maybe PDF) can  be
considered like an accessibility supported technology, other
technology specially flash and javascript still need fallback
alternative. Otherwise, we will see a lot off full flash website
working just with ie  claimed that they are accessible with a AAA
level when majority of user haven't any access to content.

It's to the WCAG working group to maintain a list of accessible
technology and not only limited to W3C technology (since the working
group is partially composed by employee of non standard technology
company it must not be a problem)

Response from Working Group:

Companies may indeed want to use their own lists.  If it is a good
list there would not be a problem.  If it is a bad list, it would be
similar to a bad interpretation of the guidelines and would need to be
controlled in the same way.   WCAG does intend to work with others to
help create a list.  This could be then used by those not interested
or capable of creating their own researched list.   As for companies
posting lists with their products on them with unrealistic appraisals,
we would expect that this would not happen because of the feedback and
comment it would likely generate on the Web and in the community.

We do not have any requirements for platforms per se, but the
documented list of accessibility support for a technology should note
which platforms the technology has AT support on. This is described
more in Documenting Accessibility Support for a Web Technology
Received on Sunday, 4 November 2007 04:10:03 UTC

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