New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Develop example of tooltip design pattern #127
Comments
Any chance this will go live in the near future? I'm looking for an accessible example to point to. |
While you are waiting for the w3c developers to design a tooltip pattern, you might want to have a look at @Heydon's tooltip component. |
Work on this is being done on CodePen. You can also view the debug page which is a lot easier to navigate with AT. Current open issues with the implementation:
Any help is greatly appreciated. |
@ZoeBijl It's looking good! Is there any description on how overflowing tooltips should behave? |
Yes, looking good! Would also be great to have a tooltip example on something other than a button such as a link/anchor, text input, and possibly regular text. |
@ZoeBijl that is a great example. One question immediately comes to mind: the example uses a As indicated in #128 the presence of a button might indicate a 'dialog toolip' pattern rather than a traditional tooltip. In any case, I think it might be worthwhile to think about what the role of the of the element that triggers the tooltip should be (when the tooltip is not attached to a form control or another element that performs a separate action, and the tooltip content is shown on touch, hover, and focus events). My gut says that no role would be sufficient, but perhaps I'm way off base. |
Do you mean when there’s more text than fits ion the tooltip?
That’s a good idea! I will add that.
Hmm, the buttons in the example would do something if they were implemented on a page. The heart/like button is what you’d find in Twitter’s UI for example. I can trigger some kind of alert to show that it did something. Would that clarify it?
While tooltips can certainly be used for other things; their main usage would still be to clarify buttons/other controls no? From @Heydon’s article:
As for the controls not triggering anything, I can look into that. I think if I add an action to them the tooltips won’t show anymore on touch devices (which also shows how useless tooltips are for UX patterns). |
Good point, I think that would clarify it. |
Great examples, @ZoeBijl ! I think you've covered all of the WCAG 2.1 SC 1.4.13 bases, because they are Dismissable, Hoverable and Persistent. Did you have something specific in mind when you wrote "Doesn’t conform to WCAG 2.1 SC 1.4.13 Content on Hover or Focus" in #127 (comment) ? |
I am pretty sure that @ZoeBijl's examples pass WCAG 2.1 SC 1.4.13. Here's the text of the SC:
The example is here: https://s.codepen.io/Moiety/debug/LaPvWy
|
@ZoeBijl The other issue mentioned in yesterday's call is that the tooltip is shown immediately without any delay. May want to implement a "hover intent" pattern to ensure that a mouse user actually intended to hover. |
That’s a good suggestion. I’ll move the code I have so far to the APG repo so we can collaborate on it more easily. My main issue is bounding box detection and I would appreciate help with that. |
@ZoeBijl is this something I can contribute to? I'd be happy to help if there's room for that. |
I’d love some help with the bounding box stuff. I’m back on Monday and will ping you with a location of this stuff :) |
When the pattern is finished, it may also be used for WCAG. See the discussion: |
@idoros Perhaps the WCAG people have ideas on how it would be correct according to SC 1.4.13 (you could ask at https://github.com/w3c/wcag/issues) |
@carmacleod, that's all good points, I'm trying to understand what would be a good default to start with. I wonder if there should be different behaviors:
I think that for now I would go with consistency that is easier to explain rather than a more complex behavior. Anyhow because there are 2 different input methods used together, then I assume the user has control over them and has made the choice to move the mouse over the tooltip (it's not that the tooltip just opened under the mouse), so the user can move the mouse away with a predictable outcome. @JAWS-test - Thank you for the reference 🙏 (I have over 40 tabs with various specs and discussions on the subject, including the SC 1.4.13 somewhere), I will do some more reading and then see if there is a place to ask there as well --- edit: opened an issue in WCAG |
Probably the most consistent and easiest to explain would be:
|
Agree it would be good to come to agreement and implement in APG, unless we see a blocker. |
If anyone wants to collaborate on this, let me know via Twitter/email ✨. Would love to knock this out of the park in a zoom call or something |
Hi @ZoeBijl |
@DavidMacDonald one issue is that the tooltip always appears at the bottom of the icon whether there is space there or not. Most tooltip implementations will render the tooltip either above or below depending on the space currently available within the viewport. |
@DavidMacDonald Here is the most recent tooltip discussion note. |
@DavidMacDonald the thing that was missing was bounding box detection. When the control was too close to the window’s edge the tooltip would overflow outside of the window; making the text unreadable. @thezacharytaylor and I updated the component this week—it now does left and right bounding box detection and correction! We’ll see if we can do the same for top and bottom. Should be ready fairly soon! Updated component is at the same URL. |
Good point! I updated the example, it will now close the tooltip when a
|
Development is done. The tooltip code is up on my GitHub. Feedback about their functionality and code clarity would be much appreciated! I’ll move it to a APG PR for further review after initial comments :) |
Awesome! |
Dear ZoeBijl, |
Pressing Similarly... Tooltip: On focus we can enable the tooltip with delay, and if the user press If |
We are rewriting our tooltips with better focus on accessibility. We have a CSS only one that is similar to the @ZoeBijl example that includes a wrapper and target (eg: But I'd like to share some concerns we've have with the approach since we are in the process of rebuilding. The system doesn't work in layouts that don't have So now, we've considered tooltip should be a top-level popup (ideally The other point is Escape to close. We do not implement this because it would be confusing for users who are focused on an icon-button within a form within a dialog. Those that could just be considered edge-cases though. |
We have multiple use cases in our product where we have a tooltip displaying on static content. We've added all of the functional requirements to pass SC 1.4.13 however we are getting violations from an accessibility scan that we can't have tabindex on an element without a widget role. I have yet to have any luck to find a role that passes the scan and wouldn't be confusing to users. |
@elizabethsjudd In my opinion, there is no role for it. The least confusing would be button. A button would also be appropriate if the tooltip is not opened automatically when the focus is received, but only after the button is activated. Or tooltips are only used on elements that already have a widget role. Alternatively, the results of the scan can simply be ignored, because the scans are not always right either. There is no WCAG rule that says that an element with tabindex must have a widget role. |
The tooltip design pattern is at:
http://w3c.github.io/aria-practices/#tooltip
The text was updated successfully, but these errors were encountered: