Open Bug 333927 Opened 15 years ago Updated 2 years ago
Ignores Website tabindex order
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:184.108.40.206) Gecko/20060214 Camino/1.0 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:220.127.116.11) Gecko/20060214 Camino/1.0 The newest versions of Firefox and Camino for Mac ignores Website defined tabindex values. If you look at TheWebDesignJournal.com you will see that there is a tabindex spesified in the source. It says that the first time the users hits tab it should focus on the search field in the menu. And after that focus on the sites <h1> title followed by eatch of the menu selections... Reproducible: Always Steps to Reproduce: 1. Go to any site with a defined tabindex. 2. Press tab a couple of times and watch the behaviour. Actual Results: Both Camino and Firefox jups straight to formfields and ignores the defined tabindex. Jumps to the searchfiled first, yes, but then ignores the rest of the tabindex. Expected Results: Both browsers should follow the given tabindex and tabbed the user trough the menu. I've tried in Camino 1.0 and Firefox 1.5. The bug appears in both browsers. This is a really bad accessibility bug! And yes, adding a tabindex value to a hyperlink (<a tabindex="#"...) is a W3C recommendation. To see the expected result, open the site with Opera and start hiting tab a coulpe of times.
From my examination, this one is pervasive and has been around for a while. I believe I have also seen this bug on Linux (SeaMonkey): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20060516 SeaMonkey/1.0.2 And on Windows (Firefox): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Specifically: elements with no tabindex or tabindex="0" are the only focus candidates, or at least Mozilla easily gets stuck in this state. It never attempts to focus elements with a positive tabindex! Please refer to HTML 4.01 specification for correct behaviour: 17.11.1 Tabbing navigation
This is a very serious issue that brokes the accessibility. Anchor, elements do not get focus, and anchor elements with tabindex="-1" should be handled as well. Thanks for all your help.
This has been around since at least version 2 and I just confirmed it again on version 3 beta 3. In my experience it seems to skip any form or anchor elements that are not text fields. This makes applications such as Webmin difficult to use since using tab will skip over drop downs, radio buttons, checkboxes, submit buttons, etc.
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.