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

I understand the point regarding embedded active elements, however this is 
actually documented as part of the calculation.

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

Rule 2B deals specifically with embedded active elements.

Here though, I'm simply referring to plain text, which appears to be valid.

Granted screen readers can do whatever they wish, however without adhering 
to basic principles to provide basic behavior such as this, nothing in ARIA 
will ever be scalable in the future, because nothing will be reliable.



----- Original Message ----- 
From: "James Craig" <jcraig@apple.com>
To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>; "James Teh" 
<jamie@nvaccess.org>; <mick@nvaccess.org>
Cc: "Sailesh Panchang" <sailesh.panchang@deque.com>; "Schnabel, Stefan" 
<stefan.schnabel@sap.com>; "Joseph Scheuhammer" <clown@alum.mit.edu>; "WAI 
XTech" <wai-xtech@w3.org>
Sent: Wednesday, February 05, 2014 11:48 PM
Subject: 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 16:47:07 UTC