Simple standalone toggletip widget pattern

Posted on Friday, 15 January 2016 by Steve Faulkner

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:

About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. 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 HTML 5.1, ARIA in HTML, Notes on Using ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility.

Comments

  1. 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?

  2. 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?

  3. 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?

  4. @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.

  5. @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.

  6. @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 (http://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”).

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

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

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

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

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

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

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

Comments for this post are closed.