RE: Techniques revision - Meaningful link names

May I provide an alternative to the views expressed in Kynn Bartlett's
message regarding link text. Poor link text does not only affect JAWS
users who may choose to view a list of links out of context, but also
those with cognitive disabilities and all surfers. Studies by Jakob
Nielsen and others show most people only 'scan' pages and do not read
them literally. An important aspect of scanning is looking for the very
visible hyperlinks. Linked text should provide some context without the
surrounding text.

On the other hand, structured markup is invisible to non-JAWS users and
provides little benefit unless the surrounding elements are also
organized in a logical, hierarchal fashion that supports visible
scanning of headings. I've also seen instances of UL and DL used for
layout purposes that are confusing when read with a screen reader
because the information does not represent a list.

Chris Brainerd

Instructional Designer

Real Choices ACCESS

Center on Disability Studies

University of Hawaii

Chris.brainerd@cds.hawaii.edu

808-956-9356



-----Original Message-----
From: Kynn Bartlett [mailto:kynn@idyllmtn.com] 
Sent: Wednesday, August 06, 2003 11:29 AM
To: David MacDonald
Cc: 'Ben Caldwell'; michaelc@watchfire.com; w3c-wai-gl@w3.org
Subject: Re: Techniques revision - Meaningful link names




On Wednesday, August 6, 2003, at 10:58 AM, David MacDonald wrote:
> So I recommend that we not justify any use ambiguous link names.

Kibitzing:

Such a requirement basically says that all links must make sense when
taken out of context -- this is a bad thing if we are also emphasizing
the importance of structure in documents.  If we say that document
structure is important and you must use it, and then we say that ALSO
the page must be usable WITHOUT structure, we are asking an awful lot.

Something like this:

      <section>
        <h>Teach Yourself CSS in 24 Hours</h>
        <p>Blah blah blah</p>
        <p><a href="http://amazon.example.com/blahblah">Buy it!</a></p>
      </section>

...is not ambiguous.  From context, it makes perfect sense what is being
presented here.  Likewise:

      <dl>
        <dt>Kynn Bartlett</dt>
        <dd><a href="mailto:kynn@idyllmtn.com">Email</a>,
            <a href="http://kynn.com/">Website</a></dd>
        <dt>David MacDonald</dt>
        <dd><a href="mailto:befree@magma.ca">Email</a>
      </dl>

...is not ambiguous either.  In both cases, the context provides meaning
to the link.  Removing the context -- as assistive technologies have
been doing -- is not a proper solution for accessibility's sake.  In
fact, it is a practice which is harmful to accessibility.

Constructing an outline based on headings is a good thing.  Constructing
such an outline and then adding links in is also a good thing.  Even
providing a straight list of links is reasonable, although not 
particularly
useful since context is removed.  However, Web developers should not be
required to support this third option -- a flat list of links titles 
--
because that is not how markup is meant to function.

Sometimes, context can be removed.  Other times it cannot.  The heading
tags (<h1> ... <h6> or <h>) are designed to be able to abstract document
structure in such a manner.  The <a> tag is most definitely not built
this way, at least when it comes to href links.  (A list of ANCHORS,
formed with <a name>, on the other hand, is a good idea -- and such
anchors should probably have title attributes attached.  Sadly, though,
this is not currently supported by user agents, is it?)

I caution you to very seriously reconsider the notion of requiring pages
to "make sense" with vital context -- including accessibility elements
and attributes -- removed from the presentation (as with lists of
links).  Such a practice is ultimately harmful to the cause of
accessibility because (a) it can result in poor UI design, (b) it can
result in rejection of accessibility by informed Web developers,
(c) it encourages a practice which goes against the idea of structured
markup, and (d) it does not encourage the assistive technology vendors
to improve their abilities to generate document abstracts.

--Kynn

--
Kynn Bartlett <kynn@idyllmtn.com>                     http://kynn.com
Chief Technologist, Idyll Mountain                http://idyllmtn.com
Author, CSS in 24 Hours                       http://cssin24hours.com
Inland Anti-Empire Blog                      http://blog.kynn.com/iae
Shock & Awe Blog                           http://blog.kynn.com/shock

Received on Thursday, 7 August 2003 23:36:22 UTC