-
Notifications
You must be signed in to change notification settings - Fork 355
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
Should radio buttons activate with Enter key when focused? #2954
Labels
enhancement
Any addition or improvement that doesn't fix a code bug or prose inaccuracy
Example Page
Related to a page containing an example implementation of a pattern
Feedback
Issue raised by or for collecting input from people outside APG task force
Milestone
Comments
mcking65
added
enhancement
Any addition or improvement that doesn't fix a code bug or prose inaccuracy
Feedback
Issue raised by or for collecting input from people outside APG task force
labels
Mar 19, 2024
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<jugglinmike> Topic: Should radio buttons activate with Enter?<jugglinmike> github: https://github.com//issues/2954 <jugglinmike> Matt_King: I think this is an important question, partly because we used to have checkboxes which activated on "enter", and somebody pointed out almost this identical issue <jugglinmike> Matt_King: e.g. how do they behave natively, etc. <jugglinmike> Matt_King: We changed the checkbox so that it only activates on "space" <jugglinmike> Matt_King: I'm interested in answering this question as soon as possible because at this moment in time, the "radio button" test plan is being revised in ARIA-AT <dmontalvo> q+e <jugglinmike> Matt_King: ...if we're going to take the "enter" key away from this, I'd like to remove the associated test now rather than have to update the ARIA-AT test plan again later <jugglinmike> jongund: I'm okay with "spacebar" alone activating the radio <jugglinmike> Matt_King: In Chrome, Cameron is saying that only the space bar activates native radio buttons <jugglinmike> Matt_King: Should we look at what native radio buttons do in at least Safari? <jugglinmike> Matt_King: Between Chrome and Safari, should we consider that "alignment"? Should we also consider Firefox? <jugglinmike> Matt_King: Our pattern is already different from native radio buttons because in native radio buttons, "forward tab" and "backward tab" are not symmetrical operations. We've discussed this previously <jugglinmike> Matt_King: The browsers don't treat it like a true composite the way that ARIA says it should be a true composite <dmontalvo> q- <jugglinmike> Matt_King: If you tab into the radio group, tab out of it, and then tab back into it, you don't end up in the same place <jugglinmike> jongund: "Enter" submits the form in native radio buttons in Safari <jugglinmike> jugglinmike: Is it worth checking what "enter" does on a radio button that isn't part of a form? <jugglinmike> Matt_King: Yeah, probably. I'd hope it would be a "no-op" in that case, but we should check <jugglinmike> jongund: In Safari, the "enter" key does nothing if there's no "form" element. The space bar still toggles in that case <jugglinmike> Matt_King: I think the fact that there is two major browsers is compelling. I also think that consistency with checkbox is relevant <jugglinmike> jongund: I don't think we should deviate from what browsers do if we don't have a good reason (e.g. like we have a good reason to deviate when it comes to "tab") <jugglinmike> CurtBellew: I agree with this--"space bar" activates and "enter" does not <jugglinmike> s/still toggles/still activates/ <jugglinmike> Matt_King: If we are going to fix this, it requires a change to the code and the documentation. I'm happy to take on the editorial change in the pattern <jugglinmike> Matt_King: Do we have any takers who would like to modify the example? <jugglinmike> jongund: I can do that <jugglinmike> Matt_King: We have two "radio" examples: one with active descendant and one with roving tab index <jugglinmike> jongund: Just removing support for the "enter" key, right? <jugglinmike> Matt_King: That's right. You can change both examples in the pull request, and I'll add the documentation changes to your patch <jugglinmike> jongund: Do we consider this a bug fix? <jugglinmike> Matt_King: I think this is a material change to guidance. I'm going to label it an enhancement <jugglinmike> Matt_King: Is it really an enhancement, though? <jugglinmike> jugglinmike: I think it comes down to whether the prior behavior was intentional. It seems like supporting "enter" was indeed intentional, and that would make this change an enhancement rather than a bug fix <jugglinmike> Matt_King: I agree <jugglinmike> Matt_King: I'm assigning myself and jongund |
mcking65
added
the
Example Page
Related to a page containing an example implementation of a pattern
label
Apr 7, 2024
github-project-automation
bot
moved this to Complete
in Radio Group Pattern and Examples Development Project
Sep 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
Any addition or improvement that doesn't fix a code bug or prose inaccuracy
Example Page
Related to a page containing an example implementation of a pattern
Feedback
Issue raised by or for collecting input from people outside APG task force
With regards to https://www.w3.org/WAI/ARIA/apg/patterns/radio/examples/radio/, currently the
Enter
key activates the control with initial focus. Per the whatwg spec on implicit submission,Enter
key should submit a form. It's confusing then, and maybe incorrect, to captureEnter
keypress to activate the radio button.For what it's worth, the default behavior in with native radio buttons -- Chrome at least -- is to only activate on
Space
, whereasEnter
does submit. See https://codepen.io/ckundo-the-styleful/pen/YzMwPPYThe text was updated successfully, but these errors were encountered: