Comment 1 by jteh on 2011-02-09 22:15
This is very similar to #1354 and I'll probably mark it as a duplicate as such. However, one thing that is different in this case is that you seem to want the content inside the div to be ignored completely. Is this really a valid rule? I'm thinking that a label shouldn't really completely replace the content.

Comment 2 by dmazzoni on 2011-02-09 22:44
The spec to follow is probably this one, but it doesn't seem to say whether alternative text replaces or augments text content:

http://www.w3.org/TR/wai-aria-implementation/#mapping_additional_nd_te

FWIW, JAWS/Firefox and VoiceOver/Safari both seem to have alternative text attributes (title and aria-label) override, so I'm tempted to follow their example. Otherwise there's no way for a web developer to design a truly accessible site - sometimes the text content is meaningless to a screen reader user, and we should allow web developers a way to strongly hint this.

I don't think the text content should be thrown away, it should be available to someone who wants more information about an element. My suggestion would be to make the label the default spoken description, if present.

Comment 3 by jteh (in reply to comment 2) on 2011-02-09 23:16
Replying to dmazzoni:

FWIW, JAWS/Firefox and VoiceOver/Safari both seem to have alternative text attributes (title and aria-label) override, so I'm tempted to follow their example. Otherwise there's no way for a web developer to design a truly accessible site - sometimes the text content is meaningless to a screen reader user

Not quite. You could wrap the meaningless text in an aria-hidden div. However, for various reasons, aria-hidden is difficult to support (and I question whether it should exist at all). Still, that might be a better option which we should perhaps consider.

I don't think the text content should be thrown away, it should be available to someone who wants more information about an element. My suggestion would be to make the label the default spoken description, if present.

"Default spoken description" is not really a concept that buffers support, since a buffer is just a big block of navigable text.

Comment 4 by aleksey_s (in reply to comment 3) on 2011-02-10 00:25
Replying to jteh:

Replying to dmazzoni:

FWIW, JAWS/Firefox and VoiceOver/Safari both seem to have alternative text attributes (title and aria-label) override, so I'm tempted to follow their example. Otherwise there's no way for a web developer to design a truly accessible site - sometimes the text content is meaningless to a screen reader user

Not quite. You could wrap the meaningless text in an aria-hidden div. However, for various reasons, aria-hidden is difficult to support (and I question whether it should exist at all). Still, that might be a better option which we should perhaps consider.

If that element has role of button and we know exactly that it's labeled, why we might need to care about its content? Isn't it enough to render that as a button with name set to its label in the buffer?

Comment 5 by dmazzoni on 2011-02-10 00:34
Wrapping text in an aria-hidden div isn't always an option. What do I do if I want to provide a better label for ?

I'm arguing that the content in the virtual buffer should be the label, because that's what the web developer specified. However, if the user wants to get more information about the current element, NVDA ought to be able to query the element that produced that bit of text in the virtual buffer and get the text content. Since this would only be done on-demand, there wouldn't be a performance penalty.

Comment 6 by jteh (in reply to comment 4) on 2011-02-10 02:10
Replying to aleksey_s:

If that element has role of button and we know exactly that it's labeled, why we might need to care about its content? Isn't it enough to render that as a button with name set to its label in the buffer?

Content and label are two very different things. I agree that they're one and the same for a button, but what about a div with no role or some other role? I would rather not make specific exceptions for specific types of controls; it makes the code very complicated and means we have to support each type of widget differently. We're supposed to be able to avoid that sort of stuff with accessibility APIs. :) That's why I'm trying to find a more generic solution.

Comment 7 by jteh on 2011-07-07 10:11
Duplicate of #1354. Whether we merge or replace is a detail that will affect both requests.
Changes:
Added labels: duplicate
State: closed