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

In MSAA, aria-describedby content is exposed as AccDescription. Screen
readers like NVDA, and in some cases JAWS, too, read the accDescription
as secondary announcement after the name, role, and states of a control
when it receives focus or focus is queried and the control happens to
have one.

accDescription is usually not picked up automatically in the virtual
buffers of respective screen readers, except of course where it is
exposed in the accessible tree of a page anyway.

having said all that, I think there is a bug in Firefox where content
that is hidden via said CSS is not exposed as AccDescription to screen
readers. So content that is to be exposed has to be either visible
anyway or hidden via a screen reader compatible means.

As for actual usage: I have mostly seen aria-describedby used in
examples to show what it does, but not really in actual accessible web
apps much. That doesn't mean it doesn't exist at all, just that I
haven't come across it much in my day to day usage.

Marco

On 09.01.2015 00:25, Bryan Garaventa wrote:
>
> 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
> <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20%28Native%20Inputs,%20Editable%20and%20Readonly%29/demo.htm>
>
> And
>
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm
> <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20%28Simulated,%20Readonly%29/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
>
>  
>
>  
>