Tooltip Text support for Views

[Redth]

Description of Change

Open questions

1. Everyone ok with an attached property? Yes they are

2. Is ToolTipProperty an ok name? WinUI uses ToolTipService. I mainly went with ToolTipProperty because of SemanticProperties and AutomationProperties. We don't really have anything suffixed with Service

3. is IToolTipElement a valid name for something that has a ToolTip? Similar question here Context menu support for Windows and MacCatalyst #9174 (comment)

4. Should ToolTip be a concrete class on ToolTipProperty and inherit from Element so you can set it in one go? We have cases for both. Right now we are following more of the Font approach here. https://docs.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.tooltipservice?view=windows-app-sdk-1.1 . The main reason to do this is if we want to allow people to instantiate an entire ToolTip and if we think specifying via a tooltip class is easier for the user.

API CHANGES

MAUI.Controls

// Other XAML Frameworks use ToolTipService
public class ToolTipProperties 
{
	public static readonly BindableProperty TextProperty = BindableProperty.CreateAttached("Text", typeof(string), typeof(ToolTipProperties), defaultValue: null, propertyChanged: OnToolTipPropertyChanged);
}

MAUI.Core

namespace Microsoft.Maui
{
	public partial class ToolTip
	{
		/// <summary>
		/// ToolTip content.
		/// </summary>
		public object? Content { get; set; }
	}
}

namespace Microsoft.Maui
{
	/// <summary>
	/// Indicates that this element has a ToolTip to show
	/// </summary>
	public interface IToolTipElement
	{
		ToolTip? ToolTip { get; }
	}
}

Samples

Windows:

MacCatalyst:

Android:

Issues Fixed

Partially implements: #1889 There's no placement property here yet, the UIKit API's seem to allow this customization, nor do the Android API's.

[mattleibow]

Looks very nice and simple tbh. Love it.

[rachelkang]

LGTM so far!

I think we can benefit from adding some semantics here as well. From an accessibility perspective, the tooltip behavior is inconsistent between the platforms (tested Android, Catalyst) and in my opinion, not ideal on any at the moment.

On Android:

1. When the screen reader focus is on the button, the tooltip gets announced (as a hint) in addition to the text (this is good)
2. When long pressing to activate the hover with screen reader on, the toolitip appears visually but the screen reader does not note anything (this can be improved by using the Announce API imho)

MacCatalyst:

1. The tooltip text never gets announced (should at least get announced as a hint)
2. Same as Android

^ Those are my two cents on how it should behave from a basic accessibility standpoint. There are more complexities involved when we consider things like how to dismiss the tooltip message (the "mouse off" equivalent of screen reader - would probably need to consider the various types of announcement APIs that interrupt you vs. let you finish)

cc @PureWeen

[Redth]

LGTM so far!

I think we can benefit from adding some semantics here as well. From an accessibility perspective, the tooltip behavior is inconsistent between the platforms (tested Android, Catalyst) and in my opinion, not ideal on any at the moment.

On Android:

1. When the screen reader focus is on the button, the tooltip gets announced (as a hint) in addition to the text (this is good)
2. When long pressing to activate the hover with screen reader on, the toolitip appears visually but the screen reader does not note anything (this can be improved by using the Announce API imho)

MacCatalyst:

1. The tooltip text never gets announced (should at least get announced as a hint)
2. Same as Android

^ Those are my two cents on how it should behave from a basic accessibility standpoint. There are more complexities involved when we consider things like how to dismiss the tooltip message (the "mouse off" equivalent of screen reader - would probably need to consider the various types of announcement APIs that interrupt you vs. let you finish)

cc @PureWeen

On android, does it make sense that since the screenreader reads the text on focus, it's redundant to read it again on long press? I'm hesitant to change the default behavior here given the logical path to activating the tooltip through a screenreader would already read out the text before that action.

For catalyst, what event would we ideally hook into for announcing the tooltip? focused?

I think we could maybe open a new issue to track improvements to the screenreader experience around tooltips and keep this PR focused on the API wrapping each of the platform implementations.

[mattleibow]

Now I am gonna be that guy... ToolTip or Tooltip? Should the T in Tip be uppercase or lowercase?

[campersau]

Framework	Spelling
WinUI3	ToolTip
WPF	ToolTip
WinForms	ToolTip
iOS	toolTip
Android	Tooltip
Tizen	tooltip

[rmarinho]

How do i select the placement of the ToolTip? Colors etc?

[PureWeen]

LGTM so far!

I think we can benefit from adding some semantics here as well. From an accessibility perspective, the tooltip behavior is inconsistent between the platforms (tested Android, Catalyst) and in my opinion, not ideal on any at the moment.

On Android:

1. When the screen reader focus is on the button, the tooltip gets announced (as a hint) in addition to the text (this is good)
2. When long pressing to activate the hover with screen reader on, the toolitip appears visually but the screen reader does not note anything (this can be improved by using the Announce API imho)

MacCatalyst:

1. The tooltip text never gets announced (should at least get announced as a hint)
2. Same as Android

^ Those are my two cents on how it should behave from a basic accessibility standpoint. There are more complexities involved when we consider things like how to dismiss the tooltip message (the "mouse off" equivalent of screen reader - would probably need to consider the various types of announcement APIs that interrupt you vs. let you finish)

cc @PureWeen

I think for now we should open a follow up issue to assess how ToolTips are typically surfaced from an a11y standpoint. All of the code in this PR uses platform concepts of ToolTips so we're not inventing anything across any platforms.

[jsuarezruiz]

I would miss something like an IsOpen property, but as a basic implementation it works fine on Windows and macOS.

[PureWeen]

I would miss something like an IsOpen property, but as a basic implementation it works fine on Windows and macOS.

I agree but I don't think this is super easy to achieve with the platform APIs. I haven't found a great way to detect this on Android. If users want richer content/experience then they should probably use PopOver on the community toolkit

Ready for now, any a11y issues are platform-specific. See #8864 (comment)