Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ARIA: The accessible name calculation for links including aria-label doesn't match the accessibility tree in the Virtual Buffer using IE and FF #3852
Reported by bgaraventa on 2014-02-05 23:27
E.G. Referenced from: http://www.w3.org/TR/wai-aria/roles#namecalculation
As a result, the name of the link that is announced by NVDA, does not match the accName property of the link as it exists within the accessibility tree.
For example, the following code is a standard link that uses aria-label to set a screen reader specific label:
When the accessibility tree accName property is viewed, "December 31, 2013" is set as the name for the link.
However, when using the arrow keys or tabbing to read the link name, "31" is announced by NVDA instead, which doesn't match the accessibility tree.
Confirmed on Win XP Pro and Win 7, using IE8 through 10 and the latest release of Firefox.
Steps to reproduce:
Comment 1 by jteh on 2014-02-06 01:51
Of course, if there is somewhere in the spec which documents exactly how and when this should be done without causing these and other problems, we'd be happy to implement it.
Comment 3 by spanchang02 on 2014-02-10 16:32
On pressing the 'D' key to jump to the landmark, NVDA should say 'Navigation landmark secondary'. or better 'secondary navigation landmark'.
The response to #1195 that 'Main' or 'Secondary' should be marked up as a heading above the navigation links is wishful thinking. A Web page is designed based mainly on the visual UI specss. That's why
Comment 4 by jteh (in reply to comment 3) on 2014-02-10 23:50
On the other hand, no one who has made any of these requests has given a satisfactory explanation of how to implement this without breaking other use cases and without making arbitrary decisions that aren't justified by spec.
And where in the spec does this concept of "identifier" come from?
If you'd thoroughly considered my point, you will note I said "If we always use the name reported by the browser". The point is that we can't just blindly use the name given to us by the browser as the reporter suggested, otherwise we will lose semantic and formatting information in all cases, not just aria-label.
"The element's name". They say nothing about whether the name gets rendered by a screen reader in browse mode. That is the crux of the issue.
I'm aware of that. My point was that the request to have aria-label override content conflicts with that of labelling landmarks and regions.
But you said above that for links, we should override the content with the aria-label. So which is it? Do we override the content with the label or not? How do we know which? Where is this choice clearly defined in the spec? As far as I can see, the spec only talks about the name. It doesn't talk about which should be treated as content as far as the user is concerned.
So on one hand, you want us to comply with the spec. On the other, you want us to violate it to compensate for incorrect markup. Which is it to be?
If you want to talk about spec compliance, go ahead and quote the sections of the spec that clearly state when we should render aria-label instead of content and when we should render content instead of aria-label. That has always been the debate here.
Comment 5 by bgaraventa on 2014-02-11 23:46
For a scenario where developers wish to provide a more informative label for screen reader users as part of a link, aria-label or aria-labelledby is provided according to the W3C accessible naming calculation. If a developer follows it, they would expect that the screen reader would provide the more informative label to the user.
Currently nothing added via aria-label is conveyed by NVDA however, which is why I filed the bug.
One way to accommodate for differences, is to provide an NVDA setting regarding feedback, the default following the W3C naming calculation and reading aria-label or aria-labelledby instead of inner text when present, another that would read only the screen text and not the aria-label/aria-labelledby association, and a third that would read both together.
In this way, you could provide a method to achieve any desired level of access and still adhere to the naming convention for active elements with native or explicit role associations.
The desired feedback level would then be up to the user.
Comment 6 by jteh (in reply to comment 5) on 2014-02-12 00:21
The question is how you define "active elements" (and whether that is covered by the spec).
That's fine for a link, but the question is: other than links, where do we apply this rule? If we apply it to editable text fields, for example, the user won't see the content inside the field. If we apply it to tables, the user won't see the content of the table. That's the point I'm trying to make.
I realise this isn't ideal and we need something better, but it's worth noting that NVDA does render aria-label/aria-labelledby if the content is effectively empty, as there is no ambiguity in that case. So, the following rather ugly hack will work:
Aside from the fact that most users won't understand such a setting (thereby making itpractically useless in the wild), the point is that I still don't know when we're supposed to have aria-label override the content and when we're not. You say "active elements", but as far as I know, the spec doesn't cover such a concept. We can make our own decisions about what roles we should do this for, but such decisions wouldn't be in compliance with the spec. According to anything quoted from the spec in this ticket, aria-label should override the content for all elements, which would break a whole load of use cases, labelled landmarks and regions among them.
Comment 7 by jteh on 2014-02-14 08:58