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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions for toolbar accessibility #2038

Closed
brycepj opened this issue Mar 23, 2018 · 13 comments
Closed

Suggestions for toolbar accessibility #2038

brycepj opened this issue Mar 23, 2018 · 13 comments

Comments

@brycepj
Copy link

brycepj commented Mar 23, 2018

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
Copy link
Member

jhchen commented Apr 2, 2018

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
Copy link
Author

brycepj commented Apr 2, 2018

@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
Copy link

charrondev commented Apr 3, 2018

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 #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
Copy link

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

@dexteritus
Copy link

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

@LadyArona
Copy link

Please keep improving the accessibility of this wonderful editor.

@vkoves
Copy link

vkoves commented Feb 13, 2020

@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:

Peek 2020-02-13 16-02

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
Copy link

robrez commented Jun 23, 2020

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

@singleseeker
Copy link

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

Work? I tried but failed.

@clairefields15
Copy link
Contributor

I have all the changes done and tested locally to implement aria-labels for toolbar items but cannot push to the repo to create a PR (ERROR: Permission to quilljs/quill.git denied to clairefields15. fatal: Could not read from remote repository.). Would love to get this work in if someone can help me out!

@vkoves
Copy link

vkoves commented Aug 25, 2022

@clairefields15 - I don't think you have write access to this repo, you'd need to fork the repository and then make a PR through that. This quickstart might help: https://docs.github.com/en/get-started/quickstart/fork-a-repo

@clairefields15
Copy link
Contributor

Ah got it! I'll do that and perhaps add a bit to the contributing documentation about that step. Thanks

@quill-bot
Copy link

Quill 2.0 has been released (announcement post) with many changes and fixes. If this is still an issue please create a new issue after reviewing our updated Contributing guide 馃檹

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

No branches or pull requests