accesskey= assigning same key to multiple links results in browser-specific behavior

[fenestro]

Assigning the same accesskey to different links results in browser-dependent behavior: in Mozilla, the last element is selected; in IE, it's the first. It's unclear what the intent is of assigning "t" to all of the tabs, for example; both Mozilla and IE pick one of the links and opens it, so it doesn't help to try to focus on the tab bar.

It's relatively clear from the spec (but left unstated) that different elements should have different accesskeys so that you can use the accesskey to pick it directly. Since I don't really know what's intended, I can't suggest how to accomplish it, but what's there now is not very useful.

While you're looking at this, several sites have suggested "standard" meanings for accesskeys (e.g., WebAIM http://www.webaim.org/). Some accessibility expers have also suggested that accesskeys aren't terribly useful (e.g., http://www.ua-wg.org/accessibility.html) and apparently they'll be de-emphasized in WCAG 2.0... I'd suggest maybe sticking with WebAIM's "1" (home), "2" (skip to content), and "4" (search) and forget about the navigation ones since they're difficult or impossible to auto-generate.

[limi]

Scheduling this for fixing in 2.1.

[hannosch]

Existing accesskeys are now unique in Plone 2.1, but we have to agree on the keys/numbers.

See also: http://plone.org/collector/4077

[hannosch]

Accesskeys have been removed in Plone 2.1, as there were more practical problems then any benefit.