Re: Regarding the accessible name calculation for aria-label within links?

> "Sailesh Panchang" <sailesh.panchang@deque.com> wrote:
> 
>> I believe, NVDA is at fault for completely ignoring the aria-label on the anchor.


Hi Bryan and Sailesh, (also adding Jamie and Mick from NVDA)

The problem is a lot more complicated than this, starting with the fact that screen readers, like browsers, attempt to present the best information for the user, whether or not the author has presented it properly. The text alternative computation is there to provide guidance as to what the user agent should expose to the API, but it is not intended to prevent screen readers from speaking anything other the computed label.

For example, given the following heading with contained links:

<h1 aria-label=foo><a href=#>bar</a> baz <a href=#>bop</a></h1>

According to your understanding of the text alternative computation, the label should be “foo” for the heading. This is accurate, but if the screen reader only spoke “heading level 1, foo” it would mask the fact that the heading contained links, so the user agent exposes the tree, including the child contents like the links with their respective labels, and the screen reader puts together its best description based on this. Any number of different speech strings could be considered “correct” and the screen readers developers tweak differences in the output frequently to improve the end user experience.

“heading level 1, foo, with 2 links, bar bop”
“heading level 1, foo, with 3 items”
“foo, link bar, link baz, level 1 heading”
etc. etc.

While it can be frustrating to web authors that the experience is not identical on each screen reader, the reason is because the screen reader is intended for the users, not the authors, and the users often appreciate knowing this additional information whether or not the author intended them to hear it.

Consider how different the interface is between JAWS in Microsoft Word on Windows, versus VoiceOver in Pages on Mac OS X, yet these are both “document” views similar to most web pages, so each platform and screen reader continues user interaction patterns from those interfaces into web content in browsers. If the W3C were to *decree* specific screen reader behavior on the Web, it would undoubtedly mean that the behavior on one or more system would be radically different than the users of that system expected due to their experience with other non-web-based applications and interfaces. This is why decreeing specific screen reader behavior is considered to be outside the scope of the W3C… These behaviors are not specific to web content, so it’s up to the platform and software vendor to decide how the interface should work.

In summary, while I would agree with you that all screen readers can and should continue to improve support for these interfaces, this particular issue may or may not be something that can be considered a “bug” within the context of ARIA, because ARIA only defines web content structure and browser to API mappings. ARIA does not decree any specific behavior of assistive technologies like screen readers. It may very well be a bug, but you'd need to convince the NVDA team of that, not a W3C Working Group.

Cheers,
James


On Feb 5, 2014, at 11:15 AM, Bryan Garaventa <bryan.garaventa@whatsock.com> wrote:

> Thanks, I understand.
> 
> The question I was given by a client though was, why does following the guidance specified at
> http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
> appear not to be accurate when the markup follows the order preference as documented?
> 
> The example sited was visually intuitive, but needed a more informative label for screen reader users as part of a standard link via aria-label.
> 
> So they thought the W3C documentation was wrong when JAWS and NVDA treated them differently.
> 
> It appears to me that the opposite is true. The W3C documentation for both the Roles Model and User Agent pages is correct, but that the screen readers are interpreting this differently, which is leading to the problem when programmers use this documentation to enhance accessibility and then get conflicting results when they test it.
> 
> The typical response I get from developers when this happens is, it's ARIAs fault...
> 
> ----- Original Message ----- From: "Sailesh Panchang" <sailesh.panchang@deque.com>
> To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>
> Cc: <stefan.schnabel@sap.com>; "Joseph Scheuhammer" <clown@alum.mit.edu>; <wai-xtech@w3.org>
> Sent: Wednesday, February 05, 2014 9:52 AM
> Subject: Re: Regarding the accessible name calculation for aria-label within links?
> 
> 
>> Bryan,
>> I believe, NVDA is at fault for completely ignoring the aria-label on
>> the anchor.
>> Practically speaking, with reference only to an anchor element with
>> visible anchor text:
>> If some additional (descriptive / advisory) text is needed to more
>> clearly convey the link's purpose especially to non-sighted users, the
>> title attribute is better suited.
>> JAWS reads the title if it is different from anchor text ... I had
>> suggested this to FS long time ago and it has been implemented since
>> JAWS 13 I think.
>> NVDA which depends on Firefox exposes both title and anchor text even
>> if they are identical.
>> The title is exposed on mouseover to users who might  be able to use a
>> mouse and discover it.
>> If aria-label text is also to be rendered along with the anchor text,
>> I think it is a mere duplication of the title attribute and it is
>> quite redundant then.
>> Besides, only ARIA-enabled browser/AT users can use it. And it is
>> simply not exposed visually.
>> 
>> Aria-label  on an anchor  with visible anchor text is useful only when
>> assistive technology  render the aria-label text and not the anchor
>> text.
>> This migh be of use in some situations mainly to help non-sighted
>> users understand the link's purpose .
>> Thanks,
>> Sailesh
>> 
>> On 2/5/14, Bryan Garaventa <bryan.garaventa@whatsock.com> wrote:
>>> Thanks, that does help a lot.
>>> 
>>> When using Firefox with JAWS, it does indicate the aria-label value as the
>>> label for the link, only in IE does this differ, so I'm inclined to enter a
>>> 
>>> bug to match the Firefox functionality since it seems to most closely match
>>> 
>>> the spec.
>>> 
>>> Stefan, thanks, I see what you mean.
>>> 
>>> The part of the calculation that appears to be most relevant here though is
>>> 
>>> where it says
>>> 
>>> Authors MAY specify an element's text alternative in content attributes,
>>> used in this order of preference:
>>>  a.. The aria-labelledby attribute takes precedence as the element's text
>>> alternative unless this computation is already occurring as the result of a
>>> 
>>> recursive aria-labelledby declaration (in other words, aria-labelledby is
>>> not recursive when referenced from another element, so it will not cause
>>> loops). However, the element's aria-labelledby attribute can reference the
>>> element's own IDREF in order to concatentate a string provided by the
>>> element's aria-label attribute or another feature lower in this preference
>>> list. The text alternatives for all the elements referenced will be computed
>>> 
>>> using this same set of rules. User agents will then trim whitespace and join
>>> 
>>> the substrings using a single space character. Substrings will be joined in
>>> 
>>> the order specified by the author (IDREF order in the aria-labelledby
>>> attribute).
>>>  b.. If aria-labelledby is empty or undefined, the aria-label attribute,
>>> which defines an explicit text string, is used. However, if this computation
>>> 
>>> is already occurring as the result of a recursive text alternative
>>> computation and the current element is an embedded control as defined in
>>> rule 2B, ignore the aria-label attribute and skip directly to rule 2B.
>>> 
>>> Since rule 2B appears to deal with embedded active elements and not plain
>>> text via static elements, it appears not to be applicable.
>>> 
>>> So it looks like JAWS is doing this correctly in Firefox, but not within IE,
>>> 
>>> and NVDA isn't following the order of preference in either IE or FF.
>>> 
>>> Granted nothing here is mandated, but it would be nice if they were
>>> consistent. :)
>>> 
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>> From: "Joseph Scheuhammer" <clown@alum.mit.edu>
>>> To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>; <wai-xtech@w3.org>
>>> Sent: Wednesday, February 05, 2014 7:01 AM
>>> Subject: Re: Regarding the accessible name calculation for aria-label within
>>> 
>>> links?
>>> 
>>> 
>>>> Hi Bryan,
>>>> 
>>>>> So, if I understand correctly, the following link
>>>>> 
>>>>> <a href="#" aria-label="December 31, 2013">31</a>
>>>>> 
>>>>> Should be named "December 31, 2013" in Applications/Browse Mode as well
>>>>> as within the Virtual Buffer.
>>>> 
>>>> Given your example the accessible name exposed through the a11y API is
>>>> "December 31, 2013".
>>>> 
>>>> The A element is exposed as a link in the a11y API.  The characteristics
>>>> table of the link role states that the can come from either the author or
>>>> 
>>>> the contents (http://www.w3.org/TR/wai-aria/roles#link).  In other words,
>>>> 
>>>> the author can specify a name if they choose.  If they don't, then the
>>>> name defaults to the contents.
>>>> 
>>>> I tested your example with FF 27, and Safari 6.1.1, and used an inspector
>>>> 
>>>> to see what was exposed through the a11y API.  FF exposes "December 31,
>>>> 2013" as the name.  Safari exposes it as the description.  The latter is
>>>> expected according to the UAIG (see the states and properties table entry
>>>> 
>>>> for aria-label for AXAPI:
>>>> http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property_table).
>>>> 
>>>> In short, both browsers are conforming to the ARIA documents.
>>>> 
>>>> As for how screen readers present this in application/browse mode versus
>>>> the virtual buffer, that's beyond the ARIA specifications. At present, the
>>>> 
>>>> specs state what browsers must/should do with the aria markup and leave it
>>>> 
>>>> to the ATs to decide how to present it.
>>>> 
>>>> Hope that helps.
>>>> 
>>>> --
>>>> ;;;;joseph.
>>>> 
>>>> 
>>>> 'A: After all, it isn't rocket science.'
>>>> 'K: Right. It's merely computer science.'
>>>>             - J. D. Klaun -
>>>> 
>>> 
>>> 
>>> 
> 
>

Received on Thursday, 6 February 2014 07:49:25 UTC