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

Dear WCAG WG,

Thank you very much for your responses.
We're looking forward to seeing the next working draft and will send
our comments if we would have any concerns.


Best Regards,
JIS Working Group


> -------- Original Message --------
> Subject: Your comments on WCAG 2.0 Public Working Draft of May, 2007
> Date: Sat, 3 Nov 2007 21:48:45 -0700
> From: Loretta Guarino Reid <lorettaguarino@google.com>
> To: Takayuki Watanabe, Masahiro Umegaki, Makoto Ueki <nabe@lab.twcu.ac.jp>
> CC: public-comments-WCAG20@w3.org
>
> Dear JIS,
>
> 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: about "Accessibility Supported"
> Source:
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0317.html
> (Issue ID: 2172)
> ----------------------------
> Original Comment:
> ----------------------------
>
> In the description of "Accessibility Supported" in the section of
> "Important New Terms Used in WCAG 2.0", there is an Editorial Note
> which reads "The W3C WAI will be compiling existing information on its
> technologies. It is expected that other organizations will compile
> such information for their technologies. There will undoubtedly be
> others who create documented lists as well."
>
> It is irresponsible of WCAG WG to rely on the "other organizations".
> WCAG 2.0 is a guidelines which would be recommended by W3C/WAI. If
> WCAG 2.0 require authors to consult documented lists of technologies
> that are known to have accessibility support, WCAG 2.0 itself should
> provide the documented lists.
>
> If WCAG 2.0 would rely on other organizations, WCAG WG should create
> the test files for each technologies so that other organizations will
>
> be able to compile such information based on the same level of the
> measure. The documented lists for any languages should be created by
> using the same test files and the same test procedure with the same
> measure. Without those materials, JIS WG or any other organization in
> Japan won't be able to do anything. Even if some organization would
> create the lists, it could be unreliable information and the sites
> based on such information could be inaccessible to the users in
> reality. For any other languages than English, this must be one of the
> big concerns.
>
> Additionaly, the format for the documented lists should be provided to
> ensure the consistency across the languages.
>
> Proposed Change:
> - Develop and Provide the test files and the measure for the
> documented lists on Accessibility Supported technologies.
>
> - Provide the format for the documented lists.
>
> - Not rely on the other organizations than W3C as WCAG 2.0 is one of
> the W3C guidelines.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> WCAG will be providing the format for a documented list.  We cannot
> document all versions of all technologies for all languages by
> ourselves however.  It is simply too much work and there are not
> sufficient resources.  Also, it would not make sense to duplicate or
> turn away good research by others.
>
> It is beyond the WCAG WG charter to document all technologies, in
> particular proprietary technologies that are not maintained by an open
> standards body such as the W3C.  The Web Content Accessibility
> Guidelines set guidelines to determine if a technology is
> accessibility supported.
>
> ----------------------------------------------------------
> Comment 2: Discussion of "Documented lists" needs clarification
> Source:
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0318.html
> (Issue ID: 2173)
> ----------------------------
> Original Comment:
> ----------------------------
>
> In the section of "Understanding Documented lists of Web technologies
> with Accessibility Support", it reads "There is no requirement in WCAG
> that a documented list be used or that technologies from such a list
> be used."
>
> It is confusing because it can also be read as "the authors don't need
> to refer and/or use the documented lists when choosing the
> technologies in order to conform to WCAG 2.0." Then the Documented
> lists of Web technologies with Accessibility Support won't be needed
> at all.
>
> In the last paragraph within the same section, at the same time, it
> reads "Authors, companies or others may wish to create and use their
> own lists of accessibility-supported technologies." This is the
> contradictory statements.
>
> Proposed Change:
> Add more clarification on what the documented lists are and for what
> they are needed.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We have added a section "Understanding Documented Lists" to the
> Understanding WCAG 2.0 document and provided a link from WCAG 2.0 to
> this section.
>
> We clarified this section as well.  It now reads:
>
> Understanding Documented lists of Web technologies with Accessibility
> Support
>
> Because individual authors will not usually be able to do all of the
> research necessary to determine which features of which Web
> technologies are actually supported by which versions of assistive
> technologies and user agents, authors will usually rely on public
> documented lists of Web technologies that document which assistive
> technologies support which features of which Web technologies. By
> public, we only mean that the list and its documentation are public.
> Anyone can create a publicly documented list of "Web Technologies and
> their Accessibility Support." People may create recommended
> "documented lists of technologies" and give them a name (e.g. the XYZ
> Accessibility Coalition's 2007 Supported Technologies List) that
> authors can use. As long as they are publicly documented, authors or
> customers etc. can easily select lists that meet their needs.
> Customers or others can pick lists that fit their environment or
> language at any point in time and specify those to be used in creating
> their content. Authors are strongly encouraged to choose lists that
> have an established reputation for accuracy and usefulness. Developers
> are strongly encouraged to provide information about the accessibility
> support for their technologies. The Working Group anticipates that
> only lists that provide accurate information and benefit both authors
> and users will achieve market recognition in the long term.
>
> There is no requirement in WCAG that a public documented list be used
> or that only technologies from such a list be used. The public
> documented lists are described only as a method to make an otherwise
> critical, but somewhat complicated, aspect of conformance easier for
> authors who are not themselves experts on assistive technology support
> (or who just don't have the time to keep up with advances in
> mainstream and assistive technology support for each other).
>
> Authors, companies or others may wish to create and use their own
> lists of accessibility-supported technologies and this is allowed in
> meeting WCAG. Customers, companies or others may however specify that
> technologies from a custom or public list be used. See Appendix B
> Documenting Accessibility Support for a Web Technology.
>
> ----------------------------------------------------------
> Comment 3: What does "accessibility support" mean?
> Source:
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0319.html
> (Issue ID: 2174)
> ----------------------------
> Original Comment:
> ----------------------------
>
> In the "Note 2" within the section of "Understanding Accessibility
> Support", it reads "When a Web Technology is "accessibility
> supported," it does not imply that the entire technology must be
> supported. Most technologies lack support for at least one feature.
> When referring to "accessibility support" for a technology, the
> support for specific aspects, features, and extensions should be cited
> if the technology as a whole is not accessibility supported. "
>
> We couldn't understand what WCAG WG want to mean by this. It can also
> be read as "if the one of the features for a technology is supported
> by a assistive technology, the technology can be recognized as
> accessibility supported". It could lead many conformant websites to be
> inaccessible in the reality.
>
> Proposed Change:
> Add more understandable clarification.
>
> Received on
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> We do not have any requirements for platforms per se, but the
> description of accessibility support for a technology should note
> which platforms the technology has AT support on.  This is described
> in the section "Understanding Accessibility Support" in "Understanding
> Conformance".
>
> We have tried to make this clearer in the current version of
> Understanding Conformance in Understanding WCAG 2.0, in the section
> "Documenting Accessibility support for a Web Technology".
>
> Most Web technologies have some aspects that are not supported.  So
> complete support is rare if it occurs at all.  The description of
> accessibility support will provide information on how much support is
> provided for various features within technologies.  Decisions about
> which features of technologies can be used (are accessibility
> supported) can then be made based on these reports.
>
> ----------------------------------------------------------
> Comment 4: Why "18 point or 14 point bold"?
> Source:
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0320.html
> (Issue ID: 2175)
> ----------------------------
> Original Comment:
> ----------------------------
>
> It reads "18 point text or 14 point bold text is judged to be large
> enough to require a lower contrast ratio." in the second paragraph of
> the "Intent of this Success Criterion". But we couldn't understand the
> reason why the working group judge that "18 point text or 14 point
> bold text" is large enough to require a lower contrast ratio. Are
> these sizes applied to the characters in any other languages such as
> CJK languages? We need the rationale or the  ground on \"18 point text
> or 14 point bold text" in order to determine if it would also make
> sense in the Japanese characters.
>
> Proposed Change:
> Add the more concrete reason why "18 point text or 14 point bold text
> is judged to be large enough to require a lower contrast ratio."
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> These numbers were worked out with assistance from the Lighthouse
> International (http://lighthouse.org/) - an organization in the US
> that does research on low vision. To handle other languages, we have
> changed the note to read:
>
> larger scale (text)
> with at least 18 point or 14 point bold or font size that would yield
> equivalent stroke width for Chinese, Japanese and Korean (CJK) fonts
>
> Note 1: Fonts with extraordinarily thin strokes or unusual features
> and characteristics that reduce the familiarity of their letter forms
> are harder to read, especially at lower contrast levels.
>
> Note 2: Font size is the size when the content is delivered. It does
> not include resizing that may be done by a user.
>
> Note 3: The actual size of the character that a user sees in dependent
> both on the author-defined size and the users display or user-agent
> settings. This success criterion is based on common pixel sizes
> available today. Users who have low vision would be responsible for
> choosing appropriate settings.
>
> ----------------------------------------------------------
> Comment 5: Rationale for "200%" and 50%?
> Source:
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0321.html
> (Issue ID: 2176)
> ----------------------------
> Original Comment:
> ----------------------------
>
> We need more concrete reason/rationale on why "200 percent" and "50
> percent" were chosen by the WCAG WG. Without the reason/rationale, we
> won't be able to determine if "200 percent" and "50 percent" can be
> applied to the Japanese characters.
>
> Proposed Change:
> Add more concrete rationale for why "200%" and "50%".
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> As text is scaled larger and larger, it becomes impossible to prevent
> loss of content or functionality. When horizontal text is enlarged
> beyond a certain level, text wrapping algorithms turn the text into a
> vertical column of words, possibly clipped if the word itself is too
> large to fit into the available horizontal space on screen. For
> vertical text, similar problems occur.
>
> Arbitrary resizing also introduces problems with testing. How does an
> author know when he has satisfied the success criterion, particularly
> for more sophisticated web pages that may change their layout  based
> on the text size to produce more readable results. An example would be
> a page that switches between single and multiple column text so that
> line widths stay within the ~16 word range recommended for some
> cognitive, learning, and language disabilities.
>
> So we felt that some choice of explicit values was necessary to make
> these success criteria testable. 200% was chosen after experimenting
> with various web pages that the working group felt were well designed,
> to see when scaling started to introduce problems. We also looked at
> the scaling supported directly by popular browsers. (IE's largest text
> scaling factor is only about 180%). And we looked at the support
> provided by screen magnifiers. For older screen magnifiers, 200% was
> the smallest scale factor that could be chosen. 50% was chosen to
> provide symmetry in the ranges. The ability to scale in both
> directions is desirable.
>
> We believe that there is a range of visual disabilities that can best
> be addressed directly and a range where the most effective solutions
> rely on assistive technology such as screen magnifiers. Other success
> criteria ensure that assistive technology can access the content
> successfully. These new success criteria identify the author's
> responsibility when supporting users where direct access is more
> effective.
>
> Note, by the way, that the success criteria don't require just scaling
> to 200% and 50%, but to all the values between. Our expectation is
> that solutions that work across that range will continue to work "as
> well as possible" beyond those limits.
>
> This is explained in the Intent Section of Understanding SC 1.4.4. The
> Working Group welcomes suggestions for ways to make this information
> clearer.
>
> ----------------------------------------------------------
> Comment 6: How to measure dB(A) SPL and Tools
> Source:
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0322.html
> (Issue ID: 2177)
> ----------------------------
> Original Comment:
> ----------------------------
>
> There should be the instructions on how to measure the volume in dB(A)
> SPL. It\'ll be helpful and useful if the working group could introduce
> any tools for the authors to measure the volume.
>
> Proposed Change:
> - Add the instructions on how to measure the volume in dB(A) SPL.
>
> - Add the links to the tools.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Same response as Issue 2113.
>
> ----------------------------------------------------------
> Comment 7: Responsible for "200%" and 50%"
> Source:
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0323.html
> (Issue ID: 2178)
> ----------------------------
> Original Comment:
> ----------------------------
>
> It can be read as "Authors have to provide a mechanism which allows
> the users to resize text up to 200 percent and down to 50 percent.
>
> If it is NOT what the WCAG WG wanted to say, the documents need more
> clarification on this.
>
> If it is what the WCAG WG wanted to say, the user agents should be
> responsible for it.
>
> Proposed Change:
> Add the clarification on who should be responsible for "200%" and 50%"
> and what the authors have to do.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> This is explained in "Understanding SC 1.4.7":
>
> See
>
> The scaling of content is primarily a user agent responsibility.  User
> agents that satisfy UAAG 1.0 Checkpoint 4.1 allow users to configure
> text scale.  The author's responsibility is to create Web content that
> does not prevent the user agent from scaling the content and that
> allows the reflow of the content within the current width of the
> viewport.
>
> ----------------------------------------------------------
> Comment 8: Sound Volume Control
> Source:
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0330.html
> (Issue ID: 2185)
> ----------------------------
> Original Comment:
> ----------------------------
>
> In 1.4.2, now it reads "or a mechanism is available to control audio
> volume which can be set independently of the system volume."
>
> This seems to address our comment which said "Is it unnecessary for
> WCAG 2.0 to require the mechanism of the audio volume control?" But
> "Response from Working Group" seems to reject our sugestion.
>
> Just to confirm. JIS WG still would like WCAG 2.0 to require the
> mechanism of the audio volume control.
>
> Most media players already have volume controls on them. However most
> of their interfaces can also be customized by the developers and the
> volume controls can be hidden in such customized skins of the media
> players. Aadditionally the authors can create the original interfaces
> without the volume controls, for example, by using Flash [1],[2].
>
> Having stop button is not necessarily sufficient since the volume can
> be too loud. In this case, it is not an user agent issue but a web
> content issue which is under the authors' control.
>
> For the customized interface without the volume controls on them, is
> it still unnecessary for WCAG 2.0 to require the mechanism of the
> audio volume control?
>
> We just want to confirm that "or a mechanism is available to control
> audio volume which can be set independently of the system volume." in
> 1.4.2 addresses our concern or not.
>
> [1] http://www.jvcmusic.co.jp/tarako/
>
> [2] http://www.kewpie.co.jp/tarako/
>
> ----------------------------------------------------------
>
> Comment 9:
>
> Source: http://www.w3.org/mid/20060623095914.FE78.NABE@lab.twcu.ac.jp
> (Issue ID: LC-1322)
>
> Comment: JIS X 8341-3 also addresses the importance of volume control.
> It allows the users who are hard of hearing to adjust the volume of
> the audio. Is it unnecessary for WCAG 2.0 to require the mechanism of
> the audio volume control?
>
> JIS 5.7 b) says:
>
> b) Sound should be controllable by users.
>
> Information:
>
> Hearing impaired users cannot detect that sound is being played. Also,
> there are cases where louder volume is preferred.
>
> Example:
>
> To enable users to adjust volume, play, and stop, provides controls
> for play, stop, and volume adjustment. When using plugins, they can be
> used for this purpose
>
> ----------------------------
>
> Response from Working Group:
>
> ----------------------------
>
> Control of volume is a user agent issue. Most players already have
> volume controls on them.  Content, due to security issues, usually
> cannot directly access the hardware volume control and thus can
> onlyturn volume down not up.   We therefore do not include a
> recommendation for content to also include a volume control, though
> user agents should. This belongs to the domain of User Agents and is
> covered in the User Agent guidelines (UAAG 1.0) which reads as
> follows:
>
> "Guideline 4. Ensure user control of rendering...User agents rendering
> audio have to allow the user to control the audio volume globally and
> to allow the user to control distinguishable audio tracks."
>
> Proposed Change:
> Response from Working Group said "Control of volume is a user agent issue."
>
> But 1.4.2 reads "or a mechanism is available to control audio volume
> which can be set independently of the system volume."
>
> Need more clarification on this issue.
>
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
>
> Yes, the situation that you describe is covered by SC 1.4.2. The
> author is responsible for making sure that there is some mechanism for
> the user to control the sound. Often, the mechanism is provided by the
> default behavior of the user agent. In this example, because the media
> player has been customized, the volume controls on the media player
> are not available to the user, so the author cannot rely on the
> default user agent-provided mechanism to satisfy SC 1.4.2. The author
> would need to provide some other mechanism.
>
> To make it clearer what is meant by controlling the volume, we have
> also reworded it as follows:
>
> 1.4.2 Audio Turnoff: If any audio plays automatically for more than 3
> seconds, either a mechanism is available to pause or stop the audio,
> or a mechanism is available to control audio volume which can be set
> to a different level from the system volume level. (Level A)

Received on Tuesday, 20 November 2007 14:16:46 UTC