- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:59:35 -0700
- To: "Magnus Burell" <magnus.burell@verva.se>
- Cc: public-comments-WCAG20@w3.org
Dear Magnus Burell, 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: Replace term "visually rendered" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0309.html (Issue ID: 2164) ---------------------------- Original Comment: ---------------------------- The term "visually rendered" in SC 1.4.4 and SC 1.4.7 is jargon. Hence, the guideline would benefit from an explanation in more plain language. --------------------------------------------- Response from Working Group: --------------------------------------------- We have changed the success criteria (1.4.4 and 1.4.7) to say: "Text (but not images of text) can be resized ...." ---------------------------------------------------------- Comment 2: Add video-clips to illustrate solutions Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0310.html (Issue ID: 2165) ---------------------------- Original Comment: ---------------------------- 3.3 is quite abstract. To make the guidline clearer, add short video-clips that show how this can look when implemented. For examples of how video can help illustrate a suggested solution, see videos explaining interaction design patterns at Yahoo.com. Click "Play" in the image: http://developer.yahoo.com/ypatterns/pattern.php?pattern=alphafilterlinks Video could also be added to explain other success criterias such as "onfocus" in SC 3.2.1 and "oninput" in SC 3.2.2 --------------------------------------------- Response from Working Group: --------------------------------------------- This would be helpful supplementary information, but the working group does not have the resources to create these videos at this time. We would be glad to consider adding any submission of this type. ---------------------------------------------------------- Comment 3: Change alternative number two "Checked" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0311.html (Issue ID: 2166) ---------------------------- Original Comment: ---------------------------- Alternative number two †Checked†does not give the user feedback or an opportunity to actually accept the change that will occur. If the submitted data is correct for the system (e.g. contains no formatting errors) but the transaction leads to, from a user’s point of view, unexpected changes. Then it could be an idea to inform the user about what the action might lead to. Proposed Change: For example: "Changing your X information will make . Do you want to? Yes No". Therefore as written now, I suggest "Checked" is removed from the list in 3.3.3. The check for input errors could be made before or after the "Confirmed" step. --------------------------------------------- Response from Working Group: --------------------------------------------- Note 3.3.3 is now 3.3.4. We have changed bullet 2 to clarify that the user is provided an opportunity to correct any errors that are identified: "Data entered by the user is checked for errors before going on to the next step in the process and the user is provided an opportunity to correct them." While bullet 3 will potentially let the user catch more errors, it does not provide the user any assistance in finding errors. Since the user will often be presented with data that contains no errors, we are concerned that it may encourage users to ignore the confirmation step. So it is not required in addition to bullet 2. We have also added an example to Understanding SC 3.3.4 to demonstrate checking for a potential input error that is not a syntax error but may produce unexpected results: Stock sale: A financial services web site lets users buy and sell stock online. When a user submits an order to buy or sell stock, the system checks to see whether or not the market is open. If it is after hours, the user is alerted that the transaction will be an after-hours transaction, is told about the risks of trading outside of regular market hours, and given the opportunity to cancel or confirm the order. ---------------------------------------------------------- Comment 4: Present more techiques on how improve texts Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0312.html (Issue ID: 2167) ---------------------------- Original Comment: ---------------------------- To make the guideline more understandable, present more techiques on how to do this and give further advise on how to test it. Proposed Change: For example: Sufficient techique: Try writing the most important first. Not only in the summary, also in the text as a whole and in separate sentences. It would support the reader's ability to choose if och if not to continue reading. Advisory Techique: An enumeration with more than four posts should be written as a list. This makes it easier to get an overview of the page. For example "bananas, apples, pineapples, peaches, mangos" could be easier to read formattes as a li-list in HTML: - bananas - apples - pineapples - peaches - mangos --------------------------------------------- Response from Working Group: --------------------------------------------- We would be happy to include references to writing at a lower reading level, but we believe that this is too large a topic to include this information directly in the Understanding WCAG document. We have added references to the "Guidelines for Creating Easy to Read Text, The Open Society Mental Health Initiative" at http://www.osmhi.org/?page=139 and the "European Guidelines for the Production of Easy-to-Read Information for People with Learning Disability" at http://www.osmhi.org/contentpics/139/European%20Guidelines%20for%20ETR%20publications%20(2).pdf Could you please send us additional references on this topic, for inclusion in the Related Resources section of the success criterion? ---------------------------------------------------------- Comment 5: Let the user use her preferred format for input Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0313.html (Issue ID: 2168) ---------------------------- Original Comment: ---------------------------- Is it not easier for the user if the requried format is corrected by the system without user involvement when applicable? For example a field for Telephone number. Phone numbers could be written separated by several characters (e.g. . / - () ). Separators are different in different countries. It is not difficult to let the system erase unnecessary separators. For example if the user input is "+64(8)555-9999-33" then the system transform this into "648555999933" or "0064.8.555.999.933" or whatever format is needed, but the user do not need to worry about this. She can instead write phone numbers in the way she is used to. This could of course be complemented by a text description of the format the system "prefers". --------------------------------------------- Response from Working Group: --------------------------------------------- Note 3.3.2 is now 3.3.3 Providing as much flexibility as possible in the input format is helpful for reducing errors. We have added the advisory technique: Accepting input data in a variety of formats However, it will still be possible for the user to enter data that the system cannot interpret and transform reliably, and the success criterion should be satisfied. ---------------------------------------------------------- Comment 6: Use heading for different columns in web page layouts? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/03014html (Issue ID: 2169) Status: VERIFIED PARTIAL/OTHER ---------------------------- Original Comment: ---------------------------- 2.4.9 Section Headings: Where content is organized into sections, the sections are indicated with headings In SC 2.4.9, do you suggest headings (hidden with CSS or visual) for different columns in web page layout? For example a hidden heading "Navigation" for left-menu, only shown for people listening to the page or not using CSS. Plus the main-heading for the content showing "here starts the main column" and finally some heading for an additonal right column. --------------------------------------------- Response from Working Group: --------------------------------------------- To clarify, we have modified the success criterion to say: "Section headings are used to organize the content." "Note: This success criterion covers sections within writing, not user interface components. User Interface components are covered under Success Criterion 4.1.2" The success criteria addresses text and subject matter. The intent is to take text that would otherwise be continuous text and divide it up so that it is easier for people with cognitive disabilities to access and understand.
Received on Sunday, 4 November 2007 04:59:54 UTC