– DRAFT –
MATF 2 April 2025

<JJ> Editorial changes for WCAG2Mobile: https://github.com/w3c/matf/commit/fd14078052bf23707a0585b75e8b1ece8819a380

<JJ> Estimated publication date: ± 17 April

2.5.7 Dragging Movements

<quintinb> @JJ summarises 2.5.7

<JJ> https://w3c.github.io/matf/#success-criterion-2-5-7-dragging-movements

<quintinb> Detlev is there content in apps for sliding - not easy to deteremine if that is dragging. For web there are exceptions where scroll is managed by user agent, e.g. css overflow. Is there anything that applies to mobile like this?

<pauljadam> I fail the slider carousels under Pointer Gestures because you don't have to drag, it's more of a swipe gesture.

<quintinb> I want to ask the difference between a drag and a swipe

<quintinb> Joe_Humbert for react native - maybe we can use WCAG2ICT peice. It seems to say the different peice is responsible for their own thing.

<pauljadam> We need to build examples of passing and failing these SC in native apps then it helps define how you test and fail each criterion.

<quintinb> Joe_Humbert on mobile swipe gestures are used in AT and non-AT software

<pauljadam> drag is when you press and hold then drag over to a specific location

<quintinb> Ah

<quintinb> Thank you

<JJ> https://tetralogical.com/blog/2023/03/17/foundations-pointer-gestures/

<quintinb> Detlev pointer gestures SC had long discussions over dragging and swipe - you need an intial direction and that had the problem that different agents had different implementations. For web you can't go vertical then horizontal for example. Some people were reluctant to have these alternatives. Now we have a similar requirement for pointer and

<quintinb> dragging. In both cases you need alternatives, the difficulty is still that you have swiping in mobile. Our advice would be that there should be arrow buttons. This may be pretty harsh and hard to sell, but it would need to be strict advice. We need to have open discussion

<pauljadam> I have a good and bad Carousels example here where the bad example only has swipes and the good example also has single tap pagination buttons. https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/iOSswiftUIa11yTechniques/CarouselView.swift

<quintinb> @quintin Worried about making too much space for x-platform. These are open source tools that need to support what the OS supports. I can just create an OS module and claim that I can make inaccessible apps because I gorgot how to log into my repo and change the repo

ACTION: Need to clarify what a layer is in a mobile application / mobile platform, e.g. would React Native app be a different layer compared to native Android/iOS app or operate in the same layer?

<pauljadam> basically for any dragging or swiping, the app developers will need to add some single tap buttons that perform the same functions

<quintinb> Does WCAG make any space for layered frameworks? Why do we do it on mobile?

<quintinb> julianmka I should have made a note for myself. It's slipped my mind - might add to Github

<JJ> You can type "q+ to XXXXX" to get a reminder

<quintinb> I forgot the "to" part

<JJ> https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures#intent

<pauljadam> iOS native slider controls only work with drag gestures and not single taps, so we can't give Apple a pass there. In my good Sliders example I've added single tap alternative buttons that will increment and decrement the sliders for users who can't perform a drag gesture,

<pauljadam> https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/iOSswiftUIa11yTechniques/SlidersView.swift

<JJ> "Dragging is therefore not path-based."

<JJ> (2.5.1) "This Success Criterion does not apply to gestures that involve dragging in any direction because only the start and end points matter in a dragging operation. "

<quintinb> Tanya I just want to comment on DetLev's comment. If we look at the understanding text on 2.5.1 - there is a distinction made between path based(PB) and dragging. Under PB there are sliders and carosels. We would reject under 2.5.1. For dragging I'm looking for more examples in mobile, the only one I can think of is reordering elements in a list.

<quintinb> Would like more.

<JJ> https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html#intent

<quintinb> pauljadam Examples of dragging: iOS native slider controls, they have to be held down and dragged. App developers have to add the single point gestures. Apple recommends adding a stepper control or even a text input

<pauljadam> My view is horizontal scrolling is more difficult than natural vertical scrolling

<quintinb> Detlev I think this case of the sldier that has content in it and just follows the user scrolling panning and scrolling the argument and working discussions is that it's basically the same thing. Scrolling up and down and back and forth are the same. I wonder if that case can be made for mobile. From the evaluator perspective it may be harder to

<quintinb> determine responsibility. Missing an answer from the group whether this is an exception. Still an open question to me

<pauljadam> I have a good and bad Horizontal Scroll Views example here that adds single tap arrow buttons to scroll horizontal in the good example and in the bad example it only works with gestures https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/iOSswiftUIa11yTechniques/HorizontalScrollView.swift

<quintinb> Detlev I can make such an issue example

ACTION: Create issue for WCAG / AGWG to clarify pointer/dragging actions with mobile application pattern examples

<quintinb> JJ I wonder how the larger group feels about these examples, people with different types of dextirity issue types will struggle in different ways

<Detlev> JJ I think for those cases the requirement is clear and basically the same for 2.5.1. and 2.5.7

3.1.1 Language of Page

<pauljadam> Please don't call it "Language of View" ;)

<pauljadam> or "Language of UI Context" :)

<quintinb> ViewGroup?

<pauljadam> The Language of Page SC shows why it's a good idea to just call things "Pages" in native apps to fit with WCAG :)

<pauljadam> This is about making sure the text in a different language is spoken with the correct speech synthesizer.

<pauljadam> https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/Documentation/Language.md

<quintinb> JJ could we fail apps because they don't have the language contained within their resources? Or do we accept defaults. Makes it hard to test

<quintinb> Joe_Humbert on my understanding apps support languages as a whole. It's not as fine grained as each view / screen / page - it's application and components. I could be wrong

<quintinb> +1 Joe_Humbert

<pauljadam> Yes it's easy enough to apply Lang of Page and Lang of Parts to native apps.

<quintinb> +1 pauljadam

<pauljadam> no

<pauljadam> they should

<quintinb> +1.2 million pauljadam

<pauljadam> Once it's possible then you must do it

<pauljadam> Google would need to fix their bug if they have an issue with Lang

ACTION: Test setting the locale for whole app using Android, iOS, Flutter, React Native, etc. to confirm if it's possible or not

<quintinb> GleidsonRamos regarding flutter - we have been testing in flutter - I do believe that it's possible in Flutter and language of parts. Maybe we should do PoC's - I have been successful in Flutter. Similar to setting the activity human language, Flutter runs in a single activity

<pauljadam> From Android View A11y Techniques https://github.com/cvs-health/android-view-accessibility-techniques/blob/main/doc/componenttypes/TextLanguageIdentification.md

ACTION: In our guidance, clarify: “each web page” vs “software” (app level vs page level)

<quintinb> Jamie I wonder if we would want to add a note to acknowledge that for mobile this may need to be at the app level. We need to ack that it's different from WCAG in it's parts level. Having some acks as a note or go boldly beyond to changing the note, for the sole purpose of being scandolous.

<pauljadam> We're still looking at the Page, every page still needs to speak properly to the screen reader.

<quintinb> Sorry Jamie I did take some creative licence there

<pauljadam> Maybe you set that globally but it's still tested like WCAG.

<quintinb> +1 pauljadam

<pauljadam> Language of Screen 🤦🏻‍♂️

<Jamie> lol quintinb

<quintinb> Apps should be accessible. Call me nuts if you like

<quintinb> Jamie should we be testing this at the app level. Does it have to be per screen? Should this respect the OS?

ACTION: Might need exception like 1.1.1 for mobile platforms that don't support setting language at app/screen level

<pauljadam> Some apps could be like half English and half Spanish so each half of the app needs its pages spoken properly.

<julianmka> But how does one draw conclusions at the app level if not by testing at the page level?

<pauljadam> It's about the way the words are pronounced to the screen reader on the page and the parts of the page.

<quintinb> It should fail if there is no mechanism to inform the user that the text is not translated

<quintinb> ^ JJ

<pauljadam> You must test each Page just like you do with web WCAG.

<Jamie> +1 quintinb

<Jamie> -1 pauljadam

<pauljadam> This is why "Page" is soooo perfect!!!

<quintinb> Are app creators responsible for ensuring the language is communicated to AT?

<pauljadam> yes

<pauljadam> just like web developers

ACTION: Check with WCAG2ICT how to deal with mixed language software in 3.1.1, because each webpage has been replaced with a singular piece of software in terms of default language

<Jamie> communicated or pronounced?

<quintinb> Then it doesn't matter of the (lack of) mechanism provided

<JJ> > Are app creators responsible for ensuring the language is communicated to AT? -> No, just that it is programatically determinable so AT *could* use it

<JJ> (imo)

<quintinb> RobW I think the fact that you set the language per app is a web concern, if the purpose is app conformance then we need to test it per "page" or screen is the correct way

<pauljadam> that's why they should have called it "Page" instead of "Software"

<quintinb> I have to drop

<JJ> Next week: continue language discussion with 3.1.2, and 3.2.2, plus new SC drafts to discuss