Bug 152074 - AX: HTML accesskeys should not be invoked for hidden elements
Summary: AX: HTML accesskeys should not be invoked for hidden elements
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: Safari 9
Hardware: All All
: P2 Minor
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-12-09 10:13 PST by Bogdan Brinza
Modified: 2015-12-09 22:14 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bogdan Brinza 2015-12-09 10:13:06 PST
Found this issue while investigating accesskey interop, at this point there is no known live site impact.

What steps will reproduce the problem?
1. http://jsfiddle.net/x7tqnppy/
2. Try to trigger button with accesskey=2

In Edge and Firefox the button can be invoked only when it's not hidden, which is per spec behavior. In Safari (and Chrome on Mac for that matter) the button can be invoked at any moment regardless of hidden state.

http://www.w3.org/html/wg/drafts/html/master/editing.html#the-accesskey-attribute

"When the user presses the key combination corresponding to the assigned access key for an element, if the element defines a command, the command's Hidden State facet is false (visible), the command's Disabled State facet is also false (enabled), the element is in a Document that has an associated browsing context, and neither the element nor any of its ancestors has a hidden attribute specified, then the user agent must trigger the Action of the command."

https://html.spec.whatwg.org/multipage/forms.html#commands

User agents may expose the commands that match the following criteria:
• The Hidden State facet is false (visible)
• The element is in a Document that has an associated browsing context.
• Neither the element nor any of its ancestors has a hidden attribute specified.
• The element is not a menuitem element, or it is a child of a currently relevant menu element, or it has an Access Key.
Comment 1 Bogdan Brinza 2015-12-09 10:13:42 PST
Also filed https://code.google.com/p/chromium/issues/detail?id=568174 for Chrome
Comment 2 Radar WebKit Bug Importer 2015-12-09 10:13:50 PST
<rdar://problem/23823052>
Comment 3 Radar WebKit Bug Importer 2015-12-09 10:13:56 PST
<rdar://problem/23823055>
Comment 4 Alexey Proskuryakov 2015-12-09 19:28:48 PST
Duplicate of bug 70911?
Comment 5 Bogdan Brinza 2015-12-09 22:14:59 PST
Looks like a dupe, indeed. I have to add that in 70911 two problems are combined: 1) hidden element with accessKey is invoked 2) if several elements have same accessKey (afaikt) only the last one in document order would be invoked

So my report is specifically about 1), while is interesting problem by itself.

Here is behavior on Windows browsers:
- Edge cycles through elements with the same accessKey (Alt is forward, Alt+Shift is backwards) and invokes each one
- Firefox cycles focus-only through elements with the same accessKey and user would need to invoke element manually
On Mac Safari and Chrome always invoke last specified in document order.

We have discussed the behavior internally and would consider matching Edge to Firefox in the future as it makes more sense to cycle focus only.

P.S. I'm used to not providing this information in Chromium database - but just in case, full disclosure - I'm Program Management Lead of a Microsoft Edge Layout, CSS, SVG, Controls and Accessibility team. My team has been filing (mostly Chromium) issues in an effort to improve browser interoperability.