In my endeavor to make this site a useful place for web developers to visit, I offer some obscure information about the accesskey
attribute in XHTML and HTML 4. As I gather more information, I will add to this entry. I may even move it to my developer section.
First off, at least in the implementations that I’ve seen, it’s widely assumed that you shouldn’t assign accesskey
values to links or form controls that conflict with the menu shortcuts of Internet Explorer 4+, Mozilla and Navigator 6+.
This is not strictly true on Windows systems (I haven’t yet tested this Linux or Mac so I don’t know if it applies to other systems. If you know, please mail me with some answers.) because of a extremely subtle way of differentiating the keystrokes of the menu item or the element in a web page.
Here is the subtle difference: if you press and hold the ALT key and then press the assigned character, then Mozilla, Netscape 6+ and IE 4+ on Windows systems will activate the accesskey
. If you press and release the ALT key and then press the assigned character, the aforementioned browsers on the aforementioned system will activate the item on the menu bar associated with that character value.
While we are on the subject, I am rather annoyed with the implementation of system selection and focus in Mozilla. Actually they’ve done a good job about following the expected behavior of accesskey
but some of that new functionality is diminished because of the way system focus is handled in Mozilla, and I assume Netscape. Let me explain.
If I set a link to point to a web document fragment, more commonly known as a bookmark or section anchor (the part of the URL that follows a pound character.), and then invoke that link, Internet Explorer, in both Mac (since IE 5) and Windows (since IE 3), shift system selection focus to any links or form elements that follow that document fragment. This means I can bypass elements that might otherwise take focus between the link that points to the fragment and the elements that follow that fragment. Netscape 6 and Mozilla, despite many excellent improvements in terms of accessibility and standards support, still don’t do this. This means that Additional (6-14-02): I have just discovered that Mozilla 1 and Netscape 7 have fixed this bug. Nevermind.accesskey
looses some potential in those browsers because I can’t use it to shift system focus and therefore hop around in the same document as well as IE.Yes, I’ve filed a bug on this.
Jukka Korpela provides a good tutorial on how to use accesskey
effectively.