Success Criterion 2.5.7 - Dragging Movements - Level AA

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#dragging-movements

Share your thoughts for applying to mobile apps as a comment below.

[jamieherrera]

See also #65 definition of dragging movement for our discussion including possible different definitions for mobile.

[jamieherrera]

See also issue #63 for a possible redefinition of user agent

[jamieherrera]

Based on previous task force conversation, this SC can be applied to native mobile apps and mobile web with minimal or no deviation from WCAG2ICT.

Proposal
In MATF's first draft of guidance, this SC's section will read as:

2.5.7 Dragging Movements
(Level AA)

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.

Note
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).

[jha11y]

Notes from 25 September, 2024 Meeting:

Meeting Minutes 25 September

quintinb: are we allowing for non-pointer movements (keyboard shortcuts / actions)?

Joe_Humbert: this does encompass that (single pointer)

Joe_Humbert: I don't think this should be the developers issue, this should already be put in place by the OS

I think any custom gestures defined by the developer is a business risk not having alternatives (because gestures aren't discoverable)

Jamie: reminder to the group that there is an open question on dragging movements - it is linked. So there is a reference

Joe_Humbert: dragging movements definition discussion w3c/matf#65

Jamie: I feel like that we could just keep it the same, but remove web

quintinb: +1 Jamie

Illai: +1 Jamie

Karla +1 Jamie

Illai +1 Jamie

Joe_Humbert: +1 Jamie

Joe_Humbert: we may have to redefine "user agent"

Joe_Humbert: redefine "user agent" w3c/matf#63

ACTION: Propose to accept 2.5.7 as written in WCAG2ICT

[JJdeGroot]

Notes from meeting on October 2, 2024

Source

Is this criteria not very specific to keyboard focus?

JJ: Recaps discussion from the Github issue and recent meeting, found at w3c/matf#52

Joe_Humbert: Reason I said this might need more discussion is because I wondered if we needed to replace the word "keyboard" because there are other ATs where this SC is important. Do we want to replace "keyboard" or keep it focused on keyboard only?

JJ: It wouldn't be too hard to conform to this SC if it applied to other ATs

I agree we should look at other AT with keyboard. Probably should look at it in mind with SC 2.1.1, SC 2.1.2 and SC 2.4.3

Jamie: If we do decide that it's about keyboard focus only, I think it would be helpful to add a note explaining that.

julianmka: I'm wary of only considering hardware keyboards for this SC. The intent as written in Understanding acknowledges switch and speech recognition.

Detlev: I think the reason for focusing on keyboard is because this SC was intended to address fixed-position content on webpages like cookie banners. While that can occur in apps and web view content, it might not be the exact same. If elements are not visible on the screen, do mobile switch and speech input allow focus on them?

Detlev: When you bring up a menu or dialog, it's a user-initiated change, but that would be covered under focus order.

JJ: So how would it work in an app where a pop-up comes up on launch with update information? Would be interesting to look at some cases where apps might fail this SC.

Joe_Humbert: Scrolling is possible with switch and voice access on iOS and Android.

JJ: Also possible to scroll with hardware keyboard.

close the queue

julianmka: Would a native element in focus is partially cut off (like with a very tight focus indicator), would that be a fail?

JJ: Probably not since the control would still be at least partially focusable. That would be under a different SC.