RE: [aapi] RE: describedby pointing to display:none element (action 1104)

No problem, there are instances where referencing a hidden element using aria-describedby is very helpful for non-sighted AT users to identify important functionality.

Here are two demos of this:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20and%20Readonly)/demo.htm
And
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm

These consist of differing ARIA Combobox controls, editable, readonly, and simulated-readonly, where on non-touch screen devices, aria-describedby is used to convey the required interaction and keystroke for opening the dropdown Listbox.

A sighted mouse user can simply type into an editable combobox and see the dropdown appear, or a sighted keyboard only user can type then use the arrows to scroll through available options intuitively.
Similarly, for readonly fields, the arrow icon indicates directional functionality for sighted keyboard only users, and the sighted mouse user can simply click the icon to open the dropdown.

Since the interaction models differ between editable versus readonly Comboboxes, it is necessary to convey this information in an intuitive and equally accessible manner to non-sighted screen reader users, so that the same information is conveyed when the Combobox field receives focus, because they will not see the arrow icon indicating which arrow direction to press, nor what is intended for that control type when specific interactivity is required.

This also addresses equal accessibility support issues, where some screen readers like JAWS don't actually pass Alt+Down to the control that has focus, making it impossible to open an ARIA Combobox in the same manner as a standard Select element, making it necessary to support the Down arrow by itself for this purpose.

Also, when a touch screen device is detected, the aria-describedby string is programmatically not set, making it easy to code for cross device compatible widgets that do not provide conflicting information, and to customize instructional text as needed without requiring the use of separate components for differing device types.

So I would definitely recommend that aria-describedby remain flexible for control types such as these where accessibility can be significantly enhanced.

Regarding the Description versus Help property, wouldn't that conflict with the previously proposed aria-help attribute? I forget if that was shot down or not.

From: Cynthia Shelly [mailto:cyns@microsoft.com]
Sent: Thursday, January 08, 2015 2:24 PM
To: Schnabel, Stefan; public-pfwg@w3.org; dbolter@mozilla.com; Joanmarie Diggs; Joseph Scheuhammer; James Craig (jcraig@apple.com); wai-xtech@w3.org
Subject: [aapi] RE: describedby pointing to display:none element (action 1104)

(adding CAAM who may not see this thread otherwise.  David, Joseph, Joanie James, and Brian, any thoughts on the use of description field for good or ill by native apps and screen-readers on your platforms?)

Hi Stefan,
Thank you for answering.  Can you help me understand why?


*         What is the use case?

*         Which screen readers make use of it with other browsers or from MSAA in IE?

*         By "we" do you mean SAP?  Are there particular features of SAP that rely on this?  What are they?  Why is aria-describedby pointing to a hidden element the best way to make these features work?


That kind of information will help me make the case.

Thank you,
Cynthia

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Wednesday, January 7, 2015 5:57 AM
To: Cynthia Shelly; public-pfwg@w3.org<mailto:public-pfwg@w3.org>
Subject: RE: describedby pointing to display:none element (action 1104)

We definitely need a proper UIA mapping for hidden describedby texts. Anything less would be insufficient.


-          Regards , Stefan

From: Cynthia Shelly [mailto:cyns@microsoft.com]
Sent: Mittwoch, 7. Januar 2015 02:48
To: public-pfwg@w3.org<mailto:public-pfwg@w3.org>
Subject: describedby pointing to display:none element (action 1104)

https://www.w3.org/WAI/PF/Group/track/actions/1104

I'm looking into this action item relating to mapping aria-describedby pointing to an element that has style=display:none.  In UIA Express, IA2, and ATK/AT-SPI, the te

xt of the referenced node is copied to the accessible description property.  In AXAPI, it is copied to the AXHelp property.

UIA does not have a description property.  I'm trying to decide how to solve this problem, and getting some pushback on the idea of adding one.  Back in the MSAA days, we found that some apps were putting odd things in accDescription, and that a lot of AT didn't use it.  That was, of course, a long time ago.  I notice IA2 and ATK/AT-SPI have description properties.  Are they currently misused or full of junk?  Do AT products make use of this text?

We could also use helptext like Apple does.  James, does this work well for you?  Do you run into collisions with other types of help text?

Here's the relevant bit of the CAAM http://w3c.github.io/aria/core-aam/core-aam.html#details-id-76

Thanks,
Cynthia