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

On 2014-02-14 6:11 PM, Sailesh Panchang wrote:
> My interpretation of  what I expect as a user for the 'I am a
> listitem' SPAN tag is based on the above distinction of aria-label on
> a container and on a  UI control.
>
>>> >>Here's a use case:  a screen-reader/magnifier user.  The magnifier presents an enhanced version of what the browser has rendered on screen, namely "What is my nom de >>plume?".  If, at the same time the screen reader speaks something different, say, "What is my name?", that is going to confuse the user.
> Does this not apply to your example too!
> i.e.
> <span role="listitem">What is my <a href="#" aria-label="name">nom de
> plume</a>?</span>
Not at all.

You previously asked if adding an aria-label would change the content.  
I replied that the content in the a11y tree is the same as that rendered 
on screen.  The AT *can* present the same content as rendered by the 
browser, but that is up to the AT.  My point was that if the content of 
the accessible was different that that rendered on screen then the AT 
could not avoid presenting something different.

In the listitem example, the author provided a label for the link that 
is different from the content.  Nonetheless, both the label and the 
content are available from the accessibility API, as well as other 
information, such as the role, possibly a description, and a variety of 
states and properties.  Part of my point was that each of these pieces 
of information are explicitly individuated in the accessible object. It 
is up to the AT to determine how to orchestrate the presentation of 
these pieces.

I think what you are getting at is that in the case of a list item or a 
link, having the name different from the content is an issue. I agree.  
However, my example was exaggerated to clarify what is going on with 
respect to the ARIA name calculation.  There is no practical reason for 
an author to supply a name of "name" when the content of the link, "nom 
de plume", is sufficient.

Still, there have been other examples on this thread that point to where 
aria-label might be used to be more informative.  Bryan gave this one, 
involving a link to a footnote:

<a href="#" aria-label="footnote1"><sup>1</sup></a>

The visually rendered content is a small, superscript numeral one. Given 
that visual convention, a sighted use will perceive this as "footnote 
1".  But, a superscript is not always indicative of a footnote.  
Sometimes a numerical superscript is an exponent.  The <sup> element 
does not reliably mean "footnote", and a screenreader can't tell what is 
intended from the <sup> markup alone.  The screen reader might be able 
to make that inference from the context that the superscript appears 
within; here, it is a link, and no other mathematical symbols are 
involved. That heuristic may work.  However, the author can do something 
to avoid the heuristic entirely by adding an aria-label to give a better 
idea of what this use of <sup> is for.  Furthermore, the 
magnifier/screen-reader user gets more or the less the same information 
from sight and sound in this example.  They see the visual indicator  
for footnote 1 (a superscript '1'), and they hear "footnote 1" 
(depending on how the screen reader presents the accessible).  The 
visual and audio renderings are consistent and reinforce each other.

Conclusions:
1.  In some cases, the point of allowing the author to provide a label 
is to give a more meaningful name than what would be provided by the 
content alone. If the content is sufficient, authors need not provide 
any additional name.

2.  The accessible objects in the a11y API list various aspects of the 
object as separate pieces of information -- the role is X, the name is 
Y, the content is Z, the checked state is W, the description is V, and 
so on.  An AT can leverage this individuation and provide a meaningful, 
useful presentation.  A screen reader could, for example, say: "List 
item with name 'What is my name?', and content 'What is my link: (nom de 
plume )?'", although I can imagine that, for power users, that level of 
detail could get tedious.  I would hope, though, that screen readers 
allow the user to query an object specifically for its name, contents, etc.

-- 
;;;;joseph.


'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
              - J. D. Klaun -

Received on Monday, 24 February 2014 15:08:44 UTC