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.
Created attachment 115127 [details] proposed patch Elements those can support focus should be focused on respective accessKey pressed.
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.
(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.
Created attachment 448034 [details] Patch
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.
Created attachment 448037 [details] Patch
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.
(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.
Created attachment 448068 [details] Patch
Created attachment 448075 [details] Patch
Created attachment 448089 [details] Patch
Created attachment 448091 [details] Patch
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].
<rdar://problem/87058679>