Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove tab index's synthetic click event feature #2003

Merged
merged 2 commits into from Nov 3, 2016

Conversation

@annevk
Copy link
Member

annevk commented Nov 2, 2016

Other than through a feature called “spatial navigation”, currently not
enabled by default in any shipping browser, this behavior is not
implemented and at this point it’s highly likely shipping it would
break compatibility with deployed content as discussed in #1952.

Removing it to reflect reality, but as we expand the features of custom
elements, exposing “activation behavior” somehow should be high on the
list as the effective default is detrimental to keyboard-only users.

Closes #1952.

Other than through a feature called “spatial navigation”, currently not
enabled by default in any shipping browser, this behavior is not
implemented and at this point it’s highly likely shipping it would
break compatibility with deployed content as discussed in #1952.

Removing it to reflect reality, but as we expand the features of custom
elements, exposing “activation behavior” somehow should be high on the
list as the effective default is detrimental to keyboard-only users.

Closes #1952.
@zcorpan
zcorpan approved these changes Nov 2, 2016
Copy link
Member

zcorpan left a comment

It's sad that this is not implemented.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Nov 2, 2016

I guess we should wait for @domenic since he had a slightly different suggestion. Whoever merges please remove the space between tab and index.

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 2, 2016

Shouldn't we also fix

The user agent should allow the user to manually trigger elements that have an activation behavior, for instance using keyboard or voice input, or through mouse clicks. When the user triggers an element with a defined activation behavior in a manner other than clicking it, the default action of the interaction event must be to fire a click event at the element.

to no longer recommend doing that, since it's probably not web-compatible?

Also it appears that with this removal the note

One valid reason to ignore the platform conventions and always allow an element to be focused (by setting its tabindex focus flag) would be if the user's only mechanism for activating an element is through a keyboard action that triggers the focused element.

becomes inaccurate.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Nov 3, 2016

to no longer recommend doing that, since it's probably not web-compatible?

Why? Elements with activation behavior can certainly be triggered by the keyboard. It's just that tabindex doesn't appear to add activation behavior.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Nov 3, 2016

becomes inaccurate.

Yeah, I suppose. It's a reason to ignore the specification altogether though as Opera did with spatial navigation, but maybe we should remove that note for now given that nobody is shipping such a feature.

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 3, 2016

Why? Elements with activation behavior can certainly be triggered by the keyboard. It's just that tabindex doesn't appear to add activation behavior.

Ah right, that makes sense. Thanks.

@domenic domenic merged commit 35e3e1e into master Nov 3, 2016
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@domenic domenic deleted the annevk/tabindex-synthetic-click branch Nov 3, 2016
@patrickhlauke

This comment has been minimized.

Copy link
Member

patrickhlauke commented Nov 4, 2016

Great stuff, thanks folks

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 4, 2016

Thank you for finding this issue!

@patrickhlauke

This comment has been minimized.

Copy link
Member

patrickhlauke commented Nov 4, 2016

It may or may not be of interest to the whatwg version here that in my PR here w3c/html#704 i do retain the last note, but rewrite it to explicitly state current UA behavior

stevefaulkner added a commit to w3c/html that referenced this pull request Nov 4, 2016
W3C-HTML-Bot pushed a commit to w3c/html that referenced this pull request Nov 4, 2016
arronei added a commit to arronei/html that referenced this pull request Apr 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.