search

shoelace-style / webawesome-alpha

This repo only contains bug reports and questions for the Web Awesome alpha release for early backers.
21 stars 0 forks source link

Accessibility and functionality issue with menu #25

Open paulGeoghegan opened 1 week ago

paulGeoghegan commented 1 week ago

Describe the bug

A bug is a demonstrable problem caused by code in the library. Please provide a clear and concise description of what the bug is here. Menus seem to function correctly. However, if you try to use the left or right arrows they seem to break unless you are expanding a sub-menu. Screen readers also only announce the amount of items for the section of the menu you are in e.g. if you have a menu with 5 items but a separator after the second item it would seem to a screen reader user that there is only 2 items. This is good but it should be clear that there are more items in the menu. When you have a sub-menu expanded and press escape which I expected to close the sub-menu it also seems to break the menu but you are still focus trapped unless you press escape again. It is also not clear when there is a sub-menu. Perhaps it should say collapsed to indicate to screen readers that they can expand it. It would also be nice if you could give each menu section as in the parts of a menu between separators labels.

To Reproduce

Steps to reproduce the behavior:

  1. Go to https://backers.webawesome.com/docs/components/menu
  2. Navigate to one of the menu components while using a screen reader
  3. Focus the menu and try to navigate and you will hear item 1 of 2 or 2 of 2 which does not indicate that there are more after the separator.
  4. Try to find a sub-menu by navigating through the menu using the up or down arrow. There is no distinction for screen readers.
  5. Expand the sub-menu by using enter or the right arrow.
  6. Note that there is no distinction between the menu and sub menu.
  7. press escape and the sub-menu closes but the menu and page loos focus.

  8. Re-focus the menu and now try to navigate using the left or right arrows. Again you are focus trapped in a seemingly empty space.

    Browser / OS

    • OS: Windows
    • Browser: Firefox
    • Browser version: 127.0.1
    • Screen Reader: NVDA
KonnorRogers commented 1 week ago

@paulGeoghegan I think you accidentally pasted the reproduction from the "range" issue

paulGeoghegan commented 1 week ago

@KonnorRogers sorry about that. I have fixed it.

KonnorRogers commented 1 week ago

@paulGeoghegan There's like 4 main points here so I'll try to keep my findings brief:

1.) Only reading number of items in a group - it appears role="separator" seems to create implicit menu groups so it will only read the number of elements in the current group, which is unfortunate. So I think thats an example issue , and not anything inherently wrong with the menu itself. Perhaps using role="group" and wrapping the items may provide a better experience? This would require some testing to see what way reads best.

2.) I notice we're conditionally setting aria-haspopup="" as a boolean, as opposed to always keeping it with aria-haspopup="menu" for menuitems that contain submenus. Along the same lines, I noticed aria-expanded has the same conditional logic as booleans, but it should be aria-expanded="true | false". I'll work on filing issues for these as they should provide a more informative experience for screenreaders.

3.) I noticed the APG example here https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/ reads the proper levels of submenus, so I need to do some accessibility tree inspection to see whats up.

4.) I am noticing if a submenu is open and the ESC key is pressed, it completely eliminates focus. I'll file an issue for that as well.

Thank you so much again for this detailed report!

paulGeoghegan commented 1 week ago

@KonnorRogers thank you for reading it and caring! I really do hope that I have been helpful.