From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9) Gecko/2001050515 BuildID: 2001050515 In the page cited above invoking the accesskey values fail to shift system focus to links that follow a bookmark anchor. The markup reads (roughly): "Jump to <a accesskey="n" href="#anchorname">site <strong>n</strong>avigation</a> [Much intervening markup and content] <p><a name="anchorname">Navigation Links</a></p> [More navigation links that follow.] ------------------------ IE 5+, even on the Mac, gets this right. The system focus is shifted to the bookmark anchor and the user can tab to all the links that follow the bookmark. According to my reading of the W3C recs the expected behavior is: 1) The user invokes the accesskey value. 2) The system immediately activates the link element that has the accesskey value. 3) This should take the user to the link destination, in this case the bookmark anchor. 4) Now that system focus has changed, the user can now tab to an element, following the bookmark, that can take focus. Reproducible: Always Steps to Reproduce: 1. In Mozilla 0.9+ (in Win2K) the user loads http://www.ngtvoice.com/software/jawbone/ 2. User presses alt+c or alt+s 3. User starts tabbing but browser fails shift focus to correct location. Actual Results: 1. Browser fails to shift focus to the destination bookmark anchor 2. Location bar indicates that bookmark link has been invoked but link outline indicates that focus is still on the link with the accesskey value. 3. Tabbing takes user to the next element that can take focus but these are NOT the correct elements that follow the bookmark anchor element. Expected Results: I assume the correct behavior should be: 1) user invokes accesskey value. 2) Bookmark link activates and takes user to bookmark destination. 3) System focus has now changed so that user can tab to all the links that follow bookmark destination. To see the expected behavior (ignoring IE 5+'s incorrect use of the enter key to invoke the link): 1)Load cited page in IE 5+. 2) invoke the accesskey, take link to it's destination 3) start tabbing. 4) System focus correctly shifts to the links that follow bookmark destination.
This worksforme in build 2001073003 win32 reporter please try a much newer build
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Yes, I will. I do that just as soon as build 2001073003 win32 lands on the www.mozilla.org/releases page. Until then Win 32 Mozilla 0.9.2 (build 20010628) still has the bug.
Just installed Build 2001080110 for Win32 and bug still exists. I am reopening this bug.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sending Clayton's bugs to layout component, HTML Element component is deprecated.
Assignee: clayton → karnaze
Component: HTML Element → Layout
QA Contact: bsharma → petersen
I've decided that this might simply be by design and not actually a bug. I've installed Mozilla 0.9.5 and the behavior I cited still persists. Upon activation of the ACCESSKEY (I've changed the value to "n" as opposed to "c" or "s" as I stated a few months ago) in the page I cited (http://www.ngtvoice.com/software/jawbone/) the page will shift to the bookmark anchor but the focus remains on the link containing the ACCESSKEY and tabbing proceeds from there. The behavior in IE 5+ (Mac and Win), again acknowledging its faulty requirement of the user to press ENTER to activativate the ACCESSKEY, is to shift the link focus to the links that follow the bookmark anchor, *not* leave it on the link with the ACCESSKEY. However the W3C recs say nothing as to what should happen in this case, that is what should happen to the tabbing after the ACCESSKEY has been invoked. IE's implementation certainly should not be viewed as the correct or incorrect behavior. It's just one interpretation. I suppose you could make arguments both ways as to the correct behavior although personally, I think the IE behavior is better for accessibility for the disabled because it enables them to quickly bypass intervening links and to shift link focus to anywhere in the page. This, I think is better for persons with mobility impairment who have to use the keyboard or headsticks. Just something for the folks at Mozilla to consider. Having said that, I will set this bug as resolved (an since there is no "by design " catagory) until LATER. I do hope the bug will verified by other testers and the design team will give my comments some consideration. If you need to get a hold of me for further explaination please contact me at address found at http://www.farlops.com/contact.html
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Priority: -- → P4
Resolution: --- → LATER
I have learned that the reason ACCESSKEY fails to behave in the way I expect is because Mozilla doesn't provide any way to move the system caret when focus/selection changes in the page. If this were solved, ideally on all platforms, then functionality of ACCESSKEY would increase and an accessibility gain would be delivered to all platforms. For more information please read http://www.farlops.com/journal/00000009.html. I am reopening this bug and re-assigning it to a more appropriate category.
Status: RESOLVED → REOPENED
Component: Layout → Accessibility APIs
Resolution: LATER → ---
OS: Windows 2000 → All
Priority: P4 → P3
Hardware: PC → All
Oops! I used incorrect terminology. "...move the system caret when focus/selection changes in the page," should read "...move application(browser) focus when selection changes in the page." So far as I know, the W3C recs don't suggest any correct behavior on this but I think the IE's behavior is more accessible than Mozilla's current selection/focus model. Perhaps future incarnations of Mozilla should try to copy IE's behavior. It would be nice to allow all users, not just the disabled, to using shortcuts to hop around in the document bypassing intervening links.
Summary: ACCESSKEY attribute fails in an A element that points to a bookmark A element → ACCESSKEY doesn't change application focus when pointed to document fragment
I have just installed Mozilla 1 and retested on the pages cited below. This accesskey bug is finally fixed in Windows! I plan to test that it's fixed in Linux and Mac but, I am marking this bug as fixed. Excellent work! My congratulations to the everyone on the Mozilla development team!
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.