Meeting minutes
<Jem> https://
Agenda for November 19, 2024
https://
Matt_King: Any requests for change to agenda?
lola: I would like to add a small item. I am running for TAG and am encouraging W3C AC reps to vote for me
lola: That's it, actually
Matt_King: Next meeting: December 3
Matt_King: No meeting November 26
Publication planning
Matt_King: We have two items completed, and two more are looking close
Matt_King: Regarding the practice page for high-contrast, I am still working on editorial revisions. By the December 3rd meeting, it should be ready for final review
Matt_King: Though it would be really good if people have time to look at it before then
Matt_King: But during that week, it should be locked down while people do a final check
Matt_King: If anyone can set time aside for review on December 3, 4, or 5--that would be really helpful
Matt_King: Then either jon or I could perform a final pass
Matt_King: Regarding the multi-thumb slider: the reviews are complete as of this morning. I think it's merge-ready. howard-e has raised an issue that I want to respond to, but I don't believe that is a blocking issue
Issue 3174 - Multi-Thumb Slider missing top of thumb slider's ring on hover
github: w3c/
howard-e: To summarize: I don't presume to understand all the calculations for the dimensions. The "ring" it produces currently renders perfectly on the preview. When it moves to the production, though, the context changes in ways that impact the appearance. There, the top of the ring is occluded
<lola> I thought this was a design choice lol
howard-e: I think there needs to be a minimum for the "y" value. It goes negative in production
howard-e: As for the severity: this is a very small visual glitch. It doesn't impact much.
howard-e: I think it could be rolled into the current pull request, but I don't know the implications of such a change for the work which has already been reviewed
howard-e: That's why I think this might make more sense as a follow-up patch
Matt_King: If it's kind of a minor visual thing... It sounds a little weird, but it seems like the most important decision is to worry about this later
Matt_King: It sounds like an issue that jon might want to work on since he wrote the CSS. He's probably in the best position to recognize any potential side-effects
Matt_King: I think I'd like to bring this up during a meeting where jon is present
Matt_King: I don't want to assign it to jon in his absence
Jem: Could you reach out to jon and ask if he would be comfortable being assigned to the issue? That way it doesn't linger
Jem: How about we mention jon in the GitHub issue?
Matt_King: Even better
lola: I approved the functional stuff for this. However, I don't have a Windows or Android device. It may need someone else for those two platforms (I tested on MacOS and iOS)
<lola> https://
Jem: I can test on Android
Matt_King: It should work via clicking on desktop and via tapping on mobile
lola: It's generally easier to use this functionality on desktop; tapping precision on mobile leaves something to be desired for this use case
Matt_King: This is for the next publication
Jem: Got it. I'll assign myself as a reviewer
Issue 3159 - Tooltip placement
github: w3c/
Matt_King: We talked about this last week, and we had questions. There is now additional information in the issue
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
Jem: Are they talking about the example?
Matt_King: They are just talking about the pattern; we don't have an example
Matt_King: They are suggesting that we add a note to the pattern. I don't know exactly what this note would say
Matt_King: The pattern still has an issue. We don't say that it's truly finalized
Jem: Perhaps we should move this to the backlog
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
Jem: I believe there is a new WCAG rule about not hiding or blocking the view of some issue
Matt_King: Perhaps you're thinking of the rule that JAWS-test referenced
Jem: No, there's more than 1.4.13
lola: I agree with what's mentioned in the issue. I personally don't think there's any action for the APG to take
lola: The APG isn't where you go to discover the "rules"; WCAG is where you go to learn those
Matt_King: I don't think they're suggesting that we add definitive text
Matt_King: Regarding the text "whenever possible, place the tooltip above"
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
lola: Once your pointer enter the space, that will trigger the tooltip
lola: The position of the pointer really doesn't matter in the sense that once it enters, it will trigger
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 w3c/
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?
CurtBellew: The latter
CurtBellew: I always assumed that the very tip of the pointer is the actual determining factor
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
lola: I'm testing now. I am pointing at one element while covering another element, and I can only click on the former
CurtBellew: 1.4.13 content on hover includes a requirement that you have to be able to move your mouse into the popup content
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
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 user's need
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
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
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?
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
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"
Jem: Then it could be advice for low-vision users. I'm trying to think about the action that an author can take
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?
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
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://
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)
Jem: I remembered the section of WCAG that I referenced earlier. I copied a link in IRC
<Jem> https://
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
Matt_King: The question is whether to add a note about where to place the tooltip or not
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
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)
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
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
Jem: And user-agents can change their size
Matt_King: So we're okay with closing this as a "won't fix"?
Jem: Yes
CurtBellew: Yes
<CurtBellew> +1
Issue 3154 - Developing a Keyboard Interface for charts and interactive graphics
Matt_King: We only have seven minutes remaining in this meeting, but I want to give this more than seven minutes. Let's skip to the next item in the agenda
Issue 3153 - Request for design requirements in button pattern
github: w3c/
Matt_King: The way I interpret this is that this person would like us to provide visual design guidance for buttons
Matt_King: This feels to me like it could be outside of the scope of the APG
Jem: It could be WCAG...
Jem: Are they asking us to change the button design?
Matt_King: No, I think they want an additoin to the button pattern. They say that button should have some indication that it is a button. Also that it has a minimum contrast ratio (which is obviously WCAG)
Matt_King: In the introduction to the APG, we have a "purpose" section...
https://
Matt_King: We do not explicitly say that the APG is not about giving guidance on the visual experience. However, we don't do that for any other patterns. It doesn't feel like the job of the APG
Matt_King: Maybe that represents an omission in the definition of our scope
<Jem> "APG is not a UI Design System"
<Jem> https://
siri: All of the criteria they have requested are WCAG requirement
Matt_King: We make sure that everything we do is consistent with WCAG
siri: I don't think we did this for other examples, either
Jem: I think it's enough that the introduction says that "APG is not a UI Design System"
Matt_King: Our job is not to be a WCAG explainer. WCAG explains WCAG
Matt_King: Maybe we cover it in the prerequisite knowledge
Matt_King: I'm going to close this unless anyone objects
[no objections]