– DRAFT –
MATF 23 September 2026

WCAG2Mobile / AG WG update

<Tanya> https://www.w3.org/wbs/35422/scope_exercise/results/

<JJ> Presentation yesterday at AG WG: https://docs.google.com/presentation/d/16JME9YIgKR9ErMC0xFvKveftLKCGYdWkylyjLtrNJnE/edit?slide=id.p#slide=id.p

<Tanya> https://www.w3.org/2026/04/28-ag-minutes.html#b1c2

<Detlev> why is that surprising?

<JJ> ^ 28 April 2026 with AG WG survey

<JJ> https://www.w3.org/2026/09/22-ag-minutes.html#4d55

<JJ> ^ 22 September 2026 about 'mobile' term

Yeah I don't like "Native and touch" for many, many reasons

<JamesH> +1 to quintinb

<sam-estoesta> 1+ to quintinb, Tanya

Detlev Tanya just said that some people just refer to the EN for things not in WCAG. I understand WCAG is applied to mobile, but in Holland we apply other things - certainly if you have hardware aspects and see that as a system then you need other things. But many things like 11.5.2 thewre's a whole set of things like moving focus etc with a screen

reader that can be covered. Some things are redundant but other things aren't. There are some things that can't be covered like execution of available actions not covered, but it's well covered there. Why is that surprising - because people dealing with mobile apps sometimes do need to go beyond wcag. It seems a good way to compliment things

missing in wag

Tanya too bad I couldn't join your session because I was assigned to another group. But the EN standard is refereing to WCAG2ICT which references WCAG (note: it's hard to scribe this)

<JJ> Thanks quintinb - many abbreviations

The references are hard for me folks

but add relationships...

@Detlev we'd delay WCAG3 if we don't focus on web

Detlev you could write WCAG so that it is applicable to mobile.

sam-estoesta Apologies for not making yesterday. Was there anything spoken about the reputation risk regarding the push back? There's been so much work already done

<JJ> Quoting alastairc:

<JJ> alastairc: I can help out with scoping. something we looked at and agreed a while ago. Chair hat on. It can be a struggle when this group is doing things like rechartering.

<JJ> … there are W3 members who want to make sure we don't stray out of our web content box.

<JJ> <alastairc> "WCAG 3.0 focuses on provisions for web content. The provisions can also be applied to software and documents but are not considered complete for those platforms in 3.0. Future versions may provide additional guidance specific to other types of digital content."

Detlev there is an existing problem with workload and requirements definition - lots of work over every sentence. It won't be that different from old WCAG. If there was some solidity in the requirements then our group could use it as a structure, everyone would be delighted

<pauljadam> mobile is the web

<JJ> +1

Detlev one should note that the normative should be tech neutral and if we went tech specific then those notes would be non-normative. No one would object to that but it's always a matter of who is talking the most and if there are several people making strong points it's a way to sway everyone.

<pauljadam> Apple probably does not want rules applied to them saying their apps are not accessible 🙄

<pauljadam> Or Apple wants to make their own rules

JamesH intro

Start of Milestone 3

<JJ> https://github.com/w3c/matf/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A%22Third%20Draft%22

2.4.1 Bypass Blocks

<JJ> w3c/matf#8

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

<pauljadam> Containers can group sections of a page with meaningful accessible names. VoiceOver users can jump between each container using the Rotor. Containers can group related controls like radio buttons or mimic the behavior of ARIA Landmarks. The container name is spoken to VoiceOver when focus is first placed on an element inside the group.

<pauljadam> Headings are also a method to bypass blocks

<pauljadam> Set of Pages is good :)

<pauljadam> web is mobile

<pauljadam> we write techniques for how to do it :)

<pauljadam> you probably wont have a skip link on a native app but it's not impossible and a web app could have it

<pauljadam> hamburger menu is also a method to bypass the navigation block when it's collapsed

<JamesH> +1 pauljadam

<pauljadam> agree I don't think skip link is required for native app

RobW I mostly agree with what Paul is putting in the chat. Paul's point on skip links - sometimes web folks insist on skip links in mobile which is odd. I think we should keep this, but with what Paul is suggesting, but make sure we make a note on skip links not being recommended

<pauljadam> just like 3 skip links is not really required or visually hidden headings

I would love if screen readers had a rotor option for errors

<JJ> Poll: do you agree with adding a note about best practices to skip content in mobile apps?

<pauljadam> +1

<JamesH> +1

<Tanya> +1

<quintinb> +1

<sam-estoesta> +1

<RobW> +1

<pauljadam> it's definitely a confusion point when trying to apply web a11y to native a11y

<Detlev> +1 sections navigation indeed much better than skip links!

ACTION: 2.4.1 Bypass Blocks - Add note about best practices to skip content in mobile apps

<JJ> Poll: do you agree with adding a note about recommending developers to NOT add a skiplink as this is not a best practice in mobile apps but a web technique

<RobW> +1 to 'not required'

<JJ> +1 to 'not required'

pauljadam I think it's sort of a usability question. There are web apps, web pages that may have a skip link because it was already there. I agree it is weird, but maybe say it's not required rather than "bad" - wcag just says "methods of bypassing blocks"

Yeah but auditors already fail on auto-focusing errors which is not even in wcag

<pauljadam> +1 to not required

<Tanya> +1 to not required

<JamesH> 0

<quintinb> +1 to not required

Detlev what does "+1 to not required" mean?

<pauljadam> Because you can use headings and containers

<pauljadam> basically

<Detlev> +1 to skip link not required

RobW I think we should have something softer to suggest it's not the best way

<pauljadam> something like skip links are generally meant for desktop screen reader users ?

ACTION: 2.4.1 Bypass blocks - Add note about skiplinks, noting that they are not required in mobile apps (if other techniques are used)

2.4.5 Multiple Ways

<JJ> w3c/matf#13

<pauljadam> native apps need a search still

<pauljadam> search and navigation

agre

*agree

<pauljadam> an index page is basically a site map

<pauljadam> they can put a site map in a native app but it's not typical, like a skip link is mostly for web sites

<JJ> https://www.w3.org/TR/WCAG22/#dfn-processes

<pauljadam> like if you have a step by step onboarding screen the navigation and search does not have to show a link to get to the middle step or the last step

<pauljadam> most apps have a search and a navigation, boom they meet the SC :)

<pauljadam> it's required

<JJ> Candidate for sitemap note, deeplink note, search functionality recommendation

pauljadam I think it defiitely applies to mobile - have a hamburger menu and possibly a search. They could have a site map if they wanted - but it seems like a good usability improvement to have a search

<pauljadam> I think that's a good note because so many a11y folks may think a site map is required

<JamesH> +1

Sorry if I got wrong folks

ACTION: Add note about sitemap and how it does apply to apps and whether it is required or not

ACTION: Consider notes about deeplink and search functioanlity and other ways to reach in-app content