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, 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.
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
titleattribute has, for both better and worse, provided a native tooltip that is allowed to be associated with any element, astitleis 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 thetitleattribute 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.