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.
Assignee: morse → rods
Component: Form Manager → HTML Form Controls
QA Contact: tpreston → madhur
Summary: with dublicate accesskey attributes only last one works → with duplicate accesskey attributes only last one works
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
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.
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 ?
Wrong component... This requires a total revamp of how we do accesskeys, of course -- we just have a hashtable lookup at the moment, iirc...
Assignee: rods → aaronlev5
Status: ASSIGNED → NEW
Component: Layout: Form Controls → Keyboard: Navigation
OS: Windows 2000 → All
Priority: P3 → --
Hardware: PC → All
Target Milestone: Future → ---
*** Bug 234646 has been marked as a duplicate of this bug. ***
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.
Is this related to https://bugzilla.mozilla.org/show_bug.cgi?id=425496 ?
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Version: Trunk → 1.9.0 Branch
Created attachment 358149 [details] 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
(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).
You need to log in before you can comment on or make changes to this bug.