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

EmojiList should be keyboard accessible #104

Closed
LukeGarrigan opened this issue Mar 9, 2021 · 6 comments
Closed

EmojiList should be keyboard accessible #104

LukeGarrigan opened this issue Mar 9, 2021 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@LukeGarrigan
Copy link

When focusing on the emoji-picker the user should be able to use arrow-keys or tab to navigate through the list of emojis.

A similar change was made to the main parent of this project (emoji-mart)
Issue: missive#218
PR: missive#284

It would be great if a similar change would be made in this project!

@serebrov
Copy link
Owner

@LukeGarrigan Thanks for the links, it looks doable.

Basically it looks like aria-label properties are added and spans for emojis are replaced with buttons (probably this makes keyboard controls just work for them without manual input handling).

Related to: #83.

@serebrov
Copy link
Owner

serebrov commented Mar 14, 2021

I started looking into it and while the mentioned change in the parent project improves accessibility behavior, it only works with special accessibility apps (like VoiceOver on mac).

This is also confirmed in the comments to the pull request:

should I now be able to type, then navigate results via arrow keys?

Yes, in terms of improving the accessibility of emoji-mart, I didn't make it a full autocomplete pattern where you can press the arrow keys to navigate between results. You have to just use the regions to move around after typing into the search bar.

Certainly not a perfect design a11y-wise, but it's at least usable with a keyboard, whereas before it wasn't. Should we open up a separate issue to improve the a11y further?

So this does not work with regular keyboard input (it won't magically enable arrow keys to select and enter emojis).
The accessibility app will be able to loop through the picker elements (categories bar, search input, emojis), which is an improvement, but it would be better to have it working like in Slack: when the search input is active, it is possible to use arrow keys to select the emoji and Enter to confirm the selection.

Here is a good article on the topic that also shows how to build a full keyboard control using arrow keys: https://www.digitalocean.com/community/tutorials/vuejs-vue-a11y-autocomplete

@LukeGarrigan
Copy link
Author

Thank you, so with your current changes the user will be able to tab through the emojis?

@serebrov
Copy link
Owner

@LukeGarrigan no, it won't work with regular keyboard input, only with special software like VoiceOver on mac (see an example here - https://a11y-101.com/development/landmarks, there is a video showing how it works).

I started working on actual keyboard control (like in Slack), but it is more complex as I acually have to handle key events and track the active category and emoji.

@serebrov serebrov self-assigned this Mar 25, 2021
@serebrov serebrov added the enhancement New feature or request label Mar 25, 2021
serebrov added a commit that referenced this issue Apr 17, 2021
[#104] Accessibility improvements and keyboard controls
@serebrov
Copy link
Owner

I've just published version 10.0.0 with keyboard controls and accessibility improvements (use button tags for clickable emojis, add aria- properties).

Keyboard controls are activated when the cursor is in the search field - emoji can be selected with arrow keys and confirmed with Enter (the select event is emmited by picker, same as when the emoji is clicked with mouse).

@LukeGarrigan
Copy link
Author

Awesome, thank you @serebrov

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

No branches or pull requests

2 participants