Accessibility issues: keyboard in toolbar, screen reader

[carmacleod]

The toolbar needs to have tabindex="0" so that typing Shift+tab takes you to the toolbar element. From there, the user should be able to type left/right arrow keys to move through the toolbar buttons.

For screen reader, there needs to be a bit more markup, like for example role="button" on the toolbar buttons. See this pattern and this example for an idea of the ARIA markup that makes a toolbar component work with a screen reader.

[carmacleod]

Also, all of the dropdowns need to "trap" the tab key so that the user can't tab right out of the dropdown. The Add and Cancel buttons in the dropdowns need to have focus outlines so that keyboard users know which buttons have focus. The emoji picker cannot be operated with the keyboard alone. I would expect to be able to use arrow keys to move left, right, up, and down in the grid of emoji, and then either space or enter key to select the one that has focus.

[mrjones2014]

this is just because the buttons aren't actual buttons, they're just spans. if you use the config to replace all the buttons with real buttons, it becomes accessible.

[carmacleod]

if you use the config to replace all the buttons with real buttons, it becomes accessible.

Buttons in a toolbar are supposed to be navigated using left/right arrow keys and not the tab key, so that the user does not have to tab tab tab tab tab to get to the textarea.

[darosale]

@mrjones2014 do you have an example of how to do that?

[mrjones2014]

@darosale unfortunately not, I was using this in a proprietary project for work, but I've since quit that hellhole of a job.

[darosale]

@mrjones2014 bigger and better things I hope. Does this require building custom components? It wasn't clear to me that there were any options for converting from span to button.

[mrjones2014]

@darosale much bigger, much better things 😄

From the little I remember, I think there was a configuration option to render custom components somehow. Not really sure beyond that. We ended up moving away from this library because of this issue.

[darosale]

@mrjones2014 Good to hear! And this might also be a deal breaker for us as well. Thanks for the insight.

[mrjones2014]

@darosale while it's not perfect for all use-cases (one of the biggest problems being not fully deterministic output from the submodule editor), react-quill is pretty dang good

[darosale]

Thanks for the recommendation! I'll have a look at this one.

[carmacleod]

@darosale react-quill still has some accessibility problems in the toolbar - can't get to all tools with the keyboard.

[mrjones2014]

@darosale @carmacleod with react-quill you can provide a completely custom toolbar.