search

w3c / core-aam

Core Accessibility API Mappings
https://w3c.github.io/core-aam/
38 stars 10 forks source link

aria-haspopup at button should not change role #51

Open JAWS-test opened 5 years ago

JAWS-test commented 5 years ago

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: https://github.com/FreedomScientific/VFO-standards-support/issues/211
jcsteh commented 5 years ago 
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 commented 5 years ago

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 commented 5 years ago 
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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 4 years ago

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 commented 2 years ago

"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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

aleventhal commented 1 year ago

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.

KevinGhadyani-Okta commented 1 month ago

Is this still an issue? There was a PR to change some docs, but I'm not sure if the underlying issue still exists.