Dropbutton should report open/closed state to assistive technology

Some interesting quirks in our dropbutton. These might make it a poor match for the W3C menu button pattern.

• The more-actions button is INSIDE the list container which it controls! I have a feeling that this is an unusual pattern.
• It's possible to drop off the end of it by tabbing. The W3C pattern examples use arrow keys to select an action, and loop around the first/last items.
• Pressing escape does nothing in our dropbutton. The W3C pattern collapses the menu button.
• The menu collapses automatically when focus is no longer inside it. This is only a minor point. So long as the aria-expanded state is up to date, I wouldn't expect any confusion when returning to it.

Update (3rd Feb 2021): Some of these aren't relevant to us. See comment #18 for explanation.

Just found #2278473: Simplify Dropbutton markup in line with our CSS standards. The proposed new markup there would make it much easier to implement the Menu Button pattern from the WAI-ARIA Authoring Practices. In particular, the "more actions" button is NOT inside the list which it controls.

Changing the parent issue, making this part of the larger plan for improving dropbutton.

I'm sure we should be using aria-expanded to convey the open/closed state, but I don't think aria-haspopup is appropriate for all instances of dropbutton.

Now aria-haspopup has a predefined list of roles which the pop-up can be (dialog, menu, etc). So if we say aria-haspopup="menu" (or even aria-haspopup="true"), then this implies that:

• the associated pop-up has role="menu"
• which in turn implies that it has descendants with role="menuitem"
• which in turn means that the descendants CANNOT have a link role. role="menuitem" doesn't permit operable descendants.

The drop button is a general-purpose widget. It could be used for:

• A list navigation links (e.g. Views UI has some links to view a standalone page display), or
• "actions" (e.g. entity operations like edit, delete, etc.) Even though many of these are actually links to other pages, they could be described as actions for which role="menuitem" is appropriate.

So I don't think we can just put aria-haspopup="menu" on all instances of dropbutton, because we won't know for sure if the items are navigation links, or whether they are a good match for role="menuitem".

Possibly we could split the dropbutton into "NavigationDropButton" and "MenuDropButton", but that might lead to a lot of refactoring and maybe developer confusion too.

It doesn't help that web devs/designers routinely speak of "navigation menus" without distinguishing these.

Using aria-expanded (and aria-controls) without aria-haspopup is fine, and well supported.

Re. #11: That's great to know. Looking at the Dropdown Language module, the use case is clearly navigation to other pages.

That's highly relevant to the worries I have in comment #10. I've been reading more opinions around the accessibility community; I'm not alone in worrying about this. It's become a bit controversial as to whether the ARIA menubutton pattern (with menu and menuitem roles) is appropriate for site navigation. The main complaint is that "menuitem" overrides the "link" role, so it's potentially confusing because there's no prior warning that a new page will load.

This issue is overlapping with #2278473: Simplify Dropbutton markup in line with our CSS standards. I was thinking of closing this as a duplicate, but that issue is now proposing a new element, instead of updating dropbutton. Leaving this one open for now, because it's relevant to the current dropbutton.

Updating the proposed resolution:

• Deleting aria-haspopup, it's not appropriate, see #10
• aria-controls has limited support; nonetheless, it works in the assistive tech which supports it. It is appropriate, per the ARIA recommendation for aria-expanded: "If the element with the aria-expanded attribute controls the expansion of another grouping container that is not 'owned by' the element, the author SHOULD reference the container by using the aria-controls attribute." Our button + list relationship matches this.
• Striking the ARIA menu button pattern. Not appropriate, see #14.

Further to #2:

The more-actions button is INSIDE the list container which it controls! I have a feeling that this is an unusual pattern.

It also makes it awkward to use aria-controls appropriately. It would be neater if the button was controlling the visibility of a single UL element, not multiple LI elements. Note the ARIA recommendation doesn't strictly require the use of aria-controls with aria-expanded; it's recommended, but we could get away with omitting it here, because the controlled items are immediately after the button.

It's possible to drop off the end of it by tabbing. The W3C pattern examples use arrow keys to select an action, and loop around the first/last items.

Actually, that's fine. It's the normal behaviour of a simple disclosure button. (Compare with a HTML details group, which doesn't use arrow keys or constrain tabbing either). The arrow keys and tabbing constraint is only expected for the menubutton pattern, which is no longer proposed here since #14.

Pressing escape does nothing in our dropbutton. The W3C pattern collapses the menu button.

This is no longer relevant. It's relevant to the ARIA menubutton pattern, but isn't expected for a simple disclosure button.