W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > November 2007

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

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 21:47:52 -0700
Message-ID: <824e742c0711032147n4058563bo4497fc0891386373@mail.gmail.com>
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

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.


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

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
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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:45 UTC