Attachment test.html added by bgaraventa on 2014-02-05 23:28
Description:

Comment 1 by jteh on 2014-02-06 01:51
This is essentially #1354 except that you refer specifically to links. Refer to #1354 for full details, but in short, we don't do this if there is actual content for several reasons:

1. If we always use the name reported by the browser instead of the content, formatting and semantic information inside the element will be lost. For example, the user won't be able to query for superscript/subscript and they won't know when part of a link is a graphic.
2. We could limit this to cases where the name is explicitly set by the author. However, if we do this, labels on landmarks, regions, tables, etc. would completely override the content of the element. In particular, this conflicts with ARIA Landmark Roles and Labeling the Landmark #1195 and NVDA does not recognize the region landmark role (even when it is a valid ARIA role) #3741.
3. We can limit (2) to certain roles of our choosing (including links), but that isn't particularly future proof and would be confusing for authors, since that wouldn't be documented in any spec.
4. If an element is labelled using aria-labelledby and the label is visible elsewhere, the label will be rendered twice: once for the label itself and once for the content of the labelled element. Radio buttons and check boxes are a prime example of this.

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 2 by jteh (in reply to comment 1) on 2014-02-06 01:52
Replying to jteh:

1. We could limit this to cases where the name is explicitly set by the author.

Note that this isn't possible in Firefox 18 and earlier, but I guess we can require users to update.

Comment 3 by spanchang02 on 2014-02-10 16:32
Hello,
The reasoning given for not fixing #3852 are not convincing.
I believe #1195, 1354, 1362, 2207,2472 have not been addressed satisfactorily. All deal with not reading aria-label. These are the same as #3852.

1. In case of a link the anchor's content is its identifier. It is the anchor text + the alt for an image if there's an image within the anchor tag.
   But when an aria-label is present on the anchor, the aria-label trumps the above.
   So for 31,
   a sighted user will identify the link as '31' and does not need the 'Dec 2014' because this context-specific text is available to the user in the vicinity of the link That's how the UI is designed.
   But the aria-label makes the link accessible for non-sighted users. The aria-label should be read in place of the anchor text '31'.
   In case of aria-label, the ARIA specs expressly require the aria-label to be interpreted as the element's name.
2. In fact, NVDA fails to identify a landmark's name:

On pressing the 'D' key to jump to the landmark, NVDA should say 'Navigation landmark secondary'. or better 'secondary navigation landmark'.
This will and should not prevent NVDA from accessing and reading the content in the div element i.e. the links.
The content of the div is not the identifier of the div but the aria-label is.

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
accessibility attributes have to be added to make it work for non-sighted users etc.
And even if that heading is present, the div with role=navigation should be identified using aria-labelledby to aid non-sighted users.
3. Also note, Firefox exposes and NVDA reads the title attribute on links along with anchor content. The title attribute is interpreted as the 'accessible description' for the link.
This is fine. But the title should be read only if it is not identical.
NVDA is an assistive technology and should compensate for incorrect markup by developers.
I reiterate, NVDA should interpret and expose accessibility attributes when present in line with specs.
Note: Need to support aria-label, aria-labelledby to identify landmarks, links and UI controls are documented in WCAG2 ARIA techniques too.
Regards,
Sailesh

Comment 4 by jteh (in reply to comment 3) on 2014-02-10 23:50
Replying to spanchang02:

The reasoning given for not fixing #3852 are not convincing.

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.

1. In case of a link the anchor's content is its identifier.

And where in the spec does this concept of "identifier" come from?

It is the anchor text + the alt for an image if there's an image within the anchor tag.

But when an aria-label is present on the anchor, the aria-label trumps the above.

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.

In case of aria-label, the ARIA specs expressly require the aria-label to be interpreted as the element's name.

"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.

1. In fact, NVDA fails to identify a landmark's name:

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.

This will and should not prevent NVDA from accessing and reading the content in the div element i.e. the links.

The content of the div is not the identifier of the div but the aria-label is.

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.

NVDA is an assistive technology and should compensate for incorrect markup by developers.

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?

I reiterate, NVDA should interpret and expose accessibility attributes when present in line with specs.

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
I understand the difficulty. The issue I'm referring to has to do with active elements specifically however, and not region containers.

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
Replying to bgaraventa:

I understand the difficulty. The issue I'm referring to has to do with active elements specifically however, and not region containers.

The question is how you define "active elements" (and whether that is covered by the spec).

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.

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.

Currently nothing added via aria-label is conveyed by NVDA however, which is why I filed the bug.

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:

<a href="#" aria-label="label"><span aria-hidden="true">unwanted content</span></a>

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,

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
Closing as a duplicate of #1354, as that's the more general issue. It should be noted that correct AT behaviour for this isn't actually covered by the spec, so this is not a spec compliance issue.
Changes:
Added labels: duplicate
State: closed