Why does the ARIA Menu Button pattern not say to use aria-expanded=true/false but the actual demo examples do use aria-expanded? Seems confusing.

[pauljadam]

I would suggest that the ARIA menu button pattern doc itself say that aria-expanded is used on the menu button to indicate when it is open and closed.

I reference this a lot and would worry that a developer may only think they need to use aria-haspopup=true when they should really also use aria-expanded.

http://w3c.github.io/aria-practices/#menubutton
http://w3c.github.io/aria-practices/examples/menu-button/menu-button-1/menu-button-1.html
http://w3c.github.io/aria-practices/examples/menu-button/menu-button-2/menu-button-2.html

Thanks!

[mcking65]

Paul, when the task force developed the menu button pattern, we discussed aria-expanded and intentionally left it out.

There should have been an issue for removing aria-expanded from the example code. I don't see that issue so maybe this issue will either spur creation of that issue or result in a change to the pattern.

We use expanded on disclosures where focus does not move into the content and the state change is detectable because it is on the focused item.

Activating a menu button moves focus to a menuitem. Then, when focus leaves the menu, the menu closes.

Including expanded on menubutton doesn't break any rules, but it does only seem to add verbosity to the button when the menu is not open. That verbosity isn't particularly useful though.

A menu button is very similar to a button that opens a dialog. Focus moves into the dialog. There is not really any value in adding aria-expanded to a button that opens a dialog because of that.

If we rome into the touch world, there are some edge cases where the menu may not be able to immediately close when the user swipes out of it ... that can be both good and bad. IN such cases, the screen reader might actually observe the button with expanded set to true. However, because of the problems with closing menus in mobile browsers, it might be better for sites to serve disclosure patterns to mobile browsers instead of opening a menu that overlays other content. In that way, the button can also be used to hide the revealed content.

In general, most ARIA patterns are not well supported in mobile browsers, and this is not likely to change until we have accessibility APIs that are better able to support touch. To get around that, in a later release of the guide, we are going to offer more information about which patterns work well with touch and strategies for doing so. That is beyond the scope of the first release though.

[pauljadam]

This is a very common pattern where there's a simple button that opens more links or more buttons to click on as a pop over or a drop down type menu so I need a good pattern here to refer developers to follow when coding.

It seems that WCAG requires the expanded state to be conveyed per 4.1.2 and aria-haspopup only conveys a property not a state.

Most of the ARIA patterns do work on mobile in my experience, the screen reader developers just need to keep fixing ARIA bugs and adding support for the new attributes.

I really like the way the examples with -haspopup and -expanded sound with VoiceOver macOS they read "Actions collapsed pop up button". Does not sound too verbose to me. I feel like you'd be leaving something out if it only said "Actions pop up button".

Is there a different pattern to use or that should be created? I also see that native select inputs on macOS are not speaking expanded states but I don't think these menu buttons really match a select totally, they don't look the same at least.

[mcking65]

@pauljadam,

Thank you for raising this issue; your feedback is helpful.

In our March 20 meeting,
The task force arrived at a compromise recommendation.
It is not documented in detail in the minutes.
So, I am documenting it here and will then seek confirmation from members to ensure I am representing it accurately.

Our recommendation for best practice is:

1. When the menu is not displayed, do not apply aria-expanded to the button.
2. When the menu is displayed, set aria-expanded to true.

This approach minimizes unnecessary verbosity while providing touch users with helpful information.

When a menu is not displayed, the button is announced as a menubutton. This is sufficient to let a user know what the button does.

When a button is displayed, the button is read as an expanded menubutton. On touch devices, users who touch the button will understand that the button may also hide the menu. Keyboard users will not encounter the button in this state because focus is automatically contained in the menu until it is closed.

Again, keep in mind this is a recommended best practice. It is equally valid to build a menubutton that never uses aria-expanded or a menubutton that always uses aria-expanded.

While in isolation the amount of verbosity reduction yielded by this practice may seem insignificant, the cumulative effects of practices like this can be rather dramatic. Every sylable spoken by an aural interface creates cognitive load. Parsing out the essence of what you need to know from all the noise can become overwhelming. When reading through a set of several buttons and discerning which to activate, in the same way that you don't want a bunch of unnecessary distracting visual embellishments, screen reader users can benefit from reductions to the number of redundant or unnecessary sylables they must filter.

Issues to track implementation of this conclusion are:

1. Issue Revise menu button pattern guidance for aria-expanded based on resolution of feedback issue 326 #362: Revise menu button pattern guidance for aria-expanded based on resolution of feedback issue 326.
2. Issue Revise menu button examples to implement updated guidance for aria-expanded that resulted from feedback in issue 326  #363: Revise menu button examples to implement updated guidance for aria-expanded that resulted from feedback in issue 326.

[pauljadam]

Ok thanks for the feedback! So basically the expanding button can either use aria-expanded OR aria-haspopup but not really both until it expands then it could use both.

I'll probably stick to just recommending aria-expanded on a button since it's one less attribute to learn, it handles the state, less spoken since there's no extra -haspopup attribute.

[mcking65]

@pauljadam commented:

I'll probably stick to just recommending aria-expanded on a button since it's one less attribute to learn, it handles the state, less spoken since there's no extra -haspopup attribute.

CAREFUL! Use aria-haspopup if you are making a button that opens a menu ... ALWAYS. The aria-haspopup attrib is the attrib that makes a button a menubutton.

If you have a "expanding button" that just shows content, maybe a list of links or anything else like we have in our disclosure examples, then use aria-expanded but do not use aria-haspopup.

It is really important to get this distinction.

A ppopupmenu overlays content and takes focus.

A disclosure pushes content out of the way and does not move focus.

[mcking65]

Fixes are committed for issues 362 and 363 and task force reviews are in progress. Closing this issue.

[annabbott]

@mcking65 : typos on this page:
Keyboard Interaction
With focus on the button:
Space and Enter: open (typo: should be "opens") the menu and place (typo: should be "places") focus on the first menu item.

[annabbott]

Edit needed on the line about "Space": lower case the "o" on "opens".

Keyboard Interaction
With focus on the button:
Enter: opens the menu and places focus on the first menu item.
Space: Opens the menu and places focus on the first menu item.

[robfentress]

I'm curious, philosophically, why you wouldn't convey as much state information as you can using ARIA. Shouldn't the amount of verbosity be something that is handled at the user agent level?

[accdc]

It's also important to note that aria-expanded cannot always be applicable to ARIA menus, which is why it cannot ever be required.

E.G It is valid to have a right-click ARIA menu attached to a tab or treeitem, both of which support aria-expanded in their own rights, and using this would conflict with the functionality of the other.

So I do recommend aria-expanded on role=menuitem nodes, but not anywhere else for this reason.

E.G What if a right-click ARIA menu is applied to a button that has a seperate show/hide disclosure that already includes aria-expanded? And yes, I have seen this already within enterprise client helpdesk applications.