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

td, th naming doesn't align with ARIA #543

Open
scottaohara opened this issue Apr 11, 2024 · 8 comments
Open

td, th naming doesn't align with ARIA #543

scottaohara opened this issue Apr 11, 2024 · 8 comments
Assignees

Comments

@scottaohara
Copy link
Member

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
Copy link
Contributor

rahimabdi commented Apr 11, 2024

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
Copy link
Member Author

scottaohara commented Apr 11, 2024

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
Copy link
Contributor

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.

  1. 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
Copy link
Contributor

discuss with: w3c/aria#2160

@spectranaut
Copy link
Contributor

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

@spectranaut
Copy link
Contributor

@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?

@adampage
Copy link
Member

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.

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

No branches or pull requests

6 participants