- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:47:52 -0700
- To: "Jim Thatcher" <jim@jimthatcher.com>
- Cc: public-comments-WCAG20@w3.org
Dear Jim Thatcher, 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: Page title as context Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0099.html (Issue ID: 2007) ---------------------------- Original Comment: ---------------------------- For 2.4.4, as the "About" and "Contact" links suggest, the title of the current page should be mentioned as an example of Programmatically Determined Context. It is probably the most common context; it is so common that we don't even think of it as context. See discussion at http://jimthatcher.com/clickhere.htm. Proposed Change: Add technique that the title of the page is context for link. --------------------------------------------- Response from Working Group: --------------------------------------------- The purpose of this provision is to be sure that the USER can determine the purpose of the link from the link or from information that the AT can provide along with the link text. Take two cases: Example 1: The person lands on a page and it has just one link called "home", and one called "Contact". In this case the user can determine that one link will take them to the 'home' page of the site (that is its purpose) and the other will take them to a page with information on how to contact the people. Example 2: The person lands on a page and finds that there are mulitple "home" and "contact" links. So they stop on a 'home' link and ask for its context. they find out that the home link is in a list item along with "Merry Men of Mauston". Similarly, all the other 'home' links are on lines with other organization names. So they can determine that the "home" links are associated with the home pages of the organizations. If the organization names are also links it is helpful since the home and contact links would appear in the list immediately after the organization names. We aren't sure what information the page title could reliably provide. But we think that the issue is handled via the techniques described remembering that it is the User that needs to be able to determine the purpose of the link. ---------------------------------------------------------- Comment 2: Ban hiding link text Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0100.html (Issue ID: 2008) ---------------------------- Original Comment: ---------------------------- For 2.4.4 and 2.4.8, the technique (C7) of putting in full link text and then hiding the redundant parts for visual users should be removed. Allowing the overload text to be removed for sighted users, but required reading for blind users is not acceptable. See discussion at http://jimthatcher.com/clickhere.htm. Proposed Change: Remove techique C7 as sufficient technique for 2.4.4. --------------------------------------------- Response from Working Group: --------------------------------------------- In your reference article for this comment you have suggested the use of the Title attribute. http://jimthatcher.com/clickhere.htm. Note that the use of Title attribute is a sufficient technique (H33). In the user agent notes we have discussed the various current user agent issues with this technique. The CSS technique (C7) to hide link text has been advocated by Screen Reader users and corporate web authors. It has proved effective on web sites. The working group believes it is a useful technique. However, bearing in mind your comment that this technique could be used in situations that could introduce repetitive link reading, we have added a note to the technique that it is best implemented on pages that do not have repetitive content in the hidden text areas. Note also that this is just one technique. Other techniques are available so that the "hidden text" technique can be avoided when it would result in repetitive text. Finally, we are working on a new sufficient technique to hide for everybody "Use a CSS class for the "hidden" text, and provide a version of the stylesheet that unhides it (with a button or link that switches stylesheets)" This would allow users (with and without disabilities) to decided if they wanted full or short link text. ---------------------------------------------------------- Comment 3: Links give context Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0102.html (Issue ID: 2009) ---------------------------- Original Comment: ---------------------------- For 2.4.8, topic links of the form TopicA Link1 Link2 Link3 TopicB Link1 Link2 Link3 TopicC etc., provide context for the repeated links that follow (Link1 Link2 Link3) each topic. I don't know how to define this context, but it is common and easy to use for screen readers because all the detailed links on TopicX follow TopicX in the usual reading order - until a new TopicY link is encountered.This is analogous to the fact that the visual display (see the hotel examples, http://jimthatcher.com/clickhere.htm) of links like this makes the context obvious for sighted users. Proposed Change: Add a sufficient technique to allow topic links to provide context. Unfortunately I have not defined Topic Links and the context they provide! --------------------------------------------- Response from Working Group: --------------------------------------------- As described, the necessary context is not programmatically determinable link context. That is, given current web technologies, there would be no way for assistive technology to determine which of the preceding links was the topic link. However, if the topic were a heading and a link, it would work as you describe, providing a programmatic association that could be announced without leaving the link, and also to provide a topic link in a Links list in a screen reader as you describe. We have added a sufficient technique that identifies the current heading as programmatically determined link context. If the topic link were marked as a heading (as seems appropriate in this example), the success criterion would be satisfied. One of the examples in that technique is also a link, which would behave as you have described in your article. It would show up in the links list. We have also added a sufficient technique about optimizing pages for the links list feature.
Received on Sunday, 4 November 2007 04:48:05 UTC