Your comments on WCAG 2.0 Public Working Draft of May, 2007

Dear Kiyochika Nakamura,

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
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/

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.

Regards,

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: validity
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0064.html
(Issue ID: 1989)
----------------------------
Original Comment:
----------------------------

Source: http://www.w3.org/mid/449A8F1D.5080403@mitsue.co.jp
(Issue ID: LC-1239)

Comment: The term, "parsed unambiguously," or "parsed into only one
data structure" is not good enough to comply with the principle 4. The
principle states that "content should be robust enough to work with
current and future user agents." Then, if web units or authored
components are well-formed but include information not based on chosen
technologies, can we guarantee that this information is conveyed?
Therefore, I believe if forward compatibility is important,
"conforming to specifications" would be better than "parsed
unambiguously."

Proposed Change:

Using the phrase "conforming to specifications" instead of the phrase
"parsed unambiguously."

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

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.

--------------------------------
Response from Kiyochika Nakamura:
--------------------------------

Overall, we are satisfied with the WG's decisions, but for the Comment
6, though we feel that the new success criterion is much better than the
old one, there still is a question.

It looks like the new success criterion still allows "user
agent-dependent" elements, such as BLINK or MARQUEE for (X)HTML. This
affects accessibility for user agents which cannot interpret those elements.

We understand that other examples such as tabindex attribute for some
elements, which is invalid, could be good for accessibility, but if a
document makes a declaration of the document type, it should follow its
rules.

Also, we believe that WCAG, as a W3C spec, should respect other W3C specs.

This comment does NOT mean that we think it is unacceptable, however, we
hope the WG takes into consideration our opinion in anyway possible.

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

The wording of this success criterion does permit the use of elements
that are not defined by the applicable specification. This is
permitted because the elements, in and of themselves, do not interfere
the the possibility of parsing the document into a usable
representation. In addition, such elements sometimes enhance
accessibility even though they do not exist in the specification. This
situation is addressed by the concept explained in the Conformance
section on Accessibility Support of Web Technologies . If a given
feature is supported by user agents, regardless of whether it is
defined in the technology specification, it meets the requirements for
accessibility support. By contrast, if a feature is not supported by
user agents even though it is defined in the specification, it does
not meet the definition of accessibility supported and cannot be
relied on to achieve WCAG 2.0 conformance.

The Working Group also respects the perspective that, as a W3C
Specification, WCAG 2.0 should actively support other W3C
Specifications. However, due to the ongoing evolution of technologies
and user agent support, it is often the case that there is not a
canonical specification against which requirements may be made. The
current wording for the success criterion attempts to address that
balance in the most effective way possible.

Two examples of items that people try to get at through validity that
we address because of their specific disability impact are BLINK and
MARQUEE, which are specifically listed as failures because of their
impact on users with disabilities. (See F47: Failure of SC 2.2.2 due
to using the blink element and F16: Failure of SC 2.2.3 due to
including scrolling content where movement is not essential to the
activity without also including a mechanism to pause and restart the
content.)

Received on Sunday, 4 November 2007 04:56:25 UTC