named anchors revisited

Named anchors are an HTML capability that can help with
orientation and navigation for the audio visitor.

This navigation feature - providing fine-grain distinguished
destinations where one can start reading at different points in a
web page - has come up in two contexts already: 1) skipping
obstructing navbars and 2) moving to a navbar when desired.
Let's step back and try to take a more systematic view of this
page structuring resource.

There is already a pretty good understanding of a guideline which
goes something like "If the opening contains more than five
navigation links before getting to the meat of the page, there
should be a convenient way to get past the navigation links to
the meat of the page."  An internal hot link provides one way to
achieve this bypass function.

There is also some recognition that when both page head and foot
are full of navigation links, it is hard to locate the meat of
the page by a "step through clickables" tabbing approacy.

Tabbing through the clickables appears to be the dominant browse
strategy of audio visitors.  Direct navigation within the class
of clickables [tab stops] has proven highly effective in field
use in Lynx.  The colloquial term for this feature is the "123g"
command.  It would seem appropriate to build on what works by
adding names to selected clickables and add tab stops for major
page modules or subdivisions.  This adds orientation signposts
that complement and work with this mode of navigation.

Rough concept of author technique:

Make sure that for each major functional subdivision of your page
[what would have been a frame if you framed the site] there is a
named anchor located at a good place for one to start reading
that section of the page.  Be aware that the chunks in which the
user perceives the content in audio are considerably smaller than
for visual presentation.  For this reason the navigation and
orientation grid needs to dissect the internal structure of a
page as well as teach the inter-page structure of a site.

Detail note: Earlier I suggested that there be a convention
promoted of using a "start-reading" name for one strategic point
where the meat of the page starts in the textual order in the
HTML.  I would be glad to relax this to allow the author to use
names that correspond to the site structure.  If the site has a
"headlines" overivew page, let the author mark "headline" of each
page with a named anchor to define the destination
<url-prefix/page.html#headline>.  Likewise, if the site has a
"related links" page in the site structure then the anchor name
for the first link in the navigation block in the footer could be
"related" or "related-links".  But one level of start points
finer than the page should be defined.  Two rules of thumb for
how many there should be would be a minimum of three to five per
page and one per five to ten destinations if there are a lot of
links off the page.

Rough concept of user agent technique:

Allow the user to learn what sub-destinations exist in a page
amenable to direct navigation.  If direct navigation to tab stops
is supported, expose named anchors as well in response to this
query and accentuate destinations that are both named and
clickable.

Argument for pursuing this strategy:

I believe that the prognosis for how much of the web we can
render usable is better with named anchors than with Hn header
structures.  This is not to say that Hns should not be used where
there are headlines; but that there are many blocks that will be
designed into pages without headlines to match.  The navigation
bar at the foot is an example.  It is visually so clear what it
is that it won't be give an set-off title after the fashion of an
H2.  But it needs to be its own direct-navigation destination and
creating that will not detract from the visual design of the
page.

I realize that relying on named anchors violates the
meta-guideline which says "if it doesn't show, the authors won't
do it."  [That is one way of interpreting the poor uptake of the
LINK element.]  This technique lends itself to propagation by
templates and author-tool fragment pre-forms.  So there is some
hope it would get used reasonably widely, even if only a minority
of the people using it understand it.

Received on Monday, 16 November 1998 09:14:43 UTC