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

From: Kiyochika Nakamura <nakamura-kiyochika@mitsue.co.jp>
Date: Fri, 08 Jun 2007 13:03:47 +0900
Message-ID: <4668D523.6010306@mitsue.co.jp>
To: public-comments-WCAG20@w3.org

Hello, WCAG Working Group,

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

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.

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


Mitsue-Links Co., Ltd.
Web Development Group
Accessibiliity Team


Loretta Guarino Reid said:
> Dear Kiyochika Nakamura ,
> 
> 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/449A8F1D.5080403@mitsue.co.jp
> (Issue ID: LC-1234)
> 
> Comment: This success criterion should be Level 1 because if it isn't
> satisfied, information could not be conveyed, at least for screen
> reader users. In the conformance section, a minimum level of
> accessibility is defined as a level 1 success criteria. Without this
> criterion, some important information might be conveyed to some users.
> So, I believe it is essential to achieve a minimum level of
> accessibility.
> 
> Proposed Change:
> 
> Move this success criterion to level 1.
> 
> ----------------------------
> Response from Working Group:
> ----------------------------
> 
> Success criterion 1.3.4 has been combined with success criterion 1.3.1
> at level A. SC 1.3.1 now reads:
> 
> Information and relationships conveyed through presentation can be
> programmatically determined or are available in text, and notification
> of changes to these is available to user agents, including assistive
> technologies.
> 
> ----------------------------------------------------------
> Comment 2:
> 
> Source: http://www.w3.org/mid/449A8F1D.5080403@mitsue.co.jp
> (Issue ID: LC-1235)
> 
> Comment: Is there any scientific or other basis for a luminosity
> contrast ratio method? Also, is there any reason to choose 5:1 and
> 10:1? I understand that a reference value is needed for these criteria
> because it should be testable, but if there is no basis, how can we
> rely on it?
> 
> Proposed Change:
> 
> Add a link to the document which explains why 5:1 and 10:1 LCR ratio
> are sufficient if there is such a document. Otherwise, explain why the
> WG has decided to choose 5:1 and 10:1.
> 
> ----------------------------
> Response from Working Group:
> ----------------------------
> 
> The 5:1 contrast ratio provides a minimum contrast of around 3:1 for
> the major types of color blindness. A contrast ratio of 3:1 is the
> minimum level recommended by ANSI/HFS 100-1988. 10:1 provides
> approximately 7:1 contrast ratio for individuals with color blindness,
> which is the recommended contrast level in ANSI/HFS 100-1988.
> 
> We have added the following to the Intent sections of SC 1.4.1 and 1.4.4:
> 
> The 5:1 contrast ratio provides a minimum contrast of around 3:1 for
> the major types of color blindness. A contrast ratio of 3:1 is the
> minimum level recommended by [ISO-9241-3] and [ANSI-HFES-100-1988].
> 
> Calculations in ISO 9241-3 and ANSI/HFS 100-1988 are for body text. A
> relaxed contrast ratio is provided for text that is much larger (twice
> as tall and with three time the thickness of lines in the character).
> 
> Notes on formula
> 
> Conversion from nonlinear to linear RGB values is based on IEC/4WD
> 61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the
> Internet - sRGB" [sRGB].
> 
> The formula (L1/L2) for contrast is based on ISO 9241-3 and ANSI/HFS
> 100-1988 standards.
> 
> The ANSI/HFS 100-1988 standard calls for the contribution from ambient
> light to be included in the calculation of L1 and L2. The .05 value
> used is based on Typical Viewing Flare from IEC/4WD 61966-2-1 and the
> sRGB paper by M. Stokes et al.
> 
> This success criterion and its definitions uses the terms contrast
> ratio and relative luminance rather than luminance to reflect the fact
> that Web content does not emit light itself. The contrast ratio gives
> a measure of the relative luminance that would result when displayed.
> (Because it is a ratio, it is dimensionless.)
> 
> Note: Refer to related resources for a list of tools that utilize the
> contrast ratio to analyze the contrast of Web content.
> 
> ----------------------------------------------------------
> Comment 3:
> 
> Source: http://www.w3.org/mid/449A8F1D.5080403@mitsue.co.jp
> (Issue ID: LC-1236)
> 
> Comment: Is there any basis for saying that a 20 decibel difference is
> good enough? How do I explain to our customers when they ask why it
> requires a 20 decibel difference? I think "just because WCAG 2.0
> states" is not a sufficient answer.
> 
> Proposed Change:
> 
> Add a note or any kind of explanation which states the reason why a 20
> decibel difference has been chosen.
> 
> ----------------------------
> Response from Working Group:
> ----------------------------
> 
> There are a number of studies that this is based on. One is the Report
> done for the Access Board in 1999. In that study, 75% of the subjects
> needed a S/N of 18 dB to be minimally acceptable.
> http://www.hearingresearch.org/Pubs/Access_Bd_Final_Report.pdf
> 
> The most recent is Interference in Hearing Aids from Digital Wireless
> Telephones by Levitt, Kozma-Spytek, and Harkins in Seminars in
> Hearing/Volume 26, Number 2, 2005. It found that a signal to noise
> ratio of 32 to 28 db was needed for 90% to find phones highly usable,
> 24 to 20 db for 90% to for minor limitation on use and 15 to 12 db for
> Major Limitation of use.
> 
> ----------------------------------------------------------
> Comment 4:
> 
> Source: http://www.w3.org/mid/449A8F1D.5080403@mitsue.co.jp
> (Issue ID: LC-1237)
> 
> Comment: This success criterion should be Level 1 because, for
> example, if it isn't satisfied and background audio interferes screen
> readers, information could not be conveyed. Also, even if a mechanism
> to turn off background audio is provided, some users could not find
> the mechanism because of its background audio, so it would be better
> that the success criterion itself was reconsidered.
> 
> Proposed Change:
> 
> Move this success criterion to level 1. And possibly restates the
> criterion such that "do not play background audio without user
> request.
> 
> ----------------------------
> Response from Working Group:
> ----------------------------
> 
> Because automatic audio can interfere with assistive technology, SC
> 1.4.1 (formerly 1.4.2) has been moved to level A.
> 
> 
> 
> ----------------------------------------------------------
> Comment 5:
> 
> Source: http://www.w3.org/mid/449A8F1D.5080403@mitsue.co.jp
> (Issue ID: LC-1238)
> 
> Comment: Why this criterion allows the time-out which is not essential
> for its function? If the first three list items of the criteria are
> allowed, some users might not be able to read through the content. For
> example, when the function to deactivate the time-out is provided but
> it is placed on the end of the page, then some users cannot reach the
> function before the time-out.
> 
> Proposed Change:
> 
> Omit the first three list items from this criterion.
> 
> ----------------------------
> Response from Working Group:
> ----------------------------
> 
> Providing a mechanism to update a time-out that the user may not
> encounter before the time-out expires would not meet the requirements
> of this SC. We have revised SC 2.2.1 to clarify this:
> 
> 2.2.1 Timing: For each time limit that is set by the content , at
> least one of the following is true:
>    * Deactivate: the user is allowed to deactivate the time limit
> before encountering it; or
>    * Adjust: the user is allowed to adjust the time limit before
> encountering it over a wide range that is at least ten times the
> length of the default setting; or
>    * Extend: the user is warned before time expires and given at
> least 20 seconds to extend the time limit with a simple action (for
> example, "hit any key"), and the user is allowed to extend the time
> limit at least ten times; or
>    * Real-time Exception: the time limit is a required part of a
> real-time event (for example, an auction), and no alternative to the
> time limit is possible; or
>    * Essential Exception: the time limit is part of an activity where
> timing is essential (for example, competitive gaming or time-based
> testing) and time limits can not be extended further without
> invalidating the activity.
> 
> ----------------------------------------------------------
> Comment 6:
> 
> 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.
> 
> ----------------------------------------------------------
> Comment 7:
> 
> Source: http://www.w3.org/mid/449A8F1D.5080403@mitsue.co.jp
> (Issue ID: LC-1240)
> 
> Comment: In example 3, the Japanese phrase after the round bracket,
> "どうすることもできなくなり、あきらめること", is the meaning of the 
> phrase "さじを投げる".
> Therefore, it doesn't need to be inserted here. Also, this Japanese
> expression is a present form. So, either changing the Japanese phrase
> into past tense or the English sentense into present form is needed.
> 
> Proposed Change:
> 
> Remove the characters between the round bracket and the closing double
> quotation mark (including the round bracket.) Then, either change
> "さじを投げる" into "さじを投げた", or English verbs into past forms.
> 
> ----------------------------
> Response from Working Group:
> ----------------------------
> 
> Thank you for pointing this out. We've deleted the explanation in
> parenthesis and have fixed some grammatical errors in the example
> based on other comments. The example now reads, "Example 3: In
> Japanese, the phrase "さじを投げる" literally translates into "he throws a
> spoon". But it means that there is nothing he can do and finally he
> gives up."

-- 
Kiyochika Nakamura
Web Development Group
Mitsue-Links Co., Ltd.
Shinjuku Square Tower 15F,
6-22-1 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1115 JAPAN
Phone: +81-3-3344-7401 / Fax +81-3-3344-7402
E-Mail: nakamura-kiyochika@mitsue.co.jp
http://www.mitsue.co.jp/
Received on Friday, 8 June 2007 04:07:01 UTC

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