Tooltip label acts like a description and obscures tooltip content

[nwhittaker]

Summary

A tooltip's label property becomes the textual representation of the tooltip. This means that string is what is applied back to the reference element via its aria-describedby attribute. However, a label and description are two different things:

…a label should be concise, while a description is intended to provide more verbose information; a label describes the essence of an object, while a description provides more information that the user might need.1

As a result, when a tooltip is given a concise label, that label becomes the description of the reference element and the browser no longer has an accessible way to expose/apply the actual text content of the tooltip.

Actual Behavior

From the API, it's unclear that the tooltip's label property is actually behaving as the description of the reference element. If the fix is to duplicate the tooltip's text content as its label, it's unclear why the label property is required since aria-describedby falls back to an element's text content anyway.

Expected Behavior

Possibly rename the label property to a less overloaded term (e.g. "description"?) and not making it required. Otherwise, improve doc to better explain what makes for a good label.

Reproduction Sample

https://developers.arcgis.com/calcite-design-system/components/tooltip/

Reproduction Steps

Visit the tooltip doc page.
Use devtools to inspect the accessibility tree of the code sample's reference element.
Notice the reference element's description is the same as the tooltip's label and does not include any of the tooltip's text content.

Reproduction Version

next.731

Working W3C Example/Tutorial

https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/

Relevant Info

It looks like a working example is still in development, but I didn't see any examples in the current work where the tooltip element had an aria-label attribute, FWIW.

Regression?

No response

Esri team

ArcGIS Field Apps

Footnotes
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-describedby#description ↩

[geospatialem]

Additional research needed on prop requirements and a11y supported.

[geospatialem]

We should consider deprecating and/or removing the label prop with the aria-describedby attribute (already provided).

However, if considered removing, this would likely be considered a breaking change, but could provide clarity to the content presented in the tooltip. cc: @jcfranco

This is in line with the W3C recommendations for tooltip:

The accessible name of a tooltip can come from the contents. While, in theory, they could come from an aria-label or aria-labelledby, in most cases, using ARIA properties to provide a tooltip with an accessible name is not recommended.

Since the component provides context today (perhaps too much in some use cases), marking this as low priority, and added an estimate for mitigation, which should include a pass of the "is accessible when open" test.

[driskull]

@geospatialem I think we should just make the label optional and update the doc to say that setting this will override the aria-describedby? What do you think?

[geospatialem]

@driskull We could definitely do that. It seems like the approach provides content twice, so could create some confusion so lean towards deprecating the prop. Maybe once we move towards a breaking change release, we could consider removing altogether?

[driskull]

Ok. lets deprecate the prop and make it optional for now.

@geospatialem can we see if there are any other components that have label as required where we may want to change it to be optional.

[geospatialem]

@geospatialem can we see if there are any other components that have label as required where we may want to change it to be optional.

A quick rundown of required label props across the components:

• action-menu - related to the text, no change
• alert - the only label present, no change
• chip-group - the only label present, no change
• combobox - the only label present, no change
• combobox-item-group - the only label present, no change (child and parent need separate labels)
• loader - the only label present, no change
• menu - the only label present, no change
• menu-item - the only label present, no change (child and parent need separate labels)
• option-group - the only label present, no change
• pick-list-item - skipping due to deprecation
• popover - We could change this one to also accept aria-describedby, but its optional, or a nice to have. Think as-is is fine since some folks implement rich popover content. WDYT @driskull?
• select - the only label present, no change
• tooltip - part of this issue
• value-list-item - skipping due to deprecation

[driskull]

@geospatialem can we update both popover and tooltip to deprecate label and make it optional? I think that would be good.

[geospatialem]

can we update both popover and tooltip to deprecate label and make it optional? I think that would be good.

We can definitely do so for both as long as we include an aria-labelledby in for the popover's reference element.

[driskull]

I'll leave popover alone since I know MV and some apps use a reference element just for positioning only.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified in master with JAWS and NVDA on Windows.