W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2004

Re: Issue #1305

From: Chris Ridpath <chris.ridpath@utoronto.ca>
Date: Fri, 17 Dec 2004 10:40:55 -0500
Message-ID: <287201c4e44e$cbf85c90$e29a968e@WILDDOG>
To: "Ben Caldwell" <caldwell@trace.wisc.edu>, "'WAI-GL'" <w3c-wai-gl@w3.org>

Very helpful comments in your previous message. Thanks Ben!

To address this issue, I've created test 191 which checks the title
attribute on each source anchor to see if it describes the link destination:
http://www.w3.org/WAI/GL/WCAG20/tests/test191.html

The testable statement is:
The TITLE attribute of each source A (anchor) element describes the link
destination.

The UAAG allows this and it fits nicely within the HTML spec.

> I think this test should be associated with
> Guideline 3.2, level 2, item 6 [1]...
>
OK, done.

If this test were accepted then every link would have good clear link text.
User agents could find it easily and create excellent link lists. You
wouldn't have to hunt and guess through alt text and/or inline text to find
the link destination.

It's a clear simple rule. Sounds like a good thing.

Cheers,
Chris


----- Original Message ----- 
From: "Ben Caldwell" <caldwell@trace.wisc.edu>
To: "'WAI-GL'" <w3c-wai-gl@w3.org>
Sent: Wednesday, December 15, 2004 4:14 PM
Subject: RE: Issue #1305


>
> Chris wrote:
> >The suggested requirement is that the title attribute on the A (anchor)
> >element be used to identify the link destination. The image's alt text
> >would identify the image.
>
> I think this test should be associated with Guideline 3.2, level 2, item 6
[1], which states:
>
> <blockquote>
> The destination of each link is identified through words or phrases that
either occur in the link or can be programmatically determined.
> </blockquote>
>
> My understanding of this is that in order to meet WCAG 2.0 at level 2 for
HTML, our checklists/test suites would require that either the title
attribute of the anchor element include a description of the link
destination or that the link text itself (or alt of an image used as a link)
would include the description of the link destination.
>
> The test was originally associated with guideline 1.1, level 1, item 1,
which states:
>
> <blockquote>
> For all non-text content that is functional, such as graphical links or
buttons, text alternatives serve the same purpose as the non-text content.
> </blockquote>
>
> Note: this text differs from the latest draft based on decisions in the
Dec. 2 telecon.
>
> Here, the level 1 requirement in checklists/test suites would be that the
text-alternatives for images used as links serve the same purpose as the
non-text content, not that they describe the destination of the link. We
still have work to do in this department and specifics for how to identify
functional content and write equivalents for it would be addressed in
general techniques and would likely need a different set of tests based on
those techniques.
>
> Chris wrote:
> >We could also ask that the image's alt text be set to the same value
> >until user agents catch up. (Did I just write "until user agents"? Oh
> >no!)
> >
> >Example:
> >
> ><a href="home.html" title="home page"><img src="house.png"
> >alt="home page"/></a>
> >
> >This strategy would limit the pain in the short term and give us long
> >term
> >gains.
>
> I disagree. The title attribute [2] provides authors with an opportunity
to provide additional information about the nature of a linked resource.
Making the link text and the value of the title attribute identical only
makes extra work for authors without any benefit to users of AT that parses
title effectively.
>
> >P.S. Does someone have a reference to what the UAAG says about this?
>
> UAAG Guideline 2.3 Render conditional content (P1) [3] states:
>
> <blockquote>
> 1. Allow configuration to provide access to each piece of
>    unrendered conditional content "C".
> 2. When a specification does not explain how to provide access to
>    this content, do so as follows:
>       + If C is a summary, title, alternative, description, or
>         expansion of another piece of content D, provide access
>         through at least one of the following mechanisms:
>            o (1a) render C in place of D;
>            o (2a) render C in addition to D;
>            o (3a) provide access to C by allowing the user to query
>              D. In this case, the user agent must also alert the
>              user, on a per-element basis, to the existence of C
>                  (so that the user knows to query D); and
>                o (4a) allow the user to follow a link to C from the
>                  context of D.
>       + Otherwise, provide access to C through at least one of the
>         following mechanisms:
>            o (1b) render a placeholder for C, and allow the user
>                  to view the original author-supplied content associated
>                  with each placeholder;
>            o (2b) provide access to C by query (e.g., allow the user
>              to query an element for its attributes). In this
>              case, the user agent must also alert the user, on a
>              per-element basis, to the existence of C; and
>            o (3b) allow the user to follow a link in context to C.
>
> The problem here is that item 1a allows the user agent to render
conditional content in place of the original. For link text, this is likely
to render the sentence that contains the link unintelligible:
>
> [example]
>
> ... and I finally got <a href="boat.htm" title="Track my progress in
restoring
> an old 1957 wooden runabout.">my old boat</a> put in the water this
weekend.
>
> Would be read as follows by user agents that allow conditional content to
replace the original.
>
> ... and I finally got Track my progress in restoring an old 1957 wooden
runabout put in the water this weekend.
>
> [end example]
>
> In my opinion, a better model would require AT to make the presence of
conditional content known to the user and allow them to query that content
on an item by item basis. This is an issue that I have an outstanding action
item to raise with the UAAG working group.
>
> Until we get past some of these issues, we may need to rely on repair
techniques to address the AT shortcomings in this area.
>
> -Ben
>
> [1] <http://tinyurl.com/6nw2v>
> [2] <http://tinyurl.com/3r2uw>
> [3] <http://tinyurl.com/5c4w9>
>
>
Received on Friday, 17 December 2004 15:41:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:32 GMT