Fix the usage of aria-haspopup

[afercia]

Describe the bug

The ARIA attribute aria-haspopup is used inconsistently across the Gutenberg UI. For example, some buttons that open a menu do use aria-haspopup, while others don't.

It is worth reminding that aria-haspopup changed between the ARIA 1.0 and 1.1 specifications.

In ARIA 1.0: https://www.w3.org/TR/wai-aria-1.0/states_and_properties#aria-haspopup

Indicates that the element has a popup context menu or sub-level menu.
This means that activation (note by me: this means activation by the user) renders conditional content. Note that ordinary tooltips are not considered popups in this context.
A popup is generally presented visually as a group of items that appears to be on top of the main page content.

In ARIA 1.1 it has been expanded to indicate opening of other patterns that aren't just menus: https://www.w3.org/TR/wai-aria-1.1/#aria-haspopup

Where the allowed values are:

false (default)	Indicates the element does not have a popup.
true            Indicates the popup is a menu.
menu            Indicates the popup is a menu.
listbox         Indicates the popup is a listbox.
tree            Indicates the popup is a tree.
grid            Indicates the popup is a grid.
dialog          Indicates the popup is a dialog.

It is clear that the concept of "popup" evolved to represent other kind of UIs.

Regardless, right now in Gutenberg there's the need to consistently communicate to assistive technology users whether a UI control opens some kind of additional UI. Worth noting that aria-expanded alone isn't sufficient because it represents a state, while aria-haspopup is a property.

Examples:
In the block toolbars, some buttons that open a menu do use aria-haspopup, for example:

• the block switcher button
• the text alignment button

Other buttons that open a menu don't use aria-haspopup, for example:

• the "Replace" button in the Image block

Screenshots:

There's also the case of a button that uses aria-haspopup but it opens... another toolbar. Semantically, this isn't correct and it can be confusing for users. I'll split this in a separate ticket. See the Heading block, where the "Change heading level" button opens another toolbar:

Lastly, there are cases where a button opens a complex UI that is made of various parts. I'm not sure which of the aria-haspopup values would be the most appropriate in these cases. This would need some research and discussion. For example, see the case of the "Quick inserter" or the “Content structure” UIs. How can we properly communicate what kind of UI is going to be opened? At a first glance, the closest value might be "dialog" but this UIs aren't real ARIA dialogs.

[tellyworth]

At a first glance, the closest value might be "dialog" but this UIs aren't real ARIA dialogs.

If we were to pick a value to start with that's better than nothing, would it be dialog? Or simply true?

[afercia]

When the opened UI isn't one of the cases listed by the ARIA 1.1 spec (menu, listbox, tree, grid, dialog) I'd say the safest option is true.

[jorgefilipecosta]

Hi @afercia, @tellyworth,
I conducted some tests within the editor. The styles I added using the developer tools proved useful:

[aria-expanded] {
    border: 2px solid red !important;
}

It appears that the link format, inserter, and list view were the remaining cases lacking the aria-haspopup and aria-expanded attributes. I've submitted PR's to rectify these concerns. Are there any other cases that require attention?

[jorgefilipecosta]

I'm closing the issue as it appears the remaining cases were addressed if there is any remaining issue feel free to reopen.

[afercia]

@jorgefilipecosta thanks much for working on this. Also, nice to see you again.
Sure if we will notice remaining issues with these attributes we will either reopen or report separately.