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

Hello James,
For recommendations on use of aria-label please refer to
http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140107/aria.html
Specifically ARIA6, ARIA8, ARIA11 (example 3), ARIA 14

I think it is necessary to draw a distinction between elements like an
anchor, any form control vis a vis a div when it is a container for
other elements / content.
<div role="navigation" aria-label="navigation">
with nav elements
</div>
The aria-label identifies the div. The content also should be available to AT.
But for an anchor or button on the other hand, aria-label overrides
the content of the link or button.
Regards,
Sailesh



Thanks,
Sailesh Panchang


On 2/13/14, James Teh <jamie@nvaccess.org> wrote:
> Hi all,
>
> It's documented as part of the calculation for the name exposed by
> accessibility APIs. That's not necessarily the content that is most
> relevant for the user for a given element.
>
> For links, it is certainly desirable that aria-label(ledby) completely
> override the content. This is also true for buttons, among others.
> However, this is not at all true for, say, an editable text field, list,
> table, landmark or region, where the user definitely needs the content.
> The question that doesn't seem to be covered explicitly by the spec as
> far as I can see (and I'm very happy to be informed otherwise) is when
> aria-label(ledby) should completely override the content (e.g. links and
> buttons) and when it shouldn't (e.g. landmarks and regions). To
> complicate matters further, spans and divs without an ARIA role but with
> both aria-label(ledby) and content are a very grey area. So, it's a lot
> less simple than it seems on the surface.
>
> We're told we should support aria-label(ledby) overriding "in line with
> spec", but that's very difficult to do when the spec doesn't clearly
> define this point. That's not necessarily a flaw in the spec as such; as
> James rightly points out, it wasn't really designed to cover AT
> behaviour. That said, we can hardly be accused of failing to comply with
> the spec if it doesn't address this point.
>
> We can of course make our own decisions about when we should and
> shouldn't do this, but that would technically not be according to spec,
> so authors can't expect the same behaviour in this regard with different
> ATs.
>
> On reflection, we can probably use the "Name from: contents" property as
> a guide here, but that's definitely not an obvious rule.
>
> Jamie
>
> On 7/02/2014 2:44 AM, Bryan Garaventa 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 -
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
> --
> James Teh
> Director, NV Access Limited
> Ph + 61 7 5667 8372
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @nvaccess
>

Received on Thursday, 13 February 2014 19:06:11 UTC