Meeting minutes
<janina> /join #rqtf
Agenda Review & Announcements
<Dylan> MSF XR Accessibility Guidelines v1.0 - https://
<Dylan> dylan@drfoxdesign.com
Dylan shared new XR accessibility guidelines from the Metaverse Standards Forum and asked this group for feedback.
The response was that this work likely fits best with the Research Questions Task Force, which is already doing a gaming gap analysis. The next discussion on that is planned for August 4.
Dylan said they are collecting input through comments on the Google Doc and a Google feedback form. The feedback form should be linked at the top of the document. They mentioned July 31 as the target date, but said feedback after that will still be used.
TPAC 2026
<Dylan> You can contact all three of the chairs (myself, James Maki, and Michael Cooper) at accessibility-chair@lists.metaverse-standards.org
<matatk> Support fund: https://
<matatk> Why come to TPAC? https://
matatk - said there was not much new versus last week. reposted the links already in the agenda, including the support fund information. there are two different support funds, and which one to use depends on eligibility. Why come to TPAC blog post, describing last year’s trip, what people got involved in, and how the meetings work.
Janina - strongly backed going to TPAC. She said it is W3C’s annual meeting and that APA gets a lot of its work done there. Her point was that attending is especially valuable for the group’s planning and progress.
matatk - July 31, 2026, closing at midnight UTC - They suggested submitting by **July 30** just to be safe
New charters review
<Fazio> I may invite a colleague from University of Galway to present on our Neurodiversity Soft Skills work
<matatk> WebAppSec WG Charter (APA thread): w3c/
New on TR
<janina> zzakim, close this item
WebMCP - should it be adopted as W3C work? (Continued from last week.)
Matatk said WebMCP is a proposal for websites to describe what they can do in a way that browser-based agents could understand and use directly, instead of relying on simulated clicks, typing, visual analysis, or digging through the accessibility tree.
Matatk - question was whether this WebMCP protocol should become an official deliverable in the Web Machine Learning group’s charter, and what the accessibility implications of that would be.
Matatk said they seem open to experimenting with WebMCP, but there are still real privacy and accessibility concerns that the group needs to think through before deciding how to respond.
<matatk> Initial draft of proposed APA comment: w3c/
Matatk said his proposed comment is that the accessibility tree should not carry WebMCP-style agent information because it serves a different purpose, and even if people disagree on that, it is still too risky to mix in because it could be abused and pollute the accessibility tree.
Matatk said the group should review and edit his draft comment on the accessibility-tree question this week so he can post an APA response by the end of the week, and then next week they can discuss the bigger question of whether WebMCP itself is a good protocol.
PaulG said his main questions are whether agent-facing forms are real visible forms or hidden agent-only ones that could clutter the accessibility tree, and whether JavaScript-exposed capabilities given to agents are also available and explained to assistive technology users so people know an agent could unlock extra features.
aulG got more specific about where the real concerns might be: he said WebMCP currently seems to expose functionality in two main ways, through normal HTML forms and through JavaScript or the page’s document model; for forms, he said the group should clarify whether these are standard visible forms that people can also use, or hidden forms added
mainly for agents, because hidden agent-only forms could create noise or clutter in the accessibility tree; for the JavaScript side, he asked whether the capabilities being exposed to agents are also available to everyone else, and whether users of assistive technology would be told that these extra capabilities exist and may require turning on an
agent to access them, especially since people may not want agents enabled all the time for privacy or security reasons.
PaulG got more specific about where the real concerns might be: he said WebMCP currently seems to expose functionality in two main ways, through normal HTML forms and through JavaScript or the page’s document model; for forms, he said the group should clarify whether these are standard visible forms that people can also use, or hidden forms added
mainly for agents, because hidden agent-only forms could create noise or clutter in the accessibility tree; for the JavaScript side, he asked whether the capabilities being exposed to agents are also available to everyone else, and whether users of assistive technology would be told that these extra capabilities exist and may require turning on an
agent to access them, especially since people may not want agents enabled all the time for privacy or security reasons.
Matatk said Paul’s questions should probably be added into the draft comment, since they fit with the group’s concerns and may also connect to the broader issue of whether WebMCP is the right approach and whether content should differ for humans versus agents.
<matatk> Web and AI IG meeting: https://
janina group should try to reach consensus soon because there is a Web and AI meeting next Tuesday that APA and RQTF are invited to, where Matatk plans to walk through key accessibility and AI concerns and share a draft agenda later this week.
Janina clarified that the urgency is because the Web and AI meeting is on Tuesday, so they want to sort out their WebMCP position before then.
Fazio asked whether putting WebMCP information into the accessibility tree might make overlays and similar tools more genuinely useful for accessibility instead of just being superficial widgets.
Janina replied that agents may still benefit from hints, but the accessibility tree should stay focused on representing the user interface and should not be mixed with internal agent data, because that would blur two different purposes and create too much risk.
Matatk agreed with the idea that agent-driven adaptive interfaces are promising, but said the current WebMCP proposal seems to focus more on higher-level, agent-oriented instructions than on the kind of structured semantic details that would directly support robust accessibility adaptations, so putting it into the accessibility tree would risk
misuse, such as stuffing ARIA with text meant for agents rather than assistive technologies.
Fazio said he would like to see a side-by-side comparison of what WebMCP supporters think agents would gain from using the accessibility tree versus what accessibility people think could be harmed or corrupted by doing that.
Janina said they should not try to work out that full pros-and-cons comparison live in the meeting, but instead do it separately in a parallel structure so the group can think it through more carefully.
<janina> kq?
Spec review requests
Matatk said the group is running short on time and may need a small team to triage and do lighter spec reviews so they can work through the backlog, including heavier items like Open UI that still need input.
ARIA 1.3 review update
<matatk> w3c/
<matatk> Core part seems to be: w3c/
Matatk said the ARIA 1.3 review update is that they got a reply to their earlier questions, the typo issue was confirmed and can be dropped, ARIA Notify will get a better introduction before CR, and the main thing left for the group to assess is whether the rationale for the new section header and section footer roles is strong enough.
Matatk said their earlier feedback on ARIA 1.3 had three parts: first, they had asked why the new section header and section footer roles were needed, especially since they are not landmark roles; second, they had pointed out what looked like a typo in the naming of one of those roles; and third, they had said the spec did not clearly explain when
or why someone should use ARIA Notify instead of other options; he then reported that Daniel Montalvo from the ARIA side replied that the group had linked back to the issue and discussion where the header and footer roles were originally justified, so APA now needs to review that rationale and decide if it is convincing, the typo was confirmed so
that concern can be removed, and Daniel opened an issue to add a better introduction to ARIA Notify before the spec moves to Candidate Recommendation, which Matatk seemed comfortable trusting them to do.
<matatk> Also PR for sectionheader and sectionfooter: w3c/
PaulG said the linked issue is confusing because it starts more broadly, but his reading is that this came from revisiting an older discussion about header and footer roles and then deciding to add new section header and section footer semantics into the accessibility mapping.
PaulG said the current proposal seems to map the new section header and section footer roles as specialized group roles in accessibility APIs, using header or footer as subroles under a general group role.
Matatk said he still does not understand the real use case for these roles and questioned how assistive technology users would benefit if section header and section footer are not landmark roles.