-
Notifications
You must be signed in to change notification settings - Fork 350
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
Tooltip placement #3159
Comments
There is WCAG SC 1.4.13 for this case, isn't there? That's why I don't necessarily see the need for it. Especially as the cursor shape can be set in the screen magnifier, so it's not even clear which position of the tooltip is the best. |
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<jugglinmike> Topic: Issue 3159 - Tooltip placement<jugglinmike> github: https://github.com//issues/3159 <jugglinmike> Matt_King: This is another one of those things where I need the opinion of someone else to figure out what to do with the issue <jugglinmike> Matt_King: I don't know if I'm following the description. Why is the large cursor going to be more below than above? Also, I'm not sure if we had any instructions related to tooltip placement <jugglinmike> Matt_King: We might need some people who aren't present today... <jugglinmike> howard-e: I'm also not too sure about what the report is referencing. <jugglinmike> Matt_King: Would it help if they provided a screenshot? <jugglinmike> howard-e: Yeah, that'd be very helpful to me <jugglinmike> Matt_King: That seems like a reasonable next step. It would be nice if it were more clear, though I'm not sure if it's even in the scope of what we want to do with tooltip... Although I suppose that's what we need to decide as a group <jugglinmike> Zakim, end the meeting |
There are different cursor shapes, but the standard shape is an arrow pointing diagonally upwards to the left. This means that the actual cursor shape is located below and to the right of the tip. But I don't see any need for action because of WCAG 1.4.13 |
@JAWS-test I fully agree that fully complying with SC 1.4.13 would cover this concern but I believe that adding this note may help authors better understand the issue at hand. By incident, the google example illustrates this very good. For keyboard users the tooltip is implemented in a way that passes the dismissible, hoverable, and persistent requirements of SC 1.4.13, but for mouse users it doesn't. |
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<jugglinmike> Topic: Issue 3159 - Tooltip placement<jugglinmike> github: https://github.com//issues/3159 <jugglinmike> Matt_King: We talked about this last week, and we had questions. There is now additional information in the issue <jugglinmike> Matt_King: There's a question here as to whether or not some additional guidance should be added to the tooltip pattern that is related to the instructions on how to conform to this particular pattern <jugglinmike> Jem: Are they talking about the example? <jugglinmike> Matt_King: They are just talking about the pattern; we don't have an example <jugglinmike> Matt_King: They are suggesting that we add a note to the pattern. I don't know exactly what this note would say <jugglinmike> Matt_King: The pattern still has an issue. We don't say that it's truly finalized <jugglinmike> Jem: Perhaps we should move this to the backlog <jugglinmike> Matt_King: I kind of want to make a decision on this. We could add it to the backlog if we agree that such a note is important to include in the pattern <jugglinmike> Jem: I believe there is a new WCAG rule about not hiding or blocking the view of some issue <jugglinmike> Matt_King: Perhaps you're thinking of the rule that JAWS-test referenced <jugglinmike> Jem: No, there's more than 1.4.13 <jugglinmike> lola: I agree with what's mentioned in the issue. I personally don't think there's any action for the APG to take <jugglinmike> lola: The APG isn't where you go to discover the "rules"; WCAG is where you go to learn those <jugglinmike> Matt_King: I don't think they're suggesting that we add definitive text <jugglinmike> Matt_King: Regarding the text "whenever possible, place the tooltip above" <jugglinmike> Matt_King: When you move the pointer around, I'm imagining that you move it around, and because it's so big, you don't move it directly on top of your target. That rather, you move to point at the target <jugglinmike> lola: Once your pointer enter the space, that will trigger the tooltip <jugglinmike> lola: The position of the pointer really doesn't matter in the sense that once it enters, it will trigger <jugglinmike> lola: The reporter has given an example where the tooltip is at the bottom and the pointer is also at the bottom <Jem> I agree with this comment https://github.com//issues/3159#issuecomment-2440529068 <jugglinmike> Matt_King: Is the entire visible pointer the pointer? Or is the pointer so large that it could actually be on two elements at the same time? <jugglinmike> CurtBellew: The latter <jugglinmike> CurtBellew: I always assumed that the very tip of the pointer is the actual determining factor <jugglinmike> Matt_King: Is it possible that the tip is pointing at a different element than the element being covered by the bulk of the pointer <jugglinmike> lola: I'm testing now. I am pointing at one element while covering another element, and I can only click on the former <jugglinmike> CurtBellew: 1.4.13 content on hover includes a requirement that you have to be able to move your mouse into the popup content <jugglinmike> CurtBellew: It sounds like the person is acknowledging that. It also seems more convenient if the popup happens above. For me, I get where Jem is coming from by suggesting that this is a backlog <jugglinmike> Jem: If you look at the JAWS-test comment, I really agree with that. There's no way we can control pointer size or location. That's a customized setting for the <jugglinmike> s/for the/for the user's need/ <jugglinmike> Matt_King: The purpose of the patterns is to help authors implement the pattern in an accessible way. Our role is to give them guidance <jugglinmike> Matt_King: If there are important things that they need to consider that are related to the design of the element--if there's something that the authors should be thinking about AND we can give them practical guidance, than it could be in scope <jugglinmike> Matt_King: The question to me, is: is there practical guidance that we can give? Or is it the case that you can't actually predict what the best location of the tooltip would be, maybe ever? <jugglinmike> Jem: My only advice would be to think about low-vision users when you implement this tooltip. There is a chance that the pointer obscures the button itself. We have to consider all kinds of disability <jugglinmike> Matt_King: That doesn't seem like very actionable advice in this scenarios. Instead of saying "think about", we should be saying "test in a certain condition" <jugglinmike> Jem: Then it could be advice for low-vision users. I'm trying to think about the action that an author can take <jugglinmike> Matt_King: If Google had read our tooltip pattern and included some kind of note about this, would they have been able to make a different design decision? <jugglinmike> Matt_King: It doesn't seem clear to me that the guidance that you should always place it above--is that practical? There are situations where you can't place it above <jugglinmike> CurtBellew: The thing with the tooltip is that you will have a default position where it appears relative to the pointer, but that default will be overridden by the context <Jem> https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html <jugglinmike> Matt_King: As long as they support 1.4.13, then they should always be able to move the pointer to a location so that it is not obscuring the tooltip and so that its tip is still hovering on the tooltip (so they will be able to read it) <jugglinmike> Jem: I remembered the section of WCAG that I referenced earlier. I copied a link in IRC <Jem> https://www.irccloud.com/pastebin/9MH08g3C/ <jugglinmike> jugglinmike: Authors only have access to the coordinates of the tip of the pointer. They cannot know the bounding box of the pointer image itself. There's no guarantee that the pointer image will always be directly below the pointer's tip <jugglinmike> Matt_King: The question is whether to add a note or not <jugglinmike> s/note/note about where to place the tooltip/ <jugglinmike> Matt_King: The only condition that we would want to add such a note is to say, first, that we believe that it should be in a specific location for a specific set of reasons <jugglinmike> Matt_King: I think that what I'm gathering from this conversation is that we don't have those two things: the location where we think it should normally be, nor the set of reasons why we would want it to be in that location (there are too many things that the author does not know about the pointer, and there are too many conditions introduced by the user agent that would motivate putting the tooltip in a variety of locations) <jugglinmike> Matt_King: I think we can say that we understand the concern but we don't believe we can provide actionable guidance that will have broad support across the accessibility community <jugglinmike> Matt_King: Browsers could change how they do extra-big pointers. Like jugglinmike was saying: they could point down from above or straight up from below <jugglinmike> Jem: And user-agents can change their size <jugglinmike> Matt_King: So we're okay with closing this as a "won't fix"? <jugglinmike> Jem: Yes <jugglinmike> CurtBellew: Yes <CurtBellew> +1 |
Some visually impaired users alter their mouse cursor size to a much larger size . When a tooltip's content is placed below its triggering element, often times the tooltip content is hidden behind the large cursor.
I'd like to suggest a new instruction for tooltips placement - whenever possible, place the tooltip content (probably above) so it wouldn't be hidden by a large cursor (or a finger).
The text was updated successfully, but these errors were encountered: