Open mcking65 opened 8 years ago
Thanks @accdc for that writeup and the examples! I tried to condense those + some of my thoughts into a potential outline of examples for the tooltip design pattern. I'd be curious what you (and everyone else) think about it:
I didn't include the error tooltip or tooltip with dynamic content because while I think the work on notifications is really interesting, it doesn't seem relevant to the tooltip pattern. It seems like they'd fit better into a section on how to author notifications and live regions (which we should also add 😄). I also think they'd do better as inline text rather than tooltips -- the live region considerations would be the same, but then they don't have any of the UX problems introduced by tooltips.
One other thing is I think we should consider control as a dismiss key in addition to escape because tooltips show up within dialogs, non-modal popups, menu dropdowns, and even combobox dropdowns with depressing regularity. If escape is standardized as the one single dismiss key, it'll cause problems in all of those cases.
Notes from the meeting on 8/17:
I noticed that screen readers don't seem to announce the role tooltip on this type of example
<button ... aria-describedby="p1">...</button>
<div role="tooltip" id="p1"...>Lipsum...</div>
Or this
<button ... aria-labelledby="p1">foo</button>
<div role="tooltip" id="p1"...>Lipsum...</div>
Also our working example has aria-labelledby and in that case it overrides any text in the button so in that case either use aria-describedby or have 2 ids in the labelledby, the button self reference and the tooltip
<button ... id="p1" aria-labelledby="p1 p2">foo</button>
<div role="tooltip" id="p2"...>Lipsum...</div>
@DavidMacDonald
With which browser and screen reader does it not work? I have checked the examples with JAWS and NVDA and they work
If the related element is not visible, should we close the tooltip?
@tychenjiajun this is a very long thread. Can you please cite the prior comment you are referring to, or provide some more context?
If the related element is not visible, should we close the tooltip?
@tychenjiajun this is a very long thread. Can you please cite the prior comment you are referring to, or provide some more context?
If the related element is not visible, should we close the tooltip?
Reakit Tooltip is a tooltip component that claims to follow this pattern. However, it has weird behaviour. When I tab on a reference to open the tooltip, then scroll the page's scrollbar using the mouse until the reference becomes invisible, the tooltip is still visible. Should scrolling dismiss the tooltip?
@tychenjiajun said:
However, it was weird behaviour. When I tab on a reference to open the tooltip, then scroll the page's scrollbar using the mouse until the reference becomes invisible, the tooltip is still visible. Should scrolling dismiss the tooltip?
No, it should not be dismissed, and I wouldn't consider that weird. It seems to follow the guidance: you tabbed to it, so you have put focus on it, and scrolling the page is not removing focus from the reference. If you had triggered the tip with the mouse, then scrolling away would move the pointer off the reference, which should cause it to go away. But once invoked by focus, it's going to stay there until focus is lost.
This Note might help:
Focus stays on the triggering element while the tooltip is displayed. If the tooltip is invoked when the trigger element receives focus, then it is dismissed when it no longer has focus (onBlur). If the tooltip is invoked with mouseIn, then it is dismissed with on mouseOut.
Any updates on this tooltip? This tickets been open for quite sometime.
@tychenjiajun, I just had a look at the Reakit tooltip you have now linked to in your comment, instead of just reading the behaviour you described. I see what you're talking about. I think what's happening is that this tip's behaviour is colliding with a few other things on this page:
I think those are both problems with the banner implementation, not with the tooltip. I guess the one thing that could be investigated is if the styling that is putting the tooltip over other content could result in other page oddities with regard to the tooltip display. Worth Reakit testing. I'm a little surprised to see the tooltip dynamically reposition based on other content. Some people may like that. Some may not. I would have thought it was stay stationary once appearing. But I don't think the reposition would be considered a failure of anything?
Microsoft Windows closes tooltips with Ctrl
not Escape
. I have bigger writeup at #2538 specifically addressing this.
Key points are: "Escape" is irregular. We lack a general pop-up ARIA for "rich" popups. Tooltips should not be "rich".
We have a use-case where we want to show the tooltip for a few seconds on initial page load and automatically dismiss it. After that the tooltip goes to regular behaviour and only appears on hover. Is this usage against the tooltip design pattern UX?
The tooltip design pattern is at: http://w3c.github.io/aria-practices/#tooltip
It is largely complete. Things to fix include:
Open questions: