Tooltips have always bugged me, apart from regularly mispelling as “TOOTlips” it is a bugger trying to create one that works across browsers with Assistive Technology (AT), in particular screen readers (I have also had a long history in battling the demons of native (title attribute) display in browsers). Then there is the issue of how the trigger control is to be represented and how the keyboard only user UX is best provided and the more general UX of using mouse hover as a trigger for content display.
I think I have come up with the rudiments of a robust pattern that resolves all (at least most of) the problems I have encountered with tooltips:
Important: It’s not meant to be a replacement for single word or term tooltips, it’s for those times when a paragraph(s) of text, structured text and interactive content is displayed.
Say hello to the toggletip™ (no more tootlip)
What it does
- Uses a real
buttonas a control. - Places the displayed content next in DOM order after the button.
- Uses some ARIA magic to augment the semantics and behaviour.
- Displays or dismisses content on click, press or tap (also dismisses on
esckey press). - Conveys state (collapsed or expanded) to AT users.
- When initially displayed content is announced by (most) screen readers that support
aria-live. - Screen readers users can also virtual cursor through and interact with the displayed content.
- keyboard only users can interact with controls in the displayed content.
What it does not do
Display content on mouse cursor hover.
Notes:
- Yes, the CSS and JavaScript could be improved (I am crap at both), so please do.
- Thanks to Sir Ian of Pouncey for his help making the JavaScript work.
- debug view of the toggletip
- Feedback welcome!
