[popup] hint - how to provide keyboard access for non-focusable elements

[scottaohara]

Coming out of https://github.com/openui/open-ui/issues/529, it was brought up in the linked issue and during the telecon meeting today about how will primary-keyboard users, and touch-device users have access to non-focusable elements that can invoke a hint popup.

The title attribute has, for both better and worse, provided a native tooltip that is allowed to be associated with any element, as title is a global attribute. So there is precedent to allow it on any element, even non-interactive elements. This however has long been an accessibility concern, as non-interactive elements are not keyboard accessible, or can the tooltips the title attribute creates be 'hovered' or 'focused' on a touch-only device. So how do these users access such content?

The idea of any element that has a hint popup keyboard focusable would allow keyboard users access to such content, but it would also mean that there would be an increased number of arbitrary elements that are now in the document focus order. Being that tooltip content is meant to be tangential to the element of which it describes, while the access would be provided for these users, they would also probably want a mechanism to not have to navigate to it as well. This also still doesn't solve for touch devices where, again, there is no hover/focus.

We would need to brainstorm and determine what features / guardrails should be put in place for hint popups (also, as mentioned on the call today - hints could be both 'tooltips' or even 'validation messages' for form fields - emulating the current native browser validation messages.

cc @mfreed7 @hidde in case i've left anything out that you feel should be added at this point.

[aleventhal]

Some options: none of them perfect

Trigger popups on focus, and automatically add a set of elements to the tab order, one of the following: Idea 1. all elements that trigger a popup (new techniques provide more a11y, and does not break old content) Idea 2. all elements that trigger a popup containing interactive content inside (consistent behavior with current title support) Idea 3. all elements that trigger a popup, and also the title attribute (consistently accessible, but potentially causing backwards compat issues for content)

Downside of ideas 2 and 3: is that the tab order would easily become too full.

I would imagine there is a Github issue somewhere about title not being accessible. Anyone have a link?

[scottaohara]

@aleventhal re: title not being accessible existing github issue, i think we may have to go spelunking in the old html list serve archives to find issues on that? the closest I could find from a quick look through the whatwg html issues is https://github.com/whatwg/html/issues/4537

i poked around in the archived/closed w3c html issues as well, but nothing in there that's directly related to the hover issue.

[scottaohara]

another consideration (not saying i agree or disagree) is that an element that invokes a popup cannot be static content. e.g., it must be an interactive/focusable element in html, or it must be an element that has a non-negative tabindex (to allow for custom elements / elements modified via ARIA). this doesn't solve the issue with touch screens, but it does completely bypass the how do we make non-focusable elements focusable so that someone can read a popup that... in most cases... probably should have just been implemented as static text.

the counter to that is the fact there might be completely reasonable instances of needing a popup for static content (e.g., a misspelled item in a rich text document). Those might need (and by that i mean it's quite common to expect this) to have a popup of suggested corrections. So, again is the potential answer here that carret browsing should invoke a popup on an otherwise non-interactive node?

[aleventhal]

Popups could be on non-focusable elements if there's another way to get the same functionality.

[Malvoz]

re: title not being accessible

the closest I could find from a quick look through the whatwg html issues is https://github.com/whatwg/html/issues/4537

There are however browser bugs to support displaying tooltips on focus (would still require authors to set a non-negative tabindex on non-focusable elements, I assume), see links in https://github.com/Fyrd/caniuse/issues/6366. And for touch devices (via longpress(?), on any element with a title): https://bugs.chromium.org/p/chromium/issues/detail?id=410531.

[mfreed7]

I'm marking this "V2" due to the decision to pull popup=hint out of the "v1" spec.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[mfreed7]

Am I correct in thinking that this issue might be resolved by the latest explainer/behavior? Namely:

• popovertarget is only supported on "buttons", which addresses the problem of non-interactive elements.
• <button popovertargetaction=hover> will "activate" the popover when a) hovered, b) keyboard-focused, or c) long-pressed. That addresses the "how to activate" question.
• Popovers are (already) inserted into the focus order. So with the above button, keyboard-focusing the button will trigger the popover, which will then automatically be located at the very next tab stop. That addresses the "how to navigate to content" question.

I likely missed something above, so please point it out. If not, I'd like to close this issue.