Simple standalone toggletip widget pattern

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 button as 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 esc key 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:

Categories: Development

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

levy says:

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

Steve Faulkner says:

@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?

Steve Faulkner says:

Hi Drew,
you could do it like this https://codepen.io/stevef/pen/WrZGXP. Important things: only set the describedby when the content is displayed, ensure that the displayed content is next in the DOM order after the button.

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?

Steve Faulkner says:

@Anselm,

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.

Which browser/version/OS are you experiencing this issue on? I cannot replicate.

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?

Unsure what you are asking here.

Steve Faulkner says:

@Anselm,

I also wonder what would be the best way to markup tooltips that show additional information to a label for an input element.

As said in the article:

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.

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:

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.

Which browser/version/OS are you experiencing this issue on? I cannot replicate.

So I just tested this in the Codepen (https://codepen.io/stevef/pen/WrZGXP) from the comments in Firefox.

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?

Unsure what you are asking here.

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”).

Steve Faulkner says:

@Anselm,

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.

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).

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?

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.

Steve Faulkner says:

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

Steve Faulkner says:

So I just tested this in the Codepen (https://codepen.io/stevef/pen/WrZGXP) from the comments in Firefox.

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)

Steve Faulkner says:

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-expanded is 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.

John Holt Ripley says:

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

Steve Faulkner says:

Hi John, I realise it’s not difficult to add the hover behaviour, but it is a behaviour that I was trying to avoid 🙂

John Holt Ripley says:

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

Steve Faulkner says:

oh, what’s the thinking there then?

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.

John Holt Ripley says:

ok – thanks Steve

Bim says:

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.