Predictability: Escape key to dismiss tooltips

[OliKei]

https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/

Hitting the Escape key to dismiss a tooltip is surely a nice option for getting rid of a tooltip, however, it may add cognitive friction for screen reader users. Screen reader users perceive the tooltip's information via a second channel (e.g. aria-description, or via title). They may not know if a tooltip is currently displayed or not, specifically if the process for displaying a tooltip depends on some system-based delay time. So in a case where a tooltip is not yet visible the use of the Escape key might then trigger unintended actions, such as cancelling a dialog.
An alternative could be that the focused control will always consume the Escape key, but then an intended cancel action might not work, again, cognitive friction.
IMHO the tooltip interaction needs to incorporate predictability, so unexpected actions will not be triggered unintentionally.
Is there a way to tell a screen reader user a tooltip is already displayed so the use of the Escape key can be used with the knowledge of a tooltip is currently displayed on the screen?

[mcking65]

As a screen reader user, I've never thought of this. I never dismiss tooltips because I don't have a reason to do so.

If I understand your question, am I right to assume that for screen reader users who can see enough to know that a tooltip is displayed, this predictability problem would not exist?

[OliKei]

Yes, I think so.

In most of the use cases of tooltips the tooltip appears modeless and should probably also disappear modeless, e.g. by tabbing further, or removing a mouse from the UI element's visual presentation.

In the case where an intended trigger is implemented to display a tooltip (e.g. via a keyboard shortcut, like a Ctrl+i may do) it would also need a shortcut to dismiss it, preferably the same shortcut, as a toggle key.

Both models, the modeless and the one with the intended trigger, usually work seamlessly together if both are implemented.