Tooltip does not consistently provide accessible label for button

[Kai Prince]

We're using tooltips in Awards Leaderboard UI repo, and there is an issue where they do not provide accessible labels until they have been activated with focus or hover.

What I've tried:

1. Setting aria-label on the button. This does not work because the d2l-tooltip will add aria-labelledby to the button which overrides aria-label.
2. Setting aria-label on the tooltip. This works, but is undesirable because the tooltip always gives itself aria-hidden="true".

[Erik Koopmans]

I don't have all the context here, but maybe it would make sense for the tooltip to never be aria-hidden?

[Dave Lockhart]

From this article by Steve Faulkner:

The ARIA attributes aria-labelledby and aria-describedby can be used to provide an accessible name or accessible description for a subset of HTML elements. It is important to note that by design, hiding the content (using CSS display:none or visibility:hidden or the HTML hidden attribute) of the element(s) referenced by these attributes does not stop the content from being used to provide the name/description.

So basically you can have something act as a label/descriptor even when it's hidden, and I'd argue it's this exact use case where that's appropriate -- where you want to avoid having the text read twice.

The markup I'd use:

<button
	id="${badgeId}"
	style="background-image:url(${this.award.Award.ImageData.Path})"
	@click="${this._awardClick}"
	class="d2l-award-button"
></button>
<d2l-tooltip for="${badgeId}" for-type="label" align="${tooltipAlign}">${this.award.Award.Title}</d2l-tooltip>

[Dave Batiste]

For context, Allan added the aria-hidden here. He did it when he introduced the announce method to handle the case where the tooltip is wired up to a custom-element where the focused element is within a different DOM scope. He later removed the code (leaving the aria-hidden) to fix regressions, and then Margaree re-introduced the idea in a backwards compatible opt-in way here.

Maybe he used aria-hidden since the tooltip content (aka label) would be announced by announce(...) in the custom element case. 🤔 I feel like the custom element scenario isn't really handled well... it still wouldn't get a proper label.

[Dave Batiste]

So if we decide to remove it, I think I would check that scenario with a screen reader.

[Kai Prince]

oooh you guys responded this is so cool. I'm a huge fan guys.

So @dlockhart you're totally correct and the accessible name spec supports that. Crazy enough when I tried with NVDA + Firefox it works totally fine, but with NVDA + Chrome and JAWS + Chrome the issues were present.

[Kai Prince]

Also something I've learned, disabling the aria-hidden part doesn't fix the problem.

[Erik Koopmans]

Yep, @dlockhart in my bit of testing (on the localhost testing page for tooltip), it was only reading the labelledby when the target wasn't aria-hidden, but I didn't investigate too far.

BTW your quote says the target can be display: none, visibility: hidden, or hidden, but doesn't mention aria-hidden="true". That said, further down in the article he says:

Note: addition of aria-hidden=true to the referenced element makes no difference

Edit: Seems like it's maybe more complicated than aria-hidden - I can sometimes get a button to read the tooltip text as a label, but very inconsistently, and not sure how to reproduce.