Matt, I just want to point out one tiny use case. You said:
In this case, the solution for authors is simple -- don't use the unsupported token values. Doing so does not create any negative side effects for users.
We have a select-only combobox that opens a dialog. The spec for
combobox says:
Elements with the role combobox have an implicit aria-haspopup value of listbox. If the combobox popup element has a role other than listbox, authors MUST specify a value for aria-haspopup that corresponds to the role of its popup.
In this particular use case, I think the token could be useful. A sighted user activating this particular combobox will not be terribly surprised when they get a dialog. It is visually apparent that the dialog is the popup, because the top of the dialog is aligned with the bottom of the combobox, as well as other visual cues like the dialog is transitioned in when the combobox is opened. So I don't think it's a "cognitive leap" for the sighted user to understand that they dropped down a combobox and got a dialog.
Just guessing, though, that it might be a bit different for a screen reader user. Most of the time, dropping down a combobox gives a listbox. If it's a grid or a tree, well, they're kind of list-like, so no big deal. But if you're suddenly in a dialog, the reaction might be "Huh?". So I'm thinking it might be useful to know ahead of time that the combo has a dialog. Perhaps something as simple as, "Repository combobox, collapsed dialog".
Car
----- Original message -----
From: "Schnabel, Stefan" <stefan.schnabel@sap.com>
To: Matt King <a11ythinker@gmail.com>, 'James Nurthen' <nurthen@adobe.com>
Cc: 'ARIA Working Group' <public-aria@w3.org>
Subject: [EXTERNAL] RE: aria-haspoup values support in AT
Date: Mon, Oct 12, 2020 3:52 AM
Hi Matt, James,
@Matt: thanks a lot for the explanation.
@James: *please* bring this to the agenda of one of the next ARIA calls as a general example how different WG member expectations still are for properties that have been rated as definitive and OK long time but are not supported by AT in practice because of mixed impressions of their usefulness, API mapping issues etc.
@all: I think we all agree that not speaking defined property values is as least confusing. The ARIA spec should start to define in future a minimal consensus speech output expectation per role/property value at least to avoid that. If we leave that in vagueness it will cause distrust an irritation both with developers and testers.
Best Regards
Stefan
-----Original Message-----
From: Matt King <a11ythinker@gmail.com>
Sent: Sonntag, 11. Oktober 2020 19:55
To: Schnabel, Stefan <stefan.schnabel@sap.com>; 'James Nurthen' <nurthen@adobe.com>
Cc: 'ARIA Working Group' <public-aria@w3.org>
Subject: RE: aria-haspoup values support in AT
Stefan,
I think we didn't spec the new aria-haspopup tokens very well when we added them to ARIA 1.1. We didn't really work through all the ramifications of the new values on accessibility APIs and assistive technologies.
Originally, we added the new haspopup tokens for the combobox role because there was some concern that screen readers need to know that the combobox would open something other than a listbox. I don't think that concern has been manifest in practice. I don't think screen readers need an attribute that tells them what kind of popup a combobox will open.
In addition, haspopup on a button changes the role of the button to menu button in some accessibility APIS. So, when people started adding haspopup equal dialog on buttons, they got menu buttons that open dialogs -- talk about confusing users!!
I wish we would have had our 1.2 process that includes developing practices and testing with screen readers when we were developing ARIA 1.1. Then, maybe we would not have changed aria-haspopup. But, that train left the station a few years ago now.
One corrective course of action could be to invalidate use of any aria-haspopup token except for false, true, and menu unless applying it to a combobox. Then, if assistive technology developers and accessibility API developers come to consensus that other uses would bring meaningful value to end users, we could expand support based on that consensus.
In the near term, it is not clear to me that there is any real world value to be gained from modifying accessibility APIs and browsers so that assistive technologies can know in advance what kind of popup an element will open. Even if there is some theoretical value, I think we would be better off using our resources to repair the other support gaps that do not require accessibility API changes and cannot be avoided by authors. In this case, the solution for authors is simple -- don't use the unsupported token values. Doing so does not create any negative side effects for users.
Matt
-----Original Message-----
From: Schnabel, Stefan <stefan.schnabel@sap.com>
Sent: Friday, October 9, 2020 4:19 AM
To: James Nurthen <nurthen@adobe.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: aria-haspoup values support in AT
James,
Would you agree that the current aria-haspoup value support (dialog, grid etc.) in all AT across all platforms is currently barely non-existing?
I mean devs set these values and wonder why the actual values are not reflected in current AT speech output.
Where is the central place to discuss and list such AT lack of support for Aria attributes?
Is there a central reference the group consults on a regular base to get a common overview?
Would you please mind to set these questions on the agenda for the next WG call?
Best Regards
Stefan