Tooltip triggers often need aria-label

[Andarist]

🙋 Feature Request

Tooltip triggers often need aria-label because the associated tooltip is not enough for assistive technologies - especially given that tooltips are only rendered conditionally. At least this is what AXE reports for my buttons for which I've implemented tooltips using @react-aria hooks

I'm not yet sure though if this won't conflict with the description contained in the tooltip and if this won't make assistive technologies to read often the same thing twice - which would be less than desirable.

🤔 Expected Behavior

useTooltipTrigger accepting aria-label (?)

😯 Current Behavior

No obvious way to handle aria-label for the tooltip trigger.

---

I'm happy to implement any required changes but I'd like to establish first how this should be handled.

[snowystinger]

I think you should probably build that into whatever your trigger element is, we've handled it in the React Spectrum side of things by allowing something like this. (ActionButton will complain if there's no visible text label and no aria-label)

    <TooltipTrigger {...props} onOpenChange={action('openChange')}>
      <ActionButton aria-label="Foo"><Icon /></ActionButton>
      <Tooltip>
        Tooltip message.
      </Tooltip>
    </TooltipTrigger>

Note, I'm assuming that there is no text label on your button element, so the button is the thing that actually needs the aria-label. Not anything to do with the tooltip trigger itself.

[Andarist]

Note, I'm assuming that there is no text label on your button element, so the button is the thing that actually needs the aria-label. Not anything to do with the tooltip trigger itself.

Right, this statement somewhat addresses my concern - if I think about this from the button's perspective which is only decorated with a tooltip then this makes sense. In the app, I'm working on we only put tooltips on action buttons (at least so far) so the <Tooltip/> component I've created kinda assumed the trigger being an action button but it totally makes sense to separate those concerns even if it's going to add some duplication of props for us (having to pass the same "label" to the action button and the tooltip components).

Note that some SR software reads both the label and the description in such a situation - which leads to the same thing being read out loud twice in our situation. Do you maybe happen to know if this is just how things work and we should be OK with that?

[snowystinger]

Ah good question, @majornista do you have a good answer for this?

[majornista]

Note, I'm assuming that there is no text label on your button element, so the button is the thing that actually needs the aria-label. Not anything to do with the tooltip trigger itself.

Right, this statement somewhat addresses my concern - if I think about this from the button's perspective which is only decorated with a tooltip then this makes sense. In the app, I'm working on we only put tooltips on action buttons (at least so far) so the <Tooltip/> component I've created kinda assumed the trigger being an action button but it totally makes sense to separate those concerns even if it's going to add some duplication of props for us (having to pass the same "label" to the action button and the tooltip components).

Note that some SR software reads both the label and the description in such a situation - which leads to the same thing being read out loud twice in our situation. Do you maybe happen to know if this is just how things work and we should be OK with that?

This is pretty much how things work. By default screen readers will read both the aria-label and elements referenced using aria-describedby even if the text for the accessibilityName and accessibilityDescription is the same, but it depends on the user's verbosity settings for the screen reader, because some screen readers have a setting that will reduce speaking of redundant text. For example VoiceOver has the setting under VoiceOver Utility > Navigation > Skip redundant labels.

[Andarist]

Thank you for the informative answer! Going to close this as it doesn't seem to be actionable here after all.