WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: skip to content, where and how many?

for

From: jukka.korpela@tieke.fi
Date: Mar 3, 2002 11:58PM


Jim Thatcher wrote:

> It is perfectly logical to have an empty anchor specifying
> a position in a page to which a link can jump.

This depends on the interpretation of the detailed semantics of <a name>,
which was never very clear. Does it set up a potential destination for
links as a location or as part of a document consisting of the content of
the <a name> element? If it had been intended to be a location, or
position, only, why allow any content? Conversely, if it was intended to
let the author specify part of a document, why restrict the content to text
level?

In the development of HTML as XHTML, the <a name> construct has been
deprecated in favor of using the id attribute. At present, we should of
course still keep using <a name> for quite some time (in conjunction with
id, if desired). But the trend is clear: an anchor destination is an
element, which corresponds to _part_ of a document, not a point-like
_location_. And in the future, the use of id will let us specify any
(continuous) part of a document to be what we really "point to" with a
link.
This would, for example, let user agents read just that part when a link
has been followed (naturally with some option of proceeding after that).

The problem with <a name> is that it may contain text and inline markup
only, whereas id can be attached to virtually any element. Thus, if the
destination is to be a table, logically, then there's no really natural way
the specify the destination using <a name> (whereas with id it would be
trivial). With a structural table, presenting tabular data, the problem can
usually be solved using <caption><a name="...">...</a></caption>. With a
layout table, the best workaround is probably to put <a name> into the
first cell of the table.

> When you require that the anchor enclose text
> of the content, then it has to be coded for every page
> and is not part of the template.

Right; so authoring tools need to be selected, tuned, or modified to take
this into account. After all, they should produce what we (as authors and
users) need, instead of dictating what we do.

> There is no "implementation" of a Local target for a link
> beyond being a position in the document.

It is up to the user agent. To take a simple example, one could write a
user style sheet to make <a name> elements appear differently from anything
else, perhaps just to see what possible link targets there are on other
people's pages. Actually, I have seen browsers that do so by default, but I
haven't written down which they were. It is certainly _possible_ ja
permissible.

The most useful thing, for normal users, would probably be to indicate, in
some manner, the target we have "jumped" into, when we have followed a
link. Speech based presentation assumably just starts reading from there
on, but in visual presentation, a clue would be useful, and perhaps very
relevant to some people (e.g., people with cognitive disabilities). Graphic
browsers generally position the presentation so that the target is at the
very top of the window. This means you lose the information if you scroll
upwards, and it usually doen't work at all near the end of a document

To my positive surprise, Netscape 6 seems to do _something_ like that. When
an accesskey is used to move to a destination, using the same accesskey
again highlights the anchor, i.e. the content of <a name>. Specifically, it
uses red color. - It needs to be remembered that accesskeys are important
to other than blind users too, e.g. people who cannot use a mouse.

--
Jukka K. Korpela, erityisasiantuntija / senior adviser
TIEKE Tietoyhteiskunnan kehitt