TPAC 2026: Our key takeaways

How will artificial intelligence (AI) change accessibility testing? Can existing testing methods work for native mobile apps? And will future accessibility guidelines properly address mobile technologies? These were some of the questions we explored during the World Wide Web Consortium (W3C) TPAC 2026 conference in Dublin.

From 26 to 29 October 2026, we, Jan Jaap de Groot and Tanya van Workum, represented Abra at TPAC.

We joined sessions of the Accessibility Guidelines Working Group (AGWG), the Accessibility Conformance Testing (ACT) Task Force, and several break-out discussions about AI. We also hosted a meeting of the Mobile Accessibility Task Force (MATF).

Four days, many discussions, and several concrete next steps. Here are our key takeaways.

1. AI and accessibility testing: three open questions

AI was one of the most interesting topics during TPAC. The discussions raised three important questions.

First: Can AI agents evaluate accessibility?

Rule-based tools check what is explicitly defined. AI agents could potentially go further: evaluate whether an accessible name describes what a button does, or whether instructions are clear. These evaluations have traditionally required human judgement.

But how reliable are the findings? Different models may evaluate the same screen and reach different conclusions. And a tool should not present an assumption as a verified accessibility failure.

The challenge is finding ways to benefit from AI-assisted evaluations while maintaining reliable, explainable results.

Secondly: Should accessibility standards be written for AI agents too?

Accessibility standards are written for people, but AI agents increasingly consume and interpret them too.

During the ACT meeting, we discussed whether standards should also be structured for AI consumption. If agents independently interpret complex requirements, their evaluations may vary depending on the model, context and information available. The same accessibility requirement could lead to different conclusions.

The declarative structure of ACT Rules describes what to test, when a rule applies and what outcomes are expected.

The question is whether AI agents are likely to interpret ACT Rules directly.

Could making accessibility requirements more structured and machine-readable help AI agents interpret them more consistently, reducing ambiguity and unpredictable evaluation results? And is this something the working group should address, or should its focus remain on guidelines written for humans, using a declarative approach?

Thirdly: How do we evaluate AI-built testing tools?

AI agents could also use structured ACT Rules to build accessibility testing tools themselves, translating requirements into automated checks. Developing a reliable accessibility testing engine traditionally requires extensive expertise and years of work. AI now makes it possible to create automated accessibility testing tools without any accessibility knowledge or expertise. However, implementing rules without fully understanding their context, exceptions and edge cases will most certainly lead to incorrect results.

Two AI-built tools might evaluate the same application and report different findings. How do we know which one is right?

ACT Rules could provide a reference for validation. They include passed, failed and inapplicable test cases that implementations can use to verify their results. The group discussed whether additional examples might be needed to properly stress-test AI-generated implementations.

Our takeaway? AI has real potential, but accessibility testing must remain transparent, reproducible and backed by evidence.

2. Can mobile rules be added to ACT?

ACT Rules are primarily written for the web. There are no established ACT Rules specifically for native mobile apps yet.

Unlike the web, native iOS and Android apps rely on different accessibility APIs, with additional complexity introduced by development frameworks. Some information may not be available through the accessibility layer, raising questions about how consistent, testable rules can be defined across platforms.

The discussion opened up the possibility of a pilot to explore, using a few initial mobile accessibility rules, what would be needed to apply the ACT methodology to native mobile apps.

3. Mobile Accessibility Task Force: presenting the responsibility layers model

During the MATF meeting, which we hosted, we presented the second draft of WCAG2Mobile. This guidance explains how WCAG 2.2 applies to mobile applications. It is informative and does not introduce additional requirements.

We also presented our responsibility model. An app's accessibility depends on several layers: the operating system, development framework, application and content. Not every layer is under the developer's control.

Take a toggle. A native toggle may expose its role and state automatically. But what if the native component itself is not fully accessible? And if a team rebuilds the toggle in Flutter, does the same exception apply?

This is where we found an interesting overlap with the Authoring Tool Accessibility Guidelines (ATAG) community.

Frameworks such as React Native and Flutter influence what ultimately appears in the accessibility layer. Could these frameworks be considered authoring tools under ATAG? And could the ATAG approach help clarify responsibility for accessibility features provided by frameworks?

4. WCAG 3: broader coverage, but what about mobile apps?

WCAG 3 aims to be more technology-neutral, cover a broader range of accessibility needs and provide clearer, less ambiguous requirements. While the guidelines remain focused on web content, the approach could make them more applicable to other technologies.

There is still a lot of work ahead. The document is undergoing significant restructuring, with ongoing discussions about conformance, testability and accessibility support.

But what does this mean for the mobile apps?

One important takeaway is that the Mobile Accessibility Task Force needs to be more closely involved in the development of WCAG 3. Rather than reviewing requirements after they have been written, MATF should contribute its mobile accessibility expertise throughout the development process, so that mobile-specific considerations can be addressed from the beginning.

What we take home

• AI and accessibility testing: AI creates new possibilities for evaluating accessibility and building testing tools, but reliability, transparency and consistent interpretation of standards remain open challenges.

• ACT Rules for native mobile apps: A potential pilot could help establish what is needed to develop consistent testing rules across iOS and Android.

• Mobile Accessibility Task Force: The responsibility layers model raises important questions about the roles of operating systems, frameworks and app developers, including possible connections with ATAG.

• WCAG 3: Closer involvement from MATF could have a positive impact on the development of WCAG 3 by ensuring that mobile accessibility considerations are addressed from the beginning.

Participating in TPAC gave us valuable insights into the direction of accessibility standards and testing methodologies, as well as opportunities to contribute to ongoing discussions.

Want to learn more about the work of the W3C groups? Read the MATF meeting minutes, the ACT meeting minutes and the WCAG2Mobile draft.

We'd love to see more mobile accessibility experts involved! Visit the Mobile Accessibility Task Force page to learn about the group's work and find its contacts. Reach out to the facilitators to ask how you can participate.