RE: Skip links should be a markup problem

Tina,

Good summary of the problem, and since you mention XHTML 2 may I just throw
in that the next draft has the new @role attribute for exactly the purpose
you describe.

The idea is that different interest groups will define different values for
@role that will be commonly agreed on. In addition, 'out-of-the-box', XHTML
2 will come with 4 or 5, sufficient to identify the main content, headers,
footers, and so on.

For example:

  <body>
    <section role="navigation">
      <nl>
        ...
      </nl>
    </section>

    <section role="search">
      <!-- search form -->
    </section>

    <section role="main">
      <nl>
        <!-- list of radio programmes -->
      </nl>
    </section>

    <section role="contentinfo">
      <p>Produced by Acme, 2005</p>
      <p>Creative Commons 2.0</p>
    </section>
  </body>

As you can see, you now have the ability not just to 'skip links' to get to
the main content, but an accessible browser could take a user directly to
the 'search this site' section, or to the licensing information. It will
hopefully also have benefit for mobile devices that could simply render the
main content, but still provide access to the other 'sections' via menus.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

> -----Original Message-----
> From: w3c-wai-ig-request@w3.org 
> [mailto:w3c-wai-ig-request@w3.org] On Behalf Of Tina Holmboe
> Sent: 23 April 2005 17:41
> To: w3c-wai-ig@w3.org
> Subject: 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 Sunday, 24 April 2005 09:47:34 UTC