Link Relationships as an Alternative to AccesskeysPosted: December 07, 2003
We like the concept of accesskeys providing quick keystroke access to various parts of a particular site. However, we also believe that given their standardization and implementation problems, we need a more robust method for providing the functionality.
Link Relationships as an Alternative to Accesskeys
Many sites use Accesskeys as a means to quickly access certain navigational items in their documents. The implementation of Accesskeys however, seems to be fraught with implementation problems, despite the fact that many developers are attempting to provide a standardized "map" for the accesskeys on a site.
We've questioned whether or not implementing accesskeys is worth it, and discussed some of the pitfalls of working with accesskeys before, and indeed there are very few keystroke combinations that are available for use. Despite the fact that we agree that Accesskey functionality is useful, we still think there should be an alternative to accesskeys that could provide the same functionality of accesskeys but without the "standardization" problems, and with little to no conflict in the implementation.
This functionality already exists via the underused link element.
Many of these commonly accessed items are predefined as valid link relationship types. So why not expand on those relationships to include oft used accesskey relationships? Then we could all embed the data in the head of our documents:
<link rel="home" href="/" title="home" />
<link rel="copyright" href="/policies/" />
<link rel="search" title="Site Search" href="/search/" />
<link rel="contact" title="Contact Us" href="/contact/" />
<link rel="accessibility" title="Accessibility Statement" href="/accessibility/" />
Now that the relationship and the target is defined, we move to implementation.
Allowing Keystroke access to Link Relationships
An ongoing problem with accesskey implementation is avoiding conflict with other pre-defined keystrokes. Rather than allowing the user agent to predetermine the method by which accesskeys are invoked (Alt + _ in PC Internet Explorer, Netscape, Mozilla, Ctrl/Cmd + _ in Mac IE/Netscape/Mozilla, Shift + Esc + _ in PC and Mac Opera) perhaps we should take a page from many pieces of adaptive technology and allow the keystroke combination to be customized by the end user.
Instead of defining the key to be used itself we have defined the target. Now all we need is to allow for the end user to choose how they wish to define the keystrokes.
This eliminates problems with accesskeys being defined differently across sites all over the World Wide Web. I would love for the ability to always make Ctrl + Shift + H take me to the home page of the site I am on, Ctrl + Shift + S to take me to search for that site, and for Ctrl + Shift + C to take me to the contact page/form.
As users, we could all get our own way, and we don't have to learn how to have keystroke access to everyone's site, we just learn how to do it within our preferred "smart" user agent. As developers, we could work to define relationships and targets rather than keystrokes that may or may not conflict with keystrokes already defined within a user agent or other piece of technology.
This would appear to be consistent with various components of the User Agent Accessibility Guidelines in terms of providing user definable keystroke access to various user agent functions.