– DRAFT –
MATF 19 March 2025

@JJ walking us through the agenda

WCAG2Mobile Call For Consensus (CFC) in AG WG

JJ Please make sure you respond to the CFC in AG WG

<JJ> Questions from Wilco

<JJ> 1. How frequently do we think this document is going to need to be updated to keep it current? Mobile technologies change fairly rapidly. Why did the group choose a working group note for this? These are generally not used for things that need regular maintenance, which it seems like this would need.

<JJ> > Compared to the web, browsers have major updates multiple times a year, and Android and iOS only once a year.

<JJ> Our group expects that our document does not need more regular updates compared to WCAG or WCAG2ICT.

<quintinb> +1 to @JJ

<julianmka> +1 Hidde

hdv what kind of document are they expecting?

<JJ> https://www.w3.org/standards/types/#NOTE

@JJ looking at the differnt types of documents www.w3.org/standards/types/#NOTE

@JJ to me a group note is quite fitting

Jamie our efforts are inteneded to be a little less catering to apple / android whims and changes. There are some differences between what WCAG ... it doesn't mean it needs to stay that way. We do need to stand on the expectations for mobile apps. The general concesus should be whether or not we are trying to support wcag. I can understand the

concern that if we're trying to mimic what is alredy out there. We don't want to work with things that are going to change from year to year. Does 2.1 and 2.2 chnage itertively?

@JJ as far as I know yes it's possible. There still needs to be a CFC

@JJ it's also possible to update an existing document

<JJ> WCAG 2.2 history example: https://www.w3.org/standards/history/WCAG22/

Jamie understanding docs (which we don't have) would be more fluid

<JJ> WCAG2ICT history: https://www.w3.org/standards/history/wcag2ict-22/

@JJ I see the concern, but not how it's different from other guidelines

julianmka Jamie covered what I was going to say. Maybe one action for us is to try to be as agnostic as possible.

<JJ> 2. If a note is the best way to do this, I'm wondering whether it wouldn't be better to incorporate this work into WCAG2ICT. This document seems a little odd to me, it essentially adds notes on top of WCAG2ICT, which itself is a document that adds notes on top of WCAG 2.2. Is there a good reason for this to be its own document, other than it is

<JJ> created by a different task force? It seems like how we organize the task forces shouldn't dictate which documents we have. The other way around seems more appropriate.

<JJ> > We have discussed this possibility, and it is still a future option. At this moment, the Mobile Accessibility Task Force has to take both the mobile web space and non-web mobile space into account. Meaning that our guidance cannot be included directly in WCAG2ICT, because it only covers non-web. For the non-web part of our guidance we want to

<JJ> align with the intent of the non-web guidance in WCAG2ICT.

<julianmka> +1

<Jamie> +1]

<Jamie> +1

<Tanya> +1

<Karla> +1

<hdv> +1

I never questioned the mechanism. I assume the decision was made by the upper-ups

<quintinb> +1

<JJ> 3. Which operating systems are considered for this guidance? Having asked TF participants this seems to be all about Android and iOS. While those are certainly dominant in the US, that's not reflective of the international market. To what extent does this guidance apply to HarmonyOS or Ubuntu Touch for example? Guidance for Android and iOS is

<JJ> valuable, but if that's the current scope of the work I feel that should be much clearer, including in the document's name. I also wonder how this applies to tablet-only operating systems such as ChromeOS and SteamOS. Can we get some clarity on this?

<JJ> > For this First Public Working Draft, our group has focused on identifying guidance gaps for Android and iOS. The guidance we have written is not exclusively applicable to these operating systems, but can be applied more broadly to other mobile operating systems. We could clarify this in our Scope section.

Jamie I feel like we lean on WCAG2ICT as a guidance point. But as a starting point that we're adding notes to notes, but it's a starting point for mobile applications\

Megan_Pletzer are we discussing mobile web or native mobile?

@JJ we are discussing the native parts for now, web content and then web view. We have been able to remove mobile web, but there are other features we need to consider. MATF doesn't have to take mbile web too much into account as it's taken care of in the larger group

I'd love to see where he gets his data...

Because it's not the data I see. That said I think saying how apps should integrate with assistive tech on mobile would be better

<Zakim> julianmka, you wanted to say that if we are considering even apps pinned to the home screen, I have concerns about how that might affect the overall scope of this doc

<quintinb> +1

HarmonyOS is just Android though...

@JJ a lot of user benefit from pinning, and given what gets lost the might be interesting guidance on what the differences are there. The guidance would be useful to the wider group

<JJ> Clarify what is a "Mobile Operating System", if an OS runs on a mobile device, it doesn't make it a mobile operating system, e.g. chromeOS is a "Desktop Operating System"?

Jamie just a cursory comment - chromeOS is a web experience. ChromeOS for example says it's for the "living room experience" - which sounds like WCAG2ICT. There are going to be the one off scenarios but do we need differntiate? If we want to align around messaging, we should discuss it

@JJ our doc is odd in aligning to WCAG, I think it seems if we clarify which platforms would benefit.

<Detlev> sorry to be late - I expected 15:00 but then realised the time shift...

<JJ> julianmka: als oconsider crossover operating systems

julianmka we might need to have a non-exclusive list of OS's

ACTION: Define what is a 'mobile operating system', e.g. it benefits from our guidance

julianmka just to clarify what we consider a mobile OS

<JJ> might need to include explicit operating system names that have been considered, e.g. Android and iOS at this point

ACTION: Check with W3C Staff if we can explicitly name operating systems

Detlev IS there any additional overlap, or would they deviate completely

<julianmka> Marketshare of mobile device OSs worldwide: https://gs.statcounter.com/os-market-share/mobile/worldwide

Harmony still runs Android Apps

<julianmka> Tablet OS marketshare worldwide: https://gs.statcounter.com/os-market-share/tablet/worldwide

JJ only really tablet form factors have the most deviation

<JJ> 4. Why did the group choose to use WCAG 3.0's "view" definition? This is something that is actively being worked on, and so any change can alter the meaning of WCAG2Mobile guidance. It would seem better for this document had its own definition of view. Those could then be helpful input for WCAG 3.0.

<JJ> > At the time that our group started working on guidance (January 2024) we figured that the view definition would be ready for use by the time we would publish our guidance.

<JJ> With the current state of affairs, that seems to be a while away and I agree we should not be using WCAG 3 definitions at this moment.

<JJ> In the meantime, the View subgroup has been established and progress has been made towards a definition that can be used in WCAG2Mobile, WCAG2ICT and WCAG 3.

<JJ> In the next version of our guidance, we will add a draft definition "view" in our own document, instead of linking to an external document.

@JJ asked about Android TV, quintinb responded that most companies use web as it deploys better

@hdv it's a little tricky with views, as they've moved away to other terms. It might be that maybe we don't have the word view in there. It's a bit annoying for the publication. Because it's in flux we might stay with the current definition. It feels like it's more stable than what's in the current draft.

ACTION: Create own 'view' definition in WCAG2Mobile

Tanya - the last time we had the presentation about views my understanding was that not everyone agreed to that definition. We had an extensive discussion, but it's not clear to me what is the latest stage of the discussion, and how we've reached a final decision

<Zakim> hdv, you wanted to respond to Tanya

<Jamie> did we vote on using "view"?

<JJ> view or page or screen are still some of the open options

hdv We had a discussion with a subgroup and that work has continued. The current status is that instead of views we are using UI or context. The ACWIG (??) group is taking this on

<JJ> ACWIG -> AGWG

<Jamie> rather... when did this group MATF vote on using "view"?

Thanks JJ

<hdv> but I think it needs to be decided in AGWG

<Jamie> then the premise of this question #4 is not related to MATF

<hdv> agreed

Detlev It's pointless having a long discussion, because whatever term we pick we'll still not solve the problem. This feels like bike shedding. Stick to views and change it when the new term is decided upon

<Zakim> hdv, you wanted to respond to own definition

@JJ we can't just decide to change definitions - we need to be certain how to apply SC's

hdv in the end we have to align with ACWG definition. Keep in mind in the longer term we need to make sure a relationship exists

<Jamie> we haven't chosen the term yet. We could use "screen" and that is not WCAG or AGWG

2.5.1 Pointer Gestures

JJ reviewing the comments

I believe this should apply as written, I like the note about taking responsible for your own layers, for example pull to refresh is not the devs problem if it's not their component

<julianmka> +1

<JJ> close the queue

Detlev I would think that custom accessibility actions should not be covered by pointer gestures. The goal is how to achieve the same action without pointer gestures. Sliders are an example on web.

@Jamie Custom actions are under which sc?

Jamie under which SC are we testing this?

<Detlev> there is list of available actions in the EN...