Microsoft-ui-xaml: Update ToolTip to meet new MAS 1.4.13

[YuliKl]

Proposal: Update ToolTip to meet new MAS 1.4.13

Summary

The new requirement states that tooltips must be dismissible, hoverable, and persistent. The ToolTip control currently doesn't meet any of these characteristics.

Rationale

• Need to be compliant with MAS 1.4.13 by June 2020

More detail about success criteria available from W3 WCAG

Scope

| Num | Capability | Priority |
| :---------- | :---------- | :------- |
| 1 | Dismissible: add support for hardware keyboard key to close an open ToolTip | Must |
| 2 | Hoverable: Ensure that moving pointer onto the ToolTip does not dismiss it | Must |
| 3 | Hoverable: Update default placement of ToolTip to eliminate the gap between tooltip's trigger control and the ToolTip control | Must |
4 | Persistent: remove current auto-dismiss timeout | Must

Important Notes

Open Questions

1. Dismiss key
   There's some debate over which key should dismiss ToolTip. Current proposal is to use Ctrl key, but this is subject to change.
   
   
   
   • Related, should the dismiss key hide tooltip on key up or on key down? It's common to show custom keyboard shortcuts inside a tooltip. If the tooltip dismisses on key down and the custom shortcut includes the Ctrl key, users may get frustrated about being unable to see the entire shortcut while trying to invoke it. On the other hand, there's some concern about the tooltip sticking around or stealing the key press if it doesn't dismiss until key up.
   
   
2. Auto-dismiss
   There's also a discussion about whether tooltip auto-dismiss should be allowed when tied to a user setting (e.g. in the Windows Settings app). The default will continue to be non-auto-dismiss-based-on-elapsed-time, but we may need to hook into a future setting.
3. Hoverable with offset
   ToolTip currently supports horizontal and vertical offsets that can be used to move its placement further away from the trigger control. These offsets create a gap between the trigger and the tooltip, likely causing the tooltip to dismiss when the pointer moves into this gap. This behavior prevents ToolTip from being hoverable. The open question is whether the control must address this behavior.

[grochocki]

There's some debate over which key should dismiss ToolTip. Current proposal is to use Ctrl key, but this is subject to change.

Would this eat the input, possibly interfering with keyboard shortcuts?

This behavior prevents ToolTip from being hoverable. The open question is whether the control must address this behavior.

Is the open question whether to continue to developers set offsets that would prevent hoverable ToolTips? Could optimizing all default templates to guarantee ToolTips are hoverable be sufficient here?

[mdtauk]

Can you point to any apps which exhibit the behaviours you are describing?

[grochocki]

Here is an example in Calculator of a ToolTip that has a gap that would prevent it from being hoverable:

Edit: Can't capture mouse pointer... this only repros for certain pointer positions, sometimes the ToolTip shows up without a gap.

[mdtauk]

There could be a hit target larger than the visible caption text, so the mouse is over it, even if not visible over it

[YuliKl]

Would this eat the input, possibly interfering with keyboard shortcuts?

We'll need to be careful in the implementation, but I don't anticipate any interference with keyboard shortcuts. These tend to be two-key combinations, e.g. Ctrl+S or Ctrl+X. If keyboard focus is on a trigger control that shows a tooltip, pressing Ctrl will close the tooltip. Because the user will continue to hold down Ctrl, pressing the second key to complete the shortcut combination should still trigger the shortcut. I believe as long as we don't mark the Ctrl press as handled in any way, everything should continue to work.

Is the open question whether to continue to developers set offsets that would prevent hoverable ToolTips? Could optimizing all default templates to guarantee ToolTips are hoverable be sufficient here?

I'm hoping that providing the right hoverable behavior by default while allowing apps to customize and potentially break hoverability is the right answer. I want to make sure we think through the implications of the platform continuing to provide apps with existing placement flexibility, making it easy for apps to violate the new requirement. Or whether the platform should ignore the offset properties, or do something really clever (that I haven't thought of yet because we can't reliably predict ahead of time exactly where the tooltip will open) when an offset is specified.

There could be a hit target larger than the visible caption text, so the mouse is over it, even if not visible over it

Tooltips should dismiss when the pointer moves off the trigger control (or off the tooltip itself). So the problem with a larger hit target is that the tooltip may not dismiss when the user expects it to disappear. This problem gets worse if several trigger controls are placed next to each other because we run the risk of one of them dominating over its neighbors when calculating when to show/hide corresponding tooltips.

[mdtauk]

Will this new behaviour for tooltips extend to the Win32 shell?

Will Tooltips need a hover state, or is it purely a functional change?

[YuliKl]

Will this new behaviour for tooltips extend to the Win32 shell?

This issue is tracking changes to the Xaml ToolTip control.

Will Tooltips need a hover state, or is it purely a functional change?

I believe purely a functional change. The hoverability requirement is primarily needed for screen magnifiers.

[lukasf]

I understand the accessibility issues, but I don't think it is a good idea to remove the gap between control and tooltip. It is good to offset the tooltip a bit, to give a distinction between control and tooltip. The W3 docs also show a gap between control and tooltip, it's not like they recommend to remove it.

Could the "hoverable" requirement be met by placing a small transparent control into the gap between the control and the tooltip? Or it could even be a transparent part of the tooltip itself, and would eat pointer movements, so the tooltip does not disappear when moving the pointer in. This way, hoverability could be done without removing the gap.

[bmeersma]

There's some debate over which key should dismiss ToolTip. Current proposal is to use Ctrl key, but this is subject to change.

The Ctrl key is a Narrator shortcut to stop typing so we probably shouldn't use it for this purpose. In Office we use Ctrl + Shift + F10 to invoke tooltips. Can we also use this shortcut to dismiss tooltips?