Re: Skip links should be a markup problem

On 23 Apr, Joe Clark wrote:

>>> <[18]http://annevankesteren.nl/archives/2005/04/skip-links>
>>
>>  Oh, no. Another one.
> 
> It gets worse!
> 
> <http://annevankesteren.nl/archives/2005/04/skip-links-2>


My apologies.

I have, in the past, assumed that the wish to discuss a topic of such
dwindling importance as the "skip link" sprung from a genuine difference
in philosophy: my "let's give the user a helping hand" against "in an
ideal world the user can do this without our intervention".

Today I acknowledge that, alas, I was ... wrong. It isn't a
philosophical difference at all, but rather one of engineering.

So I shall backtrack a little, mostly for the benefit of my other
readers. I am, of course, sorry that this information must come from
someone not an "accessibility guru", but there you have it.

Let's start with the actual problem: in web documents there often appear
content which does not change noticeably from "page" to page - a typical
example is the list of hyperlinks with which the user can navigate the
site. I'll refer to this as the "navigational menu" - "menu" for short.

For a "visual" user, the brain deals efficiently with the redundancy,
and filters out those bits of the document which is not important to her
at the moment. Unless the menu change, it is an easy task to "skip" it
and get to the content.

In a linear context, however, this doesn't work. When the graphical
design elements go away, the menu is no longer
collapsed/positioned/coloured/etc as planned, but rather presented item
by item.

Users of text-only, PDA, mobile phone, speech or Braille browsers have a
hard time - they must either wade through all the links first in every
document to get the content, OR all the content to get to the menu. For
the three first groups it is "merely" annoying - for the last two it
might be a showstopper.

That's the gist of the problem - not a difficult thing to understand.
The solutions, on the other hand ...

This text will refer to what I call the "engineering" solution: the
problem is one of how to, efficiently, navigate "inside" a document. The
first thing to ask is, of course, whether any element exist by which we
can let the browser give the user options of skipping/ignoring/hiding
repetitive content.

Sadly the answer is "no". Such an element did exist - MENU - but was,
for some unfathomable reason removed from HTML[1]. It, like its cousin nl
which may, some day, exist in the non-backward compatible XHTML 2, both
suffer the same - in this context - flaw: there is no way to tell the
difference between a navigational menu and, well, a navigational menu.
More on that further on.

Could we, instead, use the good-old LINK element? Yes, and no. While an
excellent mechanism, it cannot create complex, often hierarchal,
structures.

We could, perchance, do content analysis? Even if we assume the MENU or
nl elements, we still can not tell the difference between, say, a site
menu and a table of contents - false positives in this context is rather
out; loosing important content is unacceptable.

Title[2] - the attribute that is - to the rescue. A clever author could put
a title on each - for purpose of discussion existing - MENU, and a
clever user-agent could present this information to the user with an
option to ignore or not. A nice solution, hinging on a non-existent
element.

Next we try adding the same title to an UL. After all, a menu is simply
an unordered list, yes? So, sadly, is a list of references, a list of
ingredients, a list of ... the number of alternatives presented to the
user goes from, say, three different MENU lists to a potentially LOT of
different unordered lists. Not a practical path down which to saunter.

It has been suggested that the links in the list could be studied - an
approach which, on the surface, is reasonable. However, for a user-agent
to do such analysis would require that all links be written the same -
no more "showID.cgi?id =42", in other words.

This leaves us with an already existing mechanism without the need to
employ massively heuristic algorithms: the hyperlink. Can we create an
internal link which a user can activate if she wants to move about in
the document itself? Indeed we can. Applying the engineering form of
Occam's Razor - the KISS principle - this seems reasonable. After all,
only the author can - today - determine which bit of a document is
which.

The author can also - as long as we stop suggesting otherwise - use
internal links to create shortcuts between sections which are not
programmatically determinable such as "top" and "end".

"The shortest cut makes the longest path" notwithstanding, this is the
solution I will not only use, but continue to recommend. I will also
in good conscience fail any site aspiring to WCAG 1.0[3] 'AA' not using it.


In the future a <menu-which-can-be-skipped> element might just change
all this - but that doesn't do much good *now*. On a side note I
am not holding my breath.

I must, again, apologise for my unwarranted assumptions that the
combatants had the technical know-how to grasp the situation. Mea culpa.
Hopefully this piece will highlight the various methods available today,
as well as the more fancyful ones that might become common tomorrow.

However, at this point I will - with as much respect as I myself have been
shown in the past - ask the "other side" to put up, or shut up. Show us
the algorithm, the element, or the solution which *works*, or go stuff a
sock in it.




 [1]
  The specification of HTML gives no reason *why* MENU was
  deprecated. It does make the entirely irrelevant claim that "In
  practice, a user agent will render a DIR or MENU list exactly as a UL
  list.", but says nothing more 'bout the issue save this pearl:

    "We strongly recommend using UL instead of these elements."

  I wonder, idly, whether this mean they'll also "strongly recommend"
  that the nl element be replaced by ul in XHTML 2? Save for the label
  element which is required in nl, there ain't much difference in the
  structure.

  Reading up on the list module in XHTML 2 is rather an interesting
  experience:

    "The label element is used to define a label for a list."

  Fascinating. Lower case name for both element and tag. I guess
  something is worth being said for consistency.



 [2]
  Yes, XHTML 2's nl requires a label. Replace "title" by "label" and the
  argument still stand.



 [3]
  Right now, with the WCAG 2.0 still giving off very odd vibes, the only
  thing I would like to do in regards to WCAG 2.0 is ask whether the W3C
  has decided to combat the problem of people claiming WCAG 1.0
  compliance, but failing, by making the eye of the needle for WCAG 2.0
  the size of a decent battleship. After all, if it is nearly impossible
  NOT to comply with WCAG 2.0, the incorrect claims will simply disappear.

  Highly efficient, if not entirely logical. I hope I'm wrong.


-- 
 -    Tina Holmboe                    Greytower Technologies
   tina@greytower.net                http://www.greytower.net/
   [+46] 0708 557 905

Received on Saturday, 23 April 2005 16:41:26 UTC