Quill: Suggestions for toolbar accessibility

[brycepj]

There has clearly been some effort made to make the quill editor and toolbar keyboard-accessible. As it is, you can do pretty much everything Quill has to offer without a mouse 👍

In developing with Quill, however, I've noticed a number of improvements that could be made to make the editor more accessible, particular for screenreaders.

Toolbar Buttons

• each toolbar button needs a label (aria-label/aria-labelledby)
• each toolbar button should have an attribute representing its state (aria-pressed)

Tooltips

• tooltips needs role="tooltip" and aria-hidden
• tooltip trigger needs aria-describedby="tooltip-id"

Select/Dropdowns

• each option needs an aria-label/aria-labelledby (currently, text only exists in stylesheets :before)
• The span that displays the selected option needs to be labeled (aria-label)
• The color contrast of selected option type is too low (1.61:1)
• Options are currently tab-able, but should function like native select/options (with arrow keys) (this is a nice-to-have)

Editor

• when there's a placeholder, assign it to aria-placeholder
• Apply textbox="role" to the textarea-like box
• When multiline input is accepted, use aria-multiline
• When the text area is read-only, use aria-readonly

Picker

• the trigger needs to be labelled with the currently selected color (currently, only derived by the color of the button)
  
  
  
  • Each color in the picker needs a label (aria-label)
  
  

I'd be happy to help in implementing these -- I just wanted to get feedback from maintainers before working on a PR.

[jhchen]

These are good ideas and accessibility is something we want to improve on. Some of the specifics (ex. do native <button>s need attributes or just non-native form elements acting like buttons) I do not have the knowledge on so if others in the community can weigh in on the right requirements or if a digestible reference/guide can be provided that would be helpful.

There may be implementation changes to the UI elements coming in 2.0 that I have not decided on yet so that's an unknown factor.

[brycepj]

@jhchen Yes, by using native button elements, you typically need to do less work to make them accessible.

But in Quill's case, it's not quite enough. For example, native button elements ensure that toolbar buttons can receive focus and respond correctly to keyboard input, but because the only visual indicator of what each button does is an svg icon, there's really no way for a screenreader to figure out what to read.

Are there contributors or maintainers who have weighed in on accessibility issues in the past that we can consult?

[charrondev]

In our on-going rich editor implementation accessibility has been an ongoing priority. We ended having a custom enough use case that we ended re-implementing the toolbar though. For us we've just been consulting the WAI-ARIA Authoring Guidelines. The toolbar example was quite helpful. https://www.w3.org/TR/wai-aria-practices-1.1/examples/toolbar/toolbar.html

The editor improvements are quite important to us though. I'd be happy to either contribute a PR for those or help test them if you end implementing them before we get there.

---

One key area where I haven't been able to find a definite answer relates to the BlockEmbed. When a user inserts a complex block embed into the document (or one is present there). How do you represent it to a screen reader. Some additional work is already required to have contenteditable/quill treat it as a singular element. I've discussed a little bit moving focus onto these elements with https://github.com/quilljs/quill/issues/1961.

Right now the biggest issue I see is that when these block embeds have non-editable && focusable elements in them, you can only get to them by tabbing (as if they are at the end of the document, even when they could be in the middle/near the beginning).

I'm planning on using arrow keys/click handlers to move focus onto the block embeds. The blocks would all have tabindex=-1 so they don't break up the document otherwise. They would each have a label on them with a summary of their contents. Does that sound somewhat correct to you?

[venkata82]

follow-up on accessibility, Is there a way to focus out from Text area on keyboard Tab?

[dexteritus]

@venkata82 try something like
Editor.modules = { keyboard: { bindings: { tab: false } } };

[LadyArona]

Please keep improving the accessibility of this wonderful editor.

[vkoves]

@jhchen and @brycepj - I work on accessibility and have started using Quill recently, and have a simple suggestion for improving the toolbar buttons. Simply add an aria-label to the button with the text equivalent, as that will override the content inside for screen readers.

Otherwise, per a CSS tricks article on accessible SVGs you should typically use the <title> attribute to convey the SVG's intent. If you take this route, it'll also provide some browser-built tooltips for the buttons for sighted users!

Here's a GIF showing off how it would look to sighted users if you added a <title> to the bold SVG for instance:

Update: I also wanted to highlight issue #1173, which suggested the aria-label as well and has some code that the issue author has applied to get the toolbar to be more accessible.

[robrez]

Would be fantastic if the toolbar used the roving tabindex strategy - tabbing through toolbar buttons to get to the input area has been a painpoint in my experience