Skip to content
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

aria-describedby, aria-labelledby, aria-label not spoken on a td or th element #5567

Closed
artopaavola opened this issue Dec 2, 2015 · 8 comments
Labels

Comments

@artopaavola
Copy link

@artopaavola artopaavola commented Dec 2, 2015

NVDA (version 2015.4) does not speak aria-label, aria-description, aria-labelledby or aria-describedby on a table cell element (td or th). Tested in Windows 7 with Firefox 42, Internet Explorer 11 and Google Chrome 47.

Test page: http://codepen.io/artopaavola/pen/rOEbyR

@jcsteh jcsteh added the close/wontfix label Dec 2, 2015
@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Dec 2, 2015

aria-label(ledby) don't replace the content here because doing so would inappropriately cause all actual content to be overridden. This is expected for links and buttons, but not for uninteractive elements like div, span, td, th, etc.

NVDA treats descriptions (aria-describedby) as secondary content, rather like tooltips for sighted users; i.e. you can query them on demand, but they shouldn't necessarily interrupt the flow of normal reading. You can press NVDA+numpad5 to explicitly query information about the current object, including the description.

@jcsteh jcsteh closed this Dec 2, 2015
@artopaavola
Copy link
Author

@artopaavola artopaavola commented Dec 2, 2015

The aria-label(ledby) examples on my codepen would make no sense with that kind of data :) It was made just for demo purposes. In my opinion there are use cases where it would make sense to replace the contents of a cell with aria-label(ledby). I updated the codepen with a better example (see the th elements).

The Working Draft of ARIA in HTML specification quite clearly states that global states and properties (including aria-label, aria-labelledby, aria-description and aria-describedby) are allowed on any html element: http://www.w3.org/TR/html-aria/#allowed-aria-roles-states-and-properties

Thanks for the explanation on aria-describedby! Apple's VoiceOver reads the hints automatically and somehow I expected that NVDA would do that, too. Especially because NVDA reads aria-descriptions on interactive elements like text input fields automatically.

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Dec 2, 2015

In my opinion there are use cases where it would make sense to replace the contents of a cell with aria-label(ledby).

There might be, but this opens up a huge can of worms. As a simple example, if we replace the content with aria-label in all cases, you'd lose the entire content of labelled landmarks. This is something everyone seems to forget when they simply expect aria-label to replace the content in all cases.

The Working Draft of ARIA in HTML specification quite clearly states that global states and properties (including aria-label, aria-labelledby, aria-description and aria-describedby) are allowed on any html element

It states that they're allowed. It even states how that should be exposed via accessibility APIs. It doesn't say this should replace the content as far as document reading is concerned. See above for why that would be a terrible idea in all cases.

Thanks for the explanation on aria-describedby! Apple's VoiceOver reads the hints automatically and somehow I expected that NVDA would do that, too. Especially because NVDA reads aria-descriptions on interactive elements like text input fields automatically.

It reads them when you focus an element, since that's an on-demand action. It also reads them when you query an object, since that, too, is an on-demand action. If you just cursor to one, hwoever, it does not read them in that case.

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Dec 2, 2015

Btw, as far as I can see, aria-description doesn't exist, even in ARIA 1.1. There's only aria-describedby.

@artopaavola
Copy link
Author

@artopaavola artopaavola commented Dec 2, 2015

I wasn't suggesting that aria-label(ledby) should replace the contents in all cases - I was only talking about table cells. Probably even with the th element's case in the example it shouldn't replace the content but rather append it. When aria-label or aria-labelledby is used in a th element, and the user queries an object in a cell (td) in the table with NVDA+numpad5, NVDA reads the th element's aria-label or aria-labelledby. Not the content of the th element as it does when user arrows to a cell.

Anyways, thank you for your responses! Seems that using aria-label(ledby) or aria-describedby with a th or td element works well with OS X VoiceOver but unfortunately not so well with NVDA.

(You're absolutely right about aria-description not being part of the spec. I have no idea why I thought otherwise. I vaguely remember that there were plans to introduce it in ARIA 2.0, so maybe that confused me when I wrote the demo. I removed aria-description from the codepen so that doesn't confuse anyone if they stumble upon this conversation later.)

@artopaavola artopaavola changed the title aria-describedby, aria-description, aria-labelledby, aria-label not spoken on a td or th element aria-describedby, aria-labelledby, aria-label not spoken on a td or th element Dec 2, 2015
@hixus
Copy link

@hixus hixus commented Dec 3, 2015

@jcsteh I'm curious how will the user know when the element has additional information?

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Dec 3, 2015

@sidnc86
Copy link

@sidnc86 sidnc86 commented May 13, 2019

It seems this behavior still persists in NVDA 2019.1.1. User is expected to explicitly press NVDA+Numpad 5 to get multiple headers associated with a cell.

When @jcsteh says:

They don't. However, one could also ask how a sighted user knows something has a tooltip without moving their mouse over it (on-demand query).

Isn't a hover event equated with focus event from Accessibility standpoint? And for a screen reader user, one can think of this browse mode cursor position to be the virtual focus.

I suppose NVDA thinks of focus to be explicitly keyboard focus which is fine but to add to this, I think even this virtual reading focus should be tracked and equally treated for situations like the issue being discussed here (read out descriptions when on cell even in browse mode).

The behavior stays consistent with other screen reader software out there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.