2.5.8: Are all slider variants excluded or only sliders that look and are operated like sliders

[JAWS-test]

Please look at:

https://www.w3.org/WAI/ARIA/apg/example-index/slider/slider-rating.html

You can see 5 rating stars, which can be activated individually (in fact, even half stars can be activated, although this is not immediately obvious). Looking at it, I would assume that the stars have to be checked for the correct target size according to 2.5.8.

However, looking at the source code, I see that it is a slider and that this is considered as one control in 2.5.8.

Now the question: Does the exception apply to all visual sliders or to all programmatic sliders or to both variants?

And what is meant by "granular values"? Are there sliders without granular values? Which ones? Or is that supposed to describe that every slider has granular values?

[patrickhlauke]

i'm assuming that is awkwardly meant by a slider with "granular values" is a slider that can be freely moved and doesn't "snap" to specific points. i.e. potentially every single pixel position on the slider is a value, so it would be impossible to mandate that each of those is large enough.

in contrast, the APG example there, regardless of being a slider under the hood, effectively has 10 "areas"/targets (a zone for the half, and one for the full star, on each of the 5 stars). as such, I'd consider that as not being exempt, as it IS quite feasible to make sure the stars are large enough so that their two zones each have a sufficient size.

[JAWS-test]

Thank you, @patrickhlauke
If this opinion is shared by others, I would appreciate a addition in the Understanding to avoid misunderstandings

[bruce-usab]

If this opinion is shared by others, I would appreciate a addition in the Understanding to avoid misunderstandings

I think we can survey and then close this issue. Or update Understanding and then close.

[patrickhlauke]

there is a tentative PR change #2718

[bruce-usab]

Ready for Survey tag might be premature, since it would be nice to knit up all proposed changes for Understanding.

My recent thinking is that since 2.5.1 mentions "path-based gestures" that covers sliders. 2.5.7 Understanding can then be more about classic drag-and-drop style UI.

[GreggVan]

Not sure what you mean by

My recent thinking is that since 2.5.1 mentions "path-based gestures" that covers sliders

So just for clarity A slider would not be a "path based gesture" since it only matters what the end point is. You can jump from one point to another and it works fine. "Path-based" refers to things where the endpoints are not sufficient. The entire path (and/or the speed along the path) is important in determining the outcome. Examples - flight path of an airplane through obstacles or moving obstacles - a signature - water color painting gregg

…

------------------------------ Gregg Vanderheiden ***@***.***

On Nov 7, 2022, at 12:05 PM, Bruce Bailey ***@***.***> wrote: Ready for Survey tag might be premature, since it would be nice to knit up all proposed changes for Understanding. My recent thinking is that since 2.5.1 mentions "path-based gestures" that covers sliders. 2.5.7 Understanding can then be more about classic drag-and-drop style UI. — Reply to this email directly, view it on GitHub <#2713 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXVLX3GQSQ5U45E572LWHFOGZANCNFSM6AAAAAAQ6SE4S4>. You are receiving this because you are subscribed to this thread.

[alastc]

Some confusion on the conversation yesterday (and probably need Wilco to be involved to check is solves the problem raised). So will re-up it later.

[bruce-usab]

I think sliders are pretty much the same as scroll bars. If that is correct, then we do not need to give them any special treatment, let alone try and figure if some are emulating analog movement.

One difference is that some click-and-drag sliders/scrub controls don't do anything with a click/select along the axis of movement — so that is something to look out for with regard to 2.5.7 Dragging Movement. This sort of restricted functionality might not fail other SC (if there is a keyboard equivalent) so it is a good example for Understanding.

The Understanding for 2.5.1 Pointer Gestures will need some tweaking one we have 2.5.7, but I think it does cover sliders/scrub controls well enough (without 2.5.7 (emphasis added):

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

Scrollbars (and everything similar) are using a path-based gestures! The gesture is limited to a horizontal or vertical axial line. (This also means 2.5.1 covers "swipes".) These UI are path-based and similar to the 2.1.1 exception for "underlying function requires input that depends on the path of the user's movement". Of course 2.1.1 was written for movement in two axis, but the principle is the same. A "scrub" UI typically needs finer control / better resolution than a scroll bar, but I think is okay for WCAG to treat them the same.

[JAWS-test]

@bruce-usab You probably wanted to post your comment at another issue, because this is about 2.5.8 = target size - and nothing else

[bruce-usab]

@JAWS-test – I was OT earlier (hence my thrashing on the labels) but my reply above is in the right place.

Yes, 2.5.8 is target size — and I do not think sliders are a special case (because they are a kind of scroll bar).

My comment about sliders being path-based is something I posted to this issue because I was replying to @GreggVan comment.

[GreggVan]

Hmmm. Not sure but it sounds like there is confusion as to what "path based" means in WCAG. Path based means that the result is different if you take a different path to the endpoint. Not path based example — Think drawing where you click at two (or more) points to create a line. Where your pointer went between clicks makes no difference to the result. It is not path based. Path based examples — Now think freehand drawing or painting. This is path based. – An even better example is flying a spaceship through a moving meteor field. Different paths to the goal would result in collisions or no collisions. So sliders are not path based. No matter what path or number of back and forths you take — when you stop with a slider - the value / result is the same. (Unless it is a performance and you are scrubbing for a visual effect like disc jockeys did with records). (And yes sliders are a type of scrollbar - so should be treated the same as scroll bars. Good observation. ) gregg

…

On Nov 27, 2022, at 1:17 PM, Bruce Bailey ***@***.***> wrote: @JAWS-test <https://github.com/JAWS-test> – I was OT earlier (hence my thrashing on the labels) but my reply above is in the right place. Yes, 2.5.8 is target size — and I do not think sliders are a special case (because they are a kind of scroll bar). My comment about sliders being path-based is something I posted to this issue because I was replying to @GreggVan <https://github.com/GreggVan> comment. — Reply to this email directly, view it on GitHub <#2713 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXXGABENPDAPYX6MUQLWKPFXXANCNFSM6AAAAAAQ6SE4S4>. You are receiving this because you were mentioned.

[JAWS-test]

@GreggVan and @bruce-usab: Can you please open a new issue for your discussion on 2.5.1 and 2.5.7 or use an issue where these two SCs are already discussed. This is a different issue that I opened and has nothing to do with your discussion. Thanks!