[Bug]: VoiceOver does not read content of sp-tooltip on hover or click open

[pwong09]

trafficstars

Code of conduct

• [X] I agree to follow this project's code of conduct.

Impacted component(s)

sp-tooltip, sp-action-button, sp-overlay-trigger, sp-popover

Expected behavior

Expect VoiceOver to read the content of a sp-tooltip when user either hovers or keyboard focuses on the sp-action-button

Actual behavior

VoiceOver tells me to use control-option-space to interact with the button, but no tooltip content is read out

Screenshots

No response

What browsers are you seeing the problem in?

Chrome

How can we reproduce this issue?

See sample code

Sample code that illustrates the problem

https://studio.webcomponents.dev/edit/J3BcJnTW4U45u7DTa9a0/src/index.ts?p=stories

Logs taken while reproducing problem

No response

[Westbrook]

First, the demo as provided provides click content to the Button in the form of the Tooltip:

         <overlay-trigger placement="bottom" type="modal">
            <sp-action-button slot="trigger" label="Information" quiet size="s">
              <sp-icon-info-outline slot="icon"></sp-icon-info-outline>
            </sp-action-button>
            <sp-tooltip slot="click-content" size="s" open>
              Style combinations defined in the font for quick access
            </sp-tooltip> 
        </overlay-trigger>

This means that when the Button is activated the screen reader cursor will be passed into the Tooltip and the content will be read.

When moved to hover content, what I'm seeing right now looks like a weird timing reality:

        <overlay-trigger placement="bottom" type="modal">
            <sp-action-button slot="trigger" label="Information" quiet size="s">
              <sp-icon-info-outline slot="icon"></sp-icon-info-outline>
            </sp-action-button>
            <sp-tooltip slot="hover-content" size="s" open>
              Style combinations defined in the font for quick access
            </sp-tooltip> 
        </overlay-trigger>

In this context, various browsers are giving us different results.

• In Chrome, I get the Tooltip content read BUT ONLY when the Tooltip is open first. So, if I move the screen reader cursor into the Button, wait for the Tooltip to open, move it before the Button, then move it back onto the Button while the Tooltip is open, I get the text read, but in no other cases. We'll need to dig deeper on what that's saying, but wanted to get a first bit of usage and triage info into this issue.
• In Safari, I get the Tooltip content seemingly always.
• In Firefox, I get the Tooltip content seemingly never.

[Westbrook]

Compare possible solutions here to https://zoebijl.github.io/apg-tooltip/ as opposed to other Adobe solutions, https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/, or https://dequeuniversity.com/library/aria/tooltip, as they each have their own issue.

Current possibilities:

• https://a11y-overlay--spectrum-web-components.netlify.app/components/tooltip/
• https://a11y-overlay-2--spectrum-web-components.netlify.app/components/tooltip/

[Westbrook]

@dineshy87 and @jnurthen would yall be able to share a more specialized look at an option I've got under development here?

I've specifically been looking with only Voice Over so far, but if this seems like a path forward there, I'll be expanding my testing pattern next:

This example seems to work as expected (in relation to https://zoebijl.github.io/apg-tooltip/ as provided by James) in both forward and backwards reading directions:

• https://a11y-overlay-2--spectrum-web-components.netlify.app/storybook/index.html?path=/story/overlay-element--hover-tooltip

These examples work 100% forward, however when Chrome using control + option + leftarrow the tool tip isn't always attached as expected in the initial Voice Over output. However, it is always in the control + option + command + / menu.

• https://a11y-overlay-2--spectrum-web-components.netlify.app/storybook/index.html?path=/story/tooltip--overlaid-top
• https://a11y-overlay-2--spectrum-web-components.netlify.app/storybook/index.html?path=/story/tooltip--self-managed

Not sure what would be different about the reverse content direction in Voice Over or in our implementation that could cause this difference, but with the content being there in the control + option + command + / menu, I'm wondering if it's an acceptable outcome? It at least feels better than the current delivery with consistency outlined in this comment.