Audit the usage of `aria-haspopup` in the admin menu

[afercia]

In the admin menu (the one in the left sidebar, not the toolbar one) items that have a sub-menu have an aria-haspopup attribute. While the intent is good, I'm not sure this is a 100% appropriate usage. We've discussed this during today's accessibility team meeting and agreed it's worth investigating.

In the previous ARIA 1.0 recommendation it was clearly stated that aria-haspopup is meant to be used on controls that require user activation to reveal additional content. Then, in the new ​ARIA 1.1 recommendation, the sentence "This means that activation renders conditional content" ​was removed. Regardless, this doesn't necessarily change things and the new values for aria-haspopup don't seem to suggest the current usage in WordPress is 100% correct.

What does "user activation" means?

The aria-haspopup makes perfectly sense when users of assistive technologies land on an interactive item and need to be informed that activating the item reveals additional content.

That's not the case with the admin menu. Both when tabbing or arrowing when using a screen reader, all the menu items including the sub-menu items get revealed without requiring any special user action.

In this case, the information provided by aria-haspopup seems pointless, if not confusing.

Only in the responsive view, the admin menu works differently and the top level items do require user activation to reveal the sub menus. Seems aria-haspopup should be used only in the responsive view.

We should further investigate this issue and test with assistive technologies, not only screen readers but also, for example, speech recognition software.

For reference, the major screen readers announce aria-haspopup this way, as of January 2018:

NVDA "sub menu"
JAWS "has pop-up"
VoiceOver "Menu pop-up"

[afercia]

Moving to Future Release. Will need research and testing but it's worth exploring.

[swissspidy]

@joedolson Is this on your radar still for 6.5? Looks like a punt candidate given the lack of activity.

[joedolson]

I'm not going to get to this one for 6.5. Leaving on my radar for 6.6, though.

Improve wordpress admin menu accessibility for screen readers.

Trac ticket: #43095

[rcreators]

Looks like added PR is not solving the issue.

Its just changing aria-haspopup="true" to aria-haspopup="menu"

I don't think that will solve the issue which is mentioned in the ticket.

@joedolson is it still on your radar for 6.6?

Trac ticket: https://core.trac.wordpress.org/ticket/43095

[afercia]

​https://github.com/WordPress/wordpress-develop/pull/6818 Proposes a simple approach to add aria-haspopup only for the responsive menu. Patch submitted at WordCamp Europe 2024 Contributor Day, by contributors at the accessibility table.

[joedolson]

Noting @ryokuhi as a person I know should also be propped on this issue from the WCEU contributor day; if there are others, let me know!

[afercia]

I'm going to attach a couple screenshots to illustrate the new behavior with the patch applied.

[afercia]

Default menu: the submenu fly-outs open automatically when tabbing and when arrowing with a screen reader. No need to announce there is a popup.

[afercia]

Responsive menu: the submenus require user activation to expand. The presence of a popup is announced as 'menu popup'.

[joedolson]

I'll do a final review and commit when I get back on Wednesday.

[joedolson]

In reviewing this, I determined that the currentMenuItemHasPopup function was no longer relevant, since it was predicated on the aria-haspopup attribute always being present on items. I also determined that this really needed the aria-expanded attribute.

[joedolson]

Testing:

• Verify that there is a data-ariahaspopup attribute, no aria-haspopup attribute, and no aria-expanded attribute in desktop view.
• Verify that the aria-haspopup attribute and the aria-expanded attribute are added in responsive view.
• Verify that the aria-haspopup attribute shows up on links with submenus that are *not* the current section.
• Verify that the aria-expanded attribute defaults to 'false', and toggles to 'true' when expanded.

I've confirmed all of these in my testing.

[joedolson]

In 58449:

Administration: A11y: Use aria-haspopup only if item has popup behavior.

Update behavior of admin menu so that the aria-haspopup attribute is only applied in responsive mode, when there is a popup behavior present. Add aria-expanded attributes to report current popup state.

Props afercia, khokansardar, ryokuhi, joedolson.
Fixes #43095.

In [r58449]