93039 - ACCESSKEY doesn't change application focus when pointed to document fragment

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[Winston Smith]

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.

Comment 1

[basic]

This worksforme in build 2001073003 win32

reporter please try a much newer build

Comment 2

[Winston Smith]

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. 

Comment 3

[Winston Smith]

Just installed Build 2001080110 for Win32 and bug still exists. I am reopening
this bug.

Comment 4

[Keyser Sose]

Marking NEW.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Sending Clayton's bugs to layout component, HTML Element component is deprecated.

Comment 6

[Winston Smith]

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 

Comment 7

[Winston Smith]

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. 

Comment 8

[Winston Smith]

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.

Comment 9

[Winston Smith]

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!