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

WCAG 2 response to WG response

From: Roger Hudson <rhudson@usability.com.au>
Date: Mon, 19 Nov 2007 09:35:58 +1100
To: <public-comments-wcag20@w3.org>
Cc: "'Loretta Guarino Reid'" <lorettaguarino@google.com>
Message-ID: <E1ItslH-0004gs-VC@lisa.w3.org>

Hi Loretta and Working Group

Thanks for the responses to my comments concerning the last Public Working
Draft of WCAG 2.0.

In general I am still very concerned about the failure to provide
substantive recognition to the importance of web access for people with
cognitive, language and learning limitations within the Guidelines.

Below are my responses to your responses.

Roger Hudson
Web Usability
Ph: 02 9568 1535
Mb: 0405 320 014
Email: rhudson@usability.com.au
Web: www.usability.com.au 

-----Original Message-----
From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] 
Sent: Sunday, 4 November 2007 4:09 PM
To: Roger Hudson
Cc: public-comments-WCAG20@w3.org
Subject: Your comments on WCAG 2.0 Public Working Draft of May, 2007

Comment 1: SC 2.4.8 should be at higher level
(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)

Response to response
I don't feel that the examples you provide offer sufficient justification
for doing away with the need to provide descriptive link text. A number of
techniques could be used to avoid pages which have meaningful links being
very cluttered where it is harder cognitively to find things.

Your response includes the comment, "The working group recognizes that the
link list mechanism provided by user agents and assistive technology will
provide best results when SC2.4.8 is satisfied."

But clearly, you don't recognise the importance of this sufficiently to put
SC 2.4.8 should be at AA level, where I still believe it should be.

Comment 2: contrast ratio SC level
(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.

Response to response
Your response to my comment appears to be based on an assumption that all
web users are very technologically savvy. This is not the case, in my
testing I have come across many users who don't have the knowledge or
confidence to start changing browser and/or OS settings. Also, in some
circumstances (e.g. some workplaces, libraries, and educational
institutions) general access to these settings is blocked.

It is my view SC 1.4.3 should be at Level A. 

Comment 3: SC level for 3.1.3
(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.

Response to response
I appreciate your desire to see this bedded down before proceeding. However,
in my understanding WCAG is not about historians who have a problem
understanding chemistry, but is primarily concerned with improving access to
the web for people with disabilities, including cognitive and reading
disorders. I am more concerned with mundane things like making sure
important words and phrases in documents like financial or insurance
agreements can be understood by the widest possible audience.

I look forward to development of new techniques and the day when the SC for
this guideline is moved up to AA.

Comment 4: 3.1.4 SC should be AA
(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.

Response to response
See my response to the comment above.

I look forward to development of new techniques and the day when SC 3.1.4 is
moved up to AA.

Comment 5: Increase SC for 3.3.4
(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.

Response to response
Many thanks.

Comment 6: Success Criterion score
(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.

Response to response
I appreciate the difficulties you must have had in coming up with an
appropriate conformance/scoring system. Thanks for spending the time to
review this issue again.

Comment 7: doing a little more for people with cognitive limitations
(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.

Response to response
This is the response to one of my comments that I am the most dissatisfied
with since it still fails to address my real concern over the lack of
support given to people with cognitive, learning and language limitations. I
am pleased however to see that some of the suggested techniques may have
contributed to a new Success Criterion relating to the presentation of
blocks of text, but note that it is at Level AAA - i.e. the level that is
least likely to be complied with.

No amount of good-intention words relating to the importance of addressing
the need of people with cognitive disabilities will replace the absence of a
meaningful Success Criterion at either A or AA. When it comes to encouraging
clients and developers to consider the needs of people with cognitive,
learning and language difficulties, I am not sure WCAG 2.0 is any real
advance on WCAG 1.0.

I don't feel my suggested SC was too onerous. It suggested barriers to
comprehension should be avoided but was deliberately not too prescriptive as
to how this could be done. However, I think the suggested techniques
provided a useful guide to the issues that should be considered when
complying with the suggested SC. This combination of a specific Level AA
Guideline and suggested techniques would I believe have helped underscore
the significance of this issue with website developers and their clients.

I feel that your comments relating to human testability when it comes to
cognitive disabilities may just be a convenient way of avoiding the issue.
If an image of a navigation item or a complex flow chart just had
'alt=picture',I would assume that the WG would not consider that this
complied with the Guideline that requires the use of "a text alternative
that presents equivalent information". Unless you are willing to accept
vague img attributes such as this, it is likely to come down to humans to
determine if the value of the attribute does actually present equivalent

If a qualified human can determine whether or not a text description is an
adequate alternative to an image, why do you feel it is not possible for
qualified humans to determine if the complexity of a piece of text is such
that an alternative way of presenting the information should be considered?

Comment 8: CAPTCHA
(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.

Response to response
Let's see how CAPTCHAs play out, maybe with a bit of luck organisations will
develop and use alternative ways to protect security and avoid the bad guys
that are not so hard for people with some disabilities to use. If not, I
hope the WG re-visits this issue in the near future.
Received on Sunday, 18 November 2007 22:37:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 July 2011 06:13:24 GMT