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 Wednesday, 5 February 2014 17:52:29 UTC