In HTML, the accesskey attribute serves as a hotkey for triggering or giving focus to an element on a web page. Typically it's used in combination with one or more additional keys, and each browser defines those differently (there's a list on the Wikipedia Accesskey page).
Its use is somewhat controversial, since it's impossible to avoid key combinations that don't conflict with other key combinations already claimed by browsers, plug-ins, assistive technologies, etc. Nevertheless, it's still in the HTML5 spec, and I find it quite useful for applications such as media players, where users may want to play, pause, mute, etc. from anywhere on the page, without having to mouse or tab back to the player.
To explore this further I created an Accesskey Test Page, which contained three buttons. Each button was assigned a unique accesskey attribute, as follows:
- Button X and its accesskey were created using HTML
All three buttons worked fine in Safari and Chrome in both Windows and Mac, and in Internet Explorer 8. However...
- Opera (in Windows) has the exact opposite problem of Firefox. It recognizes the accesskey that is set dynamically on an existing element (Button Y), but not if that element is created dynamically (Button Z). (I haven't figured out how to trigger accesskeys in Opera on Mac).
This isn't an earth-shattering problem. The application will still work without accesskeys, it will just be missing a convenient enhancement. If I really wanted to, I could address the Firefox problem by removing the target element from the DOM, then rebuild it with an accesskey and add it back. Seems like a lot of extra work though, and that wouldn't solve the Opera problem. Ultimately, it may just come down to my accepting the unfortunate reality that users of some browsers are going to get a full-featured application, and others will get Accessible Media Player Lite.
Stay tuned to this blog to see how the story ends...