Accesskey Conflicts

In general, HTML defined accesskeys are being used to provide the ability to quickly invoke the links in a site that go to specific destinations including such examples as a search page, a contact page or the home page of a site. In some cases they are being used to provide an alternative mechanism to “skip navigation” or “skip to content”. In principle, this functionality is a worthwhile end goal as it has the potential to make the web more usable for all.

The Ideal Solution

There have to be a number of conditions for accesskeys to be not only useful, but successfully implemented on a large scale. These include:

Standardized implementation across sites

The reason behind this is obvious. If it isn’t standardized, then users will have to learn different accesskeys on each site they visit. Many sites and authors have suggested different standards, with the most widely referenced being that at Clagnut and DiveIntoAccessibility.org that use numbers for Accesskeys, similar to that recommended by the Government in the UK.

Conflict resolution

In cases where a conflict exists between an HTML defined Accesskey and a built in keyboard binding for a given User Agent or a user-defined keyboard binding in a user agent, the HTML defined Accesskey must not override the User Agent’s behaviour. If an HTML defined accesskey were to take precedence over a User Agent keyboard binding, critical functionality could be lost, potentially leaving the user confused, or unable to complete tasks.

Standardization

Standardization itself is not so much of a problem as is conflict resolution. Thankfully, many developers have come to this realization, and have worked toward standardizing accesskeys, and an emerging trend is to use the digits 0 though 9, instead of letters.

The Problem with Letters and Learned Behaviours

The problem with letters is obvious – HTML defined accesskeys appear to conflict with User Agent defined keyboard bindings to menus and other functionality.

In these cases of apparent conflict, the HTML defined accesskey can be invoked differently than the User Agent menus (see: relevant discussion on the WAI list, and on the WebAIM list)

The problem with this is that it will be extremely difficult to teach new keystroke behaviour to users, and there is no easy way to determine which keystroke method to use as there is generally no method for determining the accesskeys on a site when you first arrive at it (hence the reason many sites now use Alt-0 to display their accessibility statement and list of accesskeys, and others are using different methods to display the accesskeys inline within the document.)

The Problem with Symbols

In the summer of 2002, we (John Foliot and I) collected as much information as we could regarding which keystroke combinations were “reserved” in user agents and assistive devices.

There remained some symbols available, but symbols are problematic, especially when dealing with International keyboards layouts.

The Problem with Numbers

Numbers seem to be a reasonable alternative, and a strategy many are now using. There is however, a catch.

Current and previous versions of WindowEyes software use Alt+0 through Alt+9 to reference “User-defined windows” that outline specific areas of the screen. From the WindowEyes User Manual at http://www.gwmicro.com/wemanual/section4_2.htm (framebuster script means we can’t link directly to that page, so look for section 4.2 in the contents frame on the left).

Window-Eyes has two kinds of windows, standard and hyperactive. Standard user windows are for reading portions of the display screen while ignoring other portions. They can be set to any size, from one character to the entire display screen. You can read the contents of any of the first twenty standard windows with the press of a hot key. Windows 0 through 9 can be read with ALT-0 through ALT-9. Windows 10 through 19 have their hot keys undefined by default. Any of the 50 standard windows can be read with the Any Window hot key, undefined in the default Window-Eyes speaking environment. Though fifty standard user windows are available, few speech-access users ever need to use all, or even most of them.

Users using WindowEyes will not have access to numeric accesskeys. Many will argue that defining the accesskeys with numbers for everyone else will be of use, as long as defining them doesn’t override any expected behaviour of user agent, or assistive technology such as WindowEyes. This seems reasonable, but certainly not universal, and we believe that a universal solution would be preferable.

The Problem with Opera and Numbers

There appears to be more than one catch when using numeric accesskeys. While Opera supports numeric accesskeys, the mechanism to activate them differs from activating letter assigned accesskeys. In Opera, to activate a letter accesskey, you hold down Shift + Esc + letter. When using numbers on the other hand, you must press Shift + Esc, let go, and then press the number.

This becomes more problematic as the number keys also have functionality within Opera including:

• Number 0: Zoom in 10%
• Number 9: Zoom out 10%
• Number 8: Zoom in 100%
• Number 7: Zoom out 100%
• Number 6: Restore to 100%
• Number 3: Cycle through frames on a page
• Number 2: Cycle to next page
• Number 1: Cycle to previous page
• Number 4: Minimize active Page
• Number 5: Switch between restored and maximized page

This means that if you don’t press the number soon enough after you’ve pressed and released Shift + Esc, you will invoke the default number behaviour instead of the element to which the accesskey is assigned. We haven’t gone to the point of measuring what factors determine how much delay is given between the keystrokes before the behaviour reverts to the default instead of the accesskey. Perhaps some day.

Conflict Resolution

The W3C User Agent Guidelines don’t specifically spell out what should happen in cases of conflict between locally/document defined keyboard bindings and user agent/OS keyboard bindings. However, it seems logical that a document that includes “Guideline 11. Allow configuration and customization”, would suggest that such customization is done at the User Agent level, and that these settings would override the settings of the individual document. We already have this case with user defined stylesheets.

In any case, we should expect that the user agent settings would override anything that the author puts in place, because the user agent is presumably configured by the end user.

It appears that this is not the case in certain instances.

Mozilla and Conflicts with Extensions

Updated April 9, 2004: Mozilla and other Gecko based user agents such as FireFox have the advantage of being customizable through extensions that are written by third parties. One of the more popular is the RSS Reader Panel. When installed it displays a list of RSS Bookmarks in the Mozilla sidebar, along with a list of items in the RSS feed. The RSS Reader Panel is toggled on and off using the ALT + R keystroke (on a PC). In testing, this was overridden by accesskeys that were author defined in a page while browsing. What made this more confusing was the fact that the accesskeys were not visibly identified on the page. The accesskey simply hijacked the keystroke.

It is foreseeable that many more conflicts are possible as the number of third party extensions increases. Again, the question arises – in cases of conflict, who wins? Clearly we don’t want accesskeys to override behaviours of the user agent.

WindowEyes, IE, and ALT + S

WindowEyes defines the keystroke ALT + S as a function that reads that status bar. Including S in your list of accesskeys will not work with current versions of WindowEyes.

IE and ALT + D

Internet Explorer binds the keystroke ALT+D to the address bar. An HTML defined accesskey for the letter D overrides the keyboard binding to the address bar, and therefore disables that critical keyboard shortcut for IE users. This is the perfect example of where accesskeys can go wrong, as it is the exact opposite of what we believe should happen in terms of conflict resolution.

A note on International versions of IE — I installed and tested the latest version of IE in other languages (Spanish and Italian) wondering if the same problem might occur, but with different letters. Interestingly enough, the ALT + D combination was used to focus on the address bar as well simply because the letter d was in the translated version of “Address” in each of the languages we tested.

JAWS screen reading software absolutely relies on keystrokes, as does WindowEyes. These screen readers run “on top of” the other software on the users computer, and in most cases for the web, on top of Microsoft Internet Explorer. Further, IBM’s HomePageReader utilizes IE’s rendering engine to read web pages. It too, relies heavily on keystrokes to function. In these cases where keystrokes are vital, the potential for confusion and problems is greater.

These (admittedly obscure) cases show disparity within a single browser where the user agent recovers nicely on conflict for certain key bindings and in others it (quite unexpectedly) overrides default behaviour. Without clear concensus from the browser makers on conflict resolution and which keyboard binding should take priority, implementing accesskeys successfully becomes even more difficult. User preferences should take precedence over author preference. Certainly the possibility exists that there are other such conflicts that may exist in different user agents/adaptive technology combinations.

The Way Forward

Let us be clear on one thing. The concept behind accesskeys is great, but there seems to be too much wiggle room, even though others have recommended “standards”. The problem is that it still isn’t standard. When doing a search for UK Government Accesskeys standards you will find sites that claim to be following the standards using numeric accesskeys, but then went on to declare additional accesskeys that included many letters, and in some cases included S and D – unfortunate choices given the above conflicts.

The idea of accesskeys is sound, but we need a different and more robust way to implement the same functionality.