Giving the user control over accesskeys
One of the major drawbacks to the well-intentioned idea of accesskeys is that they can conflict with shortcut keys used by web browsers or operating systems. Whether the specification or browser makers are to blame for that is another story, partly discussed in Accesskey problems remain in XHTML 2.
The normal way for a website to define a shortcut key is to use the accesskey attribute on an element that may have such an attribute, specifying a character that becomes the shortcut key in combination with one or more other keys as implemented by the browser (typically Alt in Windows and Ctrl in Mac OS X).
That doesn’t leave the user with any way to change the accesskeys defined by a website. Well, now there are at least two ways that web developers can offer that possibility.
Gez Lemon and Rich Pedley have created a PHP class (an ASP version is also available) that can be used to let users define their own accesskeys. The PHP code is described and demonstrated in User-Defined Access Keys.
If you don’t like the idea of using a server-side script to make accesskeys user editable, Jacques Distler describes a JavaScript-based method in Editable Accesskeys.
Not long after that, Gez responded by creating a Greasemonkey User Script to Manage Access Keys.
Both methods have their pros and cons, so I’m not going to say one is better than the other. If you want to offer your visitors the ability to define their own accesskeys, read up on both of these methods and then decide which is most suitable for your needs.
- Previous post: Tagged, so here are four things
- Next post: Five ways of improving your website
Search and sponsorship
Job opportunities
Job openings from Authentic Jobs
Looking for web hosting?
Use the promo code 456BEREASTREET3 to save USD 20 when you sign up for DreamHost
Comments
Maybe I'm missing something, but I'm not sure how many users that are interested in defining their own accesskeys, let alone even know what they are.
The only situation I can imagine is when an end user is using that web site daily...
I hate access keys that aren't obviously enabled. I type a lot of emacs-like control characters to edit in a textarea on Safari (especially control-A and control-E for beginning and end of line), and when someone has stolen that without telling me, I start triggering things accidentally.
So please, if you're going to use access keys, make sure that your textareas clearly have some warning, and possibly some way to turn that off.
I can't follow the negative route of my 2 pre-posters. I think that this is, server- or client-side, a good idea. It offers the possibility to use them, if you don't like it, don't use it. A step further down the accessibility route. What's not to like?
Of course not every website is made for this, but there's enough sites that are checked daily by people who'd be happy to have more control over it; be it for research, news, or maybe only tv listings.
Robert,
Try surfing, for a week, with Gez's Greasemonkey script enabled. I predict that
1) You'll start using accesskeys more (even on sites that you don't regularly visit), once you can see, at a glance, that they're there.
2) Since it takes only a keystroke to customize them, you'll start "standardizing" on a common set of accesskeys for similar functions ("Search", say) as you move between sites.
Of course, the main target audience is still people who need to use keyboard navigation.
Basically, the idea of accesskeys is good. There are some drawbacks, however, some of which Roger, Jacques and Randall already addressed:
1) There is no overview (that I'm aware of) of those keyboard shortcuts that are already in use by operating systems, background OS applications or browsers. Some of these shortcuts can cause a conflict with accesskeys, if you don't check your definitions well enough.
2) There is no universal acknowledged base of accesskeys. If we'd agree on several, standardized keys (e.g. for 'home', 'top of page', 'previous page in article' or 'next page in article'), usability would greatly improve.
3) Different browsers ask for different keystroke combinations. Some require ctrl-alt-{accesskey}, others command-alt-{accesskey} or maybe even ctrl-alt-shift-{accesskey}. If there is no cross-platform, cross-browser standard, people will not get used to accesskeys if they're using different equipment in their lives (i.e. IE at their workplace, Firefox at home, or even Mac-Linux-Windows combinations).
4) As Jacques noted, the presence of accesskeys is not always obvious. There is something to be gained there as well.
I think these issues prevent accesskeys from being as useful as they could be, which is a pity really.
Jacques,
You might be right. However, for me, using a number of different computers, doing consultant work on a computer the customer provide etc, I don't always have the possibility nor time to make necessary adjustments on each and every one of them; hence that's why I look more and more for web-based services.
But for people who need it, I have no doubt it's a good thing. And I also think Jeroen is on to something: not many people know about accesskeys and there's also a huge need for a universal acknowledged base of accesskeys.
In the end, I love keyboard shortcuts, so I'm on your side! :-)
Acceskeys are only useful if they're used consistently across all sites on the internet. Not gonna happen.
The ability to do any kind of customization is kinda lost if you spend a lot of your time on someone else's computer.
That applies to lots of things, not just accesskeys.
As an aside, one of the amusements the scripts that Gez and I wrote is how they work together. Install Gez's Greasemonkey script, and surf around for a while, hitting a few sites with accesskeys.
Then visit my site, or the String Coffee Table. Different, huh?
I installed that greasemonkey script. Then I happened to visit some bug in bugzilla, which I didn't realise had so many access keys defined. Well, the UI presented by that script was awful. It gave me a huge yellow box with a whole heap of text. The access keys were highlighted in bold and each was followed by all of the values from the from control (this was exceptionally bad for select boxes).
Needless to say, I removed it straight away and I have since discovered a way to disable access keys completely in Firefox. Set the pref ui.key.generalAccessKey to 0 and access keys will no longer be a problem.
Firstly, thank you for mentioning the scripts, Roger.
Lachlan, thank you for at least trying the Greasemonkey script. I visit Bugzilla quite a lot, and have encountered the problem of the definitions taking up the whole screen. It is irritating, but can be removed quickly with 'Shift'+'Esc', or excluded completely for websites that don't play nicely by adding the URL to the "Exclude Pages" option of Greasemonkey.
The problem with Bugzilla is with the markup, as they have decided that the prompt for any control is its content, rather than its logical prompt. For example, they markup the product drop-down list inside a label element, with its logical prompt marked up in a td, and no way of programmatically determining that the content of the td is in fact the label rather than the contents of the drop-down list. This is in no way helpful for people using assistive technologies, and people using assistive technologies will come across the same problem as you. The only irritant to you is that a script obscured your view of a web page, which you were quickly able to disable. People reliant on assistive technology are not afforded the same luxury, and problems like this go unnoticed. Any accessibility feature is only useful if it has been marked up correctly, and Bugzilla's abuse of the label element isn't useful to anyone, yet alone people who do benefit from labels being marked up correctly. This isn't even a problem with accesskeys; it's a generic problem for people using assistive technology on forms that have been marked up incorrectly. Without the Greasemonkey script, the chances are you would never have noticed this, but it remains to be a problem for those using assistive technology.
Access keys is good to add to form type pages. The mobile profile XHTML has a tag for it.
Given how little UI consideration goes into most websites and applications it is dangerous ground though.
And browser hotkeys also depend on language!
While script definitions for access keys could be useful for many users, I can see them causing problems for disabled users, as turning the script on or off can be an extra step or an extra instruction to find. I personally prefer to keep scripting to an absolute minimum.
In NZ, the access keys for government websites is defined by the governmental agency that oversees internet communications (www.e.govt.nz) for all government agencies, and this is gradually been adopted by private social agencies also. The private sector is slow on the uptake, unfortunately.
I suspect that the accesskey mechanism is an example of a poorly designed standard.
Why is there even any need to actually declare what the keystroke value is?
Perhaps all that is needed is a mechanism something roughly like
accesskey="Navigation" . . . accesskey="Help" . . . accesskey="Site map"
with attribute values that are unique textual "function descriptions". Then let the browser do the work, let it allocate the mappings to actual accesskey keypress values, and then make it capable of reading or displaying a table of accesskey function descriptions versus keypresses.
Would be good if this were sorted out in XHTML 2.0. Let's get together and fix this now.
What do you think?
Cecil Ward.
Sorry, comments are closed for this post.