-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add support for Home and End keys #31
base: main
Are you sure you want to change the base?
Add support for Home and End keys #31
Conversation
Since this is considered an optional practice, do you think we should also add a parameter to the constructor to configure whether it's enabled or not? |
@iansan5653 that's reasonable! How do you feel about opting-into each key individually? type OptionalNavigationKeys = "Home" | "End"
// ...
optionalNavigationKeys: OptionalNavigationKeys[] |
Hmm, I generally like the idea but I think there's never a case where you should enable one and not the other - if a user presses Home and it works, they will also expect End to work. If this tool is intended to enforce (or at least encourage) a11y best practices, I think it's OK if we limit flexibility in favor of enforcing the expected behavior. |
Do you have an idea for what the constructor argument name should be? Is a third positional Boolean argument sufficient, or is it time to accept a third argument as an Object with a configuration key? I'm happy to implement in either style. |
Actually, now that I look at the spec itself, maybe this isn't the correct behavior? It says (emphasis added):
In this case, the combobox is always editable (a non-editable combobox is essentially the same as an HTML I'm admittedly not 100% sure if that phrasing really means that if the combobox is editable, it's wrong to move focus to the first/last option. Sorry for the back and forth on this - comboboxes are complicated 😅. To answer your question, if we do decide to implement this, I think an optional config object would be the best route. |
e130b77
to
4e76b4d
Compare
The [WAI ARIA Practices 1.1][listbox-keyboard] outlines optional support for [`Home` and `End` keys][keys] to jump to the top and bottom of the listbox, respectively. [listbox-keyboard]: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/#listbox-popup-keyboard-interaction [keys]: https://www.w3.org/TR/uievents-key/#keys-navigation Configure: Home and End navigation --- By default, continue to ignore `Home` and `End` navigation keys. When `optionalNavigationKeys: ["Home", "End"]` is passed as a configuration object, treat them as valid navigation keys.
4e76b4d
to
19e522f
Compare
I've rebased this change and caught up to the latest @keithamus Thank you for granting me CI permissions! Is this change something the team is interested in supporting? |
I agree with the last comment @iansan5653 raised; while the |
The WAI ARIA Practices 1.1 outlines optional support
for
Home
andEnd
keys to jump to the top and bottom of thelistbox, respectively.
Configure: Home and End navigation
By default, continue to ignore
Home
andEnd
navigation keys.When
optionalNavigationKeys: ["Home", "End"]
is passed as aconfiguration object, treat them as valid navigation keys.