User menu button has ambiguous role & state

[henrycatalinismith]

Steps to reproduce

1. Log in.
2. Press ⌘ + F5 to enable VoiceOver.
3. Focus the user menu.

Expected outcome

The role and value of the user menu should be programmatically determinable as per WCAG success criterion 4.1.2. The announcement when the button is focused should be something like Henry Catalini Smith, button, menu popup collapsed.

Actual outcome

In a screen reader, the user menu's role and value are ambiguous. In the following GIF, when the screen reader's focus arrives on the user menu, you would normally expect it to announce it as a button with a collapsed menu popup, but instead it's announced as plain text like Henry Catalini Smith.

Severity

The success criterion covering this issue is WCAG level A – the minimum level. Most organizations aim for a conformance level of AA, which includes all level A criteria. As this issue is effectively camouflaging this button as a text element from a screen reader user's perspective, it's likely to prevent access to the affected functionality for all but the most technically adept, so its severity is high.

Recommendation

• Use a <button> element instead of a <div> for the clickable element so that it'll be announced as a button by screen readers.
• Add aria-haspopup="menu" to the button so that screen readers announce that it controls a popup menu.
• Add an aria-expanded attribute to the button with a value of true or false depending on the current state of the menu so that the state of the menu isn't only available visually.