-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[popup] hint - how to provide keyboard access for non-focusable elements #530
Comments
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: 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? |
@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 whatwg/html#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. |
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? |
Popups could be on non-focusable elements if there's another way to get the same functionality. |
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 Fyrd/caniuse#6366. And for touch devices (via longpress(?), on any element with a |
I'm marking this "V2" due to the decision to pull |
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. |
Am I correct in thinking that this issue might be resolved by the latest explainer/behavior? Namely:
I likely missed something above, so please point it out. If not, I'd like to close this issue. |
Coming out of #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, astitle
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 thetitle
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.
The text was updated successfully, but these errors were encountered: