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

Hello, WCAG Working Group,

The following is our response to the WG's comment.

We aren't fully satisfied with the WG's decision, but we can understand
the way the WG's are taking which uses WCAG 2.0 Supporting Documents to
explain the problems.

Also, we believe that making WCAG 2.0 W3C recommendation as soon as
possible is more important than building our view into the guideline.

Therefore, we would like the WG to take our comment as we satisfied.

Thank you and we really appreciate the WG's hardwork.


Mitsue-Links Co., Ltd.
Research and Development Department
Accessibility Team


Loretta Guarino Reid said:
> 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.)


-- 
Kiyochika Nakamura
Research and Development Department
Accessibility Team
Mitsue-Links Co., Ltd.
Shinjuku Square Tower 15F,
6-22-1 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1115 JAPAN
Phone: +81-3-3344-7470 / Fax +81-3-3344-7290
E-Mail: nakamura-kiyochika@mitsue.co.jp
http://www.mitsue.co.jp/english/

Received on Tuesday, 20 November 2007 03:21:35 UTC