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

Your comments on WCAG 2.0 Last Call Draft of April 2006

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:28:47 -0700
Message-ID: <824e742c0705171628m778c8566rbd73a0045d29b931@mail.gmail.com>
To: "Charles McCathieNevile" <chaals@opera.com>
Cc: public-comments-WCAG20@w3.org

Dear Charles McCathieNevile ,

Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the
interest that you have taken in these guidelines.

We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.

This message contains the comments you submitted and the 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 updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.

PLEASE REVIEW the decisions  for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org to say whether you are
satisfied with the decision taken. Note that this list is publicly

We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ for more information about the current review.

Thank you,

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:

Source: http://www.w3.org/mid/op.tbjlv1aowxe0ny@researchsft.myhome.westell.com
(Issue ID: LC-1302)

Technical/substantive issue

The section currently provides no guidance to actually choosing a baseline
that can in fact be used accessibly.

I propose that the availability of a user agent which meets level-A
conformance to User Agent Accessibility Guidelines 1.0 for the relevant
technology and language be a minimum criterion for the selection of a

In this way, selection of a baseline that is not actually accessible
automatically makes it impossible to claim conformance to the
accessibility guidelines. This avoids the situation where it is possible
to construct content that can meet the requirements, but that is not
actually accessible due to the absence of any means for using the baseline
set. Otherwise there is a risk that the value of conformance will be
significantly reduced, since it makes no reliable statement about whether
the content is in fact accessible to real people.

This seems a reasonable requirement given that UAAG is a W3C
recommendation, and does not seem onerous for common web technologies.



Response from Working Group:

For a period, WCAG made the assumption that user agents satisfied
UAAG. This would have simplified a number of issues.

However, in the absence of any user agent for any technology that is
fully UAAG-compliant, the working group did not think it was practical
to require only the use of technologies for which such user agents
exist. The effect of such a requirement would be to make it impossible
to claim compliance for any web content.

The notion of baseline (now accessibility-supported web technologies)
was introduced to make it possible to apply WCAG in environments with
a wide range of user agent support for accessibility. It places a much
heavier burden on the author to understand the capabilities of his
customer's user agents. WCAG will be much easier to satisfy in an
environment in which UAAG is satisfied by the available user agents.

Comment 2:

Source: http://www.w3.org/mid/op.tbjlv5miwxe0ny@researchsft.myhome.westell.com
(Issue ID: LC-1303)

Structural/substantive issue

The current levels system for success criteria seems insufficiently
described, and inappropriate to the needs of developers.

WCAG 20 acknowledges that most criteria are essential in order for
some people to be able to use some types of web content. It then
attempts to describe the amount of benefit to usersin general (the
difference between level 1 and level 2) and the apparent applicability
of a technique to the web. It appears that the goal is to provide a
"reasonable" implementation planning tool.

Both of these things are in fact situation-dependent. In some cases,
it will be easy, in others critical, to apply approaches whose level
suggests that they are not so important or easy in the general case.

Thus, while providing a signed equivalent of content is extremely
important in a number of cases, and is occasionally trivially easy (in
others it is quite expensive), it is perfectly possible that all web
content claiming triple-A conformance is without signed content.

Similarly, there is no clear technical justification for different
requirement levels for captioning depending on whether content is
"live"/"real-time", or pre-recorded. The accesibility result for users
who rely on captions is exactly the same in both cases. Again, this
may be easy to implement in some cases, and is very expensive in
others, and its relative importance will be variable.

In order to assist developers, and policy makers, WCAG should describe
the imact on users of a particular success criterion being met or not.
This enables prioritisation based on the actual situation, rather than
a generalised model situation which will often be an inaccurate
representation of the case at hand.

I propose that either:
1. the levels be removed, and the information in the currently
informative "Understanding WCAG" about who benefits be moved to the
normtive recommendation. Or, as an alternative

2. the specification revert to the WCAG 1.0 priority scheme, rather
than with the "apparent ease of implementation" clouding the question
of their relevance to users.



Response from Working Group:

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

The word "levels" does not mean that some success criteria are more
important than others. Each success criterion in WCAG 2.0 is essential
to some users, and the levels build upon each other. However, even
content that conforms at AAA (triple-A) may not be fully accessible to
every person with a disability.

*In general, Level A success criteria achieve accessibility by
supporting assistive technology while putting the fewest possible
limits on presentation. Thus people with a wide range of disabilities
using a wide range of assistive technologies, from voice input and
eye-tracking devices to screen readers and screen magnifiers, are able
to access content in different ways. In other words, Level A success
criteria support the ability of both mainstream and specialized user
agents to adapt content to formats that meet their users' needs.

*The success criteria in Level AA provide additional support for
assistive technology. At the same time, they also support direct
access to content by the many people who use conventional user agents
without assistive technology. In general, Level AA success criteria
place more limits on visual presentation and other aspects of content
than the success criteria in Level A.

*Level AAA success criteria increase both direct access and access
through assistive technology. They place tighter limits on both
presentation and content.

Comment 3:

Source: http://www.w3.org/mid/op.tbjxedeqwxe0ny@researchsft.myhome.westell.com
(Issue ID: LC-1307)

Structural/substantive issue

The specification seems to take no account of situations where in fact all
user agents relevant to a given baseline offer functionality that the
guidelines are requiring of authors.

Where this is the case (for example, SVG user agents generally provide a
mechanism to pause any animation independently of the content, and in SVG
tiny it is not possible to provide the functionality in content anyway)
the guidelines should take it into account.

I propose that the baseline section be reworked, to incorporate this type
of situation. Perhaps the most robust way of specifying this would be to
explicitly relate UAAG requirements to WCAG requirements, and note that
where there are (some expression for most or all) user agents for the
baseline which meet a given UAAG requirement the corresponding WCAG
requirement need not be met. Note that the proportion of user agents for
which this needs to be true should be at least as high, and probably
higher than that which is reasonable to justify the use of a particular
baseline in the first place.

Response from Working Group:

WCAG success criteria have been written to describe the functionality
that must be available, but have avoided specifying that the
functionality must be provided by the user agent or by the content
directly. For example, SC 2.4.1 (A mechanism is available to bypass
blocks of content that are repeated on multiple Web pages) can be
satisfied by providing links in the content to bypass the blocks, or
by providing headings at the beginning of each section and relying on
the user agent to skip the repeated content by skipping to headings.

Comment 4:

Source: http://www.w3.org/mid/op.tbjxeubjwxe0ny@researchsft.myhome.westell.com
(Issue ID: LC-1308)


In the current framework, while there are success criteria there are no
normative explanations of how they apply to given technologies. Instead,
understanding WCAG 2.0 has been made an informative document.

This is inappropriate to ensure interoperability of tools and content.
This has been a major problem with the implementation of WCAG 1.0, where
important questions of interpretation (such as "are tables OK for
layout?", "do all user agents identify form fields without default text in
them?", "is it OK to rely on javascript?", "are px units OK for layout?"
among others) have gone unanswered for many years leading to a major
breakdown in interoperability between tools, services, and content itself.

I propose that the information be made available in a normative document.
The process requirements for publishing such a document would seem to be
very lightweight in the context of how long it takes the WCAG group to
determine necessary changes, and this will at least ensure that an
authorative answer becomes available for issues which arise.



Response from Working Group:

It has been challenging to write success criteria that are technology
neutral, testable, and easy to understand. We have taken great pains
to write the success criteria so that it would be clear which
techniques would or would not pass to experts. We are using the
Understanding document to make it clear for those who are not experts.
However, we don't want to restrict the range of solutions by making
the list of known solutions normative. We do not believe that we could
update normative Understanding and Technique documents quickly enough
to keep pace with the changes in technologies and user agents. The W3C
process is long for any document.

This approach also allows WCAG 2.0 to avoid introducing some of the
"until user agent" problems from WCAG 1.0.

Comment 5:

Source: http://www.w3.org/mid/op.tbjxeqrswxe0ny@researchsft.myhome.westell.com
(Issue ID: LC-1309)

The guidelines place in level 3 very many of the requirements necessary to
help people with cognitive and reading disabilities access the web. Since
only 50% of level 3 requirements (as chosen by content authors) need to be
met in order to claim confomance to the guidelines, it is quite possible
to conform to the guidelines at triple-A level while doing very little
(and clearly not enough) to address the needs of these user groups.

I propose either that this be explicitly and clearly explained in the
introductory and conformance sections, or that the levels system be
reworked as per my lat call comment on them.



Response from Working Group:

We have changed the definition of Triple-A conformance so that all
level AAA success criteria must be satisfied.

We have added language to the Introduction, the Conformance section,
and the Quick Reference to highlight the fact that WCAG 2 only
addresses some of the needs of people with cognitive, learning, and
language disabilities, and to call out the need for more research in
this area. WAI is exploring ways in which to support and encourage
work in this important area.

In addition, we have added some best practices for cognitive,
learning, and language disabilities as advisory techniques, and we
have proposed 3 new success criteria in this area.

Comment 6:

Source: http://www.w3.org/mid/op.tbly4lvhwxe0ny@researchsft.myhome.westell.com
(Issue ID: LC-1320)

Technical/substantive issue?

The current requirement fo unambiguous parsing is impossible to meet -
there are always multiple ways of parsing any data.

Instead I suggest the old wording of "conforms to formal published

This makes it feasible for User Agents to recognise the content and parse
it either according to the rules for such grammars, or in cases where it
is necessary (such as HTML) to use specifically adapted parsing techniques.



Response from Working Group:

To make this requirement easier to understand, we have reworded SC
4.1.1 as follows:

Content implemented using markup languages has elements with complete
start and end tags, except as allowed by their specifications, and are
nested according to their specifications.

Note: Start and end tags that are missing a critical character in
their formation, such as a closing angle bracket or a mismatched
attribute value quote are not complete.

The working group looked at this topic carefully over an extended
period of time and concluded that requiring strict adherence to all
aspects of specifications does not necessarily result in an increase
in accessibility. For example, it is possible to create invalid pages
that present no accessibility barriers. It is also possible in certain
situations to enhance accessibility through the use of markup that is
not part of the specification.

The working group must work within its charter and only include things
that directly affected accessibility. Some aspects of "use
technologies according to specification" and validity do relate to
accessibility. However, others do not. So requiring validity would
take us beyond our charter. We do recommend it though and it is our #1
technique listed for conforming to SC 4.1.1.
Received on Thursday, 17 May 2007 23:29:14 UTC

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