Tooltip has some accessibility issues

The tooltip component has some accessibility issues. I thought it was easier to lump them all together for the single component rather than separate issues for each.

I threw together a test page https://stommepoes.nl/work/shoelace/shoelace_demo.html and, on Windows only, ran 2 screen readers (NVDA latest, JAWS 2019) and two screen magnifiers (Windows Screen Mag, ZoomText) on 3 browsers (Edge latest, Chrome latest, Firefox latest… as of 23 September 2020). I don’t own any iThings or I would have run VoiceOver on Safari (this is the combination for MacOS that is preferred for testing) as well.

See the notes below: tooltips are difficult components to actually make accessible. The best you can do is just get close to the current recommendations 😦

The tooltips:

• do not act as an accessible description for the control (the “Hover me” button) in the example.
• are not themselves hoverable.
• cannot be removed without moving the pointer.

To Reproduce Steps to reproduce the behavior 1:

1. With a screen reader running, go to either the tooltip demo page (https://shoelace.style/components/tooltip) or the test page listed above
2. With the keyboard, navigate to the button called “Hover me”.
3. Instead of hearing the tooltip text as the accessible description (normally announced after the accessible name which in this case is “Hover me”), nothing is heard.
4. Use the Down Arrow to move the screen reader’s reading cursor to the next element. The tooltip text is heard then.

Steps to reproduce the behavior 2:

1. Go to either the tooltip demo page (https://shoelace.style/components/tooltip) or the test page listed above
2. Hover the button called “Hover me”.
3. When the tooltip appears, attempt to move the mouse pointer to the tooltip itself.
4. Instead of remaining onscreen, the tooltip vanishes.

Steps to reproduce behaviour 3:

1. Go to either the tooltip demo page (https://shoelace.style/components/tooltip) or the test page listed above
2. With the keyboard, Tab to the button called “Hover me”.
3. When the tooltip appears, press the Escape key.
4. Instead of focus remaining on the button and the tooltip vanishing, on the Shoelace demo page the tooltip remains onscreen; on the test page, keyboard focus is moved to one of the select components. ** Focus moving to a select was rather intermitant. Most of the time focus moved to the select directly above the “Hover me” button on my test page. Once I had Chrome always setting it on the first select set near the top of the page. Once in Firefox, focus did not move and the page acted like the demo test page—until I chose an option in that select, then Tabbed to the “Hover me” button. Then focus was placed on that select.

Expected behavior Accessible descriptions (such as text linked to a control using aria-describedby) are announced when the controls receive focus. Tooltips are hoverable, persistent and dismissable (as per https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus)

Screenshots

Desktop:

• OS: Windows 10
• Browsers: Edge latest, Chrome latest, Firefox latest (as per 23 September 2020)
• AT: Screen readers NVDA latest, JAWS 2019. Windows Screen Magnification. ZoomText 2019.

Notes: tooltips are a poor UX pattern. This is an example where any fixes you do are solely to get your component closer to checking boxes on some “accessibility list”, because they cannot truly be fixed. For the “tooltip not read as an accessible description” (which, I am personally against throwing tooltip text at people simply because they focussed on a control which keyboard-only users cannot help, while sighted mouse users get to choose whether they want to view that tooltip text), I believe the reason it’s not reading out is because the tooltip has aria-hidden="true" on it until the control is focussed, and I believe the removal of the aria-hidden state happens AFTER the browser has communicated to the assistive technology/screen reader that the acc. description does not exist. So it seems the only solution when following the recommended aria-describedby pattern is to leave the tooltip exposed (and simply visually hidden). To be honest, I feel it’s more user-friendly that the text comes afterwards, but then completely blind users may not know that the tooltip text is being offered as a “tip” in the context of the control rather than just plain text. Also, I dunno what Macs do.

For the “hoverable, dismissable” parts: this is because when using screen magnification, tooltips have 2 problems: either they pop up unwanted and cover screen content and I may want to be able to see the screen without moving my viewport (moving the mouse is how one moves the viewport, if you can use a mouse), but conversely if I want to READ the tooltip, I need to be able to move my mouse over the tooltip, since the tooltip may be too big to fit in my viewport when I’m hovering the button. These two things are fixable (the latter with CSS alone even), but the current suggestion on the WCAG is to offer the Escape key to close tooltips, because the Escape key is the typical pattern of removing stuff that has popped up or open. However, this can get in the way of screen reader users who are unaware there is a tooltip, and can conflict if the tooltip’d element is inside a component which is already listening to the Escape key (such as a modal dialog).

Watch this and cry with me: https://www.youtube.com/watch?v=7s_sjl4bEP8

I’m making this ticket simply because I think you should be aware of the current issues and making the tooltips themselves hoverable is a doable fix for at least one of these issues. There might be a known way to deal with the accessible-description part somewhere on the web, but since I hate tooltips for the reasons listed above, I didn’t look. Paul J Adam has created several examples in the past.

[claviska]

one fix is to have the button and content exist in the same shadow DOM, which has its own challenges (thinking of styling in particular). That didn’t work for our implementation because we wanted to let users pass in whatever trigger element worked for them

This was exactly the problem. I want to be able to wrap the trigger with a tooltip element so they can use whatever trigger they want.

So, we turned the content block into an aria-live region and populated it on hover/focus. This feels like a cheat, but it actually worked really well, and with the added bonus that we could configure it to read the tooltip content once or every time it’s shown.

This is a brilliant suggestion! I just tried it and it’s reading well now on hover and focus. You can try it out here:

https://next.shoelace.style/components/tooltip

I realize tooltips aren’t the easiest to get right in terms of accessibility, but hopefully this improvement makes them more useful for everyone. Since this thread is getting long and I believe the main issues have been resolved, I’d like to close this thread and identify any new issues or suggestions in a new one.

Thanks for the detailed feedback, @StommePoes. And thanks for the great aria-live suggestion, @maggiewachs!

[StommePoes]

Sorry I can’t give any useful kind of solution 😦

One idea is to rearrange the nested things so that the tooltip chunk and the button are inside a single shadow DOM and then the tooltip can easily aria-describe the button with aria-describedby set on that button (by button I mean the real <button> element inside that nested shadow). Problem probably is then that it’s some kind of pain in the butt to offer all the positioning or something.

Then with any screen reader what users should encounter is: if Tabbing to the button (at least for Windows and Linux SRs that switch modes) should offer that

• it’s a button
• its name is Hover Me
• its description is This is a tooltip

Those’ll all read out together in whichever order the particular screenreader does or however the user may have configured it.

A user browsing (just reading content and not focussing on anything) with a screenreader that uses modes may only get the Hover Me name and that it’s a button but I think it differs between SRs whether other control semantics get offered if the user isn’t in a “focus” mode… I can’t remember anymore, my brain has become cheese with those carbon-dioxide-gas holes, lol. So anyway any testing is only:

• turn on a screen reader
• Tab to the button
• hear all the things

and not worry about what’s announced if users are just reading stuff.