-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aria-haspopup at button should not change role #51
Comments
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.
That's also true. However, Firefox at least already handles this:
results in ROLE_SYSTEM_BUTTON, not ROLE_SYSTEM_BUTTON MENU.
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:
|
Hello @jcsteh, thank you very much for the answer. Unfortunately it does not convince me.
|
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).
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".
Yes, this is a spec violation. We should fix it.
The remaining interfaces probably don't have an equivalent existing role.
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. |
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. |
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. |
@JAWS-test: Rather than test functionally, it would probably make sense to get the developers of those screen readers to chime in here. Thanks! |
@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. |
I agree with @JAWS-test that there is clearly a problem here. |
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 |
Can we revisit this? It came up for some of our products at Google. |
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. |
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. |
@jcsteh how about just changing for role=dialog? |
Note that we are making this change ahead of the spec change, because it's an obvious usability improvement that keeps coming up. Will also drive the spec change. Bug: w3c/core-aam#51 Change-Id: Ie06afeae4118b868eaee6471f8bda9d31b25a027 AX-Relnotes: buttons with aria-haspopup=dialog will no longer use the button menu role, because it's both misleading to the user and to the screen reader, which might trigger the wrong mode. Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4081366 Reviewed-by: Mark Schillaci <mschillaci@google.com> Auto-Submit: Aaron Leventhal <aleventhal@chromium.org> Commit-Queue: Mark Schillaci <mschillaci@google.com> Cr-Commit-Position: refs/heads/main@{#1080035}
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. |
I suggest it should only expose a menu button role for values of haspopup that have a high likelihood of displaying a menu. |
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. |
Is this still an issue? There was a PR to change some docs, but I'm not sure if the underlying issue still exists. |
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:
The text was updated successfully, but these errors were encountered: