Most things have a shelf life and technology on the web is no different. Tricks and hacks that once seemed to save the day sometimes need to be retired as newer technologies or techniques get implemented.
I can think of plenty of accessibility solutions that have found their way into the archives such as using an asterisk (*) for a bullet image, text versions of websites and verbose title text around links – to mention just a few.
So what about the skip link? Firstly Gez Lemon describes Skip links as follows:
Skip links are links to another part of the page that allow visitors to navigate their way around a web document, without having to cycle through a huge list of links.
On todays web skip links are a good thing. They’ve played their part in improving the usability of the web for users with disabilities and mobile devices. Screen readers, voice input software, keyboard only users and those browsing on mobile devices all benefit.
Skip links are becoming increasingly mainstream despite them not being an explicit requirement of WCAG 1.0, the defacto standard up until December 2008. Much of what was implied in WCAG 1.0 however has become explicit in 2.0 and the skip link finds itself as a sufficient technique in for Success Criteria 2.4.1: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages securing itself a place in Level A no less.
So why am I suggesting – given the skip link’s new found status – that they may have a shelf life? Well here goes…
Document structure
Having a well constructed document that marks up headings, paragraphs and lists, and has well written and grouped links already goes a long way to supporting the user orientate and navigate within a page.
Access technologies such as voice input and screen readers hook into these so that users can use keyboard commands to jump from heading to heading, paragraph to paragraph and so on. Having these in place means users are not forced to tab laboriously through numerous page elements but instead ”scan” a page in much the same way a sighted user can.
Shift F7 lists headings for a Jaws screen reader users that can be navigated using the arrow and enter keys.
Of course this is nothing new. There has always been a question mark over the need for skip links when your documents are well constructed but what has changed is that there is a larger critical mass of websites now following web standards than before – ever the optimist – be it through a desire to be accessible, searchable or findable.
HTML5 elements
HTML5 introduces new elements designed, in part, to replace the divs in HTML4. These include header, nav, section, article, aside, and footer. This immediately gives pages a structure by identifying content areas within a page.
Image courtesy of A List Apart - An introduction to HTML 5 by Lachlan Hunt
The idea is that a screen reader can inform the user of where they are in the page as well as provide a means for the user to jump to sections, much like you can jump between headings with a screen reader. For example I might want to read each blog post on the home page of this blog by jumping from section to section then jump to an aside to browse through the categories or recommended links.
This doesn’t mean that heading levels (h1 to h6) become redundant but rather they are now presented within related container blocks. Using the new elements may well also impact how you structure your headings and put to rest ongoing debates about repeated h1′s in a page and using the website name as the h1.
What will be particularly useful on complex, content heavy sites is that you wont need hacks such as hidden headings for content that is otherwise visually obvious. For example many sites will code a hidden heading at the top of sub navigation, such as “Sub-navigation”, in order to orientate a screen reader user.
Another example of “too much accessibility thank you very much” is when developers get a little over eager with skip links and add in what seems like a whole new set of navigation such as “Skip to main content”, “Skip to sub navigation”, “Skip to search”, “Skip to footer” and so on.
You really don’t need more than “Skip to main content” and possibly “Skip to sub-navigation”. A “Skip to search link” is especially redundant as users can do a search for it by looking for the text “search” or using keyboard shortcuts. Adding these new HTML5 elements should remove the temptation to overdo skip links which can add to the complexity of site navigation as well as reduce the number of headings used in a page.
You can start using these new HTML5 elements now in your markup as most browsers are able to handle them however what level of support is being built into screen readers for new elements and attributes in HTML5 is hazy. The vendors are not participating in the HTML5 Working group despite repeated invitations from the web developer community. That said, while the specification wont be finished until 2022 you can start using HTML5 now.
WAI-ARIA landmark roles
Just as HTML5 introduces section elements so WAI-ARIA introduces landmark roles. Landmark roles allow screen reader users to orientate themselves in a page by informing them if they are in the article, banner, complementary, contentinfo, navigation, main or search. You can read more about this in Gez Lemon’s excellent article Introducing WAI-ARIA.
Landmark roles are intended to allow screen reader users to orientate and navigate around the page thereby doing away with the need for skip links. Questions have been asked about how adding both landmark roles and HTML5 section elements may work together with Steve Faulkner recommending that landmark roles be used now and removed once support for HTML5 becomes more robust.
The new sectioning elements in HTML5 have some overlap with ARIA landmark roles, but in a majority of of cases there is no equivalent for the ARIA landmark roles in HTML5. It is suggested that where there is a similarity the ARIA roles can be used to provide semantic identification that has a practical use now, for example if you want to use the HTML5 nav element, add role="navigation" to it, so supporting Assistive Technology (AT) can convey the semantic information to users. When HTML5 elements such as nav are supported by AT, you can then remove the role as it will no longer be required.
Current support for WAI-ARIA is shaping up with all browsers working on it as well as the main screen reader vendors. The specification is also likely to be completed 2009 and is becoming more and more mainstream.
Browsers
Browsers are getting better and better at helping users access content. The Web Accessibility Initiative publishes guidance not just for content in the form of Web Content Accessibility Guidelines (WCAG) but also user agent developers in the from of the User Agent Accessibility Guidelines (UAAG). The relationship between UAAG and WCAG means that browser should offer options to help users navigate around the page via the browser and not just the content.
Opera – where I work – provide spatial navigation and single key shortcuts. Spatial navigation allows you to use your Shift + arrow keys to go up, down, left or right within a page which gives much more flexibility than tabbing in a page in a linear fashion which is the main barrier that skip links address. Single key shortcuts allow you to jump between headings, links, page elements as well as customise your shortcuts. Again allowing the user quick access to content areas within a page.
Opera Mobile and Mini also offer spatial navigation to make browsing easier. This is a huge improvement on the WAP style pages where you’re forced to navigate through the page linearly. In addition to this every numeric key (0-9) has a pre-programmed function that you can customise. Within this context skip links seem less necessary however they do still have a huge benefit on WAP style pages.
Knowing enhancements such as spatial navigation and single key shortcuts are available in desktop and mobile browsers decreases the need for skip links however this does assume that all users know how to use their browser and many do not. While that is not your problem as a developer it equally can’t be ignored and I don’t think can be considered a full alternative just yet.
That aside it would be interesting to review the browsers and versions that you support and see what the baseline of navigational aids there are in the browsers and assess whether skip links are indeed necessary.
So is that it for skip links?
No, not yet. If you have skip links there’s no reason to remove them. Adding enhancements are never a bad thing and skip links are unobtrusive when implemented properly. It is however worth reviewing your content to ensure you have a logical document structure that can be read by access technology: good headings, lists, well worded links and so on. My personal take is that on a simple site such as this blog this is sufficient, on a more complex site you still may want to implement skip links. Opinion however, will always be divided so you need to think what suits your site best.
Adding in WAI-ARIA landmark roles and HTML5 can do no harm at this point but can’t be relied on in full. Apart from anything else – browser and access technology support – there is a learning curve with any new technology on the web that the user has to go through. We can’t assume that screen reader users will immediately be familiar with the benefits that HTML5 and WAI-ARIA bring, as with navigating Flash when it became more accessible users had to become comfortable with it.
So has the skip link passed it’s best before date? No. Does it have a shelf life? Yes, I think it does. Keep your document structure logical and gradually implement WAI-ARIA and HTML5 and you may just find skip links become redundant.
