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

RE: Your comments on WCAG 2.0 Last Call Draft of April 2006 (1 of 8)

From: Gian Sampson-Wild <gian@tkh.com.au>
Date: Sun, 24 Jun 2007 22:57:31 +1000
To: "'Loretta Guarino Reid'" <lorettaguarino@google.com>
Cc: <public-comments-WCAG20@w3.org>
Message-ID: <002a01c7b65f$3d20b310$b300a8c0@tkhcomputer>

Hi Loretta

It is easier to respond to each issue per email so you will be getting a lot
of emails in the next few hours about these.

Cheers,
Gian

-----Original Message-----
From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] 
Sent: Friday, 18 May 2007 9:47 AM
To: Gian Sampson-Wild
Cc: public-comments-WCAG20@w3.org
Subject: Your comments on WCAG 2.0 Last Call Draft of April 2006 (1 of 8)

Dear Gian Sampson-Wild ,

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
archived.

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/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1062)

4.1.2: What is the "name" or the "role"? What does it mean "values can
be set by the user"?

Proposed Change:

Rewrite SC 4.1.2

----------------------------
Response from Working Group:
----------------------------

The terms "name" "role" and "programmatically set" are each defined in
the glossary. How to Meet SC 4.1.2 describes the intent of this
success criterion and provides techniques about how to meet it. With
regard to your suggestion to rewrite 4.1.2, without more information
about the problems you see with this provision or specific suggestions
for how to rewrite this criterion, we are unsure how to address your
comment.

----------------------------------------------------------
Comment 2:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1020)

Issues with commenting - It is difficult to accurately comment on
WCAG2 when the documents that are needed to understand WCAG2 are not
normative and are not complete. For example, one cannot interpret a SC
without referring to techniques, yet these are not normative. There
has been a lot of people saying WCAG2 is difficult to understand, yet
they cannot rely on the UW or TD documents as these are neither
normative or complete. The WG could vote to significantly change these
documents, thereby significantly changing the meaning of particular
success criteria, without ever allowing comments from the public. In a
perfect world neither the UW or TD documents would be required in
order to understand WCAG2 but taking into account the difficulty most
people are having with interpreting WCAG2, these documents are
becoming mandatory reading.

Proposed Change:

Allow for a subsequent 'Last Call' when all documents are complete,
and specify that WCAG2 must be read and interpreted in conjunction
with UW and TD documents

----------------------------
Response from Working Group:
----------------------------

In order to be technology neutral but accurate and testable the
guidelines themselves need to be written in language that sometimes
can be abstract or technical.  We recognize that this can make them
difficult to understand. We have spent much time trying to figure out
how to make them as simple to understand as possible while keeping
them accurate and clear.  We have also been very careful to be sure
that the guidelines themselves contain what is required. Information
in the non-normative documents can never require anything that is not
already required by the language in the normative document.  Thus the
guidelines can stand on their own in terms of 'interpretability'.
However we have also created extensive support documentation to help
make them easier to understand and to include examples and specific
techniques for meeting them.

The Understanding WCAG documents and techniques documents will
continue to evolve because technologies and user agent support
continue to evolve, so that new sufficient techniques can emerge as
assistive technology and other user agent support improves over time.
It is important that these documents remain non-normative so that they
can be changed as our collective knowledge grows.

It is very useful to read the ancillary documents to better understand
the document. The ancillary materials may aid comprehension but are
not in fact normative. The ancillary materials have been filled in
since the time of the comment, and while not fully complete, are being
republished at the same time in order to provide non-normative
explanatory information to aid comprehension.

----------------------------------------------------------
Comment 3:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1021)

Cognitive disabilities - People with cognitive disabilities are
unfairly discriminated against within WCAG2. I believe this is due to
the usability and testability requirements. It is generally accepted
(and one chair has said so explicitly) that requirements that assist
people with cognitive disabilities are often general usability
techniques. Criteria that assist people with cognitive disabilities is
more likely to fall foul of the requirement for testability than other
criteria, simply because these criteria recommend changes to the way
content is written, not how a site is coded. For example, in WCAG1
Checkpoint 14.1 - Use the clearest and simplest language appropriate
for a site's content - still has no clear equivalent in WCAG2 and
partiallymaps to Level 3success criteria.

Proposed Change:

Set up a specific taskforce within WCAG WG to identify success
criteria that should be added to ensure WCAG2 addresses the needs of
people with cognitive disabilities (I volunteer to be a part of, or to
head up, this taskforce), or comply with Lisa Seeman's suggestions in
her formal objection (which I have cosigned)

----------------------------
Response from Working Group:
----------------------------

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.

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 4:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1022)

Testability - The decision to comply with the testability requirement
has outlawed some very important success criteria. This requirement
has also not been applied fairly to all success criteria. Some current
success criteria do not comply with the 8 out of 10 rule - for example
1.1.1. This SC requires that alternatives to non-text content "serve
the same purpose and present the same information". One basic example
of this is to require equivalent ALT attributes for images, but I do
not believe that 8 out of 10 people would agree on the same ALT
attribute for an image. For instance, in the Live in Victoria site
(www.liveinvictoria.vic.gov.au) there is an image under the heading
"Business Migrants". When I worked on this site, several people said
this image should have a null ALT attribute as it conveyed no
information. Several other people suggested ALT attributes of "A
couple of business migrants chatting at work" or "Guys chatting at
work". Whereas the ALT attribute that I recommended was "There is a
wealth of opportunities for Business Migrants in Victoria."

Proposed Change:

Remove the requirement for testability and set up a taskforce (I
volunteer to work on or head up this taskforce) to identify criteria
that should be included in WCAG2. Alternatively, develop a set of
supplementary guidelines that are non-testable to be used in
conjunction with WCAG2.

----------------------------
Response from Working Group:
----------------------------

The success criteria need to be testable or else people cannot tell
when they have conformed to the success criteria and thus WCAG 2.0.

With regard to SC 1.1.1 the success criterion does not require that
ALT text provided by different people be the same. WCAG 2.0
categorizes different classes of alt text and provides test procedures
to help humans evaluate whether alt text satisfies the success
criterion.

Advisory techniques are used to provide supplemental materials that
are non-testable that can be used in conjunction with WCAG 2.0.  They
provide additional guidance on what can be done beyond the
requirements of WCAG.




----------------------------------------------------------
Comment 5:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1023)

AAA conformance - It is not clear how one achieves AAA conformance. In
the WCAG 2.0 document (under the 'Conformance' heading) there is a
note "Because not all level 3 success criteria can be used with all
types of content, Triple-A conformance only requires conformance to a
portion of level 3 success criteria".  Does this mean a site can claim
Triple-A conformance if they comply with all Level A and Level AA SC
and one Triple-A SC? This statement is in contradiction with
information in the "Baseline" document which states (under the
'Vertical and Horizontal scoping in conformance statements' - first
question) "Any web content for which Level AAA conformance is claimed
must meet all Level 1 and Level 2 success criteria plus at least 50%
of applicable Level 3 success criteria".

Proposed Change:

Firstly, there must be consistency between the two documents and how
to claim AAA conformance must be clearly detailed. I do not understand
why AAA is being treated differently to A and AA. I believe AAA
compliance should mean compliance with all AAA SC, not just ones the
developer chooses to implement.

----------------------------
Response from Working Group:
----------------------------

We have changed the definition of Level AAA conformance so that all
Level AAA Success Criteria that apply to the content types used must
be satisfied.

----------------------------------------------------------
Comment 6:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1024)

Conformance schema - The decision to remove the design requirement
from Level 1 has meant there is no appreciable difference between
Level 1 and Level 2. I recall many instances where SC were moved to L2
because of this design requirement, yet I have not seen any indication
that these SC are being moved back in to L1.

Proposed Change:

Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename
Level 3 to "Advisory" or "Optional" Alternatively set up a taskforce
(which I volunteer to be a part of, or head) to review L2 and L3 SC to
see if they can be moved to L1.

----------------------------
Response from Working Group:
----------------------------

The working group feels that there are three categories of success
criteria, so we have retained three levels of conformance. 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 ):

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 7:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1026)

Conformance schema - The documents say that all success criteria are
essential to people with disabilities (see WCAG 2.0 under
'Conformance' - "The WCAG WG believes that all SC ..."), however by
using the WCAG1 labelling system this change is not obvious. In
addition to this, the Conformance section specifically states a
hierarchical nature to the to the SC in WCAG2 by defining Level 1 as
"achiev(ing) a minimum level of accessibility", Level 2 as
"achiev(ing) an enhanced level of accessibility" and Level 3 as
"achiev(ing) additional accessibility enhancements". The Conformance
section is contradictory, because in the subsequent paragraph it says
"Each checkpoint in WCAG 1.0 was assigned a "priority" according to
its impact on accessibility... the system of checkpoints and
priorities used in WCAG 1 has been replaced...". By using the
subjective terms Priority 1 / A in WCAG2, the WG is implying that
there is a hierarchical nature to the SC. People are used to the WCAG1
labelling system and will assume that by following all Level A SC that
they are creating an accessible web site.

Proposed Change:

Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename
Level 3 to "Advisory" or "Optional"

----------------------------
Response from Working Group:
----------------------------

The working group feels that there are three categories of success
criteria, so we have retained three levels of conformance. 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.


----------------------------------------------------------
Comment 8:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1027)

Definition of accessibility - In the Baseline document (under the
heading 'If the WCAG does not set the baseline, then how can we be
sure that a site will be accessible?) it says "No site or content is
ever completely accessible". In the Conformance document it says "Note
that even conformance to all three levels will not make web content
accessible to all people." I strongly object to these statements. All
content can be made accessible. In some cases, content may not be
accessible, but if the problems were identified it could be made
accessible. As the main body representing accessibility I think it
reprehensible that we have these statements.

Proposed Change:

Remove the statements. Merge Level 1 and Level 2 SC into one group
called 'Mandatory'. Rename Level 3 to 'Advisory' or 'Optional'

----------------------------
Response from Working Group:
----------------------------

The statements you refer to are meant to reflect the reality that not
all Web content can be made accessible to all people. One of the
lessons learned with WCAG 1.0 was that, for some individuals, even
content that meets WCAG 1.0 AAA did not overcome the accessibility
barriers faced by those with certain combinations of disabilities or
with certain types of severe disabilities.

Regarding the proposal to combine levels A and AA as mandatory and
rename level AAA to advisory or optional, the working group has
received a great deal of feedback on both sides of this issue. We have
chosen three levels because we feel it provides the best options for
the different users of the guidelines.


----------------------------------------------------------
Comment 9:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1028)

Baseline - From reading the Baseline documents, it appears that if a
baseline technology does not have particular functionality (for
example, the ability to navigate using only the keyboard), then the
site can still be compliant with WCAG2 (but obviously not accessible).
I think it is reprehensible that the main body advocating
accessibility is about to release a set of guidelines that patently
allow inaccessible web sites.

Proposed Change:

Remove the baseline theory, or allow only UAAG compliant programs in
baseline.

----------------------------
Response from Working Group:
----------------------------

Your concern seems to arise from a different understanding of the
meaning of Baseline than that intended by the Working Group. To help
address this the conformance section has been completely rewritten,
and the term "baseline" has been replaced by
"accessibility-supported Web technologies".

 In order to claim conformance, a Web page must satisfy the WCAG
success criteria using a technology that has assistive technology
support and works with the accessibility features in user agents.

If a technology does not have a particular functionality that is
necessary to satisfy some WCAG success criterion (such as keyboard
support), then it is impossible to create a conforming Web page
relying on that technology. The page would need to meet that success
criterion using one of the other technologies upon which it relies.

NOTE: The technologies referred to are not the user agents, so they
couldn't conform to UAAG.  They are the technologies used to build the
page (like HTML, CSS etc.) The question of whether a technology is
accessibility supported is affected by the behavior of user agents and
assistive technology for the technology.

----------------------------------------------------------
Comment 10:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1029)

Baseline - From reading the Baseline documents, it appears that if a
baseline technology does not have particular functionality (for
example, the ability to navigate using only the keyboard), then the
site can still be compliant with WCAG2 (but obviously not accessible).
This acts as a disincentive for big corporations to develop
accessibility features. Developers want things to be easy - it's a lot
easier to click "Print to PDF" in a Word document than it is to tag a
PDF. So what is to stop Adobe (sorry Loretta!) superceding their PDF
technology with a new "SDF" technology that has no accessibility
features?  In that case it would be a lot easier for a person to
create a WCAG2 compliant SDF document than it would be to create a
WCAG2 compliant PDF document. In another example, if someone had CSS
in their baseline then it would be WCAG2 compliant to use CSS markup
to highlight a specific word without having an HTML alternative, and
which would not be able to be interpreted by a screen reader

Proposed Change:

Remove the baseline theory, or allow only UAAG compliant programs in
baseline. If I have misinterpreted the baseline theory, then the WG
needs to develop a document to be used in conjunction with WCAG2 that
lists what baseline technologies must be able to do (similar to UAAG)

----------------------------
Response from Working Group:
----------------------------

The conformance section has been completely rewritten, and the term
"baseline" has been replaced by "accessibility-supported Web
technologies".

If a technology doesn't have AT support then you can't use that
technology to meet WCAG according to our conformance requirements. So
the problem you cite would be covered.

Determining whether a technology is accessible-supported is based on
the availability and support for that technology in users' user agent
and AT.  The purpose is to ensure that content can be accessed with
the user's AT.

NOTE: The technologies referred to are not user agent technologies.
They are the technologies used to build the page (like HTML, CSS etc.)

----------------------------------------------------------
Comment 11:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1030)

Baseline - Baseline needs to be defined, just like all other terms in
WCAG2. There is no specific definition

Proposed Change:

Provide a definition for baseline

----------------------------
Response from Working Group:
----------------------------

The conformance section of WCAG2 has been completely rewritten. The
term "baseline" has been replaced by "accessibility-supported Web
technologies". The issue of what it means to be an
accessibility-supported Web technology is addressed in the section
"Accessibility Support of Web Technologies" at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .


----------------------------------------------------------
Comment 12:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1031)

Baseline - Under "Examples of People and Places setting baselines" it
says baseline includes only technologies supported by "accessible and
affordable user agent(s)". What is the definition of "affordable"? I
believe this is advocating technology preference. For instance, if
Microsoft created a proprietary technology that only worked only on
IE, which came bundled with new versions of Windows, then it could be
argued that that proprietary technology could be included in a
baseline. The W3C should not be in the advocating anything that
supports large corporations taking over the web

Proposed Change:

Remove the baseline theory, or allow only UAAG compliant programs in
baseline.

----------------------------
Response from Working Group:
----------------------------

The conformance section of WCAG2 has been completely rewritten. The
term "baseline" has been replaced by "accessibility-supported Web
technologies". The issue of what it means to be an
accessibility-supported Web technology is addressed in the section
"Accessibility Support of Web Technologies" at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .

----------------------------------------------------------
Comment 13:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1032)

Baseline - All the reasons why the WG left the definition of baseline
up to the developers (or governing bodies) could also be used as
reasons why the WG have developed an updatable document on
technologies with enough accessibility features to be in baseline. The
fact that there are no user agents that comply with UAAG is an obvious
indication that there are no technologies (yet) that are as accessible
as HTML and CSS. I believe it is reckless to leave this decision up to
developers or managers whose focus is on the bottom line, not on
providing accessible web sites.

Proposed Change:

Develop a document, for use with WCAG2, that list suitable
technologies for baseline. This document can be updated by the WG or
the W3C every year.

----------------------------
Response from Working Group:
----------------------------

Note that HTML and CSS are also technologies for which there are not
yet fully UAAG-compliant user agents, so this doesn't seem like an
argument that  they are more accessible.

However, they are supported by a wider set of user agents and
assistive technologies, which is why we would expect them to be
considered accessibility-supported content technologies in more
contexts than other technologies.

WAI will provide some examples of analyzing the user agent and
assistive technology support for several Web technologies, to evaluate
whether they satisfy these requirements. However, WAI is not in a
position to evaluate what user agents and assistive technologies are
available in different environments. We would encourage experts in
those technologies in different locales to develop reference
information for Web site authors.

----------------------------------------------------------
Comment 14:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1033)

Baseline - Under "Examples of baselines and what they mean" (example
1) it says "The baseline includes HTML 4.01, in addition to GIF and
JPEG images. this extremely limited baseline.".  I object to the use
of the words "extremely limited" - it is a deliberately pejorative
statement

Proposed Change:

Remove the words "extremely limited"

----------------------------
Response from Working Group:
----------------------------

The words have been removed. They are no longer used in WCAG.
Received on Sunday, 24 June 2007 12:58:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:08 UTC