Skip Links revisited
I believe everybody knows what skip links are and what they are used for. If you don’t, you can check this article that does a recap and explains a short coming associated to the most common technique.
In short, skip links are meant to address section 2.4.1 of the Web Content Accessibility Guidelines (WCAG), which says:
Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)
Using Programmatic Focus to Bypass Blocks of Content
Rather than adding stops (skip links) before blocks of content I thought that we could let users tab from one block to another while allowing them to navigate inside those blocks via arrow keys.
The idea hit me during the dry-run of a talk Todd Kloots (@todd) prepared for CSUN (Building Accessible User Interfaces Using JavaScript and ARIA).
Todd’s demo shows a toolbar containing many buttons. It demonstrates the use of tabindex to place or remove links from the tabbing sequence.
Even though the demo page is a simple document containing nothing else than a toolbar, it shows the potential of the basic idea. "Scaling" that up could save a lot of keystrokes, without adding any extra link or button (i.e. skip links) to the document.
Imagine this as navigating through widgets. A pattern that is described by both the ARIA spec and the ARIA Authoring Practices specs.
Proof of concept
Check the demo page
I am using a default bootstrap template containing many links to demonstrate the general idea. Which is to allow keyboard users to jump from one block to another via the tab key and then navigate inside those block via the left and right arrow keys.
The first element in the page is a button that activates the script. What the script does is that it parses all blocks that have been (arbitrary) flagged by the author of the document:
- all links in each block (but the first one) are removed from the tab flow via negative
tabindex. - each time keyboard users reach a block by tabbing to it, they stop on the very first link inside that block; at which point some styling gives them a visual cue about the boundaries of that block.
- from there, they can either tab to the next block or navigate inside the block they are within via the left/right arrow keys.
- each time they reach the first or last link inside a block the visual cue is triggered again, letting users know they have reached the boundaries of the block they are in.
Yes, I hear you saying "Visual cue? Hu!? Screen-reader (SR) users cannot care less for that visual cue". Fair enough, but SR users are not the only ones who navigate via keyboard. Actually, when it comes to keyboard navigation, UAs like Jaws provide keyboard shortcuts that most sighted users have no access to. So please consider that "visual cue" as progressive enhancement rather than an integral part of this solution.
For a better implementation
I think there is plenty of room for improvement:
- Opt-out
- The script is triggered as soon as the user clicks on the button, but it would be better to have a yes/no option in the modal itself; so we don’t force the script upon the user.
- Cookie
- The demo is a standalone page, but obviously the script should apply across all pages within the site, for the entire session.
- Common shortcuts
- I chose the left/right arrow keys as a mean to navigate inside the blocks, but one could go with any key (i.e. Google’s J and K keys). Even though the best would be to offer users to pick their own shortcuts at the time the modal pops up.
- Hybrid users
-
For users who navigate via both a pointing device and the keyboard, we could easily eliminate the block styling or even the button itself:
body:hover .keyboardSection {-webkit-animation:none;}.
Make sure to add-moz-,-o-, and-ms-if you want to avoid the prefix-police.body:hover #keyboard {display:none;}
The demo page is really a proof of concept. I didn’t do any serious testing in regard to nested lists nor to other focus-able elements (i.e form controls) on the page. Unless the script is tweaked to address elements other than links, then those should grab focus and prevent the user from skipping blocks (which could be confusing).
Special thanks to @todd for revising this article and giving me some great info.
Please join the discussion.
