Definitive tooltip design pattern

[stes-acc]

Definitive tooltip design pattern – when can we expect that?

It seems that there are still MANY discussions in GitHub around this pattern and devs feel uncanny to follow.

[scottaohara]

should this issue be moved to the aria-practices repo?

[stes-acc]

Can we please designate a short F2F discussion slot collecting the pros and cons of current tooltip pattern recommendation, especially for "rich" tooltips containing non-presentational content like links etc.?

This goes deep and is absolutely related to the ARIA group popup/popover role discussion and the proposed popover API which addresses such cases but is unfortunately is not yet here to stay.

[MarioBatusic]

We can discuss the nature of the "tooltip" role and not the kind of implementation. The implementation proposals and examples therefor shoul be in aria/practices. Discussion points could be:

• Is the role tooltip a document structure or a widget?
• Which content should be alowed as accessibility children if the role is a widget?

[stes-acc]

Attaching document with examples why current tooltip and dialog deinitions in ARIA are not enough to express all current use cases. tooltipspopoversdialogs.docx

[spectranaut]

discussed at TPAC this week, notes here: https://www.w3.org/2023/09/11-aria-minutes#t07

follow up discussion will happen Friday morning, see: https://github.com/w3c/aria/wiki/TPAC-2023-ARIA-Meetings

[spectranaut]

Discussed again: https://www.w3.org/2023/09/15-aria-minutes.html

[mcking65]

@jnurthen @spectranaut

Are there ARIA WG actions to track here? Or, should this issue be transferred to aria-practices?

[stes-acc]

As discussed on TPAC, this should evolve into a role that allows also for non-presentational content like links. So, not pure APG, also ARIA evoulution included.

But as a first step, tooltip examples in APG are needed, yes.