New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Labels on an element from aria-label and/or title should be read #1362

Closed
nvaccessAuto opened this Issue Feb 9, 2011 · 7 comments

Comments

Projects
None yet
1 participant
@nvaccessAuto

nvaccessAuto commented Feb 9, 2011

Reported by dmazzoni on 2011-02-09 21:43
In Google Books, we used the following markup to try to provide an accessible label for buttons whose button text is a nonspeaking character (in this case, a unicode left-arrow character).

Other screen readers speak "Previous Page", NVDA does not unless you press NVDA+tab. Tested with Google Chrome 10 & Firefox 3.x on Windows XP & Windows 7.

Blocked by #1354

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Feb 9, 2011

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.

nvaccessAuto commented Feb 9, 2011

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.

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Feb 9, 2011

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.

nvaccessAuto commented Feb 9, 2011

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.

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Feb 9, 2011

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.

nvaccessAuto commented Feb 9, 2011

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.

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Feb 10, 2011

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?

nvaccessAuto commented Feb 10, 2011

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?

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Feb 10, 2011

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.

nvaccessAuto commented Feb 10, 2011

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.

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Feb 10, 2011

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.

nvaccessAuto commented Feb 10, 2011

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.

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Jul 7, 2011

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

nvaccessAuto commented Jul 7, 2011

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment