Accessibility guru Joe Clark pointed to my article about skip links on the public W3C WAI mailing list. Surprise, someone responded.
The first thing that interested me about WCAG 2.0 was that it was supposed to be more general and abstract (see the requirements document; just a working draft) and therefore also more forward compatible. I thought WCAG was supposed to be defined in such a way that it applied to many use cases that exist today and could exist in the future. The examples would of course mostly be about HTML and such, but not the guidelines.
So when a new language introduced elements that might obsolete the need for a particular feature that is stated in the specification the specification would still apply but perhaps in a different matter. Less abstract that would mean that authors don’t have to include a skip link just to be conforming to the latest specification available albeit a bit outdated and no longer making sense. So when XHTML2 is going to be used in some environment and WCAG2 conformance is requested authors don’t have to include frigging skip links as XHTML2 provides a navigation element. They may do that of course, but it is no longer strictly necessary.
Same for HTML5. (What is HTML5?)
(To the author of the e-mail: I was talking about the NL element. I just mentioned its name. I was not talking about its tags and the case-sensitivity of those tags.)
Furthermore, a list of links that are used today in HTML can be easily discovered by devices and can pretty accurately being identified as a navigation list. Assistive devices are supposed to be smart and applicable to the current web; they are supposed to help users. I think it is fairly trivial to implement something useful for lists of links. A device could check for each list it encounters if the list items consist of a single link, which is the list item’s only child apart from some possible white space. After that the device could check the actual links (value of the HREF attribute, you know) resolve them and compare them to the base URI. “Hé, that’s funny. They all point to the same domain. Must be some kind of navigation list, don’t you think?”
Now ask yourself the following question: How did the device find that out?
I’ll spoil it for you: Through markup!
Markup is exactly the kind of thing devices rely on. And although it is not exactly explicit, assistive devices can get pretty far with the markup that is already there, today.
That does not imply that the recommendation of including a ‘ship to navigation’ is horse shit, it implies that the specification should not be so specific and focus more on things that might affect those recommendations in the future.
I can't agree more.
I also agree but I think that its not the whole answer. When I do the information architecture and visual design I always end up with several different navigation groups. I have my primary navigation, that contains my major content sections, my secondayr navigation, which link to minor content sections, header and footer navigation that link to specific features/pages, the breadcrumb trail and the contextual navigation.
Simply identifying which elements contain navigation doesn't convey all the necessary information. As a sighted user, you'll use the visual prominence and position to establish the relative importance of the differnet navigation groups. The layout of each of the navigation types also conveys a lot of information and you don't have to read the navigation elements to establish this fact.
An unsighted user will have no such frame of reference. They only have the read text of the navigation with which to build a frame of reference and that takes a long time.
While I agree that we shouldn't have to pollute our content with unnecessary markup, I think that metadata, such as which things are navigation, and what kind of navigation it is, is just as important as making it a horizontal list with blue and green buttons.
But I don't think that we need to things the hardway. If we look at the W3 Recommendations, I think that a great solution might be something like:
<head profile="http://www.example.com/profiles.html"> <link rel="wcag:navigation primary" href="#xpointer(//ul[string-contains(@class, 'pnav')])" title="Primary Navigation" /> <link rel="wcag:navigation secondary" href="#xpointer(//ul[string-contains(@class, 'snav')])" title="Secondary Navigation" /> ... </head>
I've probably done this wrong but I think you get the general idea. This way we provide all the necessary information and we also keep our content "pure".
Markup should help us but I don't think its reasonable for us to expect a piece of software to figure out what we meant. Its not a lot of effort (assuming I could find a browser that parsed profiles, understood what wcag:navigation means, did something useful with links and understood xpointer) to explicitly tell a browser what to expect and where to find it.
Yeah, completely agree. My solution is more simple: Why don't smart devices just detect classes/id's of "header", "navigation", "menu" and the like and provide the user with a UI to skip these elements.
Skip links always seemed like a hackish solution to me.