carbon: Accessibility markup problems in Carbon react overflow menu

Apologies for my suggestion to use “Menu” as a default aria-label when a label is not provided. Windows screen readers say “[label] menu button” (NVDA) or “[label] button menu” (JAWS) when focus goes to a button with aria-haspopup="true", and so it turns out that “Menu” is redundant (i.e. NVDA says “Menu menu button” and JAWS says “Menu button menu”). A better default string might be “Overflow” or “More…”.

Regarding the label for the dropdown ul, it should really use aria-labelledby if possible, which can be set to the id for the button, so that the menu always picks up the same label as the button. That would also work if the button had visible text instead of an icon. See the APG menu button example for an example of using aria-labelledby on the dropdown menu element.

Regarding the problem of having the menu show when the button is in a table and sibling markup is used, this example seems to have solved that problem.

BTW from https://www.w3.org/TR/wai-aria-1.1/#aria-owns:

Identifies an element (or elements) in order to define a visual, functional, or contextual parent/child relationship between DOM elements where the DOM hierarchy cannot be used to represent the relationship.

I think getting a meeting together to discuss some of our options would be a good idea. Is there someone from @carbon-design-system/design to include as well? I’ll look to set something up for later next week.

@emyarod For accessibility I have always had to have the trigger as a sibling to the menu. I’ve built multiple working examples of this component that are accessible and work in various different use cases. The UX is different so maybe if we could set up a meeting between are two teams to discuss?

WH is actually working on Overflow Menu now for handlebars implementation of Carbon and we’ve ran in to many of the same issues as logged by @carmacleod but have it working when there is overflow: hidden parent. I have a meeting with our designer today that will hopefully lead to some collaboration on this component based off of my findings.

we can ignore the quote since it’s no longer in context or relevant. right now we can’t apply the suggested fix of placing the menu next to the trigger button, so we need to come up with an alternative solution. aria-owns as @asudoh mentioned may be a possibility

@carmacleod “priority: low” means the issue is valid and worth fixing, but lower priority than issues describing broken functionality, nasty regressions, or inaccessibility.