(deep-dive) Invoketarget & Interesttarget

[keithamus]

Description of bug or feature request

At OpenUI we're working through the idea of invoketarget and interesttarget, new attributes on buttons that will "wire up" buttons to elements for various interactions. You can read the explainer here: https://open-ui.org/components/invokers.explainer/.

I'd like to present this to the ARIA working group, to get guidance and direction on how best to make these new attributes as useful as possible for web authors creating accessible interfaces.

[jnurthen]

proposed for Feb 15, 2024

[spectranaut]

Polyfill for invoker: https://www.keithcirkel.co.uk/invokers-polyfill/example.html

[spectranaut]

Minutes from today's deep dive: https://www.w3.org/2024/02/15-aria-dive-minutes.html

@MarioBatusic @scottaohara and @jnurthen to review accessibility support section and polyfill for invoker, specifically.

[MarioBatusic]

Short review of the accessibility indications of the openUI attributes "invoketarget" and "interesttarget"

Main problem: The HTML UI extensions through these attributes have a default behavior, but allow arbitrary JavaScript functions in response to all "invoke" and "interest" events. This means that all accessibility measures suggested in the explainers and here are only applicable in the case of default behavior.

invoketarget attribute

See the "Accessibility" section in Invokers (Explainer).

If the Invokee is only shown or hidden in response to InvokeEvents, the ARIA information in the "Accessibility" section of the explainer is correct and sufficient.

interesttarget attribute

See: Interest Invokers (Explainer).

The explainer states that this is an improved, accessible alternative for the "title" attribute. The tooltips generated by default are like this

• not only initiated by hovering the mouse device
• Tooltips are only opened via interactive UI controls.

Accessibility is not yet defined in the explainer. The following ARIA-relevant considerations may be helpful:

• Since this is a "title" alternative, the interestee element should have the role "tooltip".
• The attribute aria-describedby should be implicitly noted on the interest element with the IdRef of the interestee.

[scottaohara]

just noting here some things that keith and i discussed earlier this week.

1. for a button opening a dialog we shouldn't need an aria-expanded state. We don't recommend this now in ARIA, and I'm not sure it makes any sense to start exposing this here. Focus will move to the dialog anyway, so the announcement of state will likely never be more than one hearing "collapsed" prior to invoking... which could actually make someone assume that some other type of disclosure widget would open.
2. popover stuff looks generally good, but there are some tweaks to the HTML AAM mapping PR that I did even this week. So good to double check on those. Specifically, a bit of clarity around aria-details relation where we want to make sure that if the invoked element is the NEXT sibling in the DOM order, there is no details relation. But if it is the PREVIOUS sibling, a details relation can still be helpful since it's often annoying/poor UX to reveal content prior to the element that invoked it. A details relation could allow for someone to easily navigate to the start of the content that comes before it in the DOM, rather than having to hunt for where the newly revealed content starts
3. the above bits about the aria-details relation would hold true for the invokers of the details element, if that continues to be part of this work.

I am not convinced that tooltip or even aria-describedby will always be what is necessary for an 'interest' element. What is of interest won't always be a tooltip, nor will it always make sense to squash the content of the interest element into a flattened text string for the invoking element. This is the same sort of trouble we're having with popover=hint, yes the primary use case for that is to invoke tooltips... but people's definition of what a tooltip is doesn't always lend itself neatly to a description association, and the element that is invoked will not have an implicit role of tooltip unless we overwrite the element's role... which may not always be appropriate.

I know there's more thoughts that need to go into interest now though... so just take the above as for future consideration i guess.