2.5.7 Dragging Movements - Carousels - Overflowed Containers

[joe-watkins]

Warning: Animated Gifs below

Hello :) Excited about 2.2!!

There is some debate out there about whether or not 2.5.7 Dragging Movements applies to a typical carousel of items that do not have forward/back buttons. Can someone from the WG let me know if either of the following two scenarios fails 2.5.7 Dragging Movements? If not, how do the examples satisfy the SC or not fail it?

1. Carousel of products with custom overflowed container requiring a pointer to drag the bar at the bottom to move the carousel forward and back. There are no other controls to perform this same functionality


2. Carousel of products on a touch device where a touch user must swipe/flick left or right to advance through the carousel. There are no nearby controls to perform this functionality.


[bruce-usab]

My own opinion is that neither example above is a dragging movement because swipe left/right is not follows the pointer. There is only one axis of movement, and the element is limited to its frame.

dragging movement: an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer

@a11ydoer Might this be a candidate (as counter-example) for Understanding?

[joe-watkins]

@bruce-usab Thank you for your speedy reply. I look forward to others' feedback too!

Confusion may also come from the term "sliders" in the Intent. "sliders" is commonly used as a term for "carousels". What are "sliders" in this case?

The intent of this Success Criterion is to ensure functionality that uses a dragging movement (e.g., sliders, drag-and-drop interfaces) has another single pointer mode of operation without the need for the dexterity required to drag elements.

[yatil]

Looks to me like this is indeed covered by above definition of “Dragging movement”. There is “engagement” on the down event, and the carousel follows the mouse pointer.

(And to my knowledge the intention of the SC is that such interactions have visible or at least keyboard-operable alternatives.)

[detlevhfischer]

@bruce-usab I don' t think a constraint to one axis means this won't be a dragging movement. The test to differentiate between 2.5.1 and 2.5.7 would be to engage then drag first up (or down) and then horizontally. If the element follows your pointer's x-coordinate regardless, it is a dragging movement. If it requires a horizontal movement (at least initially), it is a pointer gesture. The funny thing is that on a mobile device, the same thing may be treated as pointer gesture (since initial vertical movement is likely to scroll the page) while using a mouse pointer you might treat it as dragging movement.

@joe-watkins In both cases, in order to meet 2.5.1 or 2.5.7, some alternative for moving the slider that can be activated by single tap or click (e.g. arrow buttons) would need to be present.

@yatil Whether there are keyboard-operable alternatives would fall under 2.1.1 and is not required under 2.5.1 or 2.5.7

[bruce-usab]

I confirmed on the backlog call today (10/7/22) that sliders is not meant to be in that e.g. list towards the top of the Understanding document. Ping to @mbgower because it was his recollection that this had already been corrected in a previous PR.

@yatil and @detlevhfischer — a key phrase in definition is follows the pointer which should not be read creatively. Is the element on the mouse cursor (as it is moved) or not? Just because the mouse cursor can veer off horizonal 45° and the control works (as is typical with a slider), that might not make this SC applicable.

Edit: Just because the user can click-and-drag a control (even a slider control), as most people would describe the operation, that is still not dragging movement (per the linked 2.5.7 definition) because the control (typically) stays placed within the original frame, and does not "follow the pointer" except on a single axis.

[yatil]

Then "follows the pointer is" is a weird phrase because I interpret it literally (the thing clicked is where the pointer is while it follows the pointer) and I have no idea how to interpret it otherwise.

[yatil]

backlog call

Are minutes available? And shouldn’t this be on the main WCAG agenda?

[bruce-usab]

We don't use IRC (so no minutes). It is a scheduled hour for a few people to sync up on a voice call and mostly edit PRs and/or reply to issue threads. Basically overflow from work generated at one of the Tuesday AGWG calls. No decisions being made. I took the opportunity to affirm I was on track about what is meant by dragging movement (and I was) but was thrown by slider still being listed as an example.

@yatil The initial communication on the 2.x Backlog activity was on the list. The work has been going on for a while! It is only recently that I have been able to contribute. A backlog wiki page was created in September 2020.

the thing clicked is where the pointer is while it follows the pointer

The thing being clicked is the first part, so yes that is where the pointer is at that moment. After that, the thing clicked visually trails after (or on) the pointer or maybe replaces the mouse cursor (if the pointer has an on-screen representation). So that is follows the pointer. It is a common enough UI pattern, so aside from listing sliders as an example, I am not clear why there is confusion.

[yatil]

visually trails after (or on) the pointer

That seem to be just different words for “follow the pointer”. In the gif examples above, the slider panel visually trails/follows the pointer. If something else is meant, then that should be properly defined (for example, when you mean “freely follows the pointer in any direction”). Removing that ambiguity is needed.

(Thanks for the background on the backlog meetings.)

[bruce-usab]

Sorry to drop off this thread for bit. Please suggest phrasing for Understanding that would clarify that Carousels and the like are not not covered by 2.5.7.

In context of 2.5.7 follows the pointer is only one aspect of the scoping. One counter example is Eyes follow mouse (CodePen).

A slider might well work when the pointer engages with an element on the down event. It could even follows the pointer in that the end-user can veer off the horizonal — but this is more like the CodePen example, and not the free-hand / two-axis dragging movement which 2.5.7 is addressing. A slider, like the CodePen eyeballs, does not have the element (or a representation of its position) aspect.

That said, a slider might be designed to emulate a physical control, and that is close to the sort of drag-and-drop operations 2.5.7 addresses.

I think that is okay, because requiring single-pointer operation for that sort of UI is reasonable.

Regardless, applying 2.5.7 to carousels and simple toggles (that present as on/off slider) is not going to be productive. I think the SC text is fine as-is, but am happy to continue this discussion.

[yatil]

I do not understand how the animation that reacts to the movement of the mouse example applies to dragging, where you click and drag. That’s a totally different thing.

I am not sure what 2.5.7 is supposed to be addressing if dragging carousels is not what it is supposed to address, then its goal seems to be to address nothing – fine by me, but also pointless.

[bruce-usab]

2.5.7 addresses drag-and-drop. It is also intended to address some other uses of the mouse which require a dragging movement. Maybe some free-hand drawing kind of things? Certainly some games UI, but not something as time sensitive as a flight simulator (because of the qualifier unless dragging is essential).

I have not myself encounter a Carousel which made good use of dragging movement. I do not think the one describe in OP is on point for 2.5.7. I would appreciate URLs for more examples of in scope / out of scope.

I would like for it to be the case that you are more sure what 2.5.7 is supposed to be addressing! Once you have better clarity, I think you will be able to suggest improvements to the prose.

[yatil]

Joe did provide an example for the Carousel that only works with an (IMHO) dragging movement:

1. Carousel of products with custom overflowed container requiring a pointer to drag the bar at the bottom to move the carousel forward and back. There are no other controls to perform this same functionality

[joe-watkins]

While folks here are defining what a "dragging movement" is and whether it applies to the typical carousel swipe gesture for manipulation, may I please also request some clarity around whether or not a "native" overflowed container would be excluded from having to even meet this Success Criterion at all regardless of the debate over the definition of "dragging movement"?

From the SC note, bolding below by me:

This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

For example, an HTML-based container of things that scrolls as a result of CSS overflow-x: scroll. On desktop macOS Chrome and Safari, a scrollbar appears which could receive a single point click/tap to scroll the container, but on touch mobile device browsers like iOS Safari there isn't a scrollbar and a swipe-like gesture moves through the items in the container.

Question: Because of how the browser is handling this natively, does that fit into the exception "does not apply to actions that are required to operate the user agent"?

Desktop Chrome Screenshot of overflowed horizontal container of elements, scrollbar at bottom of container


iOS Safari screenshot


Question: Lastly, would the exception also apply to native applications using such built-in features such as ScrollView (I also think ReactNative's ScrollView transpiles down to this) which natively allows for a horizontal collection of items to be swiped through without the addition of buttons or some other single point mechanism for navigation?

[bruce-usab]

My apologies for being too focused on my own experience with Carousels.

X requiring a pointer to drag... There are no other controls to perform this same functionality.

Yes, that describes a fail against 2.5.7.

Question: Because of how the browser is handling this natively, does that fit into the exception "does not apply to actions that are required to operate the user agent"?

All WCAG SC are oriented towards web author supplied content. Since Carousels are not a native HTML element, for a web browser (the User Agent) there really is no "handling this natively". Please see this WAI Carousel Tutorial.

That exception is saying that web authors do not have to code for things screen reading software does, the web browser does, or the operating system is known to do. For example, with iOS, there are several native multi-pointer gestures which iOS natively provides singer-pointer alternatives. It might be helpful, but not at all necessary, for a web developer to be aware of these. Probably that knowledge is essential to an iOS app developer, because one needs to ensure compatibility with the native platform.

The exception related to the concept of accessibility supported. So yes, the exception is applicable to native applications using such built-in features such as iOS ScrollView. It is not a problem (i.e., not a failure against 2.5.7) for your iOS app to rely upon iOS ScrollView (even though iOS ScrollView nominally requires dragging). I am not at familiar with the minutia for ReactNative, so I can't say in that context.

On desktop macOS Chrome and Safari, a scrollbar appears which could receive a single point click/tap to scroll the container...

Okay, then this is not a failure against 2.5.7. Hopefully Edge has similar functionality, but that is not the responsibility for the author of a web page.

...but on touch mobile device browsers like iOS Safari there isn't a scrollbar and a swipe-like gesture moves through the items in the container.

So long as you are using the iOS native UI elements, and not rolling your own "look/work a-likes" you are are fine on iOS because Apple has taken this use of dragging into consideration and iOS provides an alternative.

[joe-watkins]

Thanks @bruce-usab I enjoy how you explain very complex topics very clearly :) A follow-up verification if possible. Thank you for the clarification regarding native apps and the exception. e.g. ScrollView specifically.

So long as you are using the iOS native UI elements, and not rolling your own "look/work a-likes" you are are fine on iOS because Apple has taken this use of dragging into consideration and iOS provides an alternative.

In this case, it's an HTML web page that has a <div> container with CSS overflow-x: scroll; applied to it being rendered by the Safari web browser on an iPhone. The browser has decided to not show a scrollbar.

Do you consider that <div> HTML container an "iOS native UI element" thus, even though there is not a scrollbar and there are no buttons present to scroll the container, it would not be a failure of 2.5.7 because the author isn't trying to get fancy and create-their-own and are just marking things up in an accessibility supported way?

I guess it would be like how iOS Safari handles <textarea> that has overflow and doesn't show scrollbars or offer buttons to scroll it, doesn't seem right to bust the author on 2.5.7.

[bruce-usab]

Thank you for your CodePen example as it is much easier to talk about concrete examples! It is not all that difficult to combine common HTML and CSS to create inaccessible (i.e., non WCAG conforming) web pages, so concepts like "native" do not help much. That CodePen example clearly passes 2.5.7.

I did not test it using iOS, I presume it works fine. Regardless, it passes 2.5.7 as an author just need some confidence wrt accessibility supported, and not every browser everywhere on all platforms with all possible AT.

[joe-watkins]

Thank you @bruce-usab for the clarity around the exception for native (both web and native app) elements and how accessibility support plays a factor here too.

With regards to the definition of "Dragging Movement", it feels like there is still some debate on that in this thread.

Personally, from the Understanding in 2.5.1: Pointer Gestures, it's pretty clear when it's defined as:

Dragging is a movement where the user picks up an object with a pointer (such as mouse cursor or a finger) and moves it to some other position.

So, if you click a thing and keep the mouse pressed and you literally pick an object up and you move that to another position in the UI, that's a Dragging Movement. e.g. Drag and Drop or Sort. This functionality is not present in the carousel examples in my original post so 2.5.7 is not applicable IMO. Correct?

Additionally, 2.5.1 Pointer Gestures does not apply on touch devices with the carousel example in my original post because the swipe gesture to manipulate the carousel does not require a SINGLE intermediate point in the swipe gesture to manipulate it, thus not qualifying a path-based gesture. Correct?

We still have debate out here in the accessibility professional community on what a "swipe" is and what a "dragging movement" is. So I appreciate your patience as we work through ironing this out. In summary, I find it hard to believe WCAG will require buttons on your typical carousel (which is probably a good UX move), at the time of this post, when 2.2 drops.

[bruce-usab]

SC 2.5.1 Pointer Gestures and 2.5.2 Pointer Cancellation were introduced with WCAG 2.1 — before 2.2 proposed to add something specifically for Dragging. My Understand is that, yes, there is cleanup work to do in Understanding to differentiate between those and 2.5.7. I am not aware of any concerns that the normative SC phrasing to need changing.

Unless one is developing an iOS app, I do not think one needs to differentiate between swipe and dragging. I think it would be difficult to draw a bright line, but I do not think it is needed. 2.5.1/2.5.2 addresses the bulk of use cases, including swiping. 2.5.7 goes beyond to require a way to do classic drag-and-drop via pointer.

[bruce-usab]

Again, your CodePen example meets 2.5.1/2.5.2/2.5.7 and as there does not seem to be a compelling reason to distinguish between swipe and dragging under Windows or OS X, why is there under iOS?

SC 2.5.1 Pointer Gestures:

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.

Is Swipe a "path-based" gesture? I do not think so! Is a scroll bar a path based gesture? Regardless, for 2.5.1, the answer does not matter because the UI can easily be operated with a singer pointer. The analysis for Swipe and Success Criterion 2.5.7 Dragging Movements is about the same.

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

Yes, one can click-and-drag on a scroll bar. The same functionality (in Windows and OS X) is available by single-click in the space between scroll bar and arrows at either end. Applying 2.5.7 to classic scroll bars is a pass. If a different auditor does not think scroll bars count as a dragging movement (personally, I do not, since I would be looking for drag-and-drop) it is okay. It is not a problem to overlook most common UI patterns because, nowadays, they have good accessibility.

I understand you to be saying that iOS hides the scroll bar, and requires a Swipe gesture instead. If this is an accessibility barrier, it is not one created by the page author!

I think the iOS feature I was looking for is called AssistiveTouch which does list multifinger and scroll gestures. Swipe, per se, is not listed, but I assume that scroll covers that.

[joe-watkins]

@bruce-usab Makes perfect sense to me thanks! Does your opinion change with regards to a pass with all 2.5.1/2.5.2/2.5.7 if we take the same CodePen example and hide the scrollbar from everyone (parent container added which has overflow hidden hiding scrollbar of nested div) but add some JavaScript to handle mouse interaction? Now mouse users can click and drag and touch users swipe to scroll through items.

New CodePen example with scrollbar hidden

Thank you for letting this issue stray a little into 2.5.1 as well since they are in the same realm.

[bruce-usab]

Thank you for your New CodePen example! It fails so hard against 2.1 Keyboard Accessibility that I cannot figure how to assess it against 2.5.7 only. With your previous example one can scroll the content without using a mouse at all: tab into the container, and use arrow keys. I expected that behavior with this example, but the scrollbar seems to be not just visually hidden, but nonexistent.

2.5.7 is squarely aimed at content which otherwise meets WCAG 2.1. It is closing a gap. Now is the best opportunity for conversations as to how well the SC is phrased, and is the SC meaningful? I think we should be trying to find UI patterns which are nominally keyboard accessible while being much better via mouse or touch. In this regard, WCAG 2.1 with Guideline 2.5 Input Modalities is a significant improvement over WCAG 2.0. SC 2.5.7 adds some more to that.

For the sake of argument, let's pretend left/right arrows keys worked with with your new example. As compared to the keyboard user, the mouse-click-drag user can scroll faster and variable speeds. But how much does that matter? I do not think that variable speed is essential. Imagining a similar canvas, but one which is larger and scrolls in two axis (e.g., thumbnail views of a photo collection) — I still do not think 2.5.7 is interesting. Yes, one can click-drag the content in the view pane, but it's not the only way to interact with the content, and not the only way to interact with the content using a single pointer.

[joe-watkins]

@bruce-usab Isn't this fun stuff we do :)

It fails so hard against 2.1 Keyboard Accessibility that I cannot figure how to assess it against 2.5.7 only.

I've updated the CodePen example with scrollbar hidden example so that the items in the overflowed container are focusable by the keyboard. Note, they don't do anything when activated in this example - this is more just to get a sense of whether or not this type of carousel would require buttons if a scrollbar wasn't present (and the JS to pull-off the shady pattern is too much work - hee hee). Can you take a peek again and provide your take on 2.5.1/2.5.2/2.5.7 again? tnx!

If you do think that example passes 2.5.1 - how do you reason that with regards to content in the Understanding -> Intent for 2.5.1 which tugs against that call "Examples of path-based gestures include swiping, sliders and carousels dependent on the direction of interaction, and other gestures which trace a prescribed path such as drawing a specific shape." (bolding by me). Some might call that CodePen a "carousel" that requires a "swipe" to scroll that carousel on a touch device, thus failing 2.5.1 because it demands a path-based gesture. Thoughts?

It's at this stage (if they are not sure if it's a 2.5.1 failure) an auditor may go for 2.5.7 in hopes for the gesture required to scroll the container on a touch device being a "dragging movement" thus not satisfying 2.5.7 and recommending buttons or something so a single point activation could be present to satisfy 2.5.7.

Now is the best opportunity for conversations as to how well the SC is phrased, and is the SC meaningful?

I believe the 2.5.7 SC is great! It's the definition of Dragging Movement that I think folks aren't clear on, as well as what WCAG thinks a "swipe" is when referenced (is it a dragging movement - is it a path-based gesture???). Examples in the Understanding (like the awesome BBC example for 1.4.10 Reflow) help soo much!

This is why this conversation ping pongs between 2.5.1 and 2.5.7 ;)

Perhaps borrowing from the Understanding in 2.5.1 Pointer Gestures to help feed the Definition of Dragging Movement could help.

Dragging is a movement where the user picks up an object with a pointer (such as mouse cursor or a finger) and moves it to some other position. This movement from start point to end point does not require the user to follow any particular path or direction.

Then add to that saying this is basically all about drag and drop type interaction also stating this does not include scrolling containers or moving through carousel items or something in a Note?

Then. revisit the Understanding of 2.5.1 and clarify what a "swipe" is (maybe add a full-on Definition?). As mentioned above 2.5.1 Understanding clearly states "swipe" is a path-based gesture. ps. There are multiple open issues here around "swipe" confusion.

For the sake of argument, let's pretend left/right arrows keys worked with with your new example. As compared to the keyboard user, the mouse-click-drag user can scroll faster and variable speeds. But how much does that matter? I do not think that variable speed is essential. Imagining a similar canvas, but one which is larger and scrolls in two axis (e.g., thumbnail views of a photo collection) — I still do not think 2.5.7 is interesting. Yes, one can click-drag the content in the view pane, but it's not the only way to interact with the content, and not the only way to interact with the content using a single pointer.

Agreed here ;)

[joe-watkins]

FWIW - this is the most logical take on "Swipe" which starts to break it down/clarify in a human-understandable way via @patrickhlauke in https://github.com/w3c/wcag/issues/2116#issuecomment-970155107

probably stating the obvious, but: i think part of the problem is that "swipe" as a term is loaded with different connotations. some people see it as a very directional "flick" (which is a path-based gesture), while others also call those draggable sliders or carousel type interactions (where you place a finger down, and then the carousel follows your finger even if you move it slowly/up and down/etc, until you lift the finger) a "swipe" (which are not path-based, since they do allow for the pointer/finger to "stray")

[detlevhfischer]

@bruce-usab wrote:

[the codepen example] ...fails so hard against 2.1 Keyboard Accessibility that I cannot figure how to assess it against 2.5.7 only (...) 2.5.7 is squarely aimed at content which otherwise meets WCAG 2.1. It is closing a gap.

I believe 2.5.1 and 2.5.7 need to be uncoupled from keyboard accessibility issues (and any other SCs for that matter). Whether or not content conforms to 2.5.7 Dragging Movements has nothing whatsoever to do with the question whether the same content is keyboard-accessible. That is a separate concern.

I believe the gap 2.5.7 closes is that WCAG 2.2 now requires some alternative with single pointer activation not just for content that is operated by complex gestures (multi-point, or requiring initial directional movement, as defined in 2.5.1), but also for content that is dragged.

@bruce-usab wrote far above in this issue thread:

a key phrase in definition is "follows the pointer" which should not be read creatively. Is the element on the mouse cursor (as it is moved) or not? Just because the mouse cursor can veer off horizonal 45° and the control works (as is typical with a slider), that might not make this SC applicable.

I disagree, I think 2.5.7 applies to constrained dragging. While the definition of "Dragging Movement" may need more clarity whether "follows the pointer" really requires that the object follows on both axes or just on one as in @joe-watkins slider codepen, there is absolutely nothing from a user needs perspective that would justify exempting constrained dragging. In both cases, the SC requires (or should require) an alternative single pointer operation to cater for those pointer users with motor impairments who find coordinated movements across the screen difficult. And that means that a swipe that does not require initial directionality of movement ("going through one intermediate point" was just a means to define such initial directionality) should in my view be considered a dragging movement. In that sense, I see 2.5.7 as "closing a gap".

[yatil]

I think I agree with @detlevhfischer here. This SC needs some work, and I think my previous comment in #2669 that the definition of what a dragging movement is and that it needs to be clear applies here. Apparently it is super hard to determine what meets the SC and what does not. I agree with Detlev on the goal of this SC to provide a non-pointer-coordination alternative to dragging-type operations.

[bruce-usab]

@joe-watkins if developers consider "swipe" to be a kind of click-and-drag -- I think that is fine. I am not going to try and draw a line. The Understanding for 2.5.1 was written before we had 2.5.7 and it does need to be updated. IMHO, SC 2.5.1 does not clearly preclude all uses of drag-and-drop, but 2.5.7 closes that gap.

I've updated the CodePen example with scrollbar hidden ...

Thank you! I think that passes 2.1.1, 2.5.1, 2.5.3, and fails 2.5.7. The example does not use multipoint or a path-based gesture (as I think of that term) so it meets 2.5.1. Mouse use requires dragging, so that fails 2.5.7.

the goal of this SC to provide a non-pointer-coordination alternative to dragging-type operations.

It is not the goal of SC 2.5.7 to ensure provision of a non-pointer alternative. The SC is limiting restrictive use of a pointer. But I am not sure what you mean by "non-pointer-coordination"!

I believe 2.5.1 and 2.5.7 need to be uncoupled from keyboard accessibility issues (and any other SCs for that matter).

I agree. But unless content is passing 2.1 Keyboard Accessible) it does not make any sense to me to get agitated about said content failing 2.5 Input Modalities. I understand that better utility for mouse operation is not necessarily dependent upon basic keyboard operation.

I disagree, I think 2.5.7 applies to constrained dragging.

The SC works fine from that perspective. Can the functionality be achieved by a single pointer without dragging? If so, that is a pass against 2.5.7. If not, that is a fail against 2.5.7.

[yatil]

Exactly that.

[joe-watkins]

Thank you all for continued jamming on this :) I truly appreciate it. Along the same lines how about this native iOS app example? Does this fail either 2.5.1 or 2.5.7. As an auditor, I really have no way to know if the author has used iOS ScrollView as I have no access to the codebase (so not sure if it falls under the shared exception for both 2.5.1 and 2.5.7).

https://user-images.githubusercontent.com/3695795/197238775-ce5931d9-0dee-48cc-8f64-57f7e4f9c282.mov

Video description: Apple maps application open to Guides section. "Guides We Love" heading precedes a carousel of cards. The touch user slowly swipes up diagonally to advance the carousel twice then swipes once right to swing the carousel back to the beginning. There isn't a "view all" or "forward" or "back" button near the carousel. Note: Swipe is emulated via Assistive Touch.

I understand we can't turn this thread into a never-ending what about this scenario, but having the AG WG's perspective on these quite common patterns will be helpful for us doing audits to standardize interpretation. :)

[bruce-usab]

I presume (but am not certain) that some of the motivation for 2.5.8 is that 2.5.1 does not unambiguously address swiping. I would not characterize swipes as a path-based gesture. Prior to this conversation, I would not have thought to characterize swipes as a dragging movement. Regardless, because of how it is conditionally phrased, Swipe-only UI is a failure against 2.57, because 2.5.7 requires that operation can be achieved by a single pointer without dragging.

As written, 2.5.7 is of the form: If X then Y. If ~X then Y. Is "swipe" an example of a dragging movement?

If yes, then 2.5.7 requires that operation must be achievable by a single pointer without dragging, so an alternative is required to be available.

If no, then there is not functionality that uses a dragging movement, and so it must already be the case that operation can be achieved by a single pointer without dragging.

A viewport with archetypical scrollbar is a fine example, and passes 2.5.7. @joe-watkins says his example renders on Safari on OS X without a scrollbar and requires swipe. Still, the code passed against 2.5.7 (since SC apply to the content, not the platform) and if there is a real-world barrier, it is covered by the note.

@joe-watkins wrt your native iOS app question, to audit I think one needs to become pretty expert with the built-in a11y features, if code inspection is not feasible. According to this Apple Support article on Touch Accomodations, Swipe is single-pointer enabled through Hold Duration + Tap Assistance. Please try it out, and let us know if that seems to work!

[joe-watkins]

@bruce-usab tnx tnx tnx!

wrt your native iOS app question, to audit I think one needs to become pretty expert with the built-in a11y features, if code inspection is not feasible. According to this Apple Support article on Touch Accomodations, Swipe is single-pointer enabled through Hold Duration + Tap Assistance. Please try it out, and let us know if that seems to work!

Yes, like keyboard testing on iOS there are some awesome hidden nuggets with regards to custom actions that you'd miss if you really didn't dig in too.

With that being said, knowing that iOS is a bit of a walled garden - is it safe to say because Apple has thought the swipe interaction through and provided OS-level alternatives through things like Assistive Touch and Touch Accommodations - that the iOS example would not fail 2.5.1 or 2.5.7 then? (I think you eluded to this earlier but just clarifying). tnx again!

[bruce-usab]

I am fascinated that bog-standard HTML scroll bars are hidden under iOS. Thank you for pointing that out!

is it safe to say because Apple has thought the swipe interaction through and provided OS-level alternative...

For web pages, yes. But for iOS apps, I do not think so!

I am not an iOS developer, and am just regurgitating what I have picked from various presentations over the years. The problem, as I understand it, is that developers sometimes use "work-alike / look-alike" implementations, instead of the accessible and native widgets provided by the platform owner. Absent insight to the toolchain, all one can do is test with platform a11y features. That is not very satisfactory, and is different than Windows where there are some code inspection utilities available.

[yatil]

Scrollbars are hidden in iOS and on macOS when using a touchpad. They can be enabled if one wants that. (I vastly prefer them hidden.)

There are no scroll bars in HTML.

[bruce-usab]

@yatil please help me phrase that so I embarrass myself less. Default CSS presentation of an overflow container?

And is it the case that the default scroll bar rendering and functionality is determined by the OS and not the browser?

I took the liberty to put animations in OP under an accordion.

[yatil]

Yeah, it is weird. It's basically the OS's treatment of scrollable containers. Some browsers do it more themself, others leave it closer to the OS. Scroll bars have a bizarre place somewhere between web and OS UI.

[joe-watkins]

Hi folks! This thread is a meaty one. Super clear on native elements and how they'd fit into the "unless" part of the SC - thanks for clearing that up everyone :)

BUT, If I've understood the thread to date, it still appears that there is a difference of opinion from @bruce-usab and @detlevhfischer, who are both participants of the AG WG, on whether or not the examples from the original post fail 2.5.7 Dragging Movements. In fact, @detlevhfischer stated that they actually fail both 2.5.7 Dragging Movement and 2.5.1 Pointer Gestures.

bruce-usab

My own opinion is that neither example above is a dragging movement because swipe left/right is not follows the pointer. There is only one axis of movement, and the element is limited to its frame.

detlevhfischer

@joe-watkins In both cases, in order to meet 2.5.1 or 2.5.7, some alternative for moving the slider that can be activated by single tap or click (e.g. arrow buttons) would need to be present.

Essentially, it boils down to whether or not the 'swipe' gesture it takes to manipulate the carousel fits the definition of a Dragging Movement.

Is there a mechanism in place to get a formal stance on this from the AGWG on this as I respect both of your opinions highly, but unfortunately I'm confused due to how much they differ.

[alastc]

It would be useful to agree a response & way forward after a long thread.

Scrollable carousels

On the original topic, for me the key bit is (from the understanding):

this does not apply to actions that are required to operate the user agent or assistive technology

We don't consider scrolling down a page to be an issue (or in scope). If the web content is using the same mechanism, why would that be an issue?

As Yatil noted:

Scroll bars have a bizarre place somewhere between web and OS UI.

Given that we assume people can scroll a page, either by click/touch & move, or with AT, or other (e.g. scroll wheel, which works horizontally if you press shift), I'm inclined to say that CSS-overflow based scrolling should not be in scope.

So for the original question, I'd suggest we answer: CSS-overflow based scrolling is not in scope of dragging movement, but separately you'd need to check keyboard accessibility (i.e. either tabbing through brings the items into view, or you can tab to the container and scroll).

Dragging definition

I'm not sure I followed all the conversation, but it looked like there was some different interpretations of what following the pointer meant?

For me that did include it being 2 dimensions, i.e. a typical drag and drop scenario. If it doesn't follow the pointer up & down (as well as left-right in this case), that wouldn't meet the definition.

I think that's a reasonable reading of the definition, but we should:

• Remove the 'sliders' example from the top of the understanding doc.
• include info on the scrolling aspect.

PS. Please don't "at" yatil, he has said he wishes to stop engaging here.

[bruce-usab]

Ping to @joe-watkins to ask if you are satisfied with this conversation? Are you comfortable closing this particular issue? If so, please do close this issue yourself.

@alastc — I agree with all your conclusions / observations. That includes that Understanding should note that CSS-overflow based scrolling is not be in scope for this SC.

Also, I would note that we have since made a modest edit to the definition for dragging movements.

current:

an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer until an up event

previous:

an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer

[detlevhfischer]

I still do not see 2.5.7 just addressing free-form drag-n-drop, and disagree with exempting things like carousel sliders implemented via CSS overflow:scroll or overflow:auto. The user need 2.5.7 addresses is that of people with motor impairments who cannot engage an element on mouse down and then move it along to another position - regardless of whether this is a free-form, two-dimensional movement, or one constrained to just one axis where the element's location basically follows only one dimension of the pointer. So from that user needs perspective, I think carousel sliders should be in scope.

I see the case for a likely exception for content in a container with CSS overflow set to scroll or auto if the scrollbar is visible and takes single pointer input, as it does on desktop browsers / mouse operation. That would limit the exception to an accessibility baseline scoped to desktop scenarios. On mobile user agents, the scroll bars (currently) do not respond to single taps to move content into view: they may even be hidden until a dragging movement occurs (iOS).

@alastc wrote:

We don't consider scrolling down a page to be an issue (or in scope). If the web content is using the same mechanism, why would that be an issue?

I think the difference is that the affordance for web page scrolling will be much clearer due to the ubiquity of pages longer than the viewport height that must be scrolled in some way to be used. The lack of visible page scroll bars in some environments also seems more clearly a user agent issue than in the case of CSS-styled content on a page (and can, in some environments like MacOS, be remedied in system settings).

[alastc]

@mbgower is working on a PR for #1917, so hopefully can tackle some aspects of this issue.

[joe-watkins]

@bruce-usab

Ping to @joe-watkins to ask if you are satisfied with this conversation? Are you comfortable closing this particular issue? If so, please do close this issue yourself.

I think we are for sure closer and I appreciate all of your time - but it still feels like there are some differences of opinions within the WG. I'm sure that's common here and there - I'd just love to see a formal take on it so I know which stance to take to inform the testing of this SC. Reason is, every human that's commented in this thread I'd take their perspective to the bank - I'm not certain which one I should run with :)

[alastc]

Hi @detlevhfischer,

disagree with exempting things like carousel sliders implemented via CSS overflow:scroll or overflow:auto.

It depends on how we consider user-agents as part of this. The author is not creating a drag and drop script for the content, they are taking advantage of how the user-agent applies scrolling.

I think the difference is that the affordance for web page scrolling will be much clearer due to the ubiquity of pages longer than the viewport height that must be scrolled in some way to be used.

Pedantically, if the page doesn't have scroll bars I'm not sure it is an affordance (visible indicator of functionality that aligns with user-expectations), but it is certainly a learned behaviour.

Pushing it to a logical extreme: What if the whole page only scrolled horizontally without scroll bars? Do you think that should fail dragging?

I can see there is a user need, but:

• I'm not clear that it is different from general scrolling, which has to be a user/user-agent responsibility.
• It seems likely to lead to over-complicated carousel (and other) components, triggering other issues.

For example, a simple carousel based on overflow does a lot better at keeping the focused item in view than most scripted carousels we audit.

Also (for the SC), when you put your finger down and move it, I don't think the element (or a representation of its position) follows the pointer. It isn't 2D, it has no up/down movement.

[detlevhfischer]

@alastc All fair dos. I think I rest my case.

Would that mean exempting sliders using CSS overflow, but not the scripted ones?

[patrickhlauke]

Would that mean exempting sliders using CSS overflow, but not the scripted ones?

it conceptually probably makes sense, as CSS overflow ones are controlled by the user agent (so onus is on the UA, like with regular scrolling), while scripted ones are the responsibility of content authors

[detlevhfischer]

Reopened this thread. Whilst I now agree on what seems its conclusion, namely that 2.5.1 and 2.5.7 do not apply to content using overflow-scroll and no scripted behavior because then, the behaviour is defined by the OS/US and not by the author, it might be worthwhile adding the following qualification:

"unless the scrollbars that most user agents show in these situatons are hidden by the author".

Thoughts?