Bug 72359 – Access key should work on focusable element.

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Vineet Chaudhary (vineetc)]

Created attachment 115113 [details]
Test Case

As per the specification http://dev.w3.org/html5/spec/Overview.html#the-accesskey-attribute all the elements can have the accesskey content attribute set.
In attached test case DIV element can support focus and should be focused with "accesssKey" attribute.

IE(7) : Is able to focus DIV.

[Vineet Chaudhary (vineetc)]

Created attachment 115127 [details]
proposed patch

Elements those can support focus should be focused on respective accessKey pressed.

[Alexey Proskuryakov]

Comment on attachment 115127 [details]
proposed patch

Implementing this in HTMLElement::accessKeyAction() means that elements are either focused, or get a simulated click (because HTMLAnchorElement and other subclasses override this method). This seems inconsistent.

[Vineet Chaudhary (vineetc)]

(In reply to comment #2)
> (From update of attachment 115127 [details])
> Implementing this in HTMLElement::accessKeyAction() means that elements are either focused, or get a simulated click (because HTMLAnchorElement and other subclasses override this method).

Thanks Alexey, for comments.

> This seems inconsistent.

I tried to make this generic behavior so that any element is focused, only if it supports focus. 
For other subclasses those overrides this method like
HTMLButtonElement/HTMLAnchorElement ==> Sends simulated click as these are click-able.
And For HTMLInputElement ==> Sets focus only as these are focusable.

Please correct me if I am getting this wrong.

[Manuel Rego Casasnovas]

Created attachment 448034 [details]
Patch

[Manuel Rego Casasnovas]

I was trying to understand why focus-visible-024.html was failing in wpt.fyi:
https://wpt.fyi/results/css/selectors/focus-visible-024.html?label=master&product=chrome%5Bexperimental%5D&product=edge%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&product=webkitgtk&aligned

And it looks like the reason is that a <DIV tabindex="0" accesskey="a"> is not focused via accesskey.

My patch to fix it is very similar to the original patch from Vineet, but also removing some implementations in the subclasses that won't be needed anymore.

This makes us match other browsers regarding accesskey.

[Manuel Rego Casasnovas]

Created attachment 448037 [details]
Patch

[Darin Adler]

Looks like the accessibility/mac/search-predicate-visited-links.html test is now failing. It failed on two different bots, so maybe it is indeed due to the changes here.

[Manuel Rego Casasnovas]

(In reply to Darin Adler from comment #7)
> Looks like the accessibility/mac/search-predicate-visited-links.html test is
> now failing. It failed on two different bots, so maybe it is indeed due to
> the changes here.

Yes that test gets affected by this change.

Thes test does this:
        accessibilityController.focusedElement.childAtIndex(0).childAtIndex(0).press();

Which ends up calling AccessibilityObject::press(), that uses accessKeyAction() (see https://github.com/WebKit/WebKit/blob/main/Source/WebCore/accessibility/AccessibilityObject.cpp#L1018).

I believe we can modify the test, because what's the focused element is not the main purpose of the test.

[Manuel Rego Casasnovas]

Created attachment 448068 [details]
Patch

[Manuel Rego Casasnovas]

Created attachment 448075 [details]
Patch

[Manuel Rego Casasnovas]

Created attachment 448089 [details]
Patch

[Manuel Rego Casasnovas]

Created attachment 448091 [details]
Patch

[EWS]

Committed r287529 (245664@main): <https://commits.webkit.org/245664@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 448091 [details].

[Radar WebKit Bug Importer]

<rdar://problem/87058679>