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

aria-label usage in BMP coverage table #261

Closed
annevk opened this issue May 31, 2021 · 10 comments · Fixed by #340
Closed

aria-label usage in BMP coverage table #261

annevk opened this issue May 31, 2021 · 10 comments · Fixed by #340
Labels
accessibility Affects accessibility

Comments

@annevk
Copy link
Member

annevk commented May 31, 2021

@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 annevk added the accessibility Affects accessibility label May 31, 2021
@annevk
Copy link
Member Author

annevk commented May 31, 2021

cc @hsivonen

@sideshowbarker
Copy link
Member

sideshowbarker commented May 31, 2021

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

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

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

annevk commented Dec 16, 2024

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

@patrickhlauke
Copy link
Member

patrickhlauke commented Dec 16, 2024

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

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

annevk commented Dec 16, 2024

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

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

annevk commented Dec 16, 2024

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

annevk added a commit that referenced this issue Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Affects accessibility
Development

Successfully merging a pull request may close this issue.

4 participants