RE: [NVDA] #2390: NVDA doesn't handle role=dialog with supporting ARIA attributes according to spec

James, how would one suppress announcement of a calculated label completely
or limit the calculated label on only certain text nodes without using
aria-labelledby?  Rule 2A indicates that if a label is empty then the
subsequent rules should followed so an empty label or aria-labelledby
element wouldn’t work.  That’s particularly why I’m surprised at the empty
description approach mentioned as it seems like an empty description should
follow the same path as an empty label.



I’m not interested in being right in this discussion but finding out what
is the accepted and agreed upon protocol here that we can rely on and
recommend.    There seems to be much disagreement on items.  For instance,
the comments from the NVDA team indicate they rely on iAccessible2/MSAA/UIA
for items – but if you look in IE you will see that IE omits the aria-label
on table elements with a role of dialog and puts the contents of a DIV with
role dialog as the accessible name even when an aria-label is present.  So
IE isn’t following the rules but somehow JAWS uses the DOM to determine the
correct aria-label.   Thus, it’s unclear when assistive technology uses the
DOM versus accessibility API information.



Jonathan



*From:* jnurthen@gmail.com [mailto:jnurthen@gmail.com] *On Behalf Of *James
Nurthen
*Sent:* Wednesday, May 30, 2012 6:51 PM
*To:* Jon Avila
*Cc:* Bryan Garaventa; w3c-wai-ig@w3.org
*Subject:* Re: [NVDA] #2390: NVDA doesn't handle role=dialog with
supporting ARIA attributes according to spec



Jonathan,
I do not agree with this. Even in the accessible name calculation
role="presentation" only serves to prevent the calculation using
the equivalent host language attribute or element for associating a label.
Text children should still be processed normally. Testing this with FF
confirms this behaviour.

<div id="abc">
   <div>Foo</div>
   <div role="presentation">Bar</div>
</div>
<input aria-labelledby="abc" type="text">

<div id="def">
   <div>Foo</div>
   <img src="http://www.w3.org/WAI/images/wai-temp" alt="Bar"
role="presentation">
</div>
<input aria-labelledby="def" type="text">

Querying the FF calculated accessible name (using
nsIAccessibleRetrieval.getAccessibleFor) for the first of these elements
returns "Foo Bar", for the second it simply returns "Foo" as the image has
role="presentation" and that prevents alt being used in the calculation.

I'm not sure this is relevant to the original question though, as the issue
here seems to be that NVDA is assuming that every dialog must have an
accessible description and if one is not provided is attempting to get one
through heuristics. I don't agree with this behaviour from NVDA. If this
behaviour continues then application developers are going to have to write
code such as

<div role="dialog" aria-label="My Useful Dialog"
aria-describedby="emptydiv">
<div id="emptydiv"></div>
<div tabindex="-1">Text of my dialog</div>
</div>

Having to add extra code to work around screen reader issues doesn't seem
like a desireable behaviour.

Regards,
James

On Wed, May 30, 2012 at 3:18 PM, Jon Avila <Jon.avila@ssbbartgroup.com>
wrote:

James,

The presentation role actually had two purposes.  One is to suppress the
native role of an element and required descendants (but not text nodes).
 The other is to influence the naming of controls



Regarding naming widgets - ARIA have a document titled "ARIA User Agent
Implementation Guide".  This guide has a section titled "Name and
Description".  In this section are specific instructions that assistive
technologies (user agents) are supposed to use to determine the name for a
widget.



My reading of rule 2A indicates that role of presentation should affect
whether the item is used for naming.





If aria-labelledby and aria-label are both empty or undefined, and if the
element is not marked as presentational
(role="presentation<http://www.w3.org/TR/2011/CR-wai-aria-20110118/roles#presentation>
", check for the presence of an equivalent host language attribute or
element for associating a label, and use those mechanisms to determine a
text alternative. For example, in HTML, the img element's alt attribute
defines a label string and the label element references the form element it
labels. See How to Specify Alternate
Text<http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.8>
 ([HTML <http://www.w3.org/TR/wai-aria-implementation/#ref_HTML>], section
13.8) and HTML5 Requirements for providing text to act as an alternative
for images<http://www.w3.org/TR/2010/WD-html5-20100624/embedded-content-1.html#alt>
([HTML5 <http://www.w3.org/TR/wai-aria-implementation/#ref_HTML5>], section
4.8.1.1). In the case of HTML frame and iframe elements, the title element
in the head element of the document inside a frame or iframe is used in
this step of the calculation of the name of the frame or iframe.



Hence, AT should be using the label for the label and then ignoring items
in the presentation for labels and descriptions.  For situations where
there is no label and only content within the dialog that has a role of
presentation then my assumption is that no label would be announced.



Jonathan