- From: Bryan Garaventa <bryan.garaventa@whatsock.com>
- Date: Wed, 5 Feb 2014 11:15:46 -0800
- To: "Sailesh Panchang" <sailesh.panchang@deque.com>
- Cc: <stefan.schnabel@sap.com>, "Joseph Scheuhammer" <clown@alum.mit.edu>, <wai-xtech@w3.org>
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 Wednesday, 5 February 2014 19:16:18 UTC