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.