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
>
>
>