Tooltip does not work with disabled button

[mpayson]

Actual Behavior

Tooltip does not show up on hover when its target button is disabled

Expected Behavior

Tooltip shows up like the doc example

Additional context from #6461

When a disabled button contains information available by tooltip, using only aria-disabled communicates the disable state while permitting keyboard focus to be moved to the button: https://codepen.io/FelFly/pen/gOdYQQq

Reproduction Sample

• https://codepen.io/mpayson/pen/poVNZPX?editors=1000
• https://codepen.io/FelFly/pen/RwYbqqe

Reproduction Steps

1. Open codepen
2. Hover over button, notice tooltip does not display

If disabled prop is removed, it works

Reproduction Version

beta.93

Relevant Info

No response

Regression?

No response

[driskull]

@mpayson For this, I think you would need to wrap the button in a div so that you can add the tooltip to that div instead.

Disabled elements don't fire hover events so we can't really do anything here. Its the same if you change <calcite-button> to <button>.

[mpayson]

Ah that makes sense, thanks for clarifying!

[driskull]

@mpayson actually, we may be able to do something here. I'll see if we can but for now wrapping it would be a good solution.

[github-actions]

Installed and assigned for verification.

[driskull]

@benelan @jcfranco can we use this issue as an area for discussion on if we should remove the pointer-events:none on disabled calcite-button?

[benelan]

Sure, @macandcheese do you have any design thoughts?

[jcfranco]

@benelan FYI, there's some initial discussion in the related PR.

[geospatialem]

Added to the Stalled milestone to discuss and prioritize after January's release.

[yannikmesserli]

Note that we encountered the exact same problem for Calcite Radio Group's items. When disabled, the tooltip explaining why it was disabled was not showing up. Should I open a new issue for it? Or is the discussion you are having (soon?) will include the pointer-event: none removal on any disabled Calcite components?

[geospatialem]

Note that we encountered the exact same problem for Calcite Radio Group's items. When disabled, the tooltip explaining why it was disabled was not showing up. Should I open a new issue for it? Or is the discussion you are having (soon?) will include the pointer-event: none removal on any disabled Calcite components?

@yannikmesserli We can definitely add this into the discussion. For now we'll purpose this issue for both discussions later this month and might add in a new issue once prioritization and next steps are determined.

In the meantime, could the following example suffice for a workaround, where a label with a button referencing the tooltip provides context on the disabled component?

[ReneU]

We're running into the same issue in ArcGIS Velocity where we have many buttons that could be disabled and we want to display an explanatory text in a tooltip. The workaround works for us but makes things more complicated.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified on master.

On mouseover a tooltip can be referenced:

Tabbing and AT skips over the button and tooltip 👍🏻

[Anastasiia-Boleiko]

Hi there,

@geospatialem Can you please clarify whether the tooltips for disabled components will be accessible for assistive technology (AT) in the future?

Use aria-disabled="true" instead of disabled (it allows adding a tooltip on hover and focus) and apply appropriate styles to have a look and feel of a disabled state. Please, see a codepan example.
A bit more info on that topic:
A11Y and UX considerations for disabling
More about aria-disabled
Making Disabled Buttons More Inclusive

aria-disabled will still focus the button and announce that it exists, but that it isn’t enabled yet; the same way you might perceive it visually.

As I mentioned earlier, it could be beneficial since some tooltips serve as relatively important information and might be helpful for those who use AT (not only for mouse users).

Thanks.

[geospatialem]

Hi @Anastasiia-Boleiko - thanks for reaching out, just getting back to messages from UC. We're meeting on this topic next week as a team as it could have some breaking change implications. Will report back our findings in the coming week or so, including next steps.