search

w3c / aria-practices

WAI-ARIA Authoring Practices Guide (APG)
https://www.w3.org/wai/aria/apg/
Other
1.21k stars 346 forks source link

Multi-Thumb Slider: Top of thumb slider's ring on hover is missing #3174

Open howard-e opened 3 days ago

howard-e commented 3 days ago

There's a visual glitch with the ring on hover element around the thumb slider on the deployed environment. Being that the ring shown around the min and max thumb slider is slightly cut off at the top on hover. Example image below: screenshot showing ring around thumb slider being cut off at top

Opening just the slider-multithumb.html file shows that all of the ring is properly shown. Example image below: screenshot showing ring around thumb slider is accurately represented

Looking through the code, it seems the y attribute being set for minSliderFocusNode and maxSliderFocusNode should be a minimum value of 2. But in the deployed environment, this gets calculated to a value of -4. Opening the slider-multithumb.html file, it gets calculated to 3.

Originally posted by @howard-e in https://github.com/w3c/aria-practices/pull/3172#pullrequestreview-2443554215

a11ydoer commented 2 days ago

@jongund can you kindly to look into this issue and work on it?

css-meeting-bot commented 2 days ago

The ARIA Authoring Practices (APG) Task Force just discussed Issue 3174 - Multi-Thumb Slider missing top of thumb slider's ring on hover.

The full IRC log of that discussion <jugglinmike> Topic: Issue 3174 - Multi-Thumb Slider missing top of thumb slider's ring on hover
<jugglinmike> github: https://github.com/w3c/aria-practices/issues/3174
<jugglinmike> 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
<jugglinmike> howard-e: I think there needs to be a minimum for the "y" value. It goes negative in production
<jugglinmike> howard-e: As for the severity: this is a very small visual glitch. It doesn't impact much.
<jugglinmike> 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
<jugglinmike> howard-e: That's why I think this might make more sense as a follow-up patch
<jugglinmike> 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
<jugglinmike> 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
<jugglinmike> Matt_King: I think I'd like to bring this up during a meeting where jon is present
<lola> Q+
<jugglinmike> Matt_King: I don't want to assign it to jon in his absence
<jugglinmike> 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
<jugglinmike> Jem: How about we mention jon in the GitHub issue?
<jugglinmike> Matt_King: Even better
<jugglinmike> ack lola
<jugglinmike> 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)
<jugglinmike> q?
<lola> https://github.com/w3c/aria-practices/pull/3172#pullrequestreview-2443554215
<jugglinmike> Jem: I can test on Android
<jugglinmike> Matt_King: It should work via clicking on desktop and via tapping on mobile
<jugglinmike> lola: It's generally easier to use this functionality on desktop; tapping precision on mobile leaves something to be desired for this use case
<jugglinmike> Matt_King: This is for the next publication
<jugglinmike> Jem: Got it. I'll assign myself as a reviewer