Comment 1 by jteh on 2015-06-25 23:17
The problem here is that the caption element maps to accessible name and we don't want the name to be rendered separately in this case, as this would result in it being rendered twice. We'll need to somehow detect aria-label* and special case it for tables.

Comment 2 by paulbohman on 2015-09-25 03:12
I believe that aria-labelledby and aria-label should override the caption element if present. At least that how the aria labels work with links, buttons, and other elements. I tested aria-labelledby on a table with JAWS and with VoiceOver and both of them read the aria-labelledby text. NVDA does read the caption if present, and the aria-label text if present, but not aria-labelledby. Currently, the way NVDA handles things right now, if a table has both a caption and an aria-label, NVDA reads the caption only. By way of contrast, JAWS reads the aria-label only. VoiceOver reads both the caption and the aria-label. From my understanding of the way aria-label and aria-labelledby are supposed to work, I think JAWS is doing it right by allowing the aria-label to override the caption.

So really there are separate issues here:

• support aria-labelledby on tables
• support the accessible name calculation for tables, which I think is that aria-labelledby overrides aria-label which overrides caption. Double check the order, but that's what I remember.

Comment 3 by paulbohman on 2015-09-25 03:16
I should mention that the above comments are for when I tested NVDA with Firefox. I noticed that on IE 10, NVDA didn't support either aria-label or aria-labelledby on tables, but I know that IE is a secondary priority compared to Firefox.

Comment 4 by jteh on 2015-09-25 04:58
Well, aria-labelledby and aria-label override the entire content for links and buttons. We certainly don't want that for tables. As I've said many times over the years, the spec doesn't actually provide any guidance whatsoever with regard to content; i.e. what should actually be reported. It only talks about name calculation, but there is far more than just name to consider here; i.e. the content of the table.

One concern I have is that if we render the name (as calculated by the browser) in all cases and ignore the caption element, we'll lose any formatting in the caption. Even if we manage to work around that, there's another problem: if the element(s) referenced by aria-labelledby are visible, rendering them in the table may cause duplication.

@bramd: I'd be good to know your thoughts about this

@bramd TL;DR: aria-labelledby, then aria-label, and finally caption.

Sources:

As required by the text alternative computation, user agents give precedence to aria-labelledby over aria-label when computing the accessible name property.

ARIA spec: aria-label (property)

That confirms that aria-labelledby indeed takes precedence over aria-label.

2. Compute the text alternative for the current node

B. Otherwise: if computing a name, and the current node has a non-empty aria-labelledby attribute, and the current node is not already part of an aria-labelledby traversal, process its IDREFs in the order they occur:

C. Otherwise, if computing a name, and if the current node has a non-empty aria-label attribute:

• If traversal of the current node is due to recursion and the current node is an embedded control as defined in step 2E, ignore aria-label and skip to rule 2E.
• Otherwise, return the value of aria-label.

D. Otherwise, if the current node's native markup provides an attribute or element that defines a text alternative, return that alternative as a flat string, unless the element is marked as presentational (role="presentation" or role="none").

AccName AAM: Text Alternative Computation

Basically, if there’s no aria-labelledby look for an aria-label and if neither is present use the caption element.

I suggest you read through the “Compute the text alternative for the current node” section yourself as that might make more sense than my blatantly plagiarised version above.

cc: @MarcoZehe, @jcsteh

I have found aria-labelledby on table cells to not work as expected on NVDA Chrome and Firefox. I used the following Codepen for testing

- Table with Select all checkbox in table header cell

NVDA output copied from Speech Viewer.

• column 1 check box not checked Select all rows
• row 2 check box not checked
• row 3 check box not checked

JAWS output

• Select all rows, check box not checked, Row 1
• Name John Doe Employee ID 001, check box not checked, Row 2
• Name Jane Doe Employee ID 002, check box not checked, Row 3

CHROME: Version 114.0.5735.199
NVDA: 2023.1
FireFox: 114.0.2

Expectation:
NVDA announces the aria-labelledby relationships
Preferable that NVDA does not announce the TH cell text hidden using aria-hidden.

@LaurenceRLewis, your comment does not seem to be related to the issue at hand. Please create a new issue.

I can't reproduce this issue; labelling a table with a caption, with aria-label or with aria-labelledby all work as expected in Chrome and Firefox.

@SaschaCowley I ca nreproduce this with the following minimal example:

data:text/html,<p>Table for testing follows:</p><table aria-label="Foo"><tr><th>Test 1</th><th>Test 2</th></tr></table>

Note that you can get the name by using NVDA's navigator/review cursor, but it is not exposed when reading in browse mode. Based on earlier comments I can't say if this has always been the case. So the real issue might be that a table gets named, but the name is not exposed in browse mode. However, that is the same from an end-users' point of view and matches this issue. In short, I think this should be reopened.

Urgh. The difference between Firefox and Chromium appears to be that Firefox returns the empty string for an empty description, whereas Chromium returns null. NVDA seems to specifically look for null. I could change that in Firefox, but I'm not really sure why NVDA enforces this.

I think this was regressed in #12888, but this issue is obviously older than that, so maybe we've had various fixes and regressions of this bug over the years.

Apologies, I think I misunderstood the issue. Is the expected behaviour here that a line get inserted into the table where a caption would be, with the contents of the aria-label?

@SaschaCowley I think the text from aria-labelledby should be reported in browse and focus mode, something like that seems to be the expected behavior.

However, comming back to the discussion about prioritizing aria labelledby over aria-label over caption, I don't know what the consensus is in web design nowadays. We should try to stick to what most web developers do and what the spec recommends. If most people use aria-labelleby to give tables a title, we should honnor that in the virtual document and in focus mode. But I agree with Jamie here, we should be careful which one we support on the fly in order to avoid double speech.
It seems at least this doc and many other modern web accessibility ressources recommend captions for table titles:
https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/Advanced

And I kind of understand that aria-labelledby might make sense to give a table its title.

But aria-label should actually be used as a text alternative for something that otherwise doesn't have a visible text on the screen (e.g. a button which appears as an icon on the screen. What is the advantage of using aria-label over caption for tables? Why should we support that in this case?

So my proposal would be as follows, not sure whether it is technically possible:

• NVDA looks for aria-labelledby when entering and focusing the table title
• If aria-labelledby is not available, fall back to captions
• If both aria-labelledby and captions are not available, render and report aria-label.