aria-label usage in BMP coverage table about encoding

[sideshowbarker]

Upon further reflection, I realize this could well be a copypasta spec bug in the AAM spec — so I raised w3c/html-aam#335 over there to get clarification.

[annevk]

cc @hsivonen

[sideshowbarker]

<td class=unmapped aria-label=Unmapped><dl><dt>U+0000<dd>�<dd> </dl>

My reading of the relevant best-practice guidance and relevant spec requirements lead me to believe a warning for that is appropriate, and so the aria-label attributes should be dropped from those td elements.

As far as the spec requirements go, https://w3c.github.io/html-aam/#other-tabular-data-elements says that for “tr, td, th Elements Accessible Name Computation”, the step that implementations must start with is:

If the table element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.

Notice it says “the table element”. So I take that to mean that implementations must essentially ignore whatever aria-label attribute a td, th, or tr element might have, and instead look back up the tree and use whatever aria-label attribute the ancestor table element has.

Does my reading of that seem correct?

If my reading of that is in fact correct, then as far as the checker behavior goes, doesn’t that mean it’s appropriate for the checker to warn about not using aria-label with td, th, or tr elements?

As far as the related best-practice guidance, the source I have been following for that is https://html5accessibility.com/stuff/2020/11/07/not-so-short-note-on-aria-label-usage-big-table-edition/, which explicitly recommends not using aria-label with td, th, or tr elements. For those, it notes “aria-label use not well supported” (meaning, not well supported in UAs/AT).

[sideshowbarker]

Update: @scottaohara has updated the relevant language in the AAM spec to make it more clear. So I think it now unambiguously states the relevant implementation requirements. (Thanks Scott!)

However, at w3c/html-aam#335 (comment), Scott points out:

That said, while using aria-label on these elements is valid and is meant to be respected when determining the name of the elements by browsers, as Steve noted in his html5accessibility post, support for aria-label with AT is rather spotty.

For instance with this table NVDA with Firefox and Chromium ignore the aria-label when navigating the list. So none of the coloring of the table will be accessible for people using this browser/AT combo.

With VoiceOver, on macOS (but not iOS) the aria-label is respected but that makes all cells initially announce as the aria-label value (e.g., "Two bytes"), requiring a user to navigate into the cell to determine what the actual value presented is.

tldr; these tables are valid, but the legend information is either not going to be announced, or it is but it will create an extra step for AT users to hear the actual content of the table cell.

Therefore, I think having the checker not emit a warning for a td element with aria-label would be not be helpful for accessibility. Therefore, I think the right fix here is to change the markup.

@scottaohara, can you suggest any alternative ARIA markup for the https://encoding.spec.whatwg.org/windows-1252.html table, or is it in fact the case that those table cells shouldn’t have any ARIA markup at all?

And to be clear, replacing aria-label with title would not be an improvement, right? (I assume that if UAs/AT don’t end up getting the aria-label text announced usefully, they also must not get the title text announced usefully either…)