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

RE: [#832] Clear link text - priority and acceptability of supplemental text

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Tue, 22 Jun 2004 10:18:27 -0400
Message-Id: <p0611040fbcfd19dedc16@[10.0.1.2]>
To: WCAG WG <w3c-wai-gl@w3.org>
Cc: UAAG WG <w3c-wai-ua@w3.org>

Summary:

Having a reasonable clue where a link will take you is fundamental to
the Web, is required for "a minimum level of accessibility."  Yes, that
is a judgement call; there is no mechanistic failure mode to point to
as our excuse.  But there is no other reasonable position to take on
this question.

So there is a level 1 success criterion to be stated here.

In stating a level 1 criterion, the ability of the UA (which is
typically exercised already in screen readers) to transform the
presentation of links in a list-of-links view with the aid of conditional
content (including the 'title' attribute in particular) is to be allowed
for in evaluating whether the data in the format meets the success
criterion.

This second point is not quite so clear cut, but I believe that this
is the highest and best resolution of this issue to select.  It is the
best way to marry the thinking in the definition of Level 1 with the
provisions of UAAG Checkpoint 2.3.  Furthermore, this is the line
of strategy being pursued by WAI PF, HTML WG, and others in the
HTML CG about how to manage binding (and sustain an ability for
late binding) to presentation decisions across the board in XML-based
displayable formats.

And Michael, in terms of Level 1, we shouldn't required that all User
Agents do it right, or that the UAAG *require* user agents to do it
right, if the format specs clearly identify the attribute or other
supplemental info as bearing pertinent conditional content and the UA
*could* make the link clear by exposing this attribute in the
list-of-links view or *does* give the user the option of exposing
this text by an element query, the criteria of Level 1 are (as I read
the draft) satisfied.

Details inline below.
At 5:26 PM -0500 6/21/04, Gregg Vanderheiden wrote:
>Clear link text means that the text that is visible on the page needs to be
>clear - yes?

No.

The failures that this rule guards against come predominantly in the
context of a list-of-links view which all screen readers provide and
most screen readers use as their alternative to the rapid scan of the
screen that the eye can perform.

[It's not so fast as the eye, but it's a lot faster than the
page-review mode where all text is read, and in which context many
more of the links are clear, including those where the "link text" is
"click here."]

The list-of-links view is composed with rewriting rules that attempt
to take best advantage of all the "conditional content" in the link
(or associated with the link by markup and/or metadata supported by
the UA). And sometimes stuff from the other end of the link, but only
if you happen to have gone there already.

The level 1 version of this rule is that the content of the link,
including all conditional content, afford text that clearly
identifies what the user should expect to happen should the link be
activated.

Yes, at level 2 you could worry about what the default presentation
achieves in this regard. But this is not the critical use case.

>This would be a type V guidelines since it would specify how the page would
>look in its default presentation.

[discussed above]

>
>Also - is this a crucial barrier to use of the web -- or just good design. 
>
>Since I don't see this as a bar to use of the web - it would fall in level 2
>or 3.

OK, you seem to be questioning whether this is required for "a
minimum level of accessibility." Because the "even given customary UA
an AT helper functions" part is for all practical purposes satisfied.

There is a theoretical possibility that in following the UAAG
injunction to create "repair text" the User Agent could follow the
href value, analyze the resource representation thus recovered, and
synthesize a link text from that analysis. But the Web is not going
there. That is too far out of line with the general trend toward
network trip reduction in the design of Web applications.

What did the recent study in the UK have to say based on the input
from the users who participated in that study?

<quote cite=
"http://www.drc-gb.org/publicationsandreports/report.asp">

In addition, the Guidelines should place special emphasis, in the
form of elevated prioritisation, on the following matters already
covered:
*	...
*	the need clearly to identify the target of each link

</quote>

WCAG 1.0 places "clearly identify the target of each link" at
Priority 2 because it is technically feasible to follow each link,
learn where it goes, and come back and step to the next link. Of
course the Web is unusable at this rate.  That makes it P2.

What the subjects in the British study are telling us here is "Forget
the theoretical distinction between technically impossible and practically
unusable.  The thing is useless in either case."

Raising the priority attached to "clearly identify the target of each link"
relative to WCAG1 P2 would, in WCAG 2 terms, seem to require giving
it 'level 1' status.

I don't see how anyone can conceive of calling the web accessible if
you don't have a clue what the links do. The web is an interactive
activity; not just a collection of documents. If it doesn't work as
interactive browsing, which requires that link results are
predictable in the main, it's not the Web.

Now, I realize that if pressed I would rapidly agree to a statistical
success criterion for the predictability of web-link outcomes. But if
uses of the 'back' browser function get above some threshold fraction
[in the vicinity of 5% to 20%] of the number of links followed,
something is seriously wrong.

Has anyone published results on the rate of 'back' function use in
the general web user community? How frequent is too much? Ten times
the background rate? What?

Al

>Gregg
>
>  -- ------------------------------
>Gregg C Vanderheiden Ph.D.
>Professor - Ind. Engr. & BioMed Engr.
>Director - Trace R & D Center
>University of Wisconsin-Madison
>
>
>-----Original Message-----
>From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
>Of Michael Cooper
>Sent: Monday, June 21, 2004 3:35 PM
>To: WAI GL (E-mail)
>Cc: 'w3c-wai-ua@w3.org'
>Subject: [#832] Clear link text - priority and acceptability of supplement
>al text
>
>
>The requirement to make clear link text is currently a Level 3 success
>criterion
>[1]. In my opinion this should be a level 1. In discussion with the
>techniques
>task force, we thought it might be a level 3 because of the possibility to
>use
>supplemental text to clarify the link (e.g., the "title" attribute in HTML).
>But
>for that to work, we need to know that the supplemental text will be
>presented
>to the user when needed. But the UAAG [2] does not provide a single mandate
>for
>how this is to be accomplished, and further permits supplemental text to be
>presented instead of the orginal text, not just alongside. We are unsure of
>the
>implications of this for the clear link text requirement and the use of the
>"title" attribute to fulfill that requirement in HTML.
>
>I propose that the requirement for clear link text be moved to level 1.
>Specific
>mechanisms for achieving that should be left to technology-specific
>techniques,
>though it would be useful if the guidelines would comment on the role of
>features like the "title" attribute in HTML for meeting this requirement.
>This
>may require coordination with the User Agent group.
>
>[1]
>http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20040602.html#consistent-behavior-
>target-identified
>[2] http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content
>
>--- Signature ---
>
>Michael Cooper
>Accessibility Product Manager, Watchfire
>1 Hines Rd Suite 200, Kanata, ON  K2K 3C7  Canada
>Tel: +1 (613) 599-3888 x4019
>Fax: +1 (613) 599-4661
>Email: michaelc@watchfire.com
>Web: http://www.watchfire.com/
Received on Tuesday, 22 June 2004 10:19:02 GMT

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