– DRAFT –
MATF March 5, 2025

<JJ> (starting in 2 mins; looking for scribe volunteer!)

WCAG2Mobile title update?

<JJ> w3c/matf#76

JJ WCAG2Mobile title update: Had a meeting and pre cfc and they would prefer we use this as the title. Plus they think it will help SEO and local web site search functions. There was some discussion regarding to what mobile means, running on a browser / tablet / wearables. Currently the guidance says that the WCAG is applied to applications running

on mobile. JJ suggests that we change this to Mobile Applications. Shaun re-opened an issue. JJ: Should we prefix mobile accessibility? Should we make it WCAG2APP? Mobile being at the start and end makes it more clear for the W3C.

<pauljadam> Mobile Accessibility: Guidance on Applying WCAG 2.2 to Mobile Apps

<pauljadam> Mobile Accessibility: Guidance on Applying WCAG 2.2 to Native Apps

<JJ> Suggestion: Mobile Accessibility: Guidance on Applying WCAG 2.2 to Mobile Applications

<pauljadam> Just not sure we want to say Mobile twice in the title?

<JJ> https://www.w3.org/WAI/standards-guidelines/mobile/

Jamie earlier you mention a W3C page that we should align with - which one are they referring to? (@JJ) - I just want to recap what's on there. At one point it was talking about mobile web stuff

<Aash> Mobile Accessibility: Guidance on Applying WCAG 2.2 to portable devices - WCAG2Portable

<Aash> Mobile Accessibility: Guidance on Applying WCAG 2.2 to devices on the go - WCAG2OntheGo

JJ an old document prefixes with mobile. Mobile accessibility is so broad.

julianmka it does distinguish between mobile web and mobile apps. If they want us to change our name they should change their page

julianmka W3C mobile pages look like they need updating

<JJ> https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/ is subpage of WCAG, mobile accessibility is direct subpage of Standards/Guidelines

<Jamie> quintinb the above comments are mine not julianmka :P

Sorry

<pauljadam> +1 on adding native in the title

That was a very quick discussion

<pauljadam> +1 on not having mobile in there twice

RobW I want to ask about the "native" aspect - it depends on our remit.

<Aash> chatGPT suggests this one: WCAG2ONE (Optimized for Native Experiences)

<Aash> Mobile Accessibility: Guidance on Applying WCAG 2.2 to Optimized for Native Experiences

<Jamie> +1 to Suggestion: Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2

JJ have a vote for 3 options: combinations with prefix and suffix

<Jamie> mobile)

<Jamie> what about WCAG2Mobile

JJ Mobile Applications is the furthest we can stretch it

<pauljadam> Apps seems more native than Applications

<pauljadam> There is pure native and there is hybrid

@quintin Our definition needs to be clear that native is not html (e.g.

<pauljadam> Yes it's more formal

<JJ> 1: Mobile Accessibility: Guidance on Applying WCAG 2.2 to Mobile Applications

<JJ> 2: Guidance on Applying WCAG 2.2 to Mobile Applications

<JJ> 3: Guidance on Applying WCAG 2.2 to Mobile

<JJ> Please type 1, 2, 3 to vote on your preferred title

1

<Joe_Humbert> 2

<pauljadam> 2

<jeroen> 1

<Carolina> 2

<Illai> 2

<julianmka> 2

<RobW> 2

<RacheleD> 2

<Jamie> 2

<Aash> 1

Joe_Humbert Reiterating that we don't like the repeat of the word mobile

ACTION: Group voted for title: "Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)"

Jamie As a comprise - we should ask them to update the Mobile A11y page, and put our page in the same context. Give us a reason why the page is separate from WCAG2ICT

ACTION: Check why Mobile Accessibility Note is not a subpage of WCAG page

Jamie Mobile Accessibility needs to mean "Mobile Applications"

WCAG2Mobile Call For Consensus (CFC) in AG WG

<JJ> https://deploy-preview-1110--wai-website.netlify.app/about/groups/task-forces/matf/ updated MATF page

JJ has asked to remove [Mobile A11y] - I don't think anyone is calling it that

JJ questions on CFC? The CFC will be extended due to CSUN next week

julianmka It would be great if all members participate in the CFC - everyone should vote.

JJ Alisair has asked that we vote, because it would usually result in getting what we want

4.1.2 Name, Role, Value

JJ standard Android and iOS components do not always meet this criteria. Removing "web authors" in favour of "software developers" - saying "most" in some cases regarding components

<pauljadam> Maybe our note could say "Native UI components" rather than "Standard UI components"

JJ there was discussion on what a control is - there is a new comment

JJ some native elements do not have a role

JJ looking at WCAG2ICT - where there is a note on roles

I disagree with that @JJ - "double tap to activate" does not indicate function

<pauljadam> It's similar to headings with levels on native. You can't actually add a heading level in Native android Yet so it's not really required to make a fake heading level. But once Android can add heading levels properly then they should be expected to do so.

<pauljadam> Basically, developers should not be adding "fake roles"

<quintinb> +1 pauljadam

Joe_Humbert We may need a note, because that double tap to activate is associated with being able to click, but does not match up to role

Joe_Humbert in WCAG2ICT we may need in a definition or another note if we accept DT2A (double tap to activate)

<pauljadam> A hint is not really a role, on Android I would treat it like heading levels, if you can make the role speak then you should but if it's not possible then it's not a fail until it is possible.

<JJ> quintinb: do not rely on screen reader output, rely on the programmatic role

TalkBack is not the only screen read on Android, DT2A is not "reliable"

<Illai> +1 to quintinb

<pauljadam> Sliders on iOS don't really speak a role they just say "adjustable" so maybe that counts as the role 🤷‍♂️

<pauljadam> is there no a11y inspector for Android I guess?

<pauljadam> on iOS you can inspect the elements easily just like on web

From the Zoom chat (Carolina): TalkBack does announce “double tap to activate”, but this hint can be disabled, and this is just something that TalkBack does. TalkBack is a powerful tool to use for testing, but it is not the actual test. The test is does a control have a name, role, and value (if applicable)

<Zakim> julianmka, you wanted to say that talkback verbosity settings can help determine programmatic

<JJ> Android has some form of UI inspector but IMO its pretty buggy

julianmka: When it comes to settings, Android let's users adjust the order of announcement - one way to expose developers' faking roles

<pauljadam> Can you inspect any app you download on your Android phone or do you need the project file?

Any app pauljadam

<JJ> Any app but its limited, with source code you can see more props

<pauljadam> So then you can see the role on Android?

Yeah you can see an XML accessibility tree from adb "adb uiautomator dump"

(maybe "adb shell uiautomator dump" - but something like that)

<pauljadam> I was hoping for something simple like Xcode Accessibility Inspector were you can inspect every element in an app and see all it's accessibility properties.

<Joe_Humbert> +1 to julianmka

There is a layout inspector in Android Studio, it uses this mechanism

<pauljadam> on web you need to be able to inspect code as well or else you would only rely on the screen reader output

<julianmka> Google's Accessibility Inspector can be somewhat helpful re: detecting roles shoehorned into contentDescription -- e.g. it will flag a label with "button" in it.

<JJ> There seems agreement that 'hint' is not sufficient as 'role' (e.g. "Double tap to activate")

Jamie - the standard UI components on other platforms don't always meet these criteria

Jamie we need to start from the base level intention of the SC

<Carolina> There is an android inspector for accessibility, we are presenting it at CSUN: Testing Mobile Apps: Tools, Techniques, and Best Practices session

<pauljadam> if the standard platform native control is not having the proper role then that is a bug with the platform developer and they need to fix it in a future release

<quintinb> +1 pauljadam

<pauljadam> If you're talking about Android Accessibility Scanner, that's not really an inspector. Or, are you taking about the Layout Inspector?

<Carolina> no, no, it is a tool that you can use to inspect the app - you can see the name, value and role ...focus etc...

<pauljadam> Native controls are "expected" to meet Name, Role, Value but they may not due to the platform developers missing adding a11y when they release the native control, or they may fix it over time, or make it worse.

ACTION: What happens if your "standard user interface component" meet 4.1.2 when used according to specification.

<Carolina> we are not only presenting that, but it would be part of the presentation

julianmka are we talking about all UI components?

<pauljadam> It's intended for custom ui control

<julianmka> Sorry, I meant Accessibility Scanner

<pauljadam> If a native control is not meeting 4.1.2 then that goes to the native control developer

JJ is it possible to make a component meet 4.1.2 - if developers are not able to do it, is it then an exception?

<Carolina> Quintin, why they wouldn't be able to add a role?

@JJ if the FWK doesn't meet it, then they just won't pass a WCAG

<Jamie> what is FWK>

Carolina I suspect that was me scribing, but I suspect it's because the particular role doesn't exist, e.g. link is not a role in Android

<julianmka> FWK = framework

<pauljadam> It's native if the user thinks it's native

<pauljadam> users don't know the difference between a pure native app, or a hybrid native app, or a web native app

<quintinb> +1 pauljadam

Jakobs Law

<pauljadam> only a developer knows

<Carolina> I think is important to have the proper role, otherwise, user could not navigate by controls on Talkback for example

<JJ> Illai: There is no App Specification like the Web Specification

<Jamie> +1 to illai

<Carolina> There are a few test that you can run to know when a control has a role or not

Illai I think the issue is that there is no clear standard guidelines on what the native elements are for "mobile" - there is no backbone for native elements. No one clear specific pattern for mobile

JJ and there is no alignment between the operating systems

<Jamie> Carolina are you able to share here more about the inspector you are speaking about next week?

<Carolina> Yes, I can share it but I kind of rather to share after the presentation. We are a week away...so if you don't mind to wait one more week?

Surely then we should align with the roles defined by that platform

<JJ> Thx Carolina, next week would be nice :)

JJ maybe we need specific understanding documents for a platform

<JJ> Close the queue

Joe_Humbert I somewhat agree with quintinb, but it could stifle new ways to interact with mobile. Quite a few of the ally techniques cross over to other platforms. I would be worried about saying "only use these specific ones"

Joe_Humbert I do think we are saying the same thing. I'm not saying to be precisely prescriptive, just to conform to the platform

<Joe_Humbert> understood quintinb :-)

ACTION: Next week 2.4.4, 2.4.6

ACTION: Guidance title update

Missed the last one JJ

ACTION: CFC Update via email / slack

Thanks
… and scene

<Carolina> thanks