Tui.editor: Accessibility anti-patterns with focus and keyboard navigation for WYSIWYG editor

[AustinGil]

Version

"@toast-ui/vue-editor": "^1.1.1"

Test Environment

https://whatsmybrowser.org/b/N6QNF36

Current Behavior

There are a couple accessibility issues I found in the WYSIWYG, specifically for users that use keyboards only to navigate a website:

• All the WYSIWYG toolbar buttons (.tui-editor-defaultUI-toolbar button) have the CSS rule outline: none. This makes it very difficult for a keyboard user to navigate and know where the focus is.
• Keyboard users can navigate through the toolbar buttons, and into the content section, but there is no way to get past the content section. The tab key should navigate to the next focusable element, but instead, it adds an indentation.

Note: I am using the Vue version, but the issues exist with the vanilla JS component as well. You can test it with the basic example https://nhn.github.io/tui.editor/api/latest/tutorial-example01-basic.html. Setting useCommandShortcut to false does not have an effect on these issues.

Expected Behavior

Tabbing through WYSIWYG toolbar buttons should highlight which button I am currently focused on.
Pressing the tab key from the content section should move out of the content and on to the next HTML element as expected.

Recommendations

• Either remove outline: none from .tui-editor-defaultUI-toolbar button, or add some sort of outline to .tui-editor-defaultUI-toolbar button:focus.

• Either remove the event listener for the tab key to handle indentation, or add another key modifier to the event such as ctrl + tab. The second option would still be consistent to the bold shortcut (ctrl + b). Note that shift key is not an option because shift + tab is the keyboard navigation to traverse backwards.

[sohee-lee7]

Sorry for the late reply. I thought about the way you suggested. But this problem is not solved by simply removing outline: none from the toolbar. It does not have the ability to move focus to the toolbar and back to the previous selection position when you return to the editor. And I do not know if there are many needs for using only the keyboard.
Currently, we provide most shortcuts to the toolbar. Therefore, please use the keyboard shortcuts. In addition, the toolbar shortcuts will be changed to allow customization in the future, so you can change the indent shortcuts.

[AustinGil]

I would argue that there are plenty of needs to provide keyboard-only navigation. Blind or visually impaired users that rely on screen readers would generally do not use a mouse to get around. There are also users with motor impairments that can use a keyboard, but not a mouse. Then there are users like myself who prefer a keybaord to navigate through form elements because it's faster.

It's not a matter of being able to access the toolbar features through keyboard shortcuts. It's a matter of not being able to use a website if this editor is part of the page. Right now, if I would rely only on a keyboard to navigate, I might use the tab key to jump through elements on the page. But if I get into the editor, the tab key no longer works as the default behavior, and I cannot exit the editor. So I'm stuck there. The only way out would be to reload the page.

Do you see how this could become an issue?

Also, I'm not trying to be overly critical of this project. I think it's quite nice. I just wanted to provide some feedback that I thought would be helpful to make it even better. For the time being, I would like to use it, but I cannot because our company has to follow web accessibility guidelines which this project would not pass.

[sohee-lee7]

Thank you for detail explanation. Your description about using keyboard and web accessibility is very good so I understand those situation. As you have explained, the tab key may not be used as shortcuts. I think that the tab key and other shortcuts should be customized for user. I will try to make way to customize keyboard shortcuts. (https://github.com/nhn/tui.editor/issues/522)

I am very impressed and grateful by your feedback. Although I am busy right now because of other issues, I cannot implement customizing shortcuts, but I will provide this feature. If you want to contribute to our editor, please give us a PR at any time. :)

[AustinGil]

Yeah no worries. I'm glad I was able to give a better description of the issue. I guess my first one wasn't great.

Anyway, I understand you are very busy and this may not be a top priority, but I wanted to make sure it was mentioned. I would love to put in a PR for it, but I too need to find time for that, so I totally understand.

[ArtanisAce]

Hi, this is also creating a problem for us, would love to see it fixed soon :)

[stale[bot]]

This issue has been automatically marked as inactive because there hasn’t been much going on it lately. It is going to be closed after 7 days. Thanks!

[stale[bot]]

This issue will be closed due to inactivity. Thanks for your contribution!

[sebastianhaberey]

We are also experiencing accessibility issues when tabbing through our page from input to input. Once the user gets to tui.editor, they have to press tab 10 (!) times to skip all the toolbar buttons before they get to the text area. And after that, there is no way to leave the editor without the mouse. I do like the Github editor solution:

• toolbar is one focus group
• left / right switches between toolbar items
• tab in toolbar leaves toolbar
• tab in editor leaves editor

I realize this would be a major change, and it's probably low on the priority list, but hey, one can always dream 😉