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

Sidebar and toolbar shrink/ expanded functionality should work correctly for screen reader users #5466

Open
JeffersonBledsoe opened this issue Nov 30, 2023 · 6 comments

Comments

@JeffersonBledsoe
Copy link
Member

JeffersonBledsoe commented Nov 30, 2023

Describe the bug

Visual users are able to hide the toolbar or sidebar so that it does not get in the way of their editing. However, assistive technology users (such as screen reader users) are not able to do this. Pressing the 'shrink' button still allows the elements within the toolbar (or sidebar) to be focused and the current open/ closed state of the

To Reproduce
Steps to reproduce the behavior:

  1. Start a screen reader
  2. Open a Volto page in edit mode
  3. Keep going 'next' with the screen reader to scroll through the toolbar elements until you reach "Shrink toolbar"
  4. Press "Enter" to shrink the toolbar
  5. Go "Back" with the screen reader

Expected behavior

  • When the toolbar is closed, it is announced that the expanded state is now false
  • I can't select anything in the toolbar anymore

Actual behaviour

  • Nothing is announced when the button is pressed
  • Going backwards still announces the buttons in the sidebar as they are focused, even though they aren't visible

Screenshots
If applicable, add screenshots to help explain your problem.

Software (please complete the following information):

  • Browser: Chrome 119, FireFox 120
  • Volto Version 17.0.x

Additional context

  • All of the same above applies to the sidebar too
  • Open/ closed state can be conveyed using aria-expanded attribute on the button element used to open/ close the sidebar and aria-controls can be used to programatically associate the "Shrink/ expand" button with the expanded state of the sidebar DOM element.
  • Need to ensure sidebar children can't be focused. This could be achieved via the "inert" attribute alongside "aria-hidden" to allow the sidebar to still be animated whilst preventing focus, preventing interaction and visually hiding it.
@JeffersonBledsoe
Copy link
Member Author

cc @Wagner3UB @ichim-david
I've not done any user testing, wanted to get a 2nd/ 3rd opinion

@ichim-david
Copy link
Member

@JeffersonBledsoe I agree with your assessment, we need to have programmatic expand shrink not just an aria-label chance like it was done in this pull request https://github.com/plone/volto/pull/5431/files#diff-5d80b3c9efb8cfe076943dc9e8d59c1bc866ffe00e911165c5ce35e3b6c5a380L185
Ai

@Wagner3UB
Copy link
Contributor

I agree.

While I was thinking about it, another question came to mind:

  • When the toolbar/sidebar is closed, the elements inside of it must be visible to screen readers?

In this case, I'm considering a user who is completely blind. For them, it makes absolutely no difference whether the toolbar is open or not, but the quantity of available elements at the moment does matter. Closing both bars will create a cleaner environment for the user doing this.

@ichim-david
Copy link
Member

I agree.

While I was thinking about it, another question came to mind:

* When the toolbar/sidebar is closed, the elements inside of it must be visible to screen readers?

In this case, I'm considering a user who is completely blind. For them, it makes absolutely no difference whether the toolbar is open or not, but the quantity of available elements at the moment does matter. Closing both bars will create a cleaner environment for the user doing this.

This is why you have expanded or collapsed states, when the section is collapsed the focusable items shouldn't be focusable anymore until the section where they are is meant to be interacted with.
When the toolbar is collapsed you are not meant to interact with the buttons inside the toolbar, the same should be for keyboard navigation or with screen readers.

@plone plone deleted a comment from akshayw1 Dec 5, 2023
@plone plone deleted a comment from Ansh101112 Dec 6, 2023
@Noobham
Copy link
Member

Noobham commented Dec 14, 2023

is this issue same as #5431

@stevepiercy
Copy link
Collaborator

@Noobham no, this is an issue. #5431 is a PR that you created to address #5118. I would say that they are all related.

The folks participating in the discussion on all these issues and PR should first decide on what should be done—maybe a checklist of tasks in one issue, closing the other—before anyone implements a fix in a PR.

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

No branches or pull requests

6 participants