I Hate Accesskeys

As usual, before the final release we’re doing a lot of QA work on our localized Firefox builds, and this includes a careful check on accesskeys. There are two different issues with accesskeys:

  • use of a character not available in the label. For example: using “F” as accesskey for “Shiretoko” creates a label “Shiretoko (F)”. This can easily happen if you update the label and forget to correct the corresponding accesskey.
  • duplicated accesskeys (two or more labels with the same scope share the same accesskey).

In the last 24 hours we found two duplicated accesskeys in the Italian build: the first one is quite hidden (you have to check for updates in the Extension manager and then click on the “More information” button), while the second one is located in the main window (Toolbar search). This last issue affects the en-US build (see bug 498840) and probably also other locales.

accesskey

I think that we should really start to think about accesskeys and how to introduce automated tests.

The first step should be to create a standard naming convention (it’s not even mandatory, but it would make things easier): right now you can find accesskeys named like “label_accesskey”, “labelaccesskey” or “label.accesskey”. At this point, checking for external characters shouldn’t be a problem.

The real challenge would be to find accesskeys conflicts – using different tables to store all the accesskeys with the same scope – in particular in pop-up menus. Have you ever tried to select different parts of a web page (create a selection with images, links, images with links, text, etc.) and check how the context menu change? Doing this kind of checks manually is simply crazy 😉

Technorati Tags: ,

4 thoughts on “I Hate Accesskeys

  1. I have a checker for accesskeys in my coverage extension (which I haven’t been running for a while). But that only covers the menu bar and the preference dialog plus a few more. Which reminds me that the preference dialog is the worst piece, as you actually get different conflicts depending on which panes you look at in which order. All loaded overlays for the pref panes contribute the access key context, but the panes only load once you select them.

    So, open pref dialog on General, go to Advanced, get an accesskey conflict. Close dialog and open it again, it opens with just Advanced, and no conflict. Fun, huh? (And known xul bug.)

    Your quest for checking the context menus on different selections sounds like a great case for writing a mozmill test. I’m hoping that we’ll get l10n runtime tests based on that. Clint works on the build integration per se in bug 457265.

  2. I added tests for the content area content menu, though it’s obviously only testing en-US. See browser/base/content/test/test_contextmenu.html

    This is a particularly fun case, because the menu content depends on what you’re right-clicking on and sometimes other state (eg, if an image has finished loadded, or if something is selected).

  3. I feel your pain, I started using automated access key checks for Adblock Plus a while ago – and felt an immediate relief. Access key conflicts are still responsible for the larger part of my communication with localizers. But at least the complicated manual testing is no longer required.

    I didn’t design any generic solution of course, simply listed the groups of access keys that are found in the same context. Testing for access keys that cannot be found in the label is easier thanks to consistent naming of DTD values. Sadly, neither approach will work on the scale of the Firefox project.

  4. Axel: Access keys in different panes shouldn’t conflict – I fixed this bug specifically to make it possible to switch SeaMonkey over to using the toolkit preferences system.

    Dolske: Yes, the main context menu is a veritable pain – SeaMonkey has quite a largish context menu (even without a separate Copy Image Location menuitem) and so far we haven’t worked out how to assign access keys without conflicts 🙁