Refactor aria implementation of collapsible nav

No, the proposal is completely wrong. It doesn't conform to the W3C ARIA recommendation. Don't make either of these changes.

The menu has been built from simple disclosure buttons. We're following the Link + Disclosure Widget Navigation pattern very closely. That's a robust pattern, with minimal moving parts.

It's true that aria-controls isn't widely supported by assistive technology yet. To date, I think JAWS is the only assistive technology which does anything with it. Note, in the Heydon Pickering Menus and Menu buttons article cited, he doesn't actually recommend removing it.

Nonetheless, it works. JAWS provides an indication that the button controls other content, and provides a mechanism to jump to the related content.

A common complaint about the jump mechanism announcement in JAWS is that it doesn't provide much benefit when the controlled content appears directly after the button (as in our case). However JAWS has addressed this by making the announcement obey a user preference. IIRC, it is disabled by default in new JAWS installations.

In assisitive technology which doesn't yet support it, it is just ignored.

In the section about aria-expanded, the ARIA recommendation says: "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 usage matches this, so we should include the machine-readable relationship.

Upshot: keep the aria-controls relationship. It follows the spec, and I don't see a strong case for removing it.

In this case, using aria-haspopup="true" can be used in its place.

Beware of conflating these: aria-haspopup is NOT an alternative to aria-controls. They serve different purposes, and I can imagine uncommon situations which warrant both.

In the W3C fly-out menus tutorial cited, aria-haspopup is used in a way which does NOT conform to the ARIA 1.1 recommendation:

Authors MUST ensure that the role of the element that serves as the container for the popup content is menu, listbox, tree, grid, or dialog, and that the value of aria-haspopup matches the role of the popup container.

The example in the W3C fly-out menus tutorial doesn't control any of these roles.

Olivero's disclosure buttons don't control any of these roles either, so we shouldn't use it. Using aria-haspopup="true" would falsely convey that the list of links behaves as an application menu. We'd be lying to the screen reader!

Aside: the ARIA 1.0 recommendation was rather vague about the meaning of "menu". It wasn't clear whether it meant the ARIA role, or just used the word in a general sense. I expect the W3C tutorial dates from that period. Rather than follow the advice in that tutorial, we ought to file a bug report against it.

Upshot: we shouldn't add the aria-haspopup attribute.

This will inform assistive tech that it opens a menu pop-up

But the problem is that the button DOESN'T reveal menu items. It reveals hyperlinks. This isn't an application menu.

You don't actually need aria-haspopup to convey that additional content will be revealed. The present use of aria-expanded conveys that.