Hello!
Context
Our Continuous Integration automated accessibility tests report in one test that there is no way for keyboard users to scroll down the dropdown that’s shown on CKEditor autocomplete, in the context of this test, this is the Quick Action autocomplete. Here is what it looks like:
It’s impossible to get control of the handle here with your keyboard and scroll quickly through the list. Pressing Tab (action which should be focusing the scolling bar) commits the autocomplete selection.
With arrow keys, one can already scroll through the items pretty quickly.
Jira issue: XWIKI-22578: Scrollable region should be keyboard accessible
Possible solutions
- Since users can use arrow keys to pretty much do the same thing, ignore this dropdown in the tests. There would be no failure anymore, and the situation would stay the same for all users.
- Remove the default behaviour of CKeditor-Autocomplete to commit the suggestion on
TabAND add aTablistener to set the focus on the dropdown. Pro: This solves the issue with an actual accessibility improvement. Con: This could deteriorate the standard user experience because now pressingTabwould not commit the active suggestion.
Opinion
I’m not sure what to go for. Technically both are possible and quite light to implement. If there was not a usability drawback, I’d implement option 2. because it makes the situation a bit better for screen readers and makes it clear that there’s no violation of WCAG here. However, I would want to check with the community if changing the behavior of this element on Tab is okay before going further with implementation.
Conclusion
As a user of XWiki and quick actions, how do you usually commit your selection of action (Enter or Tab) ? Do you think we should go with option 1 or 2? Is there a third solution that I failed to consider when analysing the issue?
Thank you in advance for your help on this topic!
Lucas C.
1 post - 1 participant