12:53:28 <RRSAgent> RRSAgent has joined #matf
12:53:33 <RRSAgent> logging to https://www.w3.org/2025/04/02-matf-irc
12:53:33 <Zakim> inviting RRSAgent
12:53:33 <Zakim> RRSAgent, make logs Public
12:53:34 <Zakim> please title this meeting ("meeting: ..."), JJ
12:53:35 <JJ> Zakim, this is MATF 2 April 2025
12:53:35 <Zakim> got it, JJ
12:53:41 <JJ> Meeting: MATF 2 April 2025
12:53:59 <JJ> chair+
12:54:04 <JJ> agenda+ 2.5.7 Dragging Movements
12:54:09 <JJ> agenda+ 3.1.1 Language of Page
12:54:14 <JJ> agenda+ 3.1.2 Language of Parts
12:54:19 <JJ> agenda+ 3.2.2 On Input
12:56:01 <Joe_Humbert> Joe_Humbert has joined #matf
13:00:36 <Megan_Pletzer> Megan_Pletzer has joined #matf
13:00:42 <Megan_Pletzer> present+
13:00:49 <pauljadam> pauljadam has joined #matf
13:01:09 <quintinb> quintinb has joined #MATF
13:01:13 <quintinb> present+
13:01:45 <Joe_Humbert> present+
13:01:50 <Tanya> Tanya has joined #matf
13:02:00 <julianmka> julianmka has joined #MATF
13:02:31 <quintinb> scribe: @quintinb
13:02:33 <GleidsonRamos> GleidsonRamos has joined #matf
13:02:33 <Tanya> present+
13:02:36 <GleidsonRamos> present+
13:02:55 <Tim> Tim has joined #matf
13:03:19 <Tim> present+
13:03:19 <julianmka> present+
13:05:39 <JJ> Editorial changes for WCAG2Mobile: https://github.com/w3c/matf/commit/fd14078052bf23707a0585b75e8b1ece8819a380
13:06:04 <JJ> Estimated publication date: ± 17 April
13:06:08 <JJ> move to next agendum
13:06:08 <Zakim> agendum 1 -- 2.5.7 Dragging Movements -- taken up [from JJ]
13:07:28 <pauljadam> present+
13:08:09 <Detlev> Detlev has joined #matf
13:08:16 <Detlev> present+
13:09:42 <quintinb> @JJ summarises 2.5.7
13:13:45 <JJ> https://w3c.github.io/matf/#success-criterion-2-5-7-dragging-movements
13:14:04 <Rachael1> Rachael1 has joined #matf
13:14:06 <Detlev> q+
13:14:10 <RobW> RobW has joined #matf
13:14:52 <JJ> ack Detlev
13:16:19 <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?
13:16:53 <RobW> present+
13:16:57 <pauljadam> I fail the slider carousels under Pointer Gestures because you don't have to drag, it's more of a swipe gesture.
13:17:25 <Joe_Humbert> q+
13:17:57 <quintinb> I want to ask the difference between a drag and a swipe
13:17:59 <JJ> ack Joe_Humbert
13:18:47 <Detlev> q+
13:18:48 <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.
13:18:54 <quintinb> q+
13:19:35 <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.
13:20:04 <quintinb> Joe_Humbert on mobile swipe gestures are used in AT and non-AT software
13:20:05 <Carol> Carol has joined #MATF
13:20:06 <julianmka> q+
13:20:22 <Carol> present+
13:20:32 <pauljadam> drag is when you press and hold then drag over to a specific location
13:20:51 <quintinb> Ah
13:20:54 <quintinb> Thank you
13:21:02 <JJ> ack Detlev
13:21:38 <JJ> https://tetralogical.com/blog/2023/03/17/foundations-pointer-gestures/
13:23:47 <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
13:23:47 <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
13:24:02 <JJ> q?
13:25:12 <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
13:25:37 <JJ> q?
13:25:40 <JJ> ack quintinb
13:25:41 <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
13:25:49 <Jamie> Jamie has joined #matf
13:26:01 <Jamie> present+
13:27:12 <JJ> 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?
13:27:45 <pauljadam> basically for any dragging or swiping, the app developers will need to add some single tap buttons that perform the same functions
13:27:57 <quintinb> Does WCAG make any space for layered frameworks? Why do we do it on mobile?
13:28:35 <JJ> q?
13:28:37 <JJ> ack julianmka
13:29:06 <quintinb> julianmka I should have made a note for myself. It's slipped my mind - might add to Github
13:29:07 <Tanya> q+
13:29:08 <JJ> You can type "q+ to XXXXX" to get a reminder
13:29:33 <JJ> ack Tanya
13:29:34 <quintinb> I forgot the "to" part
13:30:15 <JJ> https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures#intent
13:30:19 <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,
13:30:19 <pauljadam> https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/iOSswiftUIa11yTechniques/SlidersView.swift
13:30:59 <JJ> "Dragging is therefore not path-based."
13:31:15 <pauljadam> q+
13:31:18 <GleidsonRamos> q+
13:31:21 <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. "
13:31:26 <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.
13:31:26 <quintinb> Would like more.
13:31:37 <Detlev> q+
13:31:39 <GleidsonRamos> q-
13:32:01 <JJ> ack pauljadam
13:32:32 <JJ> https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html#intent
13:33:02 <Detlev> q-
13:33:07 <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
13:33:19 <JJ> q?
13:33:59 <Detlev> q+
13:34:37 <JJ> ack Detlev
13:35:44 <pauljadam> My view is horizontal scrolling is more difficult than natural vertical scrolling
13:37:01 <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
13:37:01 <quintinb> determine responsibility. Missing an answer from the group whether this is an exception. Still an open question to me
13:37:14 <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
13:37:33 <quintinb> Detlev I can make such an issue example
13:38:53 <JJ> ACTION: Create issue for WCAG / AGWG to clarify pointer/dragging actions with mobile application pattern examples
13:38:57 <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
13:39:07 <Detlev> JJ I think for those cases the requirement is clear and basically the same for 2.5.1. and 2.5.7
13:39:21 <JJ> move to next agendum
13:39:21 <Zakim> agendum 2 -- 3.1.1 Language of Page -- taken up [from JJ]
13:39:44 <pauljadam> Please don't call it "Language of View" ;)
13:39:57 <pauljadam> or "Language of UI Context" :)
13:39:57 <quintinb> ViewGroup?
13:41:36 <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 :)
13:42:16 <Joe_Humbert> q+
13:44:47 <pauljadam> This is about making sure the text in a different language is spoken with the correct speech synthesizer.
13:44:55 <pauljadam> https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/Documentation/Language.md
13:44:59 <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
13:46:49 <JJ> q?
13:46:51 <GleidsonRamos> q+
13:46:53 <JJ> ack Joe_Humbert
13:47:31 <Jamie> q+
13:47:43 <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
13:47:51 <quintinb> +1 Joe_Humbert
13:47:51 <pauljadam> Yes it's easy enough to apply Lang of Page and Lang of Parts to native apps.
13:48:06 <quintinb> +1 pauljadam
13:48:45 <pauljadam> no
13:48:50 <pauljadam> they should
13:49:05 <quintinb> +1.2 million pauljadam
13:49:07 <pauljadam> Once it's possible then you must do it
13:49:38 <JJ> q?
13:49:41 <JJ> ack GleidsonRamos
13:49:43 <pauljadam> Google would need to fix their bug if they have an issue with Lang
13:50:38 <JJ> ACTION: Test setting the locale for whole app using Android, iOS, Flutter, React Native, etc. to confirm if it's possible or not
13:50:47 <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 locale, Flutter runs in a single activity
13:50:49 <pauljadam> From Android View A11y Techniques https://github.com/cvs-health/android-view-accessibility-techniques/blob/main/doc/componenttypes/TextLanguageIdentification.md
13:50:53 <JJ> s/locale/human language
13:51:18 <JJ> q?
13:51:21 <JJ> ack Jamie
13:52:15 <JJ> ACTION: In our guidance, clarify: “each web page” vs “software” (app level vs page level)
13:52:40 <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.
13:52:54 <pauljadam> We're still looking at the Page, every page still needs to speak properly to the screen reader.
13:53:06 <quintinb> Sorry Jamie I did take some creative licence there
13:53:13 <pauljadam> Maybe you set that globally but it's still tested like WCAG.
13:53:39 <quintinb> +1 pauljadam
13:53:50 <pauljadam> Language of Screen 🤦🏻‍♂️
13:54:00 <Jamie> lol quintinb
13:54:07 <JJ> q?
13:54:07 <quintinb> Apps should be accessible. Call me nuts if you like
13:55:00 <quintinb> Jamie should we be testing this at the app level. Does it have to be per screen? Should this respect the OS?
13:55:04 <JJ> ACTION: Might need exception like 1.1.1 for mobile platforms that don't support setting language at app/screen level
13:55:07 <pauljadam> Some apps could be like half English and half Spanish so each half of the app needs its pages spoken properly.
13:55:56 <julianmka> But how does one draw conclusions at the app level if not by testing at the page level?
13:56:42 <pauljadam> It's about the way the words are pronounced to the screen reader on the page and the parts of the page.
13:56:55 <quintinb> It should fail if there is no mechanism to inform the user that the text is not translated
13:57:04 <quintinb> ^ JJ
13:57:05 <pauljadam> You must test each Page just like you do with web WCAG.
13:57:09 <Jamie> +1 quintinb
13:57:28 <Jamie> -1 pauljadam
13:57:43 <pauljadam> This is why "Page" is soooo perfect!!!
13:58:11 <quintinb> Are app creators responsible for ensuring the language is communicated to AT?
13:58:19 <pauljadam> yes
13:58:29 <pauljadam> just like web developers
13:58:30 <RobW> Q
13:58:31 <JJ> 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
13:58:37 <Jamie> communicated or pronounced?
13:58:41 <quintinb> Then it doesn't matter of the (lack of) mechanism provided
13:58:44 <JJ> Zakim, close the queue
13:58:44 <Zakim> ok, JJ, the speaker queue is closed
13:59:22 <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
13:59:26 <JJ> (imo)
13:59:29 <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
14:00:18 <pauljadam> that's why they should have called it "Page" instead of "Software"
14:00:45 <quintinb> I have to drop
14:02:00 <JJ> Next week: continue language discussion with 3.1.2, and 3.2.2, plus new SC drafts to discuss
14:02:21 <JJ> Zakim, list participants
14:02:21 <Zakim> As of this point the attendees have been Megan_Pletzer, quintinb, Joe_Humbert, Tanya, GleidsonRamos, Tim, julianmka, pauljadam, Detlev, RobW, Carol, Jamie
14:02:38 <JJ> regrets+ JonGibbins
14:02:44 <JJ> regrets+ JeroenHulscher
14:02:48 <JJ> regrets+ Karla
14:02:52 <JJ> regrets+ hdv
14:02:56 <JJ> regrets+ AlainVagner
14:03:01 <JJ> rrsagent, make minutes
14:03:02 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/02-matf-minutes.html JJ
14:08:29 <JJ> rrsagent, bye
14:08:29 <RRSAgent> I see 6 open action items saved in https://www.w3.org/2025/04/02-matf-actions.rdf :
14:08:29 <RRSAgent> 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? [1]
14:08:29 <RRSAgent>   recorded in https://www.w3.org/2025/04/02-matf-irc#T13-27-12
14:08:29 <RRSAgent> ACTION: Create issue for WCAG / AGWG to clarify pointer/dragging actions with mobile application pattern examples [2]
14:08:29 <RRSAgent>   recorded in https://www.w3.org/2025/04/02-matf-irc#T13-38-53
14:08:29 <RRSAgent> ACTION: Test setting the locale for whole app using Android, iOS, Flutter, React Native, etc. to confirm if it's possible or not [3]
14:08:29 <RRSAgent>   recorded in https://www.w3.org/2025/04/02-matf-irc#T13-50-38
14:08:29 <RRSAgent> ACTION: In our guidance, clarify: “each web page” vs “software” (app level vs page level) [4]
14:08:29 <RRSAgent>   recorded in https://www.w3.org/2025/04/02-matf-irc#T13-52-15
14:08:29 <RRSAgent> ACTION: Might need exception like 1.1.1 for mobile platforms that don't support setting language at app/screen level [5]
14:08:29 <RRSAgent>   recorded in https://www.w3.org/2025/04/02-matf-irc#T13-55-04
14:08:29 <RRSAgent> 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 [6]
14:08:29 <RRSAgent>   recorded in https://www.w3.org/2025/04/02-matf-irc#T13-58-31
14:08:33 <JJ> zakim, bye
14:08:33 <Zakim> leaving.  As of this point the attendees have been Megan_Pletzer, quintinb, Joe_Humbert, Tanya, GleidsonRamos, Tim, julianmka, pauljadam, Detlev, RobW, Carol, Jamie
14:08:33 <Zakim> Zakim has left #matf