RE: aria-haspoup values support in AT

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

Received on Monday, 12 October 2020 07:52:14 UTC