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

[JeffersonBledsoe]

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 sidebar DOM element, while 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

[JeffersonBledsoe]

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

[ichim-david]

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

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]

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.

[Noobham]

is this issue same as #5431

[stevepiercy]

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