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

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:34:35 UTC