Create a tooltip component

This looks good but the tooltip is always to the right of the parent element isn't it? Maybe there could be also a modifier class when it should be to the left like it needs to be in #2170947: Visual cleanup of Edit shortcuts link - comment #13.

Or we could add that when/if it really will be needed later :)

Absolutely! :) I was thinking the tool tips in joyride are looking nice with the arrow, little less opaque and with smaller radius (it looks smaller).

Seems like we'll be able to use hint.css? :)

From the GitHub discussion:

• Source: https://github.com/chinchang/hint.css/blob/add-a-base-build/src/hint.bas...
• Build: https://github.com/chinchang/hint.css/blob/add-a-base-build/hint.base.css

I'll give this a go.

Update 1:
- I've applied the patch from Lewis. The tooltips look good, but the <em> tags are displayed as code. I'm looking for a solution for this at the moment.
- Screenshot of the issue be found here.

@LewisNyman: It's a bit off topic, but is there a style guide for these elements? Should I add some documentation on how developers/themers can use this new design element? Where can this documentation be found? ;-)

Update 2:
Small coding remarks:

+++ b/core/modules/shortcut/shortcut.module
@@ -393,14 +393,18 @@ function shortcut_preprocess_page(&$variables) {
+          'attributes' => array ('class' => array('hint--right'), 'data-hint' => $link_text, 'title' => $link_text)

- array () should be array() - so with no space.
- there should be a , at the end of the line.

Here's a new patch with the small remarks from comment #19. Still needs work, since the <em>'s are an issue. I've updated the issue summary.

OK. I've solved the issue with the <em>. I've changed the %shortcut_set into @shortcut_set .

Change the Issue summary. Since we've made some changes to the html, the tests for the shortcut module are failing. These tests need some work.

+++ b/core/core.libraries.yml
@@ -281,6 +281,13 @@ html5shiv:
+      assets/vendor/hint.css/hint.css: { }

I don't think there should be a space?
{ } -> {}

The rest of the patch looks good.

To-do: Remove the space from the last patch. Added the novice tag.

Removed extra space as mentioned by @sqndr in #28 and #29. Please review the rerolled patch.

@er.pushpinderrana - Thanks for change. Marking this as RTBC!

I just saw this.

There are still accessibility issues with hint.css https://github.com/chinchang/hint.css/issues/81

I'm happy to report that it works well with keyboard users.

The problems with screen readers may be that there's still no best practice that's well supported for tooltips.

I created this issue with hint.css:
https://github.com/chinchang/hint.css/issues/81

Also filed issues with NVDA & ChromeVox.

Was there any consideration of http://jqueryui.com/tooltip/

This too has known accessibility issues:
https://www.ssbbartgroup.com/blog/2013/07/03/jquery-ui-accessibility-ana...

But I'm not clear what version it was tested against.

@falcon03 suggested that actually a year ago https://www.drupal.org/node/1919940#comment-7234280

Notes too from Twitter with @scott_gonzalez:
https://twitter.com/scott_gonzalez/status/484402080677777408
https://github.com/jquery/jquery-ui/commit/b9e438d07c370ac2d4b198048feb6...

This is probably the better way to proceed.

Well, the jQuery Tooltips are certainly available:
core/assets/vendor/jquery.ui/ui/jquery.ui.tooltip.js

Seems pretty powerful http://www.tutorialspoint.com/jqueryui/jqueryui_tooltip.htm

I'm just not sure how to use it.

I'll be less categorical than sun is in #1919940-6: Build API to Replace Links using Title Attributes with Proper Accessible, Themable Tooltips, by saying that any solution that requires jQuery is a no-go. It'd mean we're back to jQuery (and some jQueryUI) being loaded on all pages.

I agree with him that it's not the place of Drupal to take care of this but if we can do something for a11y, why not.

That said, rerolled patch to use libraries properly.

Fanciness may be an argument, but Accessibility is not a good argument to bring up for Hint.css, because its tooltips may appear outside of the visible viewport and are thus not accessible.

Hint.css:

Native UA tooltips:

For the UA demo, a title="" attribute was added to the download button on http://kushagragour.in/lab/hint/

UA tooltips can be displayed outside of the browser window, and they are automatically repositioned in case the tooltip does not fit on the screen.

Since purely CSS-positioned (ahead of rendering time), Hint.css tooltips are hard cut-off on the visible browser window viewport. The tooltip text does not soft-wrap even in situations in which the whole tooltip could fit on screen.

This applies to all possible tooltip directions, whereas the bottom and top directions are most problematic, since those may simply be rendered off-screen. In the right and bottom directions, a tooltip causes browser scrollbars to appear on hover on smaller screens.

Lastly, unless I'm missing something, the data-hint attribute is unknown to screen-readers, so any contained help text won't be announced. I assume the source attribute would have to be changed to consume one of the ARIA description attributes instead.

Bottom line: Hint.css looks like a great effort and library. I like the idea. But without some minimal JavaScript for positioning & text-wrapping (& scaling), I don't see how it can reliably work for tooltips in today's world of vastly different screen sizes. In its current form, it clearly introduces accessibility problems (even for users not having a visual disability).

The attempt to control layout/positioning in HTML (via classes) is conceptually flawed. Normally, layout/positioning exclusively belongs into CSS. However, CSS still lacks conditional screen/box selector constraints at the element level that would allow to prevent tooltips from appearing cut-off/incomplete or off-screen/invisible. At this point, the necessary level of positioning control can only be achieved through JS in a reliable way.

Due to that, we should move forward with a CSS + JS based solution.

I'm not sure why a potential dependency on jQuery presents any kind of problem? Tooltips normally appear on more complex user interfaces only (e.g., forms) and those pages have a very high probability of requiring jQuery either way already.

(That's not to be meant as an endorsement for the jQuery Tooltip library [there are popular alternatives], but only meant to say that I can't get behind the resistance to a JS based library.)

jQuery based library is my issue. But I guess one could just do away with the library and use the default browser tooltips.

I'm ok with implementing that with jQuery if it's Seven only.

Sites owner always expected more than just showing the hints, Pure CSS libs never able to fulfill their needs.

anyway, #1890266: dropbutton text fails to retain .dropbutton-widget width has same issue mentioned in Comment #38. (sometimes a hint could be a dropdown menu, just see how do you styling it.)

Less code than expected, nice.

From what I tested, jquery handles the offscreen situation nicely but there are a few styling issues.

Background should be opaque, not transparent. It's not legible when there is text under the tooltip (which is very often). Position of the tooltip isn't helping much, either top or bottom is more helpful.

with $(document).tooltip(); and a black background the tooltips looks good enough.

Would love to have it, but....

Open for business

Added tags + updated to 8.2.x.

Note: Discussion for a solution is very much needed before any patches appear for this issue.

Design solutions should probably also take the design of the Tour module call-outs into account.

eBay has come out with this pattern https://ebay.gitbooks.io/mindpatterns/content/disclosure/tooltip.html

Also curious about Web Components tooltip:
https://www.webcomponents.org/element/PolymerElements/paper-tooltip

Ran into these accessibility tooltip patterns too:

https://van11y.net/accessible-simple-tooltip/
https://van11y.net/accessible-modal-tooltip/

We need to keep in mind WCAG 2.1 when building this.

Success Criterion 1.4.13 Content on Hover or Focus

"Where receiving and removing pointer hover or keyboard focus triggers additional content to become visible and hidden, respectively, the following are true:

Dismissable
- A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
Hoverable
- If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
Persistent
- The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author."

Thanks for linking the WCAG 2.1 criterion. More information is available in the draft of Understanding Content on Hover or Focus, with diagrams.

The WAI-ARIA Authoring Practices includes a pattern for accessible behaviours of a tooltip widget. If we follow this, we'll need some ARIA attributes to establish the tooltip role and relationship with the trigger element.

A few things about the WCAG 2.1 Success Criterion 1.4.13 Content on Hover or Focus...

Dismissable
- A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

The WAI-ARIA Authoring Practices assumes the escape key will provide the means of dismissing the tooltip. This would rule out a pure-CSS approach.

Hoverable
- If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

This is important for screen magnifiers. A tooltip may be too large to fit inside the magnifier's viewport, so moving the pointer over the tooltip itself may be necessary in order to read it all. If the tooltip is offset from the trigger in any way (e.g. speech bubble style, with a connecting triangle) then we'd need to account for moving the pointer across a short empty area, e.g. use a slight delay before it disappears.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

Basically, this means the HTML title attribute is exempt from this WCAG criterion. But that's a cop-out really - the point of this issue is that we want accessible tooltips, and the HTML title attribute won't suffice. The Understanding Content on Hover or Focus draft explains: "This criterion does not attempt to solve such issues when the appearance of the additional content is completely controlled by the user agent. A prominent example is the common behavior of browsers to display the title attribute in HTML as a small tooltip.".

The "add to shortcuts" tooltip in Seven passes this success criterion. For dismissable, it passes because it doesn't obscure any content. That's not because of the component itself though, it's because nothing is placed after it in that region.

Forgot to say, I'd like to follow the ARIA Authoring Practices on this one.

Reworked #49 for 8.6.x

Thanks for the patch @volkerk - I'm just moving this to Needs Review as that way the bot will check it. Core's probably moved since then, so....

Sorry it took me 6 months to notice your patch!!!

Do you have any screenshots of it?

Also wanted to post Scott Vinkle's Tooltip solution so we'd have that in the mix:
https://inclusive-components.design/tooltips-toggletips/

During reroll i got only 1 conflict here
/core/modules/shortcut/shortcut.module -L 359

<<<<<<< 3ba6bc11689c4691063a46ac03ef933885f16f2b
        '#title' => new FormattableMarkup('<span class="shortcut-action__icon"></span><span class="shortcut-action__message">@text</span>', ['@text' => $link_text]),
=======
        '#title' => SafeMarkup::format('<span class="shortcut-action__icon"><span class="shortcut-action__message">@text</span></span>', ['@text' => $link_text]),
>>>>>>> Applying patch from issue 2207383 comment 12571588

so i changed in on
'#title' => new FormattableMarkup('<span class="shortcut-action__icon"></span><span class="shortcut-action__message">@text</span>', ['@text' => $link_text]),

I see no reason to use formattable markup here - it looks more like inline template

Here's an approach to using tooltips with WCAG 2.1 - https://sarahmhigley.com/writing/tooltips-in-wcag-21/

Note that core is about to adopt Popper.js in #3074267: Replace jQuery UI position() with PopperJS.

Popper.js has an optional Tooltip,js addon which might be useful here: https://popper.js.org/tooltip-examples.html

Closing this as outdated since PopperJS now exists (see comment #81)

Updated link to the one provided by @bojanz in #81 above. Should be https://popper.js.org/docs/v2/modifiers/offset/ or something like that.