td, th naming doesn't align with ARIA

[scottaohara]

ARIA says that cells and column/rowheaders can get name from content. But HTML AAM doesn't list this.

TBH, i'm failing to understand a good use case for allowing a cell to be named from author (more so for a standard table - slightly less so for a grid). I say this because, at least from my quick testing, unless the cell is properly keyboard focused - the author provided name (aria-label) is not always relayed to screen readers. and in cases where it is, if it includes the visible content of the cell, it can result in redundant announcements of the information (first as the name/part of the name, and again as the cell content).

Even for grids though, it can be strange to have a cell that has a name of X when focused, but have different content of Y when you actually navigate 'into' the cell. Anecdotally speaking, I've heard negative responses to this sort of behavior, since it means a screen reader user has to be aware they need to interact with a grid in both application mode AND reader mode, to truly understand the content of the grid.

[rahimabdi]

The only scenarios I can think of:

• A blank origin cell (first cell in the table) that requires an explicit accessible name because it may not be clear it has been intentionally left blank; all ATs will announce "blank" but this relates to the a11y best practice of ensuring table header cells are non-empty so perhaps a name could clarify that
• Cells or row/column headers that have a visual presentation conveying meaning. For example, a column's cells have been shaded in a darker color to visually indicate that they are "not applicable" although they are empty. Besides sr-only text, how might the author convey that those cells are "not applicable" (e.g., <td aria-label="not applicable">?

[scottaohara]

some questions for your scenarios though

1. what is 'requiring' that the blank cell be named? again, in my testing when navigating by table cells using table commands, the aria-label isn't even announced. maybe there's a misconception that this blank cell needs to be a columnheader? that's not true though - it could just be an empty cell, and now there's no columnheader that isn't conveying a name.
2. i'd submit that there would need to be actual content in those cells, rather than just a use of color. Someone turns on a high contrast theme, or goes into reader mode, then that coloring is gone. An image (icon) could accompany this coloring, and be provided alternative text, without the need to use an aria-label (which again, wouldn't be announced if navigating using table commands)

i'm not responding with the above to flat out dismiss your scenarios. i am just trying to level set with where we are both coming from.

[rahimabdi]

Hi @scottaohara!

some questions for your scenarios though

1. what is 'requiring' that the blank cell be named? again, in my testing when navigating by table cells using table commands, the aria-label isn't even announced. maybe there's a misconception that this blank cell needs to be a columnheader? that's not true though - it could just be an empty cell, and now there's no columnheader that isn't conveying a name.

Good point. Anecdotally, I've received feedback from screen reader users that have voiced concern about empty table header cells although I agree that making it a data cell alleviates this.

2. i'd submit that there would need to be actual content in those cells, rather than just a use of color. Someone turns on a high contrast theme, or goes into reader mode, then that coloring is gone. An image (icon) could accompany this coloring, and be provided alternative text, without the need to use an aria-label (which again, wouldn't be announced if navigating using table commands)

👍🏾. The only other case I can think of is image content (or general non-text stuff) in a cell however, the image would be supplied with its own text alternative rather than one derived from the cell's label.

[spectranaut]

discuss with: w3c/aria#2160

[spectranaut]

Discussed last week: https://www.w3.org/2024/06/20-aria-minutes#t08

[spectranaut]

@aardrian, I added you as assigned because in the meeting a few months ago it mentions you being interested in helping find a solution.

We have this on the TPAC agenda for now (as it has f2fcandidate from that same meeting) -- but I'm wonder if anyone wants to champion it/help it move forward in that context?

[aardrian]

Related items for my use later (from TPAC notes and somewhat related abbr):

• https://www.jantrid.net/2015/12/woe-aria-surprisingly-but-ridiculously.html
• https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/
• Let NVDA read aria-label of th nvaccess/nvda#17213
• ABBR attribute on TH elements not supported nvaccess/nvda#3566
• https://bugzilla.mozilla.org/show_bug.cgi?id=673418#c13
• HTML-AAM: @abbr should be part of name calculation #16
• Columnheader roles do not work with the abbr attribute aria#816 (comment)

There may be a separate AAM issue to file here:

• https://w3c.github.io/html-aam/#el-abbr (yes, the element)
• https://w3c.github.io/html-aam/#att-abbr (the attribute)

Test page:
https://codepen.io/aardrian/pen/QWebNmZ

[adampage]

Just adding here that I’ve got an unmerged WPT PR (#44965) with a bunch of subtests intended to cover every naming sequence in HTML-AAM’s Accessible Name Computations By HTML Element section. Here are the freshest test results.

The tr-td-th.tentative.html test shows that:

1. Both Chrome and Firefox compute name from contents for a th. (Safari does not).
2. Only Chrome computes name from contents for a td. (Firefox and Safari do not).
3. In both cases above, name from contents trumps the title attribute, which is currently step 2 (after aria-label/aria-labelledby) in HTML-AAM’s name computation for tr, td, and th.