[BITV/A11Y] Tooltips accessibility

[PVince81]

• TODO: update nextcloud-vue in server: Bump @nextcloud/vue from 5.3.1 to 6.0.0.alpha.0 nextcloud/server#33387
• some requirements for custom tooltips (but not needed anymore):
  • Take care of delaying all tooltips, [BITV/A11Y] Delay all tooltips #2216
• Apps
  • [BITV]: Replace custom tooltips with native one for files nextcloud/server#35770
  • [BITV]: Replace custom tooltips with native one for files_sharing nextcloud/server#35654
  • [BITV]: Replace custom tooltips with native one for Users page nextcloud/server#35888
  • [BITV]: Replace custom tooltips with native one for Apps page nextcloud/server#35887
  • [BITV]: Replace custom tooltips with native one for personal and administration settings nextcloud/server#35886
  • [BITV]: Replace custom tooltips with native one for Mobile & desktop settings page nextcloud/firstrunwizard#804
  • [BITV]: Replace custom tooltips with native one for privacy settings page nextcloud/privacy#835
  • [BITV]: Replace custom tooltips with native one for system settings page nextcloud/serverinfo#418
  • [BITV] Replace custom tooltips with native one nextcloud/activity#1045
  • [BITV] Replace custom tooltips with native one nextcloud/notifications#1410
  • [BITV]: Rework native tooltips on NcAvatar #3677

[JuliaKirschenheuter]

Useful links to implement accessible tooltips:

• https://sarahmhigley.com/writing/tooltips-in-wcag-21/
• https://www.youtube.com/watch?v=lb0_v7D4kbs&ab_channel=MSFTEnable
• https://codepen.io/smhigley/pen/KjoerX

[JuliaKirschenheuter]

Some of tooltips are inconsistent: some shows a file name, some show an icon, some of them are reachable via icon only. There are should be done in a same way. See some examples:

[PVince81]

in nextcloud-vue 6.0.0 beta there was a move to "floating-vue" which I hope is more accessible: #2600

since this is done by Raimund from the community it's not clear if that library satisfies the a11y requirements so we need to verify

[PVince81]

now I'm not sure where I got the list of requirements in the original post, especially the idea that it needs to be possible to tab into them. need to recheck with WCAG/BITV for more precise requirements

[JuliaKirschenheuter]

I've searched for requirements regarding tooltips and here are my points.

What a tooltip have to be / should not be.

3 main conditions for Content on Hover or Focus (AA)

1. Dismissable
   A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content.
2. Hoverable
   If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing
3. Persistent
   The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

From https://www.w3.org/WAI/standards-guidelines/wcag/new-in-21/#1413-content-on-hover-or-focus-aa

• Please keep in mind, that information, which is inside of a tooltip sometimes can't be reachable / obvious to use / visible and can't be explored and screen readers sometimes ignore descriptive text by default. It is almost impossible to test all use cases incl/ browsers, screen readers, mobile devices and so on. That means that this information will be lost. Please never put important information inside of the tooltip.
• Tooltip should contain only small peace of additional information.

General requirements

• Tooltips must be discoverable and readable with a mouse, other pointer devices, keyboard, screen reader, zoom software, and any other assistive technology.
• The visual display can be controlled by either a keyboard or a mouse.
• Closing process can be controlled by either a keyboard or a mouse. Using Esc key is not a best solution.A global escape listener would not be able to differentiate between a user wanting to dismiss a tooltip vs. close a dialog, dropdown menu, if one were open.
• Follow a logical tab order.
• Be easy to access without dismissing the tooltip and without relying on fine motor control.
• Only interactive elements have to trigger tooltips. But! Touch devices and other alternative pointers can't reach tooltips on buttons or links (hover is unavailable on a touch device). The reason for it is that button or links triggers there own events and it is not possible to trigger those events and show a tooltips in a same time.
• Tooltip have to never overlap other content. That is a very tricky point especially with combination with magnification software or just ZoomText. Also https://www.w3.org/TR/WCAG21/#resize-text could be a reason for failure.
• Tooltips doesn't have a timeout to hide itself.
• Combining pointer and keyboard events must not create multiple tooltips or other buggy behavior.
• Tooltip must not be dismissed while moving mouse over the tooltip content. Also with combination with magnification software or just ZoomText.
• Tooltp's content must not be lost by using magnification software or just ZoomText.

Implementation requirements

• Do not use the title attribute to create a tooltip.
• Avoid aria-haspopup and aria-live.
• Ensure the tooltip is unreachable when hidden via aria-hidden.
• Use aria-describedby or aria-labelledby to associate the UI control with the tooltip.
• Tooltip have to be opened on focus or mouse over, and closes on blur or mouse out.
• Allow a mouse or pointer user to hide the tooltip through a close button.
• To close a tooltip via keyboard use Ctr.

Good-looking tooltip (after UX study)

From

• https://www.youtube.com/watch?v=lb0_v7D4kbs&ab_channel=MSFTEnable,
• https://sarahmhigley.com/writing/tooltips-in-wcag-21/#:~:text=The%20accessibility%20requirements%20of%20tooltips,not%20required%20to%20operate%20it,
• https://inclusive-components.design/tooltips-toggletips/
• https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

[JuliaKirschenheuter]

Usage of tooltips through our apps

There are several examples regarding usages. Most of them are used for action buttons or links and just some text (sometoes just duplicating text). Some of them are used for "placeholder" inside of input element.

[JuliaKirschenheuter]

Conclusion

It is very hard to meet all most important requirements to fulfill accessibility fulfillment. It is also hard to find a very-accessible implementation e.g. third libraries.

As is wrote above, tooltips makes no sense on touch devices and other alternative pointers can't reach tooltips on buttons or links.

I would suggest to move tooltips out and replace important and for user relevant pieces of information with other UI elements and / or place this additional text to hidden elements and bind them via aria-describedby.

@nimishavijay, @jancborchardt i will be happy to hear a feedback from you 🧡

[PVince81]

@JuliaKirschenheuter thanks a lot for the research!

I think I observed that in some scenarios we do use "aria-describedby" as soon as a tooltip appears. But the latter only appears whenever the tooltip opens. It disappears when the tooltip closes. Not sure if this is suitable. It might be part of the tooltip implementation.

Before hover:

After hover:

I can't tell if this is sufficient or whether we should go through all tooltips across every app in Hub and try and replace it with an inline text of sorts if the content is essential.

[JuliaKirschenheuter]

I think I observed that in some scenarios we do use "aria-describedby" as soon as a tooltip appears.

Right connection with element via "aria-describedby" is of coarse an important part of implementation. But besides this 95% work should be done too. For a moment only "aria-describedby" wouldn't help us a lot. (Please look in my general requirements)

[jancborchardt]

I would suggest to move tooltips out and replace important and for user relevant pieces of information with other UI elements and / or place this additional text to hidden elements and bind them via aria-describedby.

I don’t fully understand – is the suggestion to get rid of tooltips? Cause tooltips are useful, also for sighted people.
Totally agree with the aria-describedby point, and then using that to show the tooltip text.

---

Visually, we can use 2 different approaches depending on case, if that’s ok?

title (when text is there but could be ellipsized)	tooltip (for showing supporting text)

Yes, currently we sometimes show the title for text that could be ellipsized but is not, like if the subline is only short. What can we do here – is having a title so bad? Otherwise we need to figure out via JS if it does overlap, and show the title attribute based on that?

---

Regarding the requirements, they all make sense to me, except this:

Dismissable
A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content.

Without moving the pointer hover or keyboard focus – so it can not be an x close button like in the example. It has to be something like Esc, no? I would also say that Esc is quite ok for that. We can have a global stack listening for Esc, which first closes any tooltip if open, then a menu if open, then a viewer if open, etc.

[JuliaKirschenheuter]

Without moving the pointer hover or keyboard focus – so it can not be an x close button like in the example.

Imagine you are on a mobile device. How could you close a tooltip then? What if there are multiple tooltips in several rows like

It has to be something like Esc, no? I would also say that Esc is quite ok for that. We can have a global stack listening for Esc, which first closes any tooltip if open, then a menu if open, then a viewer if open, etc.

Well, Esc will be listened everywhere. Once Esc is pushed - everything will be closed.