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

Good there seems to be agreement all around!
Yes screen readers / magnifiers, etc. are assistive technologies first
whose primary role is to provide accommodation to their users while
they navigate an environment that is quite often inaccessible.
The SRs quite effectively guess the column / row headers for a simple
data table that does not have TH or scope or the most likely label
text for a form control when there is no for-id  or ARIA markup etc.
Essentially they look for the accessibility markup and when it is
absent then resort to their fallback logic for providing
accommodation.
But when the accessibility attributes are present, they need to
interpret them in line with the specs for the technology uniformly and
reliably.
It is also a function of how the At gets the markup: whether directly
or by relying on the browser to expose it. If it is the latter, then
the browser too has to work correctly in line with the specs.
Regards,
Sailesh


On 2/6/14, Bryan Garaventa <bryan.garaventa@whatsock.com> wrote:
> 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 17:28:38 UTC