Meeting minutes
Announcements and Intros
<Rachael> WCAG 3 Provision Review https://
Rachael: Announcements - look at what other subgroups are doing. Open until April 27th. Please take time to do so. Asking for collaboration asynchronously.
<Rachael> https://
Rachael: Holding a two-day virtual meeting, May 11-12. Looking for a six-hour commitment for each day. Please fill out the survey above. Goals: Retrospective. Conformance subgroup out brief, and make notable progress on conformance model, and to make decisions for the June publication and to write an outline for our policy document. Please make
time during those two days.
Wilco: Asks for status of the charter
Rachael: Kevin is on vacation. Most of it is ready to go and is moving forward. Expectation is to ask for an extension. Will provide a better answer next week when Kevin is back.
<Zakim> Jennie_Delisi, you wanted to discuss questionnaire
Jennie_Delisi: In the survey, the times are listed in a specific day.
Rachael: Will modify the survey so it is more clear.
WCAG2 proposed changes https://lists.w3.org/Archives/Public/w3c-wai-gl/2026AprJun/0005.html
Patrick_H_Lauke: One of two weeks have past for the items in the working group for approval. Round is light (3 items). Barring any negative feedback, the changes will be merged. There's a list of proposed changes that will go into errata, which will go through pre-CFC and then CFC process.
GreggVan: Asks if there is a survey, or just do you just want a response in an email?
Patrick_H_Lauke: Please add comments in GitHub.
Charles: US Dept of Justice has issued an interim final rule and is invite public comment on ADA Title II. In the public comment, I would like to provide a piece of clarity about the changes to WCAG 2 being only informative or errata. Is there preferred language for these types of changes?
alastairc: Understanding is when errata is agreed, it gets added to the document, and to be considered to be the latest version of WCAG 2. Yes, it's the best term.
<Patrick_H_Lauke> probably the first time i heard somebody claim that WCAG is ... "dynamic" ... ;)
<Charles> +1 to Jonathan. this was my point. we need language to help dismiss the concern of dynamic changes.
Jon_Avila: ADA Title Rulemaking, referred to the 2018 version of WIC 2.1, which is set in stone, and isn't changing. The interim final rule was that WCAG was dynamic, was untenable, and changing. there's a misunderstanding around how the updates work, and when the referenced version with a particular date is referenced, that is fixed. Encourages
people to read the document to understand what other future implications there could be.
Mobile taskforce update
alastairc: Look for the URL to be posted in IRC.
alastairc: Update from Mobile Task Force.
<JJ> WCAG2Mobile presentation slides: https://
JJ: (Jan Japp) Quick intro - live in the Netherlands. Company Abra works on mobile accessibility. Been on task force for ~4 years. Want to review what the task force has been doing. This is the same deck from TPAC from November last year.
JJ: [Refer to slide 1-2 content posted above].
JJ: [slide 4] Narrative of slide contents; screenshot of initial publication in February 2015.
<Patrick_H_Lauke> not going to lie, i'm still not a fan of "mobile" as a moniker...
<alastairc> I know, but it's such a common / industry term
<julierawe> Can someone please reshare the link to this slide deck? (Apologies for joining the meeting a bit late!)
<Patrick_H_Lauke> "web on small screen + primarily touch interface, native apps, hybrid apps"
<Patrick_H_Lauke> the first part should not even need to exist...
<Charles> previous topic – URL for the ADA Title II Interim Final Rule where commenting is open: https://
JJ: [slide 5] Last official publication was May 6, 2025. New guidance is called WCAG2Mobile. Structure is almost identical at level A and AA. There is informative guidance on how to interpret certain success criteria for mobile applications. Common question is what is the difference between WCAG2ICT and Mobile Apps. We focus ons on not only the web
part, but the non-web part. There are native, hybrid, and cross-platform apps. We will have the web implementation plus the non-web interpretation and additional guidance.
JJ: [Slide 6] Spend a lot of time on definitions on the draft released on November 2025. Things get confusing on mobile, because of the definition of scoping the page, screen, or view. Additional challenges to make a definition that works for both web and non-web at the same time. We replace "web page" with "page" and have a lot of discussion about
other definitions, like "user agent." Time was spent on definitions and the 'layers' come in. Spent a lot of time on these definitions.
JJ: [slide 7] Working on second draft; have the feedback we need, and are processing feedback. Have 11 definitions to complete. Target is to have it ready by the second quarter.
JJ: [slide 8] Group note expected end of 2026. 16 success to complete. Want to get some more feedback from AG; fine-tune definitions and some of the guidance. Likely will be early 2027 before we have a fully published, group note.
GreggVan: What is the definition of 'mobile'? Is it phones, tablets, laptops?
<Patrick_H_Lauke> "mobile" is an unfortunate historic term ...
<Charles> "unfortunate historic term" covers a lot of what we discuss
JJ: Good question, there is an open issue for this. It is tricky. What differentiates the requirements is the ability to use touch. Attributes are portable, and maybe have touch as a primary input.
<Patrick_H_Lauke> touch, small screen, orientation/motion sensors, ...
GreggVan: The mobile task force is formed because there was something needed. If it's just touch, shouldn't it be renamed the 'touch-based task force'? What is different from the WCAG and WCAG2ICT task force to make Mobile Task Force unique? Needs clarity on the scope to help evaluate the rules.
JJ: Feels that definitions are a really big part of this. Android, iOS, and non-web are big scoping questions.
<JJ> https://
<alastairc> ^ latest draft of the MAFT note
Patrick_H_Lauke: Was involved in the original Mobile Task Force, and brought up renaming it. The name is slightly vague. Wanted to ask about the 'native' aspect - when talking about native apps, companies are applying WCAG. Thinks that 'native' is probably more the axis where I would make the differentiation. I would strongly welcome seeing what
specific advice was given for that scenario, and rolling that directly into the understanding documents for WCAG 2.2; and not having another specific specification. Would rather see them rolled into WCAG 2.2 'proper' through the WCAG 2 Task Force. It would remove the ambiguity from the WCAG 2 mobile plate.
alastairc: To clarify, it would be useful to gather the web-oriented bits withi mobile to incorporate into the understanding documents.
Patrick_H_Lauke: Correct. There should be a way to integrate this guidance into WCAG 2.2
alastairc: Wanted to respond to Gregg's point about the definitions. Mobile is such a common industry term, but we can't call it the "WCAG to iOS/Android" because we just can't name things like that.
<Patrick_H_Lauke> need to bail, but would be happy to flesh this out further - i.e. collaboration between WCAG2Mobile and WCAG 2 Backlog TF, moving web-specific advice to WCAG 2.2 proper
Detlev: The bulk of the discussions in the mobile accessibility task force is all about Android and iOS at the moment so it's quite clear there is a moral problem of an initial commitment to cover both mobile, web on mobile devices, and native mobile. Which is a problem because in practice I think there has been very little discussion on web stuff
on mobile devices, and I totally agree with Patrick. The second point is that I'm wary of deviating from WCAG2ICT, and would like to keep that deviation to a minimum, or avoid it altogether.
<Jon_Avila> I agree with Detlev.
<Charles> mobile lacks a consensus based definition. native operating systems are very different than web. so i don’t understand the difference between 2ICT and 2Mobile.
<alastairc> q/
JJ: They are keeping a close eye on that and staying aligned. We don't want to deviate there, but we are seeing some feedback. It could help to bring some of that back to WCAG2, maybe some of it can be used in WCAG 3. Findings could potentially be used to WCAG2ICT. One of the issues we saw is related to pages. there is also the 'set of software
programs.' When we look back at ICT definitions, there is overlap that can't contradict and bringing it back into WCAG2ICT because it could solve a lot of (definition) problems. We mostly have guidance for the native components, so we haven't found much need yet to provide additional guidance for the mobile we part. See the need to comment on the
native part.
alastairc: It would be good to eep track of any advice coming from Task Force Mobile that does conflict with WCAG2ICT. I don't know if there is much yet, but keep an eye on that.
<JJ> Indeed, ideally MATF guidance should not contradict, but specify and fill gaps. I think that a WCAG2Mobile document can (also) serve these purposes.
<Jon_Avila> Web apps and mobile apps do have some screen specific titles.
GreggVan: There is guidance for non-web, which as WCAG2ICT. The question is what is the guidance for mobile? It's going to contradict some things in WCAG, and that's not good for anyone. Shouldn't try to create its own document, because there's the risk of contradicting guidance. Mobile should help shape and advise. If the language is not exactly
the same, then which one is the industry supposed to follow? You talked about page, we've been trying for a long time to come up with a definition for a page outside of the web page. We're talking about 'views' now, and would like to hear about any wisdom there. There's another issue of 'set of web pages' came about because people would use a set
of web pages, like an app. And they were meant to work together. A set of web pages can also mean an 'app.' The title was meant to help someone when they were dropping in on totally different URLs. And they don't need to know what it was about. An entire web app only has one title. These things aren't mysteries if you think back to where they came
from, and you think of what their equivalent in a web app would be, they just fall away.
<Jon_Avila> I disagree with Gregg on the screen titles.
GreggVan: Examples for why it was a problem, aren't a problem if you think about them.
<Jon_Avila> yes there are
alastairc: Specific titles can be assigned per view.
<Jon_Avila> EN301549 exempts app titles because they need to be copyrighted, etc.
GreggVan: Understanding is that they can't. The point is that the examples don't counter what Patric and Detlev were advocating, and I agree.
<Wilco> +1
<Charles> +1 to Detlev. ‘mobile web’ is just web.
Detlev: Returning to the original problem of mixing native mobile apps and mobile web. There seems to be an agreement that it's not a good choice, and that mobile web belongs to WCAG, and not into the Mobile Task Force. Does it make sense to get some kind of group consensus that we should change that and Mae the Mobile Task Force entirely on native
mobile apps.
alastairc: Can you describe the focus on what the group has been looking at so far, because my understanding is that it's primarily on native.
JJ: Yes, it is primarily native [gives examples]. Examples include title, non-text content. Is the absence of these attributes a platform defect or at the developer level?
Detlev: The question is can we get rid of 'Mobile Web' - can we have a decision on excluding it? Can we have a decision on excluding it?
<alastairc> The task force work statement: https://
JJ: Most of the participants on the task force are mobile app developers, not web app developers or web site developers. A lot of them would encourage this idea of only focusing on the native. There is this new addition that web views need to be tested. It's been the native interpretations that have been problematic.
alastairc: Put the work statement into IRC. Will catch up with Kevin when he's back.
Continue Scope of WCAG 3 Conversation https://docs.google.com/presentation/d/1BkgIVS8ODwokDPXJd91ChHfN7-WuaZdGcvK3Ru-hc_Y/edit?slide=id.g3d665925735_0_10#slide=id.g3d665925735_0_10
JJ: If you have any additional feedback, please send me an email or ping me anywhere. You can find my email on the Mobile Accessibility Task Force page. Happy to receive any feedback or ideas. let's keep in touch.
<JJ> My e-mail address: janjaap@abra.ai or MATF group: public-mobile-a11y-tf@w3.org
alastairc: Scoping of WCAG 3, in what the group's focus is. (see slides in link above). In terms of the problem we're trying to solve.
alastairc: Some of the blurring occurs in native applications where html content is within them as part of an application. TV boxes may be written in HTML or have both.
… It's hard to make these generalizations. There was a good discussion in GitHub about platforms.
… some of the key things from that are on slide 7. n
<Rachael> s/.n/.
alastairc: Is it within a browser? Is it not within a browser but on a platform? Is the platform provider separate from the author. We also have closed systems like kiosks which may or may not take advantage of a platform.
<alastairc> https://
alastairc: these are some of the characteristics from that discussion. We are now going to do an interactive survey.
If you can open the link above, we've got these as a starting point.
… would anyone like to make recommendations for changes in this exercise? Are any categories not clear?
Graham: confused by APIs
graham: understand it means excluding APIs
shadi: When reading the survey, there's a difference between writing specifically for a technology or for other contexts and excluding other contexts
… originally web was primary content
… later it was made more broadly applicable without addressing specific technolgies
… should we write specifically, or take care nit to exclude them
<Zakim> Jennie_Delisi, you wanted to discuss docs viewed within a browser
alastairc: question os are we able to apply it - hardware for example is not possible
Jennie_Delisi: Are. we intending bewteen docs seen in software client and in the web? Most people don't know it is not the same, they expect the same functionality in the browser
alastairc: good question...
<Zakim> Rachael, you wanted to answer Jennie
Rachael: We have pulled it out into separate thing because the context was different
<joryc> Model Context Protocol
Jon_Avila: Same question about pub content - are assistive technologies a separate point? Two thing MCP service is going to be assistive technology and a consumer of content - and a11y features can be consumed by these technologies
MCP model context protocols
<joryc> https://
Jon_Avila: Technologies may act on behalf of PwD
graham: Are we excluding agents - but if any output of them is also excluded? Will that nit need to be covered?
… do we cover that? Worrisome area
Wilco: need clarification why we are opening a scope discussion? We are so far into the standard that it seems this should have been set already
alastairc: We need to define what informative things we commit to be doing in the next phase
Rachael: it is an iterative process, we need to narrow down questions as part of the process
Charles: The same distinction of PDF inside/outside the UA applies to XR
… if we are separating PDF we need to do the same to XR
<bbailey> +1 for "should apply to" versus "could apply to"
<Zakim> joryc, you wanted to say I agree with Jonathan and how we should expand to meet AI
Heather: Other groups look at the guidelines and decide what they can or cannot do - we should limit that because technology will broaden and stakeholders need to decide what applies - it could be applied in parts even to hardware
<Charles> +1 to joryc that this list cannot be evergreen
joryc: A lot of change is happening UA will talk to UA - we cannot nail down a lot of things because it will make WCAG 3 irrelevant by the time it is published
<Jon_Avila> That's a good point - an auto generated experience for a user could be a conforming alternative version.
discussions like about what is a page seem a bit irrelevant - the focus should be digital communication in general so it can be applied to a million things that will appear
<Zakim> alastairc, you wanted to focus on "authored" things
Thant was joryc
alastairc: Questions is what is it people are authoring - links to a11y support issue
<Jon_Avila> One way to look at it - If PDF is delivered via uri it is often considered web - if it's delivered another way not via uri it's not web.
alastairc: there is mite stability in what people are authoring
… like set top boxes or authoring mobile apps or kiosks this are the differentiators
<Charles> opinion: the scope of the guideline can be different than the scope of methods within it.
Wilco: Not sure if this is ever going to be done if we extend the scope that much - set top boxes or kiosks are not in the spec (charter?)
bbailey: Even for desktop software WCAG does not cover it all, there are additional things to be done
Rachael: Step back - this is not a comprehensive list . it will change rapidly. It should help us understand what we are talking about. Lines have blurred so much between web and the rest. The exercise should bring us mire clarity what we are covering since that will impact on the way we write out recommendations
<Zakim> Rachael, you wanted to speak to Jory's point
Rachael: exercise should help us understand boundaries better
graham: Are we treating AI as authors? Fundamental question...
<Zakim> joryc, you wanted to say I agree with Wilco's concerns but also think we need to get this right
alastairc: it is an umbrella term that be have to break down more - AI as producer, consumer
joryc: We need to keep in mind that these things are authored. Agree with Wilco's concern about scope creep - but we need to open out mind as to what interfaces ae and what we may cover - we are at a point at where we talk about transfer across multiple forms appatatuses, user interfaces so that goes back to properly structuring information to
ensure digital a11y
… I don't want to see WCAG swept under the rug because it doesn't match technology once it comes out
<Wilco> +1
GreggVan: we convey information in many ways, not necessarily in a structured format . we cannot impose on the world restrictions on how things are structured - the world will push back and do it differently
alastairc: (looking at survey results)
<Charles> could we have the scope of the guideline be digital content and the scope of methods be any (not all) from this list?
alastairc: nine responders; all said web content no one said hardware - (look at the results yourself...)
<alastairc> https://
alastairc: some said OSs, surprising; others said assistive technology, but that wouldn't worek
<Jon_Avila> I didn't realize.
<joryc> Assistive technologies will have Web UI's in many cases
Rachael: We should give people a few minutes to di the survey...
alastairc: OK
GreggVan: Operating systems: there is the pumping ant the interface. the second needs to be accessible like anything else. As to AT: the reason not to include it generally is that it is tuned to specific functional requirements: but some are focused on one particular disability so they may nit be possible to use for people with multiple
disabilities
… should not require AT to be accessible to all but encourage it
alastairc: OS has its own apps, as it were
alastairc: The main things people expect to be covered is web content, doc, and apps
Rachael: Any argument about including some stuff? Is there consensus?
GreggVan: we should have should and nit shall for AT
… recommend people read EN 301 549 to see how the guidelines have been massaged to apply to non-web stuff (dos, software) - WCAG 3 may recreate EN which would make making the next version of EN easy :)
… with closed systems, you have to involve hardware; and it is still missing cognitive aspects, so we need to look what else we are taking on to serve people's needs
Wilco: agree with Gregg need to break this down and do it incrementally
<maryjom> +1 to Gregg and Wilco
<GreggVan> +1 to making it easier to adapt WCAG3 to non-web -- but don't try to actually do it
alastairc: There os a difference between taking everything on and being technology neutral- the WCAG2ICT work is helpful for that - we should orient around what digital interfaces people working with platforms create - that gives us our scope. so it would be bigger, but not include the hardware part
Rachael: original structure was the requirement and then tech-specific methods. So if we want to include things like kiosks we could say on a high level things like images need alternatives, but that does not need to flesh it out for all technologies. we could focus on some core ones first and then write additional methods / techniques for other
environments later. It still has an impact on phrasing the guidelines to make it flexible enough to be used that way
alastairc: 2 aspect: review if top-level req work across platforms, 2. what should we start with, like web /native XR
… XR would be something that would push the requirements, ensure that requirements are future-proof
<Zakim> GreggVan, you wanted to sat All of the above if they are done over the web using web technologies. As soon as you move off the web -- all sorts of things need to be added and considered. It will add years to WCAG3 completion. maybe get WCAG3 out the door and as tech neutral as possible -- and then come out with ACAG that covers all technology
GreggVan: Moving beyond web focus to all technology would take years, should come later
<Zakim> bbailey, you wanted to ask why drop PDF and word processing docs ?
alastairc: EN 301 459 has been through that process - builds exceptions, application cases etc, but could we not take a leaf from that
bbailey: question why PDF is dropped from the list (?)
alastairc: The original GitHub missed it because the application of req to web and documents were reasonably similar
GreggVan: can be changed to "anything that can be rendered in modern web browsers" that should be out scope - what id downloaded installed outside the UA, should be out of scope
our scope not out scope (avboce)
GreggVan: you cannot get into closed functionality you automatically get into hardware, telecommunications etc.
<Zakim> joryc, you wanted to say the web is more than HTML-based UI, for examples shouldn't CLI's follow a11y best practices?
GreggVan: would need bigger team, other competencies, will add a lot of time - look at EN 301 549 to get an idea how complex it gets
<Jon_Avila> Web includes WebGL, Canvas, SVG, MathML, WebXR, etc.
joryc: Limiting scope to web would defeat the purpose of the new standard - what we need to look at is communicating digital content and the principles behind it - hardware is easy to scope out.
… if we consider all artifacts of the web, new UA, all these things are going to matter - limiting things to web-based narrows it down too much - the should focus on digital communications
<joryc> I include things transmitted using web protocols when I say web.
<alastairc> hmm, ok, I think of web as http(s) and rendering in a browser.
Rachael: Read through EN many other standards - I see nothing that pushes us into the hardware aspects, I do nit see that at all. There are things that we don't want to cover, like emergency comms. Mut many things an be tackled with exceptions. Start with web, but give us the scope to move forward.
<joryc> ftp is a web technology for example
<joryc> HTTP is not the only web protocol. This is well established
GreggVan: never said we are limited to HTML - web includes PDF - internet is. much broader, like IoT.
… I was talking about "anythings that works on the web"
… software will include open and closed software - may not be open to AT but may include its own AT
<joryc> How does that software get the Data Greg?
GreggVan: if you have closed software we get into building AT-like functions into software, require headphones etc.
… with closed systems you cannot get there without including hardware aspects
<kirkwood_> Open standard.
<JJ> If I build a native mobile app, I don't have to worry about the hardware, just like when I create a website. Just like the web, the platform has APIs to deal with hardware. I don't see why WCAG would need to cover hardware.
GreggVan: we should write WCAG 3 for web, get it out, and then tackle the second half afterwards - we all want to get WCAG out soon - the way to do that is not to double your workload - too much to bite off
<joryc> The audio got to the device with http...
<Charles> there is a ‘user interface’ at each level: device; operating system; software; content.
Jon_Avila: if we cover text and audio in closed functionality - EN had to make compromises to adjust them towards speech output, so some were rewritten to apply. We can't do it at the top level because we would lose some people who require programmatic access
<JJ> The web browser itself is a native application.
alastairc: still nit seeing an automatic movement from including applicability of native software to having to take on hardware - we do it today in native mobile testing - there may be a route where you have methods and tests for those technologies
<Zakim> joryc, you wanted to explain that technologies that would be characterized as "web" are behind almost anything where data is going back and forth between non-local systems
<Jon_Avila> I agree how we think about browsers will dramatically change soon.
joryc: When talking about web I talk about moving information across technologies - a browser may nit be involved in web technologies - this is mite expansive than just the web and the browser. Browsers will become very different and may not exist for many users soon - so we donÄ#t want to miss this tech changes
kirkwood_: When we talk about access to information in low band-width zones we can show that there is design that works for those people this is also what the web is about
GreggVan: We might have guidelines for web content AND software that is open to AT - so that would exclude closed software but still goes beyond the web.
Getting into closed software is harder because AT won't work there because that is the def of closed
alastairc: have more of that discussion in the future
<Jon_Avila> Thank you.