aria-label usage in BMP coverage table

[annevk]

@sideshowbarker #260 fails to build because https://encoding.spec.whatwg.org/windows-1253-bmp.html has aria-label usage that the HTML checker warns for.

Basically, it's a lot of stuff like:

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

[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]

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.

[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…)

[annevk]

Perhaps someone else from @whatwg/a11y can advise on this?

[patrickhlauke]

noting also that aria-label would, IF supported, override the content in the cells. so having something like

<td class="discontiguous upper" aria-label="Three bytes">
  <dl>
    <dt>U+2013</dt>
    <dd lang="el">–</dd>
    <dd>22</dd>
  </dl>
</td>

would mean (if SRs actually used the aria-label) that SR users would not get access to the actual visible content of the cell, but just hear "Three bytes" ... meaning they'd miss out on actual important content.

I'd say in general, rather than trying to patch things with aria-label here, it makes much more sense to use visually hidden extra text, a la

<td class="discontiguous upper">
  <span class="visually-hidden">Three bytes</span>
  <dl>
    <dt>U+2013</dt>
    <dd lang="el">–</dd>
    <dd>22</dd>
  </dl>
</td>

https://www.a11yproject.com/posts/how-to-hide-content/

[stevefaulkner]

or use aria-description

<td class="discontiguous upper" aria-description="Three bytes">
  <dl>
    <dt>U+2013</dt>
    <dd lang="el">–</dd>
    <dd>22</dd>
  </dl>
</td>

Note: the implementation is flaky currently

[annevk]

Thanks for the quick responses and guidance! Given that these tables are purely informal, I'll go with Steve's suggestion for now. If we get an actual report about this being problematic for someone we'll have to re-evaluate.

[patrickhlauke]

if it's known to still be flaky, why go with that approach rather than the more robust (admittedly slightly more verbose) visually hidden text?

[annevk]

Because we haven't had anyone complain about aria-label and I'd rather go with what's correct long term.