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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish sidebar: the Cancel button can't be used with speech recognition software #25194

Closed
afercia opened this issue Sep 9, 2020 · 6 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Good First Issue An issue that's suitable for someone looking to contribute for the first time [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Sep 9, 2020

Describe the bug

In the Publish sidebar, the "Cancel" button can't be used with speech recognition software.

This is a good example of how to not use an aria-label attribute. In fact, the aria-label mismatch the visible text:

Screenshot 2020-09-09 at 17 45 43

Worth reminding the aria-label attribute overrides the button text so that the computed accessible name of the button is "Close panel". However, this text is not visible for sighted speech recognition software users. They will try to voice a command based on the text they see on the page. They will try to voice "Click Cancel" because that's the control's name the UI exposes visually. However, the real name of this control is "Close panel". Thus, there's no chance for these users to use this button as they won't have a clue the real name is "Close panel".

To reproduce
Steps to reproduce the behavior:

  • on macOS, enable Voice Control under System preferences > Accessibility > Voice Control > Enable Voice Control
  • the Voice Control mic will appear on the screen:

Screenshot 2020-09-09 at 16 05 55

  • create a new post, insert some content, click Publish
  • the Publish sidebar slides in
  • try to voice the command "Click Cancel"
  • nothing happens
  • try to voice the command "Close panel"
  • the Publish sidebar closes

Since in this case the button has visible text, the simplest fix is to just remove the aria-label. I do realize the good intent to provide some better context for screen reader users but the button text "Cancel" is already meaningful, also because it lives close to the "Publish" button. Its meaning is clear.

Worth also reminding that for the WCAG 2.1 this is a success criterion failure, as the accessible name must contain the text that is presented visually (preferably at the beginning). Instead, in this case the two text mismatch entirely. For more details:

Success Criterion 2.5.3 Label in Name
https://www.w3.org/TR/WCAG21/#label-in-name

Expected behavior
The button to work with speech recognition software.

Editor version (please complete the following information):

  • WordPress version: 5.6 trunk
  • Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? both
  • If the Gutenberg plugin is installed, which version is it? 8.9.3
@afercia afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Good First Issue An issue that's suitable for someone looking to contribute for the first time labels Sep 9, 2020
@prashanttholia
Copy link
Contributor

prashanttholia commented Sep 10, 2020

Hi, I'd like to work on this issue. Please allow me to do so.

@allilevine
Copy link
Contributor

Hi, I'd like to work on this issue. Please allow me to do so.

@prashanttholia I think you can go ahead and start working on this one if you'd like to! Have you checked out the Developer Documentation and the Contributors Handbook?

Since in this case the button has visible text, the simplest fix is to just remove the aria-label. I do realize the good intent to provide some better context for screen reader users but the button text "Cancel" is already meaningful, also because it lives close to the "Publish" button. Its meaning is clear.

Would there be value in adding another attribute with the "Close panel" value for screen reader users? Like this aria-describedby example.

@afercia
Copy link
Contributor Author

afercia commented Sep 16, 2020

Would there be value in adding another attribute with the "Close panel" value for screen reader users? Like this aria-describedby example.

Changing the button text directly would be a better option. However, I'm not sure screen reader users would have any clue of what a "panel" is. "Panel" is only a visual reference, I don't think this term is used anywhere in plain text to describe this UI. Also, descriptions may not be announced by screen readers, depending on the verbosity settings.

@prashanttholia
Copy link
Contributor

Thanks @allilevine . I haven't read the documentation yet. I will go through them and make sure that I fulfill the guidelines mentioned in them.

Based on the points mentioned by you and @afercia, I'm going ahead with keeping the button text as-is and removing the aria-label attribute.

I am curios however about whether adding a aria-describedby attribute with text such as 'Cancel Publishing' (for users who have relevant verbosity settings enabled) be a good idea? Let me know if you find it worthy.

Thanks.

@afercia
Copy link
Contributor Author

afercia commented Sep 17, 2020

Keeping things simple is often a better choice. The button will be already read out as "Cancel" and it is placed close to the Publish button. I'd tend to think it's sufficiently clear, while an additional description would add unnecessary noise for screen reader users.

@afercia
Copy link
Contributor Author

afercia commented Sep 21, 2020

Fixed in #25441

@afercia afercia closed this as completed Sep 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Good First Issue An issue that's suitable for someone looking to contribute for the first time [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

3 participants