Summary

Oh no, not another post about access keys? I'm afraid it is, but this is a nifty Greasemonkey script that not only exposes access keys used on the website you're visiting, but you can edit them to suit your preferences.

Author: Gez Lemon

Contents

Greasemonkey

Jacques Distler contacted me about a client-side solution for editable access keys he had written for his website, Musings. The footer contains a definition list of the access keys used throughout his website, and he uses scripting to allow them to be edited in place. Jacques suggested a Greasemonkey script that did the same thing for websites that use access keys. Unfortunately, it's the start of a new semester for Jacques, so he didn't have any spare time to implement the script. Fortunately for me, I've been wanting an excuse to play with Greasemonkey, so decided to write the script myself.

I had read bits and pieces about Greasemonkey, but I had seriously underestimated just how useful an extension it is. Greasemonkey is a Firefox extension, that allow users to install user scripts. Greasemonkey is a most remarkable extension, and could prove incredibly useful for empowering people with disabilities, particularly cognitive difficulties, as it provides a convenient means to repurpose content according to the needs of the visitor. What's more, if you can write JavaScript, you're pretty much ready to go, as there's nothing at all complicated about it.

[Back to the contents]

Installing the Manage Access Keys Script

If you don't already have Greasemonkey installed, you can download a version from the Greasemonkey website. The user script here requires version 0.6.4. Once you've installed the extension, you'll need to restart your browser (as you do with all Firefox extensions). After installing the extension, point your browser at http://juicystudio.com/services/mak.user.js, and you will be prompted to install the script by a monkey (providing you've installed 0.6.4 or higher).

Once you've installed the user script, a list of available access keys will be displayed at the foot of the page on websites that have implemented access keys, with an edit button to allow you to re-assign the access keys to your preference. For website owners that already display access keys on each page along with a facility to edit them, I have provided an id of jsgmAccessKeyContainer so that the site can avoid running the user script. If the id value is found anywhere in the content, the script does not provide the list of access keys. The id value is deliberately obscure, so that a website is highly unlikely to incidentally use the id value, but may be added anywhere in the content to prevent the script from running. Of course, if the script is annoying on certain websites or pages within a website, then there is a facility within the Greasemonkey extension to exclude those pages, or even remove the user script completely, or apply to specific sites or pages.

[Back to the contents]

Limitations

One of the suggestions Jacques made for the script was an option to revert back to the author's preferred keys. This should be a relatively straightforward task of just removing persistent data that was set with the GM_setValue function; simple! Unfortunately, I couldn't figure out a way to do that. There doesn't appear to be anything within Greasemonkey itself to do that, but if you know different, then please let me know as I think it would be a very neat feature to have.

Update: I mistakenly thought that Greasemonkey scripts couldn't use cookies. I've updated the script to use cookies, and have added a "Restore Author Defaults" button.

The script obviously doesn't play well with other scripts that do the same thing, particularly with the server-side user-defined access key class I wrote. The reason is that the server-side solution relies entirely on cookies to define the access keys, but the Greasemonkey script is run afterwards, and re-assigns the keys to values set up using the script, and they take precedence. Because the server-side script doesn't have access to the data, it's blissfully unaware that the key bindings have been re-assigned, and displays the values that it's read from cookies. If I had used the same cookie names for the server-side solution and the user script, it would have worked, but due to my misunderstanding about how Greasemonkey works, I chose different values. I've chosen not to fix it as it's a problem that could occur whenever two scripts collide, but mainly because I'm completely out of time.

[Back to the contents]

Updates

[Back to the contents]

Further Reading

Category: Accessibility.

Comments

  1. [greasemonkey-user-script-to-manage-access-keys.php#comment1]

    Why not use Find As You Type instead of accesskeys? http://www.mozilla.org/access/type-ahead/

    I use this feature all the time and I have never felt any need for accesskeys. Quite the opposite, sites that use accesskeys hinder me to use my own shortcuts (like, say, ALT+1 to enter a "?" character), which is why I have disabled them altogether. 

    user_pref("ui.key.generalAccessKey", 0);

    Posted by zcorpan on

  4. [greasemonkey-user-script-to-manage-access-keys.php#comment4]

    On my site, that will bring you to the first "s" in "Musings" in the banner. If you did hit enter, that *certainly* would not have the desired effect.

    Typing "sk" *will* get you to the right place, but the procedure suffers from a certain lack of discoverability. And it only works for links. If you wanted to get to the search-bar (Accesskey-4) on any page of my site, FAYT would not help you.

    Posted by Jacques Distler on

  5. [greasemonkey-user-script-to-manage-access-keys.php#comment5]

    Correct, my bad. Type "sk", or perhaps even "skip" to be on the safe side.

    To get to the search field press /, then type "search", then press TAB. The same seems to work for this site. Even so I agree that UA's should have better mechanisms to navigate between form controls, but I don't think that accesskeys are the answer.

    Posted by zcorpan on

  6. [greasemonkey-user-script-to-manage-access-keys.php#comment6]

    To get to the search field press /, then type 'search', then press TAB.

    Certainly not a reliable method. There are plenty of pages (like, say, http://golem.ph.utexas.edu/~distler/blog/archives/000723.html ) where the word "search" appears multiple times on a page (it's a pretty common word).

    Hunting through the content of a page to find the desired anchor text or label text is *not* a robust substitute for more direct navigational aids. It *is* incredibly useful. It's just not a replacement for other methods of facilitating keyboard navigation (like accesskeys).

    Posted by Jacques Distler on

  7. [greasemonkey-user-script-to-manage-access-keys.php#comment7]

    Nice implementation, my only concerns for this technique is that it is browser dependant. but if you have your other solution using cookies you fall into the trap of compatibility with greasemonkey as stated in your article. Maybe if there was a Standard for Extensions amongst browsers this would not be an issue?

    Posted by Gaz on

  8. [greasemonkey-user-script-to-manage-access-keys.php#comment8]

    Why not use Find As You Type instead of accesskeys?

    Type Ahead is a good accessibility feature, but it's not a replacement for access keys. Ignoring consistency, the problem with access keys is that they've been implemented by browser manufacturers using the same keys they use as keyboard accelerators for their own product (with the exception of Opera, which has implemented access keys sensibly).

    which is why I have disabled them altogether. 

    
user_pref("ui.key.generalAccessKey", 0);

    That disables access keys, but doesn't remove them from the DOM. In this case, the script would display the access keys defined on the page, but they obviously couldn't be activated. I think it's a shame that Mozilla don't allow the user_pref function to allow people to define multiple keystrokes like Opera that work like sticky keys.

    Posted by Gez on

  9. [greasemonkey-user-script-to-manage-access-keys.php#comment9]

    The script obviously doesn't play well with other scripts that do the same thing, particularly with the server-side user-defined access key class I wrote.

    It does now, at least with the latest version of my client-side Javascript implementation. I don't know that there's anything you can do to make it play nice with your server-side implementation, except use your aforementioned trick to disable the Greasemonkey script entirely.

    Posted by Jacques Distler on

  10. [greasemonkey-user-script-to-manage-access-keys.php#comment10]

    but if you have your other solution using cookies you fall into the trap of compatibility with greasemonkey as stated in your article. Maybe if there was a Standard for Extensions amongst browsers this would not be an issue?

    The problem isn't so much with the extensions, but the values chosen by authors for their cookies. Authors can choose whatever values they like, which means two scripts doing similar things are likely (almost definitely) to conflict.

    I'm glad you made your comment, as it got me questioning why Greasemonkey can't work with cookies (it turns out it handles cookies well). For some reason, I jumped to the conclusion that Greasemonkey doesn't allow cookies to be set, hence the GM_getValue and GM_setValue functions. I should have tested the result of setting cookies, and I wouldn't have spent so long working around a problem that doesn't exist. Oh well, we live and learn *smile*

    As a result, I've been able to add the function to restore accesskeys to the author's defaults.

    Posted by Gez on

  11. [greasemonkey-user-script-to-manage-access-keys.php#comment11]

    It does now, at least with the latest version of my client-side Javascript implementation

    I've updated the script to use cookies, so providing they're the same value, it should work okay. I'm completely out of time, so I'm going to leave the server-side solution as is, but it could be implemented using the same cookie values as the Greasemonkey script.

    Posted by Gez on

  12. [greasemonkey-user-script-to-manage-access-keys.php#comment12]

    I've updated the script to use cookies, so providing they're the same value, it should work okay.

    I meant "better than OK." Rather than using the cobbled-together definition-list of accesskeys that the Greasemonkey script creates, if you land on a site using my Javascript (such as, umh, my site), Greasemonkey gives you the author-supplied definition-list instead.

    Posted by Jacques Distler on

  13. [greasemonkey-user-script-to-manage-access-keys.php#comment13]

    I meant "better than OK." Rather than using the cobbled-together definition-list of accesskeys that the Greasemonkey script creates, if you land on a site using my Javascript (such as, umh, my site), Greasemonkey gives you the author-supplied definition-list instead.

    Oh, cool! I just happened to update the script shortly before, so misunderstood.

    Posted by Gez on

  16. [greasemonkey-user-script-to-manage-access-keys.php#comment16]

    Very nice work guys. I tested this on my own site and it works perfectly. My opinion is that if you are going to use accesskeys, they should be discernible to the user, otherwise what's the point? Naturally, visual clues are not much help to those with sight disabilities, but I'm not going to get into that argument. Thanks Jacques, for the concept, and Gez for the implementation. Thumbs up!

    Posted by Douglas Clifton on

  17. [greasemonkey-user-script-to-manage-access-keys.php#comment17]

    Gez said:

    "Ignoring consistency, the problem with access keys is that they've been implemented by browser manufacturers using the same keys they use as keyboard accelerators for their own product (with the exception of Opera, which has implemented access keys sensibly)."

    Konqueror also features a great accesskey implementation that works a bit better than opera's method. Press ctrl and tooltips appear on screen for accesskeys. then just press the corresponding key. Easy and quite discoverable.
    -Greg-

    Posted by Greg Diebel on

Comments are closed for this entry.