Skip links ARE a markup problem (was RE: Skip links should be a markup problem)

Tina Holmboe wrote:
[out of written order - This was Tina's final statement:]

> 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.

Tina, while I generally agree with what you have written, please define
"works", as I believe that there are mechanisms (an element) in place which
already "works" dependant on your user agent: the relative link.

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

This statement I agree with 100% - but overcoming the "obstacle" is the
problem.  How do we, as developers, influence the software authors to
implement existing functionality to existing standards (never mind future
wish list elements)?

> 
> 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. 
> 

Or might not.  Interestingly, the major AT solutions are emerging with
"enhanced" functionality which empower the end users to navigate poorly
structured documents.  While not optimal, tools like JAWS can bring up a
list of <h > heading elements and use them as a virtual named anchor list,
allowing the end user to go directly to any of the headings.  This assumes
of course that the document *has* proper, semantic heading authored into it.
But it "works" for those users.

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

Hmmm... Interesting Red Herring.  The discussion at hand is how to allow end
users the ability to "skip over" redundant hyperlink blocks (a.k.a. the site
navigation menu).  While further "explaining" complex hierarchal structures
is also an important need/desire, it neither adds nor subtracts from the
current discussion.  The end user simply wishes to bypass the repetitive
stuff and get to the "meat" of the individual document.  At WATS.ca, we
employ the following:

	<link rel="home" href="/" title="home" />
	<link rel="copyright" href="/policies/" />
	<link rel="bookmark" title="Page Content" href="#content" />
	<link rel="bookmark" title="Site Wide Navigation" href="#prinav" />
	<link rel="bookmark" title="Section Navigation" href="#secnav" />
	<link rel="bookmark" title="Footer" href="#footer" />

While not perfect, it does allow for a) page content navigation, and b) some
hierarchal information regarding navigation.  The biggest issue here is that
the 2 major browsers are not supporting this element to the end users.
Sadly, IE and Firefox simply bypass this code; user agents such as Mozilla
(I'm stumped here, why not Firefox too?), Opera (some limited support), and
Lynx are currently supporting them, so, to answer your question, are they
"working"?  Answer: for some, yes.

> 
> 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".

Correct.  However, the issue is/has been, should this internal navigation
link be visible or invisible, and how should it be implemented?  The
original poster is correct - it should be a markup problem - the problem is,
how do we mark it up?

Tina, I, like many, have grappled with this issue.  The solutions are
limited, and the issue is often compounded by "visual" design issues.
(In)famous hacks such as {margin-left: -3000px} and/or hiding the text link
behind a graphic have been employed, but each have their pros and cons.
Some argue (and not without merit) that the skip nav link should be visible
for all to use - again this becomes a clash between "functionality" and
"design", with no clear cut winner.  Proper support for the relative link
however, could/would solve this issue.

> 
>  [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.

Odd Vibes?  You are kind.  I am personally concerned that the adoption of
WCAG 2.0 will not happen in this decade, and that "real" support for it is
even further out.  My last reading of the document is that it is long on
theory, short on real solutions, and leaves developers even further in the
dark than the current flawed WCAG 1. (but hey, that's just my opinion).

MOVING FORWARD:

So what are we to do?  Well, for one I would like to see the W3C/WCAG do a
couple of quick fix things to the "existing" documents/standards.  

#1 on my list would be to modify the DTD to include the specifically named
relative links of "navigation" and "content"; adding them to the existing
list (http://www.w3.org/TR/1998/REC-html40-19980424/types.html#h-6.12)  

While individual authors can hack a DTD to include them ("Authors may wish
to define additional link types not described in this specification. If they
do so, they should use a profile to cite the conventions used to define the
link types. Please see the profile attribute of the HEAD element for more
details"), this is neither practical nor realistically functional.  

However, if the W3C made these 2 minor changes to the DTD, and it reached
the media with sufficient "noise", then we could assume that the message
would go out to developers: start using these relative links.

I further suspect that the browser authors would/could quickly adopt these
new element attributes (if the media noise was loud enough) into their
tools: Opera already supports some relative links, Firefox should and
probably would in about a week's time if it were "announced", given that
Mozilla currently does support them and the open source nature of the
browser, and, well apparently Microsoft are "listening" to the community as
they work on IE 7, so it's not outside the realm of possibility that IE 7
could support them too.

#2 is put WCAG 2 aside for 6 months and fix WCAG 1 (WCAG 1.5?)  Nuke some of
those annoying "Until user agents" statements, (and a personal bugaboo -
kill the Accesskey requirement, but I digress), and finally re-write the
guideline to specifically insist on the use of the relative link - take your
pick which one you want to re-jig:

	13.2 Provide metadata to add semantic information to pages and
sites. (probably not, <link rel is really not metadata, although it is
stored in the <head>)

	13.3 Provide information about the general layout of a site (e.g., a
site map or table of contents). (good candidate here)

	13.4 Use navigation mechanisms in a consistent manner. (supports the
requirement)

	11.1 Use W3C technologies when they are available and appropriate
for a task and use the latest versions when supported. (also supports the
requirement)

#3 Mount a serious "developer" campaign to have authors start using these
elements right away.  Let's take a page from the Firefox book, or WaSP, or
whatever.  Get slashdot on board, Zeldman too, and all those other
'gurus'... Roll this out seriously and it solves the issue relatively
quickly.

Ah... But it's Sunday morning, I must still be dreaming...

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   
Phone: 1-613-267-1983 / 1-866-932-4878 (North America)

Received on Tuesday, 26 April 2005 15:46:40 UTC