- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:06:23 -0700
- To: "Andrew Arch on behalf of Vision Australia" <andrew.arch@visionaustralia.org>
- Cc: public-comments-WCAG20@w3.org
Dear Andrew Arch, 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: Level of SC 1.2.1 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html (Issue ID: 1972) ---------------------------- Original Comment: ---------------------------- Source: http://www.w3.org/mid/000101c6964a$9c7e3160$011610ac@yourdh7axfhyur (Issue ID: LC-1283) Comment: It is too easy to fail SC at Level 1 - most organisations I have worked with will not go to this length in most cases, hence will never be able to claim even "A" conformance. In fact, on most Government and corporate sites I have worked with, the provision of a transcript and/or a script gives all the information needed to substitute for the multimedia Proposed Change: Level 1 should have SC along the lines of "provide a transcript if spoken words only and no action" and "provide a script including the dialogue if video wit activity" SC 1.2.1 & 1.2.2 should be moved up a level, and all other SC reconsidered as to the appropriate level. ---------------------------- Response from Working Group: ---------------------------- The working group considered carefully the levels assigned to all the GL 1.2 success criteria. SC 1.2.1 and 1.2.2 are level A success criteria because vision and hearing impaired users will not be able to access multimedia without this information. SC 1.2.2 can be satisfied by a full transcript. But captioning is a much better augmentation for the deaf than a separate transcript, since much can be communicated non-verbally, even when there is no action. --------------------- Response from Andrew: --------------------- Comment 22 = satisfied WRT SC1.2.2; my original comments still stand WRT SC 1.2.1 --------------------------------------------- Response from Working Group: --------------------------------------------- We haven't received any new information in the latest review round that would cause us to change our judgment on this. We still believe captioning is a much better augmentation for the deaf than a separate transcript, since much can be communicated non-verbally, even when there is no action. ---------------------------------------------------------- Comment 2: 1.4.3 at Level AA allows sites that are unreadable for many Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html (Issue ID: 1973) ---------------------------- Original Comment: ---------------------------- Source: http://www.w3.org/mid/000101c6964a$9c7e3160$011610ac@yourdh7axfhyur (Issue ID: LC-1286) Comment: Under the new Conformance level definitions, I strongly suggest that 1.4.1 & 1.4.2 should be Level 1 and that 1.4.3 & 1.4.4 should be Level 2 Proposed Change: reconsider the Levels the SC fall under - move them up a level ---------------------------- Response from Working Group: ---------------------------- The description of conformance levels in WCAG 2 has been rewritten to clarify the levels (see http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ). Because background audio can interfere with assistive technology, SC 1.4.1 (formerly 1.4.2) has been moved to level A. Because level A attempts to put the fewest possible limitations on presentation, and because assistive technology will be able to present the text or text equivalents of this content to the user, the working group felt that SC 1.4.2 (formerly 1.4.1) was most appropriate at level AA. Because of the additional limitations they put on presentation, the working group felt that SC 1.4.4 (formerly 1.4.3) and SC 1.4.5 (formerly 1.4.4) are most appropriate at level AAA. ---------------------------- Response from Andrew: ---------------------------- Comment 25 = partially satisfied; however, by leaving SC1.4.3 at "AA", we still allow site with blue on green, or grey on blue, or yellow on white, to pass at "A" while being unreadable for many many people. Also, SC1.4.4 seem to say that current IE uses will not be able to resize the text easily (view text size > larger/smaller) if a site just meets "A". --------------------------------------------- Response from Working Group: --------------------------------------------- 1) We have moved 1.4.2 Audio control to Level A. 2) We have left 1.4.3 Contrast (Minimum) (was 1.4.1) at level AA because there are ways using operating system or User Agent high contrast highlighting or tools for people with colorblindness. 3) With 1.4.3 Contrast (Minimum) staying at level AA, 1.4.5 Contrast (Enhanced) is staying at AAA 4) 1.4.4 Resize text was not moved up because text scaling is primarily a user agent responsibility. Leaving this at Level AA should not however, present a disadvantage for current IE users. Internet Explorer 7 includes a zoom feature which works with absolute font sizes. ---------------------------------------------------------- Comment 3: satisfied if SC2.2.1 includes some mention of auto-redirect Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html (Issue ID: 1974) ---------------------------- Original Comment: ---------------------------- Source: http://www.w3.org/mid/000101c6964a$9c7e3160$011610ac@yourdh7axfhyur (Issue ID: LC-1288) Comment: This should be a level 2 SC - for many people with reading difficulties, or using AT, reading a page is a time consuming exersize, and page refreshes may not allow them to read to the end. Proposed Change: move this SC up a level & consider strengthening it WRT content refreshing automatically ---------------------------- Response from Working Group: ---------------------------- Automatic page refreshes or updates are a type of time limit covered by SC 2.2.1, which is a Level A success criterion. See SC 2.2.1 at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#time-limits-required-behaviors. ---------------------------- Response from Andrew: ---------------------------- Comment 27 = satisfied if SC2.2.1 includes some mention of auto-redirect --------------------------------------------- Response from Working Group: --------------------------------------------- We have updated the intent section of 2.2.1 to clarify that page refreshes are time limits. ---------------------------------------------------------- Comment 4: SC 3.1.2 should be level 1 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html (Issue ID: 1975) ---------------------------- Original Comment: ---------------------------- Source: http://www.w3.org/mid/000101c6964a$9c7e3160$011610ac@yourdh7axfhyur (Issue ID: LC-1295) Comment: What is the point of having 3.1.1 at Level 1, but 3.1.2 at Level 2? My screen reader will then just read the entire page in the web unit language! Proposed Change: Move 3.1.2 to Level 1 ---------------------------- Response from Working Group: ---------------------------- There were requests to combine SC 3.1.1 and 3.1.2, to move their levels up and to move them down. After much discussion, the consensus of the working group was to leave them in the current positions. ---------------------------- Response from Andrew: ---------------------------- Comment 34 = not satisfied, please provide reasoning for retaining as per previous draft. My comment is still valid. --------------------------------------------- Response from Working Group: --------------------------------------------- The working group felt that the language of the page was more important than the language of the passage. It also does not require as much coding from the author. Also Inline language changes are not available in all technologies. SC 3.1.2 had many complicating factors with respect to what exactly qualifies as a change of language in a passage. That is why it has a rather lengthy note on it to clarify situations that are not to be considered a change of language. We felt at level A this should not be required. ---------------------------------------------------------- Comment 5: LC-1300 - include WCAG 1.0 Checkpoint 1.5 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0047.html (Issue ID: 1976) ---------------------------- Original Comment: ---------------------------- Source: http://www.w3.org/mid/001b01c69664$ec069c30$011610ac@yourdh7axfhyur (Issue ID: LC-1300) Comment: Several WCAG 1.0 checkpoints that are still very important for some people with disabilities are missing from WCAG 2.0:- 1.5 (text equivalents for image map links) - important for people with some learning difficulties (some people are text oriented, others are graphics oriented) ... 10.5 (separating links visually) - acknowledged as important for some people with cognitative disabilities... 13.8 (front loading) - important for many people with reading difficulties 14.1 (clear language) - important for many people with reading difficulties; also the related SC are now Level 3 (cf P1 in WCAG 1.0)Proposed Change: Add these Checkpoints back in as WCAG 2.0 SC. I acknowledge that some of these may not be machine testable, but they are human (consensus) testable. ---------------------------- Response from Working Group: ---------------------------- 1.5 (text equivalents for image map links) - important for people with some learning difficulties (some people are text oriented, others are graphics oriented) Response: Image maps are non-text content and they are links. Therefore, this requirement is covered under Success Criteria 1.1.1, 2.4.4, and 2.4.5. HTML technique H24 "Providing text alternatives for the area elements of image maps" is a sufficient technique for these success criteria. ... -- 10.5 (separating links visually) - acknowledged as important for some people with cognitive disabilities Response: We have added an advisory technique to GL 3.1, 1.3 and 2.4 titled "Making links visually distinct." -- 13.8 (front loading) - important for many people with reading difficulties Response: This is addressed by an advisory technique listed under SC 2.4.6 (formerly 2.4.5), "Starting section headings with unique information". -- 14.1 (clear language) - important for many people with reading difficulties; also the related SC are now Level AAA (cf P1 in WCAG 1.0) Response: A characteristic that is important to WCAG 2.0 is the testability of each success criterion. We have not been able to create a testable description of "clear language." We have tried to cover this in some of the success criteria and have added advisory techniques in Guideline 3.1. However, there is no direct mapping. -- ---------------------------- Response from Andrew: ---------------------------- Comment 39 (WCAG 1.0 - 1.5) = unsatisfied. Current user agents do not display the area alt text when the image is not display. Also, for people with image processing difficulty, the image map may not be comprehensible, while a text list might be. Furthermore, image-maps pixelate for screen magnifier users - text-based lists are easy to magnify well/smoothly. Comment 39 (WCAG 1.0 - 10.5) = unsatisfied with just an advisory technique; original comment still stands Comment 39 (WCAG 1.0 - 13.6) = unsatisfied with just an advisory technique. Is this because it is not 'testable'? Comment 39 (WCAG 1.0 - 14.1) = unsatisfied, but I might just have to accept --------------------------------------------- Response from Working Group: --------------------------------------------- Regarding (WCAG 1.0 - 1.5): In IE7 there are placeholders for images when the advanced settings are set not to load images. The alternate text shows in Zoomtext and reads in JAWS. This is not the case for Firefox 2.0. Firefox does not load the images at all when images are set off. There is no placeholder. But this is true for all images. If someone turns off images in Firefox 2, they will not get *any* alt text, including image maps. We have not encountered any Screen readers or Screen Magnifiers that have behavioral differences while rendering image map alt-text (compared to regular alt text on images) when images are turned off. Regarding the image pixilation issue, we have zoomed in on an image to the point of having 4 words across the entire screen (5x). There was not significant pixilation that would greatly inhibit comprehension. Current versions of screen magnifiers have come a long way on the pixilation issue. We feel that there is not sufficient basis for including this issue as a separate Success Criterion. The working group believes the best way to address this issue is as an advisory technique. -- Regarding (WCAG 1.0 - 10.5): We have requested input from a WCAG contributor who is self identified as having a cognitive disability and has been a strong advocate for the Cognitive community. She has not encountered or heard of any benefits to people with Cognitive disabilities from WCAG 1.0 checkpoint 1.5 since its release in 1999. The working group believes the best way to address this issue is as an advisory technique. -- Regarding (WCAG 1.0 - 13.8): There are several reasons why the working group felt that this WCAG 1.0 Checkpoint could not be required in WCAG 2.0. Part of the reason is that it is not testable. It can be very difficult (and sometimes more confusing) to make data-driven content conform to this sort of requirement. There are cases when it is important to number items before the Title or to have a section name (or code) included in the Title. This is especially true for technical web sites and documentation. This is also true for dynamic sites that present web pages populated with information from a database in different arrangements based on the query. In a dynamic web environment which is currently the norm for web sites, it is much more difficult to require this than on a static HTML page as in 1999 when WCAG 1.0 was published. -- Regarding (WCAG 1.0 - 14.1): We agree that clear language is helpful. However, it is very difficult to test for this. In order for authors to know whether they have actually fulfilled the requirements of the Guidelines, the success criteria need to be testable. Unfortunately, there is a cost to this because things that are not easily testable can only be given advisory status. However, if we removed the testability requirement from the Success Criteria then the entire WCAG 2.0 would be advisory. In addition, the requirements for clear and simple writing vary based on human language. Since WCAG has to apply to all web sites in all languages, the working group did not feel that we could create useful requirements in this area. We have, however, captured a range of advisory techniques that may be applied in different contexts and languages as they apply. and we are seeking more. ---------------------------------------------------------- Comment 6: The phrasing of this SC is not definitive enough Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0297.html (Issue ID: 2126) ---------------------------- Original Comment: ---------------------------- Some of the informative discussion refers to techniques that would add to confusion for visual users. The current test procedure for F73 (links not visually evident) states "Check that each link within text that is part of a sentence or paragraph (or other area where they could be mistaken as non-linked text) in the page is underlined or otherwise visually identifiable (i.e. bolded, italicized) as a link without relying on color". However, the use of bolding and italicising is normally used for emphasis of words or sections of a document. Allowing the author/designer to use bold or italics to indicate linked text instead of underling leads to a recommendation that goes against conventional practice and, while meeting SC 1.4.1 technically, does not actually make links identifiable for visual users. Proposed Change: Rephrase the SC as "Any information that is conveyed by color differences is also simultaneously and unambiguously visually evident without the color differences." Rephrase the F73 test as "Check that each link within text that is part of a sentence or paragraph (or other area where they could be mistaken as non-linked text) in the page is underlined" Clarify some of the informative discussion to ensure that conventions are followed. --------------------------------------------- Response from Working Group: --------------------------------------------- We have harmonized instead with the language in ISO, HFES and TEITAC. the provision now reads "Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element." ---------------------------------------------------------- Comment 7: This SC is at a level that will not be adopted by many sites - it is too important to leave at AAA Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0298.html (Issue ID: 2127) ---------------------------- Original Comment: ---------------------------- Screen reader users commonly use a navigation technique which brings up a list of all the links on the current page. The list of links created by the screen reader software is presented in a separate dialog box or window and enables users to move to a specific links by entering the first letter of the link from the keyboard. For example, entering the letter "e" moves the focus to the first link which starts with the letter "e", then the second link starting with "e", and so on. Having access to this list an important and much used functionality for screen reader users as it allows them quick and easy access to all the links on the page (links being one of the most crucial elements of a web pages). When the links are presented in this manner, the user has no access to the context in which the link appears on the page without returning to the page and progressively moving through the interactive elements. It is therefore important to implement meaningful, descriptive, and unique link texts as this allows screen reader users to utilise this important means of navigation (if such link text is not used, for example if all link text consist of the phrase "click here", then the links list cannot be used.) Screen reader users can use the tab key to jump sequentially through all active elements on a page, including link elements. When a link attains focus the screen reader announces the link text. If the link text does not provide a meaningful and descriptive link text, the screen reader user must explore the surrounding text to determine the destination of the link, including determining whether the preceding or the following text provides the relevant information. This slows down the access to page content and navigation and can lead to ambiguity with regards to link destination. Some users groups with reduced vision (including certain users who rely on screen magnification software) try to minimise any reading so it only includes essential information, as reading places great strain on their eyes. Such users endeavour to navigate and orientate themselves using visual cues such as colours and borders as these do not involve the reading of letters. When such uses scan page content to pick up important information (including links) they are helped by links being rendered with different colours and underlined (as per SC 1.4.1), as this makes the links stand out and therefore easy to pick out from the surrounding text. Implementing meaningful link text helps these users as they only have to read the link text to understand the link destination and do not have to read the surrounding text. Some users with cognitive disabilities might find it difficult to understand that the destination of links can only be ascertained by reading the surrounding text. Such users can find it confusing that links with identical link text can point to different locations, for example if a page contains 10 "click here" links. Some users with reading difficulties have problems deciphering text, providing these users with clear destinations via the link text is a very important aspect of meeting the needs of the widest range of people with disabilities. Proposed Change: Upgrade SC 2.4.8 to level AA --------------------------------------------- Response from Working Group: --------------------------------------------- The working group recognizes that the link list mechanism provided by user agents and assistive technology will provide best results when SC 2.4.8 is satisfied. While the working group encourages authors to make link text as descriptive as possible out of context, we do not feel that this success criterion can be satisfied for all Web pages. For Example: - a page has book titles followed by PDF, HTML, DOC. - Article name (long) followed by a sentence and the link "more" - GOOGLE search where each entry has text plus the following links [translate this page] HTML and [CACHED] and [SIMILAR PAGES] - toolbar with menus with an arrow icon - the link says "open". Having full links makes the page very cluttered, harder cognitively to find things when the same long (sometimes multi-line) text is repeated with one word different, and is very long to listen to for those not adept at auditory skipping (or where unique information is back end loaded) These issues were considered carefully for a long time, the working group feels that having 2.4.4 at Level A and this issue addressed at Level AAA strikes the right balance. While user agent and assistive technology support for finding the link context is poorer than we would like, we have checked that there is at least one case of support for each of the types of link context we have listed as sufficient techniques. So a user who has tabbed to a link can ask for those pieces of context without leaving the link. We hope that if authors satisfy SC 2.4.4 and make link context programmatically determinable, user agent developers will find a way to let users access the context when needed, such as when the link list is created. The first techniques listed in 2.4.4 are: "G91: Providing link text that describes the purpose of a link H30: Providing link text that describes the purpose of a link for anchor elements (HTML) ---------------------------------------------------------- Comment 8: access to the text alternatives for image maps Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0014.html (Issue ID: 2314) ---------------------------- Original Comment: ---------------------------- Further to our previous comment on "Prohibiting images of important text", Vision Australia would also like to raise the issue of how a user accessing pages with images off would necessarily know of the presence of an image map, let alone be able to access the map regions? Most browsers do not render the text alternative for and outlines of map regions. WCAG 2.0 SC 1.1.1 seems to currently allow for informational images as long as those images have a text equivalent that can be programmatically determined â€" eg an Alt attribute in HTML. If those user groups with low vision magnify an image with current technology, it can pixelate to the extent of being unusable, so they expected to turn images off to access the text alternative. However, in the case of HTML image maps, it is just the text alternative of the image that is display, not the text alternatives for he MAP areas or hot-spots. The user is not to know that the image has selectable areas, nor where those area boundaries are even if they did know that the image they can no longer see does have selectable areas. Furthermore, some people with cognitive disabilities are unable to process image-based information and prefer clear text-based information. These people can see the image perfectly well, but may not recognise the areas they are supposed to select from. WCAG 1.0 has a checkpoint (1.5) that requires the provision of "redundant text links for each active region of a client-side image map". For many groups accessing the web, this is still a requirement. Proposed Change: Add a success criterion requiring image map links to also be made available as text-based links --------------------------------------------- Response from Working Group: --------------------------------------------- We believe that the issue you highlight is already addressed by the current wording of 1.1.1 which requires that if non-text content is a control or accepts user input, then it has a name that describes its purpose. We have extended technique H24 to indicate to authors how to meet 1.1.1 and have added the following to the User Agent Notes: However, currently, visual User Agents do not display the alt attribute text for area elements of image maps when accessed by keyboard or when images are not displayed, and may clip the area elements if the intrinsic size of the image is not used. In addition, the display of alt attribute text in response to mouse-hover does not display in the font size or color combination set in the User Agent.
Received on Sunday, 4 November 2007 04:06:39 UTC