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

Add support for Home and End keys #31

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

seanpdoyle
Copy link
Contributor

@seanpdoyle seanpdoyle commented Nov 22, 2020

The WAI ARIA Practices 1.1 outlines optional support
for Home and End keys to jump to the top and bottom of the
listbox, respectively.

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.

@iansan5653
Copy link
Member

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?

@seanpdoyle
Copy link
Contributor Author

@iansan5653 that's reasonable! How do you feel about opting-into each key individually?

type OptionalNavigationKeys = "Home" | "End"

// ...
optionalNavigationKeys: OptionalNavigationKeys[]

@iansan5653
Copy link
Member

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.

@seanpdoyle
Copy link
Contributor Author

seanpdoyle commented Jul 13, 2022

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.

@iansan5653
Copy link
Member

iansan5653 commented Jul 13, 2022

Actually, now that I look at the spec itself, maybe this isn't the correct behavior? It says (emphasis added):

Home (Optional): Either moves focus to and selects the first option or, if the combobox is editable, returns focus to the combobox and places the cursor on the first character.
End (Optional): Either moves focus to the last option or, if the combobox is editable, returns focus to the combobox and places the cursor after the last character.

In this case, the combobox is always editable (a non-editable combobox is essentially the same as an HTML <select> element) so these keys should actually return focus to the input and move the cursor. I think it might be incorrect to use these keys to move focus to the first/last option in an editable combobox.

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.

@seanpdoyle seanpdoyle force-pushed the aria-optional-keyboard-shortcuts branch from e130b77 to 4e76b4d Compare August 2, 2022 20:31
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.
@seanpdoyle seanpdoyle force-pushed the aria-optional-keyboard-shortcuts branch from 4e76b4d to 19e522f Compare September 25, 2023 15:46
@seanpdoyle seanpdoyle requested a review from a team as a code owner September 25, 2023 15:46
@seanpdoyle
Copy link
Contributor Author

I've rebased this change and caught up to the latest main.

@keithamus Thank you for granting me CI permissions!

Is this change something the team is interested in supporting?

@keithamus
Copy link
Member

I agree with the last comment @iansan5653 raised; while the home/end keys offer useful shortcuts they should not change the behaviour while the input is focused. Can we ensure that this is the case with tests?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants