129268 - with duplicate accesskey attributes only last one works

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[Petri Lehtonen]

If same accesskey is used for multiple input elements only the last one is
remembered. Usually if two elements share the same accesskey pressing it more
than once switches between the elements. I think this behavior would be nice in
forms rendered in Mozilla as well.

Comment 1

[Stephen P. Morse]

reassigning

Comment 2

[Tom Croucher]

I think this is more important than it has been given. For users needing
accessibility this is making accesskeys in some web sites unusable. For example
in a site which uses the accesskey "s" for both a search box and a submit button
for that form, using the accesskey will always submit the form without anything
in the search box.

Comment 3

[Greg Ubben]

I agree.  I've designed a few web sites that use accesskeys and have done a lot 
of research into how they're best used and how different web browsers handle
them.  I've also consulted with a vision-impaired support engineer on this
issue.  This is something IE does better, and is one of the things that has
made IE a better product as far as accessibility is concerned.

It is extremely useful to have a model where the accesskey only changes focus
rather than causing activation (there's now a preference to work around this
though it's off by default), AND where you can assign the same accesskey to
multiple elements.  This essentially gives you multiple tabbing sets.  One
good example of where this is put to good use to make a site more accessible
is a Yahoo-like web directory where when browsing the category tree, hitting
Ctl-C tabs through the sub-categories, and hitting Ctl-I can tab thru the
sites listed within that category.  Hitting Shift-Ctl-C or Shift-Ctl-I tabs
backwards, just like Shift-Tab does for the normal tabbing.  (Tab stops
should wrap around.)

Another example where this might be used is search engine results, where
there is a primary and two secondary links for each result.  Hitting tab
requires 3 keystrokes to get thru each result, so defining an ACCESSKEY=I
for the primary link on each result would make the results much more
navigatable/accessible.  Or a sectioned portal-like site where a repeating
key can be used to move between sections.  And of course, this prevents
bad conflicts for pages that come from multiple sources each of which may
have defined the same accesskey.

There really is no disadvantage for this feature as far as the user is
concerned.  It's just a code complexity / do the work issue.  Also BTW,
the HTML 4.0 spec is ambiguous on this I believe.

How about:  Hardware=All, OS=All, Keywords=access ?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Wrong component...  This requires a total revamp of how we do accesskeys, of
course -- we just have a hashtable lookup at the moment, iirc...

Comment 5

[timeless]

*** Bug 234646 has been marked as a duplicate of this bug. ***

Comment 6

[Andrés G. Aragoneses]

IMHO: having duplicate accesskeys is not good in the end. What about showing a
warning in the JavaScript console when someone tries to activate an accesskey
and a collision of accesskeys is found? This would do accesskey-maintenance
easier. And I am talking about accesskeys in webpages *and* in XUL UI.

Comment 7

[sir moon]

I know it's been a couple years since this has even been discussed, but this bugged me recently and on Windows at least the current behavior is a platform consistency issue.  Try creating two native controls on a dialog box with the same access key and you'll find that Windows cycles between them.  In general, the Windows algorithm is:

1) find how many controls have this access key
2) if one, activate that control
3) if more than one, tab to the next control with that access key

The Windows algorithm generally satisfies both groups - if you want the keystrokes to _do_ something, you'll set up your page with a unique access key for each control, and pressing the access key will do what you expect.  If you want to use the keystrokes as a more selective tab order, you define the access key more than once, and it also does as you expect - in Internet Explorer, and in the Windows dialog manager for native applications.

Of course implementing this is something else altogether.  Just wanted to put this out there though.

Comment 8

[Dan Dascalescu]

Is this related to https://bugzilla.mozilla.org/show_bug.cgi?id=425496 ?

Comment 9

[Simon Bünzli]

This has been FIXED for Firefox 3.0 by making the focus switch between all the elements with the same accesskey instead of just activating the last one.

Comment 10

[bugzilla.mozilla.org]

Attachment: Testcase

Since there was no testcase or URL given I tried to create one in this attachment.

The testcase confirmes that multiple INPUT elements with the same accesskey get activated properly.

But I also noticed that the same accesskey on multiple LABEL elements does not work at all. Does this belong here or is this another bug? 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090121 Shiretoko/3.1b3pre

Comment 11

[Karl Tomlinson (:karlt)]

(In reply to comment #10)
> But I also noticed that the same accesskey on multiple LABEL elements does not
> work at all. Does this belong here or is this another bug? 

Thanks for the testcase.
As this bug has already been marked fixed, it would be best to file a new bug (if there is no existing unresolved bug re multiple label elements).