- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Wed, 05 Feb 2014 10:01:26 -0500
- To: Bryan Garaventa <bryan.garaventa@whatsock.com>, wai-xtech@w3.org
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 15:02:04 UTC