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 22:09:14 -0700
Message-ID: <824e742c0711032209i3adf92eanf0456d4d9b37e07e@mail.gmail.com>
To: "Roger Hudson" <rhudson@usability.com.au>
Cc: public-comments-WCAG20@w3.org

Dear Roger Hudson,

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: SC 2.4.8 should be at higher level
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0274.html
(Issue ID: 2104)
Original Comment:

The sufficient techniques for Success Criterion 2.4.4 (level A) do not
appear to preclude the use of "more" or "click here" links. All that
is required is the surrounding sentence of paragraph provides a
context for the link. Clearly, this could result in situations where a
screen reader user is presented with a list of meaningless links when
they use the common navigation technique of obtaining a list of links
on the page with a keyboard shortcut.

Success Criterion 2.4.8 however does appear to use of descriptive and
meaningful text links. This criterion however is at AAA Level, which
given the importance of this issue to screen reader users is in my
view inadequate

Proposed Change:
SC 2.4.8 should be at AA level.

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

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 2: contrast ratio SC level
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0273.html
(Issue ID: 2103)
Original Comment:

1.4.3 Contrast (Minimum): Text (and images of text) have a contrast
ratio of at least 5:1, except if the text is pure decoration.
Larger-scale text or images of text can have a contrast ratio of 3:1.
(Level AA)

Comment: My comments relating to this issue last year suggested the
Level should be increased to A. I was advised in general terms by the
working group that the issue was discussed but no specific response to
my comment was provided.

I believe this is a significant accessibility issue since in my work I
have observed many people (including sizable proportion of the older
population)experience difficulties in differentiating between
foreground and background colours used on websites.

Proposed Change:
1.4.3 should be at Level A

Response from Working Group:

There are a number of ways that text can be made visible by people who
have trouble with low contrast. Many OS's have a high contrast mode
which makes the entire desktop high contrast, or a high contrast
"highlight" feature such than any 'selected' text is highlighted in
high contrast. There are also tools that will increase the contrast
for people with colorblindness. As a result there are strategies for
those with colorblindness or who need high contrast.

5:1 contrast is limiting on design with the availability of tools the
working group felt that this provision was best at level AA.

We did consider a lower bar at level A but felt that would limit
design and that by not having a lower provision at Level A - those
places that wanted contrast by default - and that could live with the
design constraint, would specify this SC be included in their design
or purchase specification.

Comment 3: SC level for 3.1.3
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0275.html
(Issue ID: 2105)
Original Comment:

3.1.3 Unusual Words: A mechanism is available for identifying specific
definitions of words or phrases used in an unusual or restricted way,
including idioms and jargon. (Level AAA)

Comment: In general WCAG 2.0 does not provide enough guidance for
improving the accessibility of web content for people with cognitive,
language and/or learning limitations. At the very least, providing a
mechanism for enabling users to easily obtain definitions of unusual
or specialist phrases should be a Level AA success criterion.

Proposed Change:
Change the SC for 3.1.3 to AA

Response from Working Group:

This is a new provision in WCAG 2.0 and it is not clear how difficult
it will be to conform to this success criterion or whether there is
any practical approach at all for some types of content - especially
when technical content comes from different sources and the Webmaster
or Web 'author' is not conversant in the technical matters.  Content
in some fields would become extremely difficult to read if *all*
specialized vocabulary had to be defined either inline or via linking,
even when the terms are well known in their respective fields. Jargon
is typically a barrier for people who are not in the field where the
jargon is used -- e.g., the jargon of literary history may be
problematic for chemical engineers but not for literary historians.
Practitioners in a field are likely to provide definitions when
introducing new terms or re-defining existing ones-- but would not
think of defining, or even recognizing as jargon, basic and very
common words in their field that they use routinely every day.

With more experience it may be that techniques will be developed to
handle this issue and it can be moved up in future guidelines.  But at
this time it is too new and the Working Group feels it should be at
Level AAA.

Comment 4: 3.1.4 SC should be AA
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0276.html
(Issue ID: 2106)
Original Comment:

3.1.4 Abbreviations: A mechanism for finding the expanded form or
meaning of abbreviations is available. (Level AAA)

Comment: In general WCAG 2.0 does not provide enough guidance for
improving the accessibility of web content for people with cognitive,
language and/or learning limitations. At the very least, providing a
mechanism that will enable users to easily obtain an expanded form or
meaning of abbreviations should be a Level AA success criterion.

Proposed Change:
The SC for 3.1.4 should be AA

Response from Working Group:

Many fields include acronyms among their jargon, and these would have
the same difficulties discussed in our response to your comment on
3.1.3.  A computer science paper with links on all the abbreviations
would be very difficult to read. The working group feels that this is
the appropriate level for this success criterion because it can't be
applied to this type of technical content, and is therefore not
appropriate for all types of sites.

For these reasons, the group feels that is should remain at level AAA.
 It should be noted that acronyms were AAA in WCAG 1.0 as well.

Comment 5: Increase SC for 3.3.4
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0277.html
(Issue ID: 2107)
Original Comment:

3.3.4 Labels or Instructions: Labels or instructions are provided when
content requires user input. (Level AA)

Comment: Clear labels or instructions for users when they are required
to make an input are likely to benefit everyone, but can be absolutely
essential for people with cognitive, language and/or learning

Proposed Change:
Change the SC level for 3.3.4 to A

Response from Working Group:

We have moved SC 3.3.4 (now 3.3.2) to level A.

Comment 6: Success Criterion score
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0278.html
(Issue ID: 2108)
Original Comment:

I feel the use of the conformance system that uses the letter A to
indicate the Success Criteria level is potentially confusing.

The WCAG 2.0 Success Criteria schema is different to that used in WCAG
1.0, but WCAG 1.0 also indicated Priority level compliance with the
letter A.

In practice, web developers and regulatory organizations used the WCAG
1.0 Priority levels as a measure for determining levels of
accessibility, and they are likely to continue to do so with WCAG 2.0.
And, if the letter A is to used as the indicator there is a real risk
that people will believe a WCAG 2.0 AAA is the same as a WCAG 1.0 AAA
and not understand the differences. As a result some important WCAG
2.00 AAA Success Criteria such as 1.4.6 are likely to be ignored.

Proposed Change:
The working group should develop a new system for indicating
compliance levels for the Success Criteria.

Response from Working Group:

The working group has moved away from the Priority 1, 2, 3 at the
specific request of people working with cognitive disabilities because
it sounded like the items at level AAA were only 3rd priority things
when they were in fact very important to people. Things ended up in
Level AAA for a number of reasons including the fact that some could
not be applied to all types of content. But not because they were 'low

We considered a number of alternative terms for the levels but every
combination seemed to have an issue. We have decided to retain A, AA
and AAA.

Comment 7: doing a little more for people with cognitive limitations
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0279.html
(Issue ID: 2109)
Original Comment:

Guideline 3.1 is concerned with the need to make text readable and
understandable. In general WCAG 2.0 contains very few provisions for
improving the accessibility of web content for people with cognitive
disabilities or learning difficulties.

When this lack of specific guidance relating to people with cognitive,
language and learning limitations were raised by me and other people
following the release of the WCAG Last Draft in 2006, the general
response of the Working Group was, \"We have added some best practices
for cognitive, learning, and language disabilities as advisory
techniques. We have not been able to propose many additional success
criteria that meet WCAG\'s testability requirements.\"

I agree it is hard to make some of the requirements for improving
accessibility for people with cognitive, language and/or learning
limitations machine testable. However, my reading of the definition of
testability includes the provision for reliable human testable
compliance. It is my view, many issues that were previously dismissed
as not testable, are in fact testable by qualified human testers.

Proposed change: I believe the Working Group should include the
following Level AA Success Criterion for guideline 3.1. At the least,
this will go some small way to addressing the short comings in
relation to cognitive and learning limitations in the proposed draft
of WCAG 2.0.

Proposed Change:
3.1.? Comprehension: Barriers to the readability or comprehension of
text, tables and forms be avoided, or a mechanism for obtaining
supplementary content or an alternative version is provided. (level

Techniques could include:

Use the clearest and simplest language appropriate for a site\'s content.

Provide a mechanism for users to easily change text font size and the
line-height of paragraphs.

Avoid the use of complex and highly decorative backgrounds for text or
provide a mechanism for users to easily remove the background.

Avoid the use of highly decorative font styles for text or provide a
mechanism for users to easily change the text style.

Avoid the use of text line lengths in excess of 80 characters or
provide a mechanism for users to easily reduce column width or line

Avoid the use of text lines that are both left and right justified or
provide a mechanism for users to easily obtain a version that is not
fully justified.

For technical or complex content that is to be accessible to a general
audience (for example legal documents or insurance conditions),
provide an additional simple-language version.

(NB: I realise some of these techniques are included for other Success
Criterion, however I believe that restating them here will help focus
attention on the importance of considering the needs of people with
cognitive, language and/or learning difficulties.)

Response from Working Group:

It is true that we allow human testability. However, the human
testability must render consistent results across various experts.
Because the inherent ambiguities in this field and the current level
research, there are only a few techniques that we can add with
confidence of agreement. However, we have added several new advisory
techniques to SC 3.1.5.

We have added a new success criterion at Level AAA

"For the visual presentation of blocks of text, 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 [LC-1253]
[LC-569 (add)]
        * line spacing is at least space-and-a-half within paragraphs,
and paragraph spacing is larger than line spacing [LC- 569]
        * text is resized without assistive technology up to 200
percent in a way that does not require the user to scroll horizontally
to read a line of text "

We believe that satisfying this success criterion will help people
with some types of cognitive limitations.

Comment 8: CAPTCHA
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0020.html
(Issue ID: 2315)
Original Comment:

I am concerned that the techniques for addressing the accessibility
issues associated with the use of CAPTCHA do not adequately meet the
needs of people who are both vision and hearing impaired.

Proposed Change:
1. It should be clear that the use of highly distroted audio
equivalents is not appropriate.

2. An additional alternative techinque should be provided that a
person with impaired vision and hearing is able to use. For example,
providing a contact phone number.

Received on Tuesday, 3 July 2007 05:04:55 GMT

Response from Working Group:

The Working Group recognizes that CAPTCHAs create a significant
barrier, and requiring only two alternate modalities will exclude some
users. The WG believes, however, that this requirement strikes the
best balance between benefit to users and achievability for authors.
Recognizing that there are further steps possible and that authors
need to be informed of the situation, we have added a note to
Understanding 1.1.1 explaining the situation and providing additional
recommendations, which authors are strongly encouraged to follow.
Received on Sunday, 4 November 2007 05:09:26 UTC

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