aria-haspopup at button should not change role

[JAWS-test]

In my opinion there should be no different role for buttons with aria-haspopup (currently MSAA + IAccessible2: "ROLE_SYSTEM_BUTTONMENU" instead of "ROLE_SYSTEM_PUSHBUTTON").

reasons:

1. aria-haspopup can also be located on other elements (e.g. links) and does not cause any other role.
2. aria-haspopup at button does not automatically mean that it is a button with menu (listbox, tree, grid, dialog)
3. in the screenreader (e.g. JAWS, version 13 - 2019) the specification leads to an erroneous output as "button menu" with various consequential errors (e.g. in IE 11: no output of aria-roledescription, aria-expanded, change to form mode, no output as "menu", if aria-pressed at button etc.; the problems also occur partially with Chrome and Firefox, only Edge ignores the specification and always outputs buttons correctly as buttons), see: JAWS does not announce aria-expanded on a native button element if aria-haspopup is present (regardless of its boolean/token value). FreedomScientific/standards-support#211

[jcsteh]

1. aria-haspopup can also be located on other elements (e.g. links) and does not cause any other role.

That's true. However, the MSAA spec states for ROLE_SYSTEM_BUTTONMENU: "The object represents a button that expands a menu." So the intent here was to conform with the MSAA spec. Generally, it's ideal if ARIA mappings conform with existing platform APIs/conventions as far as possible.

2. aria-haspopup at button does not automatically mean that it is a button with menu (listbox, tree, grid, dialog)

That's also true. However, Firefox at least already handles this:

data:text/html,<div role="button" aria-haspopup="dialog">Test</div>

results in ROLE_SYSTEM_BUTTON, not ROLE_SYSTEM_BUTTON MENU.

3. in the screenreader (e.g. JAWS, version 13 - 2019) the specification leads to an erroneous output as "button menu" with various consequential errors (e.g. in IE 11: no output of aria-roledescription, aria-expanded, change to form mode, no output as "menu", if aria-pressed at button etc.; the problems also occur partially with Chrome and Firefox

Given that this has been the mapping in the spec and browsers for years, that's a bug in JAWS, not the spec. It's reasonable to debate whether the mapping should have been this way in the first place, but IMO, it's not valid to say it's a bug in the spec because of incorrect behaviour in a single AT product.

All of that said:

1. Generally, I agree that mutating the role based on states is kinda weird.
2. However, because of the documented behaviour in the MSAA spec, there may be clients which depend on this.
3. The NVDA screen reader doesn't care either way; it'll just say "button" instead of "menu button", but either way, it will announce the states.
4. Because of 2), before this could be changed, it would need to be verified with other AT products; e.g. Dolphin SuperNova, Baum Cobra (assuming it's still being supported), ZoomText, etc.
5. The change would then need to be made in both Firefox and Chrome.
6. Given the amount of work for 4) and 5) and potential unanticipated backwards compat breakage (vs a small fix in a single product), this seems difficult to justify. That said, if the consensus is to change the spec, we can make the change in Firefox easily enough.

[JAWS-test]

Hello @jcsteh, thank you very much for the answer. Unfortunately it does not convince me.

1. MSAA defines many roles that do not exist in ARIA and HTML. MSAA also has ROLE_SYSTEM_BUTTONDROPDOWN and ROLE_SYSTEM_BUTTONDROPDOWNGRID. This would correspond to aria-haspopup=listbox and =grid, but is not specified. Furthermore, the definition of ROLE_SYSTEM_BUTTONMENU does not match that of button with aria-haspopup ("The object represents a button that expands a menu" vs. "Indicates the availability and type of interactive popup element, such as menu or dialog, that can be triggered by an element.").
2. Firefox only outputs buttons with aria-haspopup=true as menu buttons, all others as buttons, also aria-haspopup=menu (Note: This does not mean the output by the screen reader, but MSAA and UIA, detected with Inspect.exe). This is a violation of the ARIA specification, which says that aria-haspopup=true is the same as =menu (http://www.w3.org/TR/wai-aria-1.1/#aria-haspopup).
3. The incorrect definition in https://www.w3.org/TR/core-aam-1.1/ only applies to MSAA + IAccessible2, but not to the remaining interfaces.
4. If the incorrect output by JAWS is not a reason to change the specification (this I would agree), then the output in Dolphin SuperNova, Baum Cobra, ZoomText should not matter and should not need to be checked. The specification should simply be correct, the screen readers should then follow it.

[jcsteh]

1. MSAA defines many roles that do not exist in ARIA and HTML. MSAA also has ROLE_SYSTEM_BUTTONDROPDOWN and ROLE_SYSTEM_BUTTONDROPDOWNGRID. This would correspond to aria-haspopup=listbox and =grid, but is not specified.

That's possibly just something that wasn't considered when these were specified. I'd argue it's more reasonable to say that this is a bug in the spec. That said, while ROLE_SYSTEM_BUTTONMENU has been seen in desktop apps outside of ARIA, I don't think the other roles you mention have been used anywhere (certainly, I can't recalling seeing them in 10+ years of screen reader development).

Furthermore, the definition of ROLE_SYSTEM_BUTTONMENU does not match that of button with aria-haspopup ("The object represents a button that expands a menu" vs. "Indicates the availability and type of interactive popup element, such as menu or dialog, that can be triggered by an element.").

aria-haspopup="menu" indicates that a menu can be triggered by the element (in this case button). I don't see how that fails to comply with "The object represents a button that expands a menu".

2. Firefox only outputs buttons with aria-haspopup=true as menu buttons, all others as buttons, also aria-haspopup=menu (Note: This does not mean the output by the screen reader, but MSAA and UIA, detected with Inspect.exe). This is a violation of the ARIA specification, which says that aria-haspopup=true is the same as =menu

Yes, this is a spec violation. We should fix it.

3. The incorrect definition in https://www.w3.org/TR/core-aam-1.1/ only applies to MSAA + IAccessible2, but not to the remaining interfaces.

The remaining interfaces probably don't have an equivalent existing role.

4. If the incorrect output by JAWS is not a reason to change the specification (this I would agree), then the output in Dolphin SuperNova, Baum Cobra, ZoomText should not matter and should not need to be checked. The specification should simply be correct, the screen readers should then follow it.

It does need to be checked if we're making a change to the spec to get rid of ROLE_SYSTEM_BUTTONMENU, since the change would be backwards incompatible. Of course, if we're not changing the spec, nothing has to be checked.

[jcsteh]

To be clear, the reason I'm saying things need to be checked with other AT if we choose to change something here is that this has been in the spec for many years now. Other AT may be relying on that behaviour. If we're changing the spec to fix one AT and we end up breaking three others, that's not a great situation to be in.

FWIW, if we were seeing this bug in multiple AT products, I'd probably just argue we should change the spec for pragmatic reasons.

[JAWS-test]

If the output has to be checked with another AT: who does that? Do I have to do that? I don't have any experience with the other screen readers and don't have any licenses for them either.

[joanmarie]

@JAWS-test: Rather than test functionally, it would probably make sense to get the developers of those screen readers to chime in here. Thanks!

[JAWS-test]

@joanmarie: I have no contact to any screenreader manufacturers. In my opinion it is not a problem with the screenreader, but with the specification. I think the specification should be correct, no matter what the screenreaders do.

[jnurthen]

I agree with @JAWS-test that there is clearly a problem here.
Specifying role="button" aria-haspopup="dialog" should not result in ROLE_SYSTEM_BUTTONMENU
IMO we should change the mapping from
button with non-false value for aria-haspopup
to
button with aria-haspopup set to true or menu
The other values of aria-haspopup should follow the mapping for button with default values for aria-pressed and aria-haspopup

[brennanyoung]

"if we were seeing this bug in multiple AT products, I'd probably just argue we should change the spec for pragmatic reasons."

I can report that we are seeing this bug in multiple AT products, because all those products rely on what ends up in the accessibility tree. AFAICT none of them try to ameliorate the problem, which would require ATs inspecting the code which generated the accessibility tree.

In general, changing the role to menubutton even when the button opens a dialog is going to continue to cause problems for authors and testers as long as the ARIA 1.1. values are in spec, so it should be regarded as a bug (even if AT users have learned to tolerate this behaviour).

[aleventhal]

Can we revisit this? It came up for some of our products at Google.
How about we just change the rule for role=dialog, which is the one that causes the worst experience?

[aleventhal]

I'm going ahead with a change to Chrome that uses a regular button role when aria-haspopup=dialog. This keeps coming up and is an obvious usability issue. We can always tweak the Chrome impl further based on what the group decides.
https://chromium-review.googlesource.com/c/chromium/src/+/4081366

[jcsteh]

I 100% support a change to the spec such that anything other than "true" or "menu" keeps the button role. The situation is less clear for "true" and "menu", though. I'm not saying i wouldn't support it, but I do think backwards compat is a potential concern that shouldn't be dismissed purely for spec correctness/cleanliness.

[aleventhal]

@jcsteh how about just changing for role=dialog?
That's the one that creates a problem for users, from what I hear from @scottaohara.
It's not only the announcement, but how if affects the reading mode.

[jcsteh]

I have no strong objection to just making this change for aria-haspopup="dialog", though I don't really follow why we wouldn't want to make the change for other values except for true and menu. I guess doing it only for dialog is the most risk averse approach. On the other hand, this was mapped to menu button at a time when a menu was the only option and it arguably does make some sense for menus. I don't think it makes any sense at all for grids, etc. and I don't think the menu button role was ever intended to be used that way, so I don't think this is a backwards compat risk.

[stevefaulkner]

I suggest it should only expose a menu button role for values of haspopup that have a high likelihood of displaying a menu.

[aleventhal]

Temporarily to fix the worst problem, we just changed this for dialog. We wanted to fix interactions with screen reader modes, where it's expected that down arrow should move into the object.

Am happy to change more of them if that's what the group decides, but at the same time, it's probably acceptable right now and not a high priority for us. If there's a spec update, we will comply with that.