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)
See the Pen eJgXKd by steve faulkner (@stevef) on CodePen.
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!
Comments
Hi, great stuff as always. I think it could be great to add :
– close on click outside of of toggletip
– close when focus go out of the toggletip
@levy, feel free to fork and add 🙂
What would be the recommended approach when you want to have your toggle tip content in the HTML document, rather than in JavaScript?
Hi Drew,
you could do it like this https://codepen.io/stevef/pen/WrZGXP. Important things: only set the
describedbywhen the content is displayed, ensure that the displayed content is next in the DOM order after thebutton.Hey, thanks for this. Unfortunately, the link handler in the tooltip does not work anymore – I think it’s overridden by your custom JS handler to toggle the tooltip.
What would you say would be the best option to show the “information”-icon after the text/label? Would flexbox’ `flex-direction: row-reverse;` be a good idea? Or something else?
I also wonder what would be the best way to markup tooltips that show additional information to a label for an input element. For example how to obtain the information for the input or how it could look like (example values). Could you give me a hint how this would be done?
Sorry, another few questions:
What is the expected focus behavior? Should it get focus when it’s shown? And removed when not shown anymore? Because currently, when using `document.activeElement` it does not get focused on click or keypress, only by tabbing onto it and then it’s only the button, not the tooltip.
Also, is it intended that the tooltip shows when you press the “ESC” key on the site? Or should it only work when the tooltip is shown to hide it again?
@Anselm,
Which browser/version/OS are you experiencing this issue on? I cannot replicate.
Unsure what you are asking here.
@Anselm,
As said in the article:
For short text tooltips that are attached to pre-existing controls that have other primary functions, I would suggest the tooltip design exemplified in this tooltip widget demo.
@Steve:
So I just tested this in the Codepen (https://codepen.io/stevef/pen/WrZGXP) from the comments in Firefox.
I want to change the visual order of the text (“some text”) and the icon (so that the icon appears after the text “some text”).
@Anselm,
It is expected that the tooltip is only displayed on button activation; click, tap, enter key or spacebar (when button has focus). It is not expected that the tooltip gets focus (but focusable content inside the tooltip can recieve focus if the user chooses to do so).
Use of the ‘esc’ key to dismiss content such as dialogs is a standard UI pattern, I added to this ‘hybrid’ pattern as a usability aid.
Oh, now I understand, the ‘some text’ is just that, it is not part of the pattern. I put it there when testing the CSS positioning of the displayed content. Have updated text to make this clear
Looks like that is something codepen is doing, if you try the debug view works fine.
I went ahead and forked your pen to show that it is possible to achieve something similar without JS for better accessibility (although you could add the toggle for aria-expanded and a check for closing with the esc key back in as an enhancement)
Thanks Nigel, will check it out. Progressive enhancement was one of the issues I did not tackle in the demo, as I was concentrating on trying to get a pattern that worked well across as many AT as possible. I think
aria-expandedis an important aspect of the pattern as it let’s users know that something has changed. I am also reluctant to equate better accessibility with no JS, as I think they are orthogonal.If the content for the tooltip can exist within the html (rather than being added with JS), then adding hover behaviour is reasonable simple:
`#doit:hover + #tool1 {
display: block;
}`
https://codepen.io/johnholtripley/pen/KVypYN
Hi John, I realise it’s not difficult to add the hover behaviour, but it is a behaviour that I was trying to avoid 🙂
oh, what’s the thinking there then? I thought you’d have click for keyboard users, and then layer on top of that the hover for mouse users would give the best to both?
cheers, john
My thinking is that for tooltips that are really overlays, in that they contain content that may require interaction or more than a few seconds to consume, or cover a reasonable amount of the screen, on hover displays are annoying and a reduce usability (for me at least). I think it is better for users to be able to consciously choose when such content is displayed or not and the display of such content is not contingent upon the ability to accurately use the mouse pointer for a sustained period of time.
ok – thanks Steve
Great stuff Steve!
Another access tech user group to benefit from this technique is screen magnification users. Title attributes are a menace for this user group, as high magnification can mean that only six or seven characters are in the magnified viewport and of course disappear as soon as the mouse moves even a pixel away from the link.
The toggletip’s persistence until dismissed solves this beautifully.