– DRAFT –
MATF July 2, 2025

scribe quintinb

Project planning

Thanks Joe_Humbert for cover for JJ while he was honeymooning!

You should have accessd to https://github.com/orgs/w3c/projects/147

There are 169 new sub issues, each with a parent issue

Thanks Tania and Megan for setting up the MATF board

<julianmka> This looks great!

Change of context definition

<JJ> w3c/matf#69

JJ perhaps we need to focus on native mobile apps and get to hybrid later?

Joe_Humbert We did an informal poll, perhaps a larger discussion. If it's web content, doesn't WCAG apply directly?

<quintinb> +1

<Jamie> +1 to Joe_Humbert

Joe_Humbert maybe we can add to a preamble that web pages on mobile (Quintin asks: rendered in a browser?) must refer to WCAG

<Joe_Humbert> quintinb not just rendered in a browser because "webviews" aren't always are considered "browsers" particularly when they have no interface

Jamie I am supporting the concept Joe_Humbert brought up. This iteration needs to fill the gaps of mobile apps. If people ask about web apps, this isn't the doc for them. We need to clarify what is not yet defined. They're both important but perhaps a phased approach

Joe_Humbert yeah that is my concern

<Jamie> thanks quintinb

Tanya We need to decide on a format to make it clear for ourselves and the readers of the draft. I did not understand how the abstract relate to how we apply our guidance. The structure of the document needs to be clarified and make a definition of done. \

Joe_Humbert the reason for the separation for mobile vs web is that developers state they are only in control of the native code.

<pauljadam> web views might be a page that is shared among multiple apps like the terms of service page but you should be able to access that HTML code and make it accessible as well

<pauljadam> It's harder for a tester to know what is web view or native view.

"I chose a framework without any access to the internals" is not an excuse for inaccessibility

We should focus on "how a mobile app is accessible" - developers need to fix for that

User interface component definition

<Joe_Humbert> to be clear, I'm not advocating for inaccessibility, just advocating for our document to not be unwieldy in scope for developers to consume

<JJ> w3c/matf#68

Oh I'm 1000% with you Joe_Humbert - I know it's not you

Apologies if I seem extreme, I can be quite nice sometimes

hdv One thing to add - component is also be redefined. There is talk about creating a definition for component and interactive element. These are still in flux. Just like with views. This is expected to last a while. User interface component is a little more specific - some web developers will consider non-interactive components as components such

as headings. User interface component is more specific

<Joe_Humbert> +1 to alan's definition as a starting point

<JJ> https://accessibilite.public.lu/en/raam1.1/glossaire.html#user-interface-component

julianmka I think the note does a really nice job of showing how you can have something without perfect fidelity between mobile and web but still have an accessible experience. We should crib (I think that was the word?) this note

<pauljadam> SwiftUI has a checkbox? I've only seen a Toggle.

Thanks julianmka - It's a bit close to another word and I would be careful about writing that one down - and verbal b's and p's are difficult to distinguish sometimes

<JJ> https://developer.apple.com/documentation/swiftui/checkboxtogglestyle

Never seen a checkbox or radio button in native SwiftUI pauljadam!

<JJ> or is that only macOS

<pauljadam> yeah macOS only now for native checkbox that is the square

Yeah mobile

<pauljadam> Apple only has Picker as the alternative to radio buttons https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/Documentation/RadioButtons.md

<pauljadam> Checkboxes should be made out of Toggle https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/Documentation/Checkboxes.md

Tanya are we maybe going to deep - if we are giving examples or specifics we need to decide if we're at that place right now. Where is the line?

<Tanya> +1 to Joe_Humbert

Sorry Joe_Humbert I missed that

hdv Nothing to add

<Joe_Humbert> maybe we make Notes generic and have one section that discusses specific "gotchas" with different OSes. That way instead of having to change lots of Notes, we just update one section. This might be better in understanding documents

ooh yeah +1 to that Joe_Humbert

I love not saying "Mobile"

<Joe_Humbert> +1 to Tanya about updating the abstract to make our process clear