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

Jonathan,
See inline.

On Wed, May 30, 2012 at 4:21 PM, Jonathan Avila
<jon.avila@ssbbartgroup.com>wrote:

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

Why do you remove using aria-labelledby as a possibility? It seems like the
correct approach.


>   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 don't read 2A like this. It reads "if aria-labelled by or aria-label is
empty or undefined". It does not mention anything about aria-labelledby
pointing to a valid element which contains no content.


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

I agree. As there is disagreement we need the spec to be clarified. I'll
raise it to PFWG as I think this text needs re-wording.


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

That doesn't sound right. What version of IE - and are you inspecting MSAA
or UIA? Can you provide me a testcase and I'll take a look into the test
files and make sure they are covered in the CR exit tests.


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

Yep - it is unclear. It would be great is they always used the
accessibility API as we would then have consistency.

regards,
James


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