search

w3c / matf

Guidance from the Mobile Accessibility Task Force (MATF)
https://w3c.github.io/matf/
Other
6 stars 1 forks source link

Success Criterion 2.5.7 - Dragging Movements - Level AA #53

Open JJdeGroot opened 3 months ago

JJdeGroot commented 3 months ago

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

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

jamieherrera commented 3 weeks ago

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

jamieherrera commented 3 weeks ago

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

jamieherrera commented 3 weeks ago

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 commented 2 weeks ago
Notes from 25 September, 2024 Meeting: [Meeting Minutes 25 September](https://www.w3.org/2024/09/25-matf-minutes.html#t02) 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](https://github.com/w3c/matf/issues/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](https://github.com/w3c/matf/issues/63) ACTION: Propose to accept 2.5.7 as written in WCAG2ICT
JJdeGroot commented 2 weeks ago
Notes from meeting on October 2, 2024 [Source](https://www.w3.org/2024/10/02-matf-minutes.html#t02) Is this criteria not very specific to keyboard focus? JJ: Recaps discussion from the Github issue and recent meeting, found at [w3c/matf#52](https://github.com/w3c/matf/issues/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.