- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 19:33:52 -0700
- To: "Yukie Motomiya" <yukie.motomiya.zm@hitachi.com>
- Cc: public-comments-WCAG20@w3.org
Dear Yukie Motomiya, 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: Grounds for "200%" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0283.html (Issue ID: 2112) ---------------------------- Original Comment: ---------------------------- We have two questions on 1.4.4 and 1.4.7: Q1. Why "200%" and "50%"? Q2. Why do the authors have to be responsible for "200%"? We couldn't understand the reason why the authors should ensure that the "visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent". In the section of "Intent of this Success Criterion", it reads "The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, ...". However there should be more concrete reason why the working group feels "200%" and "50%" are reasonable. Also we'd like to know this percentage can be applied to the characters in any other languages such as CJK languages. Additionally, all the authors have to do is to use relative measurements in order to make text resizable. Do these SC mean that the authors should provide the mechanism with users to resize text up to 200 percent and down to 50 percent? If so, it should be done by the user agents. Proposed Change: - Add the concrete reason why "200%"/"50%" and the sufficient grounds for any other languages than English. Or change these SCs to simply saying "Visually rendered text can be resized by the user agents without assistive technology." - Add the concrete reason why "authors" should be responsible for "200%" and "50%". --------------------------------------------- Response from Working Group: --------------------------------------------- The working group spent a lot of time discussing such options; in fact, some of our initial proposals looked very much like your suggestion, "Visually rendered text can be resized by the user agents without assistive technology." However, we discovered several problems. 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 2: How to measure dB(A) SPL and Tools Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0284.html (Issue ID: 2113) ---------------------------- Original Comment: ---------------------------- We'd like know how to measure the volume in dB(A) SPL. Are there any tools which alows the authors to measure the volume easily? Proposed Change: - Add how to measure the volume in dB(A) SPL - Introduce the tools for the authors to measure the volume in dB(A) SPL --------------------------------------------- Response from Working Group: --------------------------------------------- Technique G56 will answer questions for people who have a beginning knowledge of making audio. It introduces different way of determining audio contrast. There are three basic ways described in G56: 1) Use an audio creation tool to measure the contrast as its being created. 2) Listen to the examples (sufficient and failure) provided in G56 and test it that way. 3) Measure the final wave form in an inexpensive (less than $100) audio program such as Cool Edit Pro. A separate tutorial is available which we will link to from the Additional Resources section of Technique G56. It provides a more in depth description of how to create and measure audio content on the web, as well as a discussion of popular tools used in the creation of audio for the Web and how to measure volume in dB(A) SPL. It is here: www.eramp.com/david/audio_contrast_general_techs.htm ---------------------------------------------------------- Comment 3: Time Limit for Security/Access Control Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0285.html (Issue ID: 2114) ---------------------------- Original Comment: ---------------------------- There can be the time limit for: - the security reasons - the access control(system/network performance management) If the users are not allowed to turn off, adjust, and/or extend the time limit in such cases, what should the authors do? These cases also should be the exception. Proposed Change: Add the followings to GL 2.2.1 - Security Exception: the time limit is required for the security reason, and no alternative to the time limit is possible; or - Access Control Exception: the time limit is required for the system/network performance management, and no alternative to the time limit is possible. --------------------------------------------- Response from Working Group: --------------------------------------------- Those situations were kept in mind when the current language was crafted. Use of time limits for security concerns relates to not leaving a terminal open. By asking if the user needs more time, you know that they are still present. So the extend provision would allow security concerns to be met. RE Access Control Exception: There is a limit on the number of times a person can extend. So access is eventually returned. If the exception were allowed, then people who need 5 or 10 times more time to complete would never be able to. The number of people who would be sitting on their terminals requesting more time at each time out is small enough that that it should not cause any problem in overall use of system resources. ---------------------------------------------------------- Comment 4: Layout using CSS Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0289.html (Issue ID: 2118) ---------------------------- Original Comment: ---------------------------- In the last sentence within the "Description" section, it reads "When the source order does not match the visual order, the tab order through the content must reflect the logical relationships in the content that are displayed visually." What if the author positions the groups of the content in the different order than the source order by using CSS? For example, a web page contains the navigation bar and the main content. In the visually rendered order, the navigation bar is placed first in the content, the main content is placed second. However, in the source order, the main content is placed first and the navigation bar is placed second. In this case, the visually displayed order does not much the source order, but the tab order through the logical relationships and sequences make sense. Is this applied to G59 technique? --------------------------------------------- Response from Working Group: --------------------------------------------- Positioning different sections of the content via CSS would satisfy SC 2.4.3, since focus would follow logical order within each section of the page, and there is no logical requirement that the sections be in any relative order. We have added such an example to Understanding SC 2.4.3. We have also added a new success criterion at Level A that the focus order be consistent with the information and relationships conveyed through presentation. While there are sometimes several orders that would be consistent with the information and relationships conveyed through presentation, we do not feel that your proposed example would meet this new success criterion. ---------------------------------------------------------- Comment 5: 3.2.3 should be Level A Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0292.html (Issue ID: 2121) ---------------------------- Original Comment: ---------------------------- 3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA) It's safe to say that these SCs are the common practices in the web design and "support the ability of both mainstream and specialized user agents to adapt content to formats that meet their users' needs". Proposed Change: Move 3.2.3 to Level A. --------------------------------------------- Response from Working Group: --------------------------------------------- This is too broad a requirement to have at level A. There are reasons where it may be desirable, more usable and more understandable to change the order of the navigation elements from one page to another. This was level AA in WCAG 1.0 as well. ---------------------------------------------------------- Comment 6: 3.2.4 to level A Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0296.html (Issue ID: 2125) ---------------------------- Original Comment: ---------------------------- 3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA) It's safe to say that these SCs are the common practices in the web design and "support the ability of both mainstream and specialized user agents to adapt content to formats that meet their users' needs". Proposed Change: Move 3.2.4 to Level A. --------------------------------------------- Response from Working Group: --------------------------------------------- We consider it good news that this success criterion describes common practice in Web design, since it is very important to people with some types of cognitive, learning, and language disabilities. The success criterion's purpose is to support consistency in direct access to content by people who use conventional user agents, rather than providing additional support for alternate renderings via assistive technology. And it does place more limits on visual presentation. For these reasons, we believe Level AA is the appropriate level.
Received on Sunday, 4 November 2007 02:34:05 UTC