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:06:23 -0700
Message-ID: <824e742c0711032106n5671e6ddx5a9993e31d6f68c7@mail.gmail.com>
To: "Andrew Arch on behalf of Vision Australia" <andrew.arch@visionaustralia.org>
Cc: public-comments-WCAG20@w3.org

Dear Andrew Arch,

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: Level of SC 1.2.1
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html
(Issue ID: 1972)
Original Comment:

Source: http://www.w3.org/mid/000101c6964a$9c7e3160$011610ac@yourdh7axfhyur
(Issue ID: LC-1283)

Comment: It is too easy to fail SC at Level 1 - most organisations I
have worked with will not go to this length in most cases, hence will
never be able to claim even "A" conformance. In fact, on most
Government and corporate sites I have worked with, the provision of a
transcript and/or a script gives all the information needed to
substitute for the multimedia

Proposed Change:

Level 1 should have SC along the lines of "provide a transcript if
spoken words only and no action" and "provide a script including the
dialogue if video wit activity"

SC 1.2.1 & 1.2.2 should be moved up a level, and all other SC
reconsidered as to the appropriate level.

Response from Working Group:

The working group considered carefully the levels assigned to all the
GL 1.2 success criteria. SC 1.2.1 and 1.2.2 are level A success
criteria because vision and hearing impaired users will not be able to
access multimedia without this information. SC 1.2.2 can be satisfied
by a full transcript. But captioning is a much better augmentation for
the deaf than a separate transcript, since much can be communicated
non-verbally, even when there is no action.

Response from Andrew:
Comment 22 = satisfied WRT SC1.2.2; my original comments still stand WRT
SC 1.2.1

Response from Working Group:

We haven't received any new information in the latest review round
that would cause us to change our judgment on this.  We still believe
captioning is a much better augmentation for the deaf than a separate
transcript, since much can be communicated non-verbally, even when
there is no action.

Comment 2: 1.4.3 at Level AA allows sites that are unreadable for many
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html
(Issue ID: 1973)
Original Comment:

Source: http://www.w3.org/mid/000101c6964a$9c7e3160$011610ac@yourdh7axfhyur
(Issue ID: LC-1286)

Comment: Under the new Conformance level definitions, I strongly
suggest that 1.4.1 & 1.4.2 should be Level 1 and that 1.4.3 & 1.4.4
should be Level 2

Proposed Change:

reconsider the Levels the SC fall under - move them up a level

Response from Working Group:

The description of conformance levels in WCAG 2 has been rewritten to
clarify the levels (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ).

Because background audio can interfere with assistive technology, SC
1.4.1 (formerly 1.4.2) has been moved to level A.

Because level A attempts to put the fewest possible limitations on
presentation, and because assistive technology will be able to present
 the text or text equivalents of this content to the user, the working
group felt that SC 1.4.2 (formerly 1.4.1) was most appropriate at
level AA.

Because of the additional limitations they put on presentation, the
working group felt that SC 1.4.4 (formerly 1.4.3) and SC 1.4.5
(formerly 1.4.4) are most appropriate at level AAA.

Response from Andrew:
Comment 25 = partially satisfied; however, by leaving SC1.4.3 at "AA",
we still allow site with blue on green, or grey on blue, or yellow on
white, to pass at "A" while being unreadable for many many people. Also,
SC1.4.4 seem to say that current IE uses will not be able to resize the
text easily (view text size > larger/smaller) if a site just meets "A".

Response from Working Group:

1) We have moved  1.4.2 Audio control to Level A.
2) We have left 1.4.3 Contrast (Minimum) (was 1.4.1) at level AA
because there are ways using operating system or User Agent high
contrast highlighting or tools for people with colorblindness.
3) With 1.4.3 Contrast (Minimum) staying at level AA, 1.4.5 Contrast
(Enhanced) is staying at AAA
4) 1.4.4 Resize text was not moved up because text scaling is
primarily a user agent responsibility. Leaving this at Level AA should
not however, present a disadvantage for current IE users. Internet
Explorer 7 includes a zoom feature which works with absolute font

Comment 3: satisfied if SC2.2.1 includes some mention of auto-redirect
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html
(Issue ID: 1974)
Original Comment:

Source: http://www.w3.org/mid/000101c6964a$9c7e3160$011610ac@yourdh7axfhyur
(Issue ID: LC-1288)

Comment: This should be a level 2 SC - for many people with reading
difficulties, or using AT, reading a page is a time consuming
exersize, and page refreshes may not allow them to read to the end.

Proposed Change:

move this SC up a level & consider strengthening it WRT content
refreshing automatically

Response from Working Group:

Automatic page refreshes or updates are a type of time limit covered
by SC 2.2.1, which is a Level A success criterion.

See SC 2.2.1 at

Response from Andrew:

Comment 27 = satisfied if SC2.2.1 includes some mention of auto-redirect

Response from Working Group:

We have updated the intent section of 2.2.1 to clarify that page
refreshes are time limits.

Comment 4: SC 3.1.2 should be level 1
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html
(Issue ID: 1975)
Original Comment:

Source: http://www.w3.org/mid/000101c6964a$9c7e3160$011610ac@yourdh7axfhyur
(Issue ID: LC-1295)

Comment: What is the point of having 3.1.1 at Level 1, but 3.1.2 at
Level 2? My screen reader will then just read the entire page in the
web unit language!

Proposed Change:

Move 3.1.2 to Level 1

Response from Working Group:

There were requests to combine SC 3.1.1 and 3.1.2, to move their
levels up and to move them down. After much discussion, the consensus
of the working group was to leave them in the current positions.

Response from Andrew:
Comment 34 = not satisfied, please provide reasoning for retaining as
per previous draft. My comment is still valid.

Response from Working Group:

The working group felt that the language of the page was more
important than the language of the passage. It also does not require
as much coding from the author. Also Inline language changes are not
available in all technologies.

SC 3.1.2 had many complicating factors with respect to what exactly
qualifies as a change of language in a passage. That is why it has a
rather lengthy note on it to clarify situations that are not to be
considered a change of language. We felt at level A this should not be

Comment 5: LC-1300 - include WCAG 1.0 Checkpoint 1.5
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html
(Issue ID: 1976)
Original Comment:

Source: http://www.w3.org/mid/001b01c69664$ec069c30$011610ac@yourdh7axfhyur
(Issue ID: LC-1300)

Comment: Several WCAG 1.0 checkpoints that are still very important
for some people with disabilities are missing from WCAG 2.0:-

1.5 (text equivalents for image map links) - important for people with
some learning difficulties (some people are text oriented, others are
graphics oriented)


10.5 (separating links visually) - acknowledged as important for some
people with cognitative disabilities...

13.8 (front loading) - important for many people with reading difficulties

14.1 (clear language) - important for many people with reading
difficulties; also the related SC are now Level 3 (cf P1 in WCAG
1.0)Proposed Change:

Add these Checkpoints back in as WCAG 2.0 SC.

I acknowledge that some of these may not be machine testable, but they
are human (consensus) testable.

Response from Working Group:

1.5 (text equivalents for image map links) - important for people with
some learning difficulties (some people are text oriented, others are
graphics oriented)

Image maps are non-text content and they are links. Therefore, this
requirement is covered under Success Criteria 1.1.1, 2.4.4, and 2.4.5.
HTML technique H24 "Providing text alternatives for the area elements
of image maps" is a sufficient technique for these success criteria.



10.5 (separating links visually) - acknowledged as important for some
people with cognitive disabilities

We have added an advisory technique to GL 3.1, 1.3 and 2.4  titled
"Making links visually distinct."


13.8 (front loading) - important for many people with reading difficulties

This is addressed by an advisory technique listed under SC 2.4.6
(formerly 2.4.5), "Starting section headings with unique information".


14.1 (clear language) - important for many people with reading
difficulties; also the related SC are now Level AAA (cf P1 in WCAG

A characteristic that is important to WCAG 2.0 is the testability of
each success criterion. We have not been able to create a testable
description of "clear language." We have tried to cover this in some
of the success criteria and have added advisory techniques in
Guideline 3.1. However, there is no direct mapping.


Response from Andrew:

Comment 39 (WCAG 1.0 - 1.5) = unsatisfied. Current user agents do not
display the area alt text when the image is not display. Also, for
people with image processing difficulty, the image map may not be
comprehensible, while a text list might be. Furthermore, image-maps
pixelate for screen magnifier users - text-based lists are easy to
magnify well/smoothly.

Comment 39 (WCAG 1.0 - 10.5) = unsatisfied with just an advisory
technique; original comment still stands

Comment 39 (WCAG 1.0 - 13.6) = unsatisfied with just an advisory
technique. Is this because it is not 'testable'?

Comment 39 (WCAG 1.0 - 14.1) = unsatisfied, but I might just have to accept

Response from Working Group:

Regarding (WCAG 1.0 - 1.5):
In IE7 there are placeholders for images when the advanced settings
are set not to load images. The alternate text shows in Zoomtext and
reads in JAWS.

This is not the case for Firefox 2.0. Firefox does not load the images
at all when images are set off. There is no placeholder. But this is
true for all images. If someone turns off images in Firefox 2, they
will not get *any* alt text, including image maps.

We have not encountered any Screen readers or Screen Magnifiers that
have behavioral differences while rendering image map alt-text
(compared to regular alt text on images) when images are turned off.

Regarding the image pixilation issue, we have zoomed in on an image to
the point of having 4 words across the entire screen (5x). There was
not significant pixilation that would greatly inhibit comprehension.
Current versions of screen magnifiers have come a long way on the
pixilation issue.

We feel that there is not sufficient basis for including this issue as
a separate Success Criterion. The working group believes the best way
to address this issue is as an advisory technique.


Regarding (WCAG 1.0 - 10.5):
We have requested input from a WCAG contributor who is self identified
as having a cognitive disability and has been a strong advocate for
the Cognitive community. She has not encountered or heard of any
benefits to people with Cognitive disabilities from WCAG 1.0
checkpoint 1.5 since its release in 1999.

The working group believes the best way to address this issue is as an
advisory technique.


Regarding (WCAG 1.0 - 13.8):
There are several reasons why the working group felt that this WCAG
1.0 Checkpoint could not be required in WCAG 2.0. Part of the reason
is that it is not testable.

It can be very difficult (and sometimes more confusing) to make
data-driven content conform to this sort of requirement. There are
cases when it is important to number items before the Title or to have
a section name (or code) included in the Title. This is especially
true for technical web sites and documentation. This is also true for
dynamic sites that present web pages populated with information from a
database in different arrangements based on the query. In a dynamic
web environment which is currently the norm for web sites, it is much
more difficult to require this than on a static HTML page as in 1999
when WCAG 1.0 was published.


Regarding (WCAG 1.0 - 14.1):
We agree that clear language is helpful. However, it is very difficult
to test for this.

In order for authors to know whether they have actually fulfilled the
requirements of the Guidelines, the success criteria need to be
testable. Unfortunately, there is a cost to this because things that
are not easily testable can only be given advisory status. However, if
we removed the testability requirement from the Success Criteria then
the entire WCAG 2.0 would be advisory.

In addition, the requirements for clear and simple writing vary based
on human language. Since WCAG has to apply to all web sites in all
languages, the working group did not feel that we could create useful
requirements in this area.  We have, however, captured a range of
advisory techniques that may be applied in different contexts and
languages as they apply. and we are seeking more.

Comment 6: The phrasing of this SC is not definitive enough
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0297.html
(Issue ID: 2126)
Original Comment:

Some of the informative discussion refers to techniques that would add
to confusion for visual users. The current test procedure for F73
(links not visually evident) states "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) as a link
without relying on color". However, the use of bolding and italicising
is normally used for emphasis of words or sections of a document.

Allowing the author/designer to use bold or italics to indicate linked
text instead of underling leads to a recommendation that goes against
conventional practice and, while meeting SC 1.4.1 technically, does
not actually make links identifiable for visual users.

Proposed Change:
Rephrase the SC as "Any information that is conveyed by color
differences is also simultaneously and unambiguously visually evident
without the color differences."

Rephrase the F73 test as "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"

Clarify some of the informative discussion to ensure that conventions
are followed.

Response from Working Group:

We have harmonized instead with the language in ISO, HFES and TEITAC.
the provision now reads
"Color is not used as the only visual means of conveying information,
indicating an action, prompting a response, or distinguishing a visual

Comment 7: This SC is at a level that will not be adopted by many
sites - it is too important to leave at AAA
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0298.html
(Issue ID: 2127)
Original Comment:

Screen reader users commonly use a navigation technique which brings
up a list of all the links on the current page. The list of links
created by the screen reader software is presented in a separate
dialog box or window and enables users to move to a specific links by
entering the first letter of the link from the keyboard. For example,
entering the letter "e" moves the focus to the first link which starts
with the letter "e", then the second link starting with "e", and so

Having access to this list an important and much used functionality
for screen reader users as it allows them quick and easy access to all
the links on the page (links being one of the most crucial elements of
a web pages).

When the links are presented in this manner, the user has no access to
the context in which the link appears on the page without returning to
the page and progressively moving through the interactive elements.

It is therefore important to implement meaningful, descriptive, and
unique link texts as this allows screen reader users to utilise this
important means of navigation (if such link text is not used, for
example if all link text consist of the phrase "click here", then the
links list cannot be used.)

Screen reader users can use the tab key to jump sequentially through
all active elements on a page, including link elements. When a link
attains focus the screen reader announces the link text. If the link
text does not provide a meaningful and descriptive link text, the
screen reader user must explore the surrounding text to determine the
destination of the link, including determining whether the preceding
or the following text provides the relevant information. This slows
down the access to page content and navigation and can lead to
ambiguity with regards to link destination.

Some users groups with reduced vision (including certain users who
rely on screen magnification software) try to minimise any reading so
it only includes essential information, as reading places great strain
on their eyes. Such users endeavour to navigate and orientate
themselves using visual cues such as colours and borders as these do
not involve the reading of letters. When such uses scan page content
to pick up important information (including links) they are helped by
links being rendered with different colours and underlined (as per SC
1.4.1), as this makes the links stand out and therefore easy to pick
out from the surrounding text. Implementing meaningful link text helps
these users as they only have to read the link text to understand the
link destination and do not have to read the surrounding text.

Some users with cognitive disabilities might find it difficult to
understand that the destination of links can only be ascertained by
reading the surrounding text. Such users can find it confusing that
links with identical link text can point to different locations, for
example if a page contains 10 "click here" links.

Some users with reading difficulties have problems deciphering text,
providing these users with clear destinations via the link text is a
very important aspect of meeting the needs of the widest range of
people with disabilities.

Proposed Change:
Upgrade SC 2.4.8 to level AA

Response from Working Group:

The working group recognizes that the link list mechanism provided by
user agents and assistive technology will provide best results when SC
2.4.8 is satisfied.

While the working group encourages authors to make link text as
descriptive as possible out of context, we do not feel that this
success criterion can be satisfied for all Web pages. For Example:
- a page has book titles followed by PDF, HTML, DOC.
- Article name (long) followed by a sentence and the link "more"
- GOOGLE search where each entry has text plus the following links
[translate this page] HTML and [CACHED] and [SIMILAR PAGES]
- toolbar with menus with an arrow icon - the link says "open".
Having full links makes the page very cluttered, harder cognitively to
find things  when the same long (sometimes multi-line) text is
repeated with one word different, and is very long to listen to for
those not adept at auditory skipping (or where unique information is
back end loaded)

These issues were considered carefully for a long time, the working
group feels that having 2.4.4 at Level A and this issue addressed at
Level AAA strikes the right balance.

While user agent and assistive technology support for finding the link
context is poorer than we would like, we have checked that there is at
least one case of support for each of the types of link context we
have listed as sufficient techniques. So a user who has tabbed to a
link can ask for those pieces of context without leaving the link.

We hope that if authors satisfy SC 2.4.4 and make link context
programmatically determinable, user agent developers will find a way
to let users access the context when needed, such as when the link
list is created.

The first techniques listed in 2.4.4 are:
"G91: Providing link text that describes the purpose of a link
H30: Providing link text that describes the purpose of a link for
anchor elements (HTML)

Comment 8: access to the text alternatives for image maps
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0014.html
(Issue ID: 2314)
Original Comment:

Further to our previous comment on "Prohibiting images of important
text", Vision Australia would also like to raise the issue of how a
user accessing pages with images off would necessarily know of the
presence of an image map, let alone be able to access the map regions?
Most browsers do not render the text alternative for and outlines of
map regions.

WCAG 2.0 SC 1.1.1 seems to currently allow for informational images as
long as those images have a text equivalent that can be
programmatically determined " eg an Alt attribute in HTML. If those
user groups with low vision magnify an image with current technology,
it can pixelate to the extent of being unusable, so they expected to
turn images off to access the text alternative.

However, in the case of HTML image maps, it is just the text
alternative of the image that is display, not the text alternatives
for he MAP areas or hot-spots. The user is not to know that the image
has selectable areas, nor where those area boundaries are even if they
did know that the image they can no longer see does have selectable

Furthermore, some people with cognitive disabilities are unable to
process image-based information and prefer clear text-based
information. These people can see the image perfectly well, but may
not recognise the areas they are supposed to select from.

WCAG 1.0 has a checkpoint (1.5) that requires the provision of
"redundant text links for each active region of a client-side image
map". For many groups accessing the web, this is still a requirement.

Proposed Change:
Add a success criterion requiring image map links to also be made
available as text-based links

Response from Working Group:

We believe that the issue you highlight is already addressed by the
current wording of 1.1.1 which requires that if non-text content is a
control or accepts user input, then it has a name that describes its
purpose.  We have extended technique H24 to indicate to authors how to
meet 1.1.1 and have added the following to the User Agent Notes:
However, currently, visual User Agents do not display the alt
attribute text for area elements of image maps when accessed by
keyboard or when images are not displayed, and may clip the area
elements if the intrinsic size of the image is not used. In addition,
the display of alt attribute text in response to mouse-hover does not
display in the font size or color combination set in the User Agent.
Received on Sunday, 4 November 2007 04:06:39 UTC

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