TPAC 2026 calendar - Breakout Sessions

At last year's TPAC breakout on Semantics for the Agentic Web, we asked whether the web needs a semantic layer for AI agents alongside ARIA for assistive technologies. Since then, that question has turned into a real problem on live sites. Several browser agents now tell web developers to add aria-label and aria-description attributes to buttons, links, and inputs so agents can tell what a page does. Because ARIA overrides visible text and feeds straight into screen readers, stuffing prompts and agent instructions into accessibility attributes breaks the experience for screen reader users.

At the same time, browser engines and web developers are debating how much of the agentic web should rely on existing HTML "as it is spoken" versus new declarative markup or imperative tool APIs like WebMCP. Many web interactions are simple, stateless actions where writing a JavaScript tool handler is overkill, but standard HTML and existing structured data don't always make it obvious what a control does or whether an agent is safe to trigger it.

Alongside related sessions on AI-friendly webpages, declarative and imperative solutions, and extending WebMCP, this session gets the accessibility, HTML, structured data, and WebML communities in the same room to talk through concrete markup trade-offs:

• Keeping ARIA for accessibility: Why are agent builders telling developers to overload aria-label when semantic HTML elements and forms already exist? Can better browser heuristics on standard HTML solve this, or do developers need a simple way to describe controls for agents without breaking screen readers?
• Standard HTML and Schema.org vs. new attributes vs. imperative tools: For everyday page actions like search, filtering, and cart updates, how far can standard HTML forms, Schema.org Microdata, and JSON-LD get us? Where is the clean handoff between declarative markup in the DOM and registering JavaScript tools via navigator.modelContext.registerTool?
• Safety hints and human-only controls: Should HTML have a declarative way to mark the risk of an action, like separating read-only navigation from actions that change state, spend money, or always require a human click? And since careless or malicious sites can mislabel controls, how should browsers and agents treat safety hints from a site?
• Working with existing browser signals: How should agent semantics fit with features browsers already have, like form autofill, password managers, and login status APIs, so developers don't have to describe the same flow three times?

Goal(s):
Work out how far standard HTML and existing structured data can go for everyday agent actions, how to keep agent instructions out of ARIA, and where declarative HTML hands off to imperative APIs like WebMCP.

PACT is a shared effort to develop a privacy preserving protocol which can enable user-agents to bypass CAPTCHAs and block pages, without compromising either user privacy or the effectiveness of sites' anti-abuse tooling.

In this session we'll talk through the problem PACT is trying to solve, the proposed solution, and seek feedback on the approach from the community.

Goal(s):
Share perspectives and concerns about PACT

Cybernetic Avatars (CAs) are technologies that extend human capabilities through remote, robotic, and digital embodiments, enabling people to interact with other people and environments beyond physical constraints.

Following the introductory discussion from our previous TPAC breakout session, this session will provide a brief recap of the Cybernetic Avatar concept and share updates on our recent activities, use cases, and validation efforts.

In particular, we would like to explore the possibilities for implementing and supporting Cybernetic Avatar interactions through Web technologies and browser-based environments. Based on our current use cases, we will discuss potential technical requirements, challenges, and opportunities for enabling Cybernetic Avatar systems to interact through the Web.

The session is intended to be an open discussion with the community, and we welcome perspectives on relevant Web technologies, APIs, architectures, security, accessibility, and other considerations that may contribute to future Cybernetic Avatar implementations.

Additional Chair: Masaaki Sato

Goal(s):
Discuss Cybernetic Avatars and their possibilities on the Web.

Last year we presented declarative partial updates - new HTML/JS ways to update the document.
We see an opportunity to extend it in various ways, and would like to discuss with a wider audience!

Specifically:

• allow fetching the update from an external URL <template src>
• Built-in sanitization <template sanitize>
• Control whether the update buffers or streams <template buffer>

Goal(s):
Get feedback from a wider audience for the new directions

This session will center on the paper "Who Shapes Web Standards? Uncovering the Main Topics of Interest in the W3C". The paper investigates the main areas of interest of organizations participating in W3C by applying topic modeling to publicly available data on member organizations' participation in W3C groups, using the number of representatives assigned to each group as a proxy for organizational priorities.

The analysis identifies five major areas of focus: Browser, Ads & Privacy; High Performance; Credentials & Web of Things; Accessibility; and Payments. It also shows that large enterprises, particularly those based in the United States, dominate participation in browser development and advertising-related work, while Japanese organizations are more strongly represented in Web of Things activities.

The session will begin with a presentation by the paper's lead author, followed by an open discussion with the audience. In addition to examining the methodology and key findings, participants will compare the results with the firsthand experiences as W3C contributors, providing valuable context for interpreting the analysis and fostering a deeper understanding of the dynamics that shape the development of Web standards.

Goal(s):
The goal of the session is to discuss the findings of the research on W3C while fostering an exchange of perspectives between the researchers and W3C contributors.

ARIA-AT is the test suite for testing browser features in screen-reader settings. This is an important testing initiative happening at the W3C for the advancement of an inclusive and accessible web. This session will delve into how ARIA-AT works, what makes it different from WPT, Test 262, ACT and others, how tests are constructed and run, and more.

We'd love to encourage those who are involved in accessibility work, testing and support infrastructures (e.g. BCD, WPT, Baseline), and those generally interested in how we can test browser features against screen-readers.

Goal(s):
Learn more about ARIA-AT

The Social Web Community Group has been working on end-to-end encrypted (E2EE) messaging in ActivityPub for more than 2 years. The E2EE Task Force has developed a community group report, MLS over ActivityPub, with two interoperable implementations. In this sessions, we'll go over the E2EE work in SWICG and discuss next steps.

Goal(s):
Share information about E2EE messaging in ActivityPub and collect feedback for next steps

This breakout will continue the discussion on agentic commerce for the Web we already started with our session at the W3C/GS1 Workshop on E-Commerce for Humans and Agents, which was followed by a productive breakout. There, workshop organizer Philippe le Hégaret suggested that we bring the ideas to TPAC to inform and receive feedback from the pertinent W3C working groups and communities, particularly in light of our work to standardize the underlying data structures and protocols at the IETF.

We want to frame the discussion around agentic commerce rather than e-commerce for agents: letting agents transact through the same Websites, payment rails, and brands their human principals already use, rather than a separate, agent-only surface that humans must configure in advance. We will discuss KYAPay, which uses a signed JWT that carries verified agent and human identity (KYA) and payment credentials (PAY) so that the security infrastructure already guarding merchant websites can tell legitimate, human-authorized agents apart from malicious bots, and so agents can pay across cards, stablecoins, and (in future) banks. We have submitted it to the IETF OAuth working group, and it is already in production with a growing consortium including Experian, Akamai, F5, Fastly, Forter, Imperva, Cequence, and Auth0, among many others (see kyapay.org).

Our main points will be:

Agents must be able to use the web ubiquitously, like their human principals. If humans must "set up" agent access in advance for each site, we are back to the workflow automation that already exists, and we lose the probabilistic discovery and serendipity that agents and LLMs bring. This is why the goal should be agentic commerce on the existing web, not a parallel agent-only surface that fragments the ecosystem and recreates that setup friction.

This is achievable now. A browser-use agent can already navigate, browse, and check out on a website with just a few prompts. Coupled with verified access via KYAPay, which removes the complexity of bot evasion, we see near 100% checkout rates.

KYAPay gives every layer of defense one source of truth. Bot managers, fraud managers, account-takeover protectors, and CIAM solutions operate at the application layer. Today each makes its call in isolation, so their verdicts on the same request can contradict one another. A single KYAPay token lets all of them use the same verified identity and fraud signals, so their decisions are more likely to be consistent than conflicting.

Layered, extensible identity gives security infrastructure precise anchors. KYAPay's identity tiers distinguish the human principal, the agent platform/operator, and the agent instance, letting vendors block a single principal or agent instance rather than banning an entire platform over one bad actor.

KYAPay complements OAuth. Our KYA↔OAuth token exchange work with Okta and Ory lets agents log in on behalf of their human principals, opening up loyalty, offers, and other logged-in experiences merchants already offer humans. The protocol works today, and the JWT approach interoperates with the APIs and agent-to-agent communication of tomorrow.

Idea for discussion: Merchants can use KYAPay signals to style their existing pages for agents. Just as a "print" button uses CSS to restyle a page for printing, a merchant that receives a KYAPay token can restyle its existing page for the agent. This reuses technology merchants have already mastered, keeps interface ownership and brand with them (avoiding the disintermediation they fear), preserves the fraud and good/bad-actor signals their models are built around, and lets them optimize and iterate with familiar tools like A/B testing rather than carefully managed API-schema changes.

Goal(s):
We would like to collaborate and whiteboard actual end-to-end workflows that we collectively believe will work for all. As a stretch goal, I would like to identify partners who want to prototype and/or help refine and standardize these capabilities.

Development of WebVMT in the OGC Testbed programme has identified new requirements for static video metadata and dynamic timed data on the web with guidance from SDW WG, MEIG and WICG DataCue. Scope has widened from a focus on location to include timed data of any type in any format, including binary, and fixed video metadata.

HTML cue (TextTrackCue) design has been progressively adapted to support these enhancements, but the latest proposals require significant changes to either modify the existing timed text scheduler (TextTrack) or propose an alternative scheduler that meets the new requirements identified for handling timed data.

Goal(s):
Identify missing requirements for video metadata and timed data on the web from the wider community, and how best to integrate these requirements with HTML.

I would love to invite the Solid CG and the Social Web CG developing Solid and ActivityPub to share the progress we have been making on open-world federations (federations where any identity providers can join without redeploying relying parties, as opposed to closed-world federations where relying parties enumerate identity providers ahead of time) with (a) Email Verification and (b) the Atproto community.

• Email Verification
  • https://developer.chrome.com/docs/identity/email-verification
  • https://github.com/WICG/email-verification
  • https://dickhardt.github.io/email-verification/draft-hardt-email-verification.html
• Handle Verification
  • https://atproto.com/blog/working-to-decentralize-fedcm
  • https://bsky.app/profile/did:plc:thaoj4hhvraos7y6v3yog7re/post/3mui4mejurc2x
  • https://github.com/w3c-fedid/idp-registration

Much of this is still very early and malleable, so am hoping to have an open discussion:

• How, if at all, is Solid and ActivityPub similar to email/handle verification?
• How are they different?
• Where are things at with Solid/ActivityPub?
• Where are things at with FedCM and cross-browser implementation? Can extensions play a big role?

Goal(s):
Share and exchange information, interest and requirements

There are many ways that agents interface with web content. Each browser engine is currently taking slightly different approaches, but there's a lot of common ground/overlap too. For agents, in coordination with browsers, to interface with the long tail of content, they will naturally need to deal with the messy HTML "as it is spoken" by the majority of the web. At the same time, alternative imperative approaches have been proposed, but those could cause further fragmentation, negatively impact accessibility, pose new privacy and security risks, and entirely exclude people who don't want to, or can't, use AI agents in the browsers.

There are limitations and concerns about each approach, so it would be good to tease those out during this session to come to a shared understanding.

Goal(s):
Explore the pros and cons of different approaches. Find a path forward to standardization.

Ecma's TC39 has been developing AsyncContext for a few years now: it's a new JS API that allows implicit propagation of some JavaScript values across asynchronous code. One if its main motivating use cases is being able to gather telemetry data in frontend applications, similarly to how it's already possible in Node.js and in many other programming languages.

There are a few other web specifications that are already exploring to build on top of AsyncContext: what other features would AsyncContext be an useful building block for? Should the web platform expose some information natively that is propagated through async JS code? Does the proposal meet your needs as it is, or what do we need to change?

Possible co-chair TBD: @mmocny

Goal(s):
Make sure that we are considering everybody's needs in the design of the AsyncContext specification, and help spec authors figure out how to integrate with it.

Users of the web are best served by being able to experience it in their native languages. Currently, localization of web content is achieved with a multitude of custom solutions, most of which are unable to express the full depth and breadth of human expressions in all languages. Introducing an easy-to-use but powerful standard localization solution would improve the experience of all users, in particular the vast majority who do not speak English natively.

During the past year, DOM Localization has been accepted as a Stage 1 WHATWG proposal, and Message Resources (the definition of the underlying file format) has been accepted for incubation by the W3C Internationalization WG.

This work has been previous discussed at breakout sessions at past TPACs (2023, 2025), and it builds on Unicode MessageFormat, now a part of Unicode's UTS 35 standard.

Goal(s):
Collect comments on the proposals and recruit interests to work on the standards.

This breakout session will explore the feasibility of giving users control over computation placement of the AI models running in the browser. We will analyse the current friction points where web features clash with user privacy settings.

We will propose a lightweight experiment: could a shared vocabulary of locations (an "enum" of places) be the missing link that makes it technically viable for User Agents to enforce user preferences without breaking existing web features?

We will also look at risks to the approach, and how we might avoid a "Do Not Track 2.0" scenario - why a purely opt-in signal failed, contrasting it with the potential of an enforceable mechanism.

Chairs: Matthew Atkinson (Samsung Electronics,@matatk), Muadh Al Kalbani (Samsung Electronics, @m-alkalbani), Ehsan Toreini (Samsung Electronics,@toreini)

Goal(s):
Discuss the problem and solution space around where models may run, proposing the shared vocabulary approach as one avenue to explore - supporting User Agents to ensure that the user has control over this aspect of their privacy.

Over the past year, W3C has been increasing its efforts in policy engagement, with the goal of supporting policy outcomes for "making the web work, for everyone." Most of our focus has been on communication and coordination, e.g., to serve as a reputable source of technical information for policy development. We'd like to ensure that our efforts in this arena are effective, and wanted to take time at TPAC to learn what we could try in the upcoming year(s) for better policy engagement. We'd love ideas from community members with experience and/or interest in policy, and would really appreciate diverse perspectives from different stakeholders to inform our work.

Goal(s):
Help shape W3C's policy engagement work in 2027 (and beyond)

Web standards work is good at gathering feedback on features that already exist or solutions that have been proposed. It is much harder to learn what developers need before anyone writes a proposal, e.g., the gaps that lead to heavy workarounds, inaccessible components, and large libraries.
There have been efforts to address this. The Web We Want (2019 to 2024) collected developer ‘wants’, but struggled with having an owner to triage and with getting ideas to people who could act on them. Similarly, WICG gives people a place to incubate proposals, but still requires a lot of standards knowledge to participate.
In recent interviews with authors of frameworks and libraries, even experienced standards advocates told us that they don’t know where to raise unmet needs. In this session, we would like to explore what has and hasn’t worked and design a lightweight way to surface developer needs earlier and route them to the group that can act on them.

Goal(s):
Agree on a vendor-agnostic lightweight way to surface developer needs before proposals exist, who triages them, and how they reach the groups that can act on them.

TODO(goto): fill this up

Goal(s):
TODO

How can we make threat modeling practical for specification developers?

In this hands-on session, we'll use some W3C specifications to demonstrate how to build a lightweight threat model, identify threats and responses, and determine when the analysis is sufficiently complete.

We'll then show how to turn the findings, including assumptions and remaining threats, into useful Security Considerations sections, without making the process unnecessarily complex.

Note: Additional chairs to be confirmed.

Goal(s):
Demonstrate a simple, repeatable approach to threat modeling and writing Security Considerations, and gather feedback from specification editors.

Join the Chrome and Firefox teams to see recent advancements in the Web Speech API over the past year. With the specification transitioning to the W3C Recommendation track under the proposed 2026-2028 Audio Working Group Charter and both Chrome and Firefox Nightly now supporting on-device speech recognition, web-based speech interaction is entering a new era of privacy, low latency, and cross-browser interoperability.

Goal(s):
Demonstrate multi-engine on-device speech recognition and newly added capabilities, and gather cross-WG feedback on multilingual recognition, speaker diarization, audio timing, and faster-than-realtime transcription.

XML is still widely used and will continue to be so for many years. There is interest within the user community both in continuing the development of existing standards (XPath, XSLT, etc.) and creating new ones (Invisible XML, XProc, etc.). There are several community groups engaged in XML-related activities along these lines (e.g., XSLT and XQuery Extensions, XProc, and Invisible XML). Community Groups enable incubation, but in some cases this is growing interest in standardization. With the XML Activity closed, where and how and should XML-related community groups transition to Working Groups when they begin to design interoperable standards?

Goal(s):
Gauge support in the W3C community for creating a Working Group for new XML standardization activities.

The OpenUI Community Group would like to present on upcoming features, specifically to talk about their impact on accessibility, we'd also like to invite the ARIA Working Group to attend and provide feedback.

See https://github.com/openui/open-ui/issues/1510 for more.

• ARIA chairs: @jnurthen, @spectranaut
• Open UI chairs: @gregwhitworth, @keithamus, @mfreed7

Goal(s):
Highlight OpenUI work and discuss the impact to ARIA

Presentational case mapping (capitalization and title casing) continues to be among the most-requested features in ECMA-402 (https://github.com/tc39/ecma402/issues/294). However, since we currently offer no utility for this, developers are left with i18n-unfriendly workarounds like str[0].toUpperCase() + str.slice(1).

Two related but distinct problems in this space:

• Word and sentence capitalization transforms: CSS provides text-transform: capitalize, which titlecases the start of every word while leaving trailing characters unchanged. However, there is no CSS transform for sentence casing (w3c/csswg-drafts#8893) or editorial title casing (w3c/csswg-drafts#12526), and JavaScript currently has no titlecase mapping primitive at all (tc39/ecma402#294). Naive JS workarounds fail on scripts where uppercase and titlecase differ (such as Georgian Mtavruli vs. Mkhedruli), digraphs like Dutch IJ (IJsselmeer), and leading punctuation.
• Contextual capitalization of localized strings: CLDR stores display names, month names, and weekday names in middle-of-sentence casing, alongside <contextTransforms> data for standalone and UI menu contexts. Because Intl formatters do not yet expose DisplayContext (tc39/ecma402#355), calling Intl.DisplayNames or Intl.DateTimeFormat to populate a UI menu or header produces lowercase strings in dozens of locales (e.g., español de España, français, janvier), and applying CSS text-transform: capitalize produces incorrect results on multi-word names (Español De España).

When TC39-TG2 discussed https://github.com/tc39/ecma402/issues/294, implementers suggested that although there are use cases for this data in JS, we should coordinate with CSS WG and W3C i18n on a holistic design rather than designing JS and CSS features in isolation.

In this session, I would like to bring together those groups, with a focus on CSS, W3C i18n, and TC39-TG2, to align on terminology, use cases, and where each layer of the platform should provide building blocks versus high-level solutions.

Goal(s):
Align across CSS, W3C i18n, and TC39-TG2 on a cohesive Web Platform strategy for capitalization, sentence/title casing, and contextual display transforms.

WebMCP enables collaborative workflows in which users and agents work within the same web interface. This session will (1) identify challenges encountered in implementing and using WebMCP tools, and (2) explore how the same set of WebMCP tools can be reused across collaborative and autonomous browsing tasks ranging from simple requests to complex, multi-step workflows.

We will present selected results from prior work on generating web tools, integrating web tools into web agents, and evaluating their effectiveness. These results highlight how tool design and tool-definition exposure can affect task success and token usage, and motivate further discussion of tool granularity, tool composition, and improvements to the WebMCP interface. We will also discuss how WebMCP can support web tool execution that interleaves deterministic steps with agentic steps that may use an LLM internally or draw on the user’s own agent for LLM-dependent reasoning.

The central design question is how core WebMCP capabilities can ensure generality, interoperability, and ease of use, while optional WebMCP capabilities provide well-defined support for different tool granularities, execution patterns, and forms of tool–agent interaction.

We propose to discuss the following topics:

Tool granularity and selection. Fine-grained, single-function tools can serve small, focused user requests and be reused across workflows. Larger tools can encapsulate workflows and reduce repeated agent decisions. Both large inventories of small tools and numerous workflow-specific variants can increase context and selection costs. How should tool definitions convey functional scope, expected effects, relationships to other tools, and any agentic steps, so that an agent can choose the appropriate granularity for a request?

Dependent tool composition. How can an agent plan multiple tool calls in one decision, using actual return values from earlier calls as input arguments for later calls without an intervening LLM call? What support is needed for discoverable output schemas, references to return values, input binding, and validation? How should execution respond to errors, cancellation, navigation, or changes in registered tools? Which responsibilities belong in WebMCP and which belong in agent-side execution?

Agentic steps using the user's own agent. When a workflow requires LLM-dependent reasoning, how can a tool request reasoning or a decision from the user's own agent that invoked it, and then continue execution? How can that agent apply the original task context and user-provided constraints? What interfaces and lifecycle rules are needed to associate the request with a pending tool execution, suspend and resume execution, and handle cancellation or document unload? How should access to the agent's context and capabilities be mediated?

Selective tool exposure and page observations. How can tool registration and discovery be coordinated with selective inclusion of tool definitions in the model context? How should agents update their information when registered tools change or when user interactions and application updates change the page context? What support is needed from applications, browsers, and agents to keep this information useful while controlling context costs?

Page context and WebMCP's role alongside MCP. How can WebMCP support tools whose availability and execution depend on the current document or live page state, alongside tools with broader application scope? Which page-context and lifecycle capabilities should be optional? How can shared UI, existing client-side application logic, and browser-mediated execution support transitions between collaborative workflows and autonomous task execution? What makes WebMCP useful beyond an MCP-only integration, and how can the two work together?

Goal(s):
Identify and prioritize practical requirements for WebMCP interface capabilities across different tool granularities, composition patterns, and forms of tool–agent interaction.

This is a session held by the TAG to inform potential nominees for the 2026 election cycle what it's like to be a TAG member. It will be an opportunity to ask questions, better understand expectations and work load, learn how we work, and generally get a clearer view of how TAG participation works.

Goal(s):
To understand how the TAG works and answer questions for those interested in running for election

Cross-document navigations ("MPA" style) received a big boost in the last couple of years with cross-document view transitions.

However, this is incomplete! What do we do with the "uncanny valley" time between starting a navigation and the next document being render-blocked?

Brainstorming around multiple ideas in different stages of maturity:

• two-phase view transitions
• imperative deferPageSwap
• Declarative Skeleton UI

Goal(s):
Get a good discussion about trade-offs for different approaches from a broad audience

As a community we are always developing ways to preserve and enhance the user’s privacy. This often focuses on techniques that avoid, or minimize, the amount of user data that go over the wire. Another vector for privacy, particularly in public places, is the visual output from the user’s devices.

Some devices have hardware rendering modes that make it harder for so-called ‘shoulder-surfing’ privacy compromises to occur. We propose a simple spec - essentially an HTML attribute - to flag potentially sensitive content for this rendering mode, so that devices may use it, if they are able to.

This session will demonstrate how such a spec may work, and will be a call for participation in developing the idea further.

Goal(s):
Demonstrate the potential of a simple Privacy Screen spec, and seek participation in the project.

Many W3C groups continue to use IRC for real-time discussion and meeting coordination. IRC has served W3C well, particularly through integrations with tools such as Zakim, RRSAgent and GitHub bots, but there are increasingly questions around whether it remains the best fit for how groups collaborate today.

This isn't a new question, replacing or supplementing IRC has been discussed within W3C for many years (see w3c/modern-tooling#16).

Recent changes have brought the question up again. The CSS Working Group recently lost its publicly searchable IRC logs, prompting discussion about alternatives including IRCv3 and bridging the existing IRC channel to Matrix. Other W3C groups already use Matrix, Slack and other platforms alongside or instead of IRC.

Should we provide a common home?

W3C groups currently use a variety of platforms for real-time collaboration, including IRC, Slack, Discord, Matrix and Zulip. In many cases these have been adopted independently by individual Working Groups, Community Groups or their members, with groups sometimes responsible for arranging hosting, bots, bridges or other infrastructure themselves.

This fragmentation can make participation harder: someone involved in several W3C groups may need accounts and clients across several different platforms, each with different approaches to history, search, access and moderation. It also means individual groups can end up solving the same infrastructure problems independently, or the burden falls on individuals rather than the systems team.

This breakout would be an opportunity to step back from any particular technical solution and discuss what W3C groups actually need from real-time collaboration tooling.

Topics could include:

• Persistent and searchable discussion history
• Accessibility and ease of participation for new contributors
• Integration with existing W3C meeting infrastructure (Zakim, RRSAgent, etc.)
• Public participation versus access control and abuse prevention
• Federation, bridging and interoperability between platforms
• Long-term hosting, maintenance and ownership of collaboration infrastructure
• Experiences from W3C groups already using Matrix, Slack or other tools
• Whether W3C should continue investing in IRC (including IRCv3), support additional platforms, or work towards a longer-term replacement

Ideally, we'd leave the session with a clearer picture of common requirements, what is working well for groups today, and some potential next steps for experimentation or further work.

Goal(s):
clearer picture of common requirements for modern tooling

Originator Profile Collaborative Innovation Partnership (OP-CIP) has been implementing Originator Profile (OP) technology on websites to demonstrate their authenticity and tamper-resistance. The effort is now moving from proof-of-concept to real-world deployment.

In FY2025, 14 media outlets and 2 local governments in Japan took part in our experiment. We also successfully delivered OP-attached ads through an existing ad network and displayed them on live websites.

In this session, we will share what we learned and discuss how these use cases can be extended to other industries and regions.

OP-CIP introduction

OP technology documents

Goal(s):
To help participants understand how OP works in practice within a specific industry (media and public sectors), and to discuss how this deployment can be expanded to other industries and regions.

The Web-based Digital Twins for Smart Cities Interest Group (SCIG) would like to have annual joint discussion on related SDOs about our collaboration towards standards for Web-based Smart Cities as usual.

As the group's Charter describes, SCIG's mission is working on the following:

• identify and document use cases and requirements that W3C specifications need to meet to support various services within Smart Cities,
• obtain feedback from all stakeholders on the usage of Web technologies for those services,
• gather expert input on important features for those services based on the Web technology,
• and provide a forum for technical and business discussions related to those services.

You will learn the current best practices of cutting-edge standards for smart cities around possible framework and vocabulary ontologies, and then see how Web standards could possibly counter the fragmentation of existing smart city approaches.

Goal(s):
Based on the group's Charter, we'll summarize the SCIG's discussion so far, and ask the key stakholders from related SDOs about their standardization acitivies, pain points and current best practices. Then we'll discuss what Web standards possibly could improve the fragmented situation.

Pointer Events Level 3 has just recently gone to stable recommendation. In this session, we'd like to give a short presentation and overview (with live demos) of Pointer Events in general, and what new features have been introduced in the latest version of the specification.

Goal(s):
Provide an overview of Pointer Events and the new features in Level 3

AI Agents acting on the user's behalf risk them being misaligned with user intent and values. For anyone who has used the current generation of AI agents, the alignment problem is very real when it comes to asking an agent to do even simple tasks (i.e., inherent in all AI models is that they actively lie, cheat, deceive, hallucinate, exhibit bias, or worse).

How do we design guardrails into web standards and APIs that can protect users from misaligned AI agents? (i.e., where the user agent itself protects the user from misaligned agent). Though the agents can be helpful, without user intervention there's a real risk of AI systems going "off the rails" and intentionally or unintentionally doing reputable harm.

How can we make sure that we build in checks and balances that AI agents cannot bypass: that we always keep the human in the loop, especially for critical actions?

Goal(s):
Explore the risk of the alignment problem to the web

With AI becoming ever more mainstream, we want to begin the conversation for defining what it means to be AI-friendly (implement WebMCP? Use JsonLD? etc) and whether there are things we might be able to provide for free (lift existing attributes as declarative WebMCP? Use accessibility tree?)

Goal(s):
Continue the conversation from the AI agent workshop around building AI friendly websites and encouraging adoption of AI-friendly standards

ArkWeb is the web engine that powers OpenHarmony. It is a Chromium-derived engine with a distinct feature set, its own release cadence, and a growing set of contributions back to upstream web standards. This session introduces ArkWeb to the wider web community: where it is today, what it adds beyond upstream Chromium, how it is approaching AI-driven browsing, and where it contributes to web standards. We want front-end developers and engine developers to know what ArkWeb is, and to be able to participate in it.

OpenHarmony is an open source project governed under the OpenAtom Foundation, with an ecosystem spanning phones, tablets, wearables, and IoT devices. Its web engine, ArkWeb, is based on Chromium but is developed as a downstream distribution rather than a downstream build: it carries its own platform integration layer, its own security and privacy posture tuned to OpenHarmony's application model, and it ships features that are not yet in upstream Chromium.

That last point is the part most of the web community has not seen. Some of these additions are platform-specific (application lifecycle, system ability integration, distributed device scenarios). Others are closer to the standard web surface and address gaps that the wider community has also identified. We would like to walk through both categories candidly, including where we think a feature belongs in a shared standard rather than in one engine.

The session is deliberately an introduction rather than a working meeting. The goal is for people who build for the web to leave with an accurate mental model of ArkWeb — what it is, what it supports, what it does not — and for engine and standards developers to see concrete places where they could collaborate, test against ArkWeb, or contribute. We are also interested in hearing what the community would need from us: better conformance reporting, participation in WPT, presence in browser compatibility data, or something else.

AI is a specific area where ArkWeb has been exploring actively, and where there is broad interest across browsers right now. We will describe our approach and be explicit about the open questions, rather than presenting it as a solved design.

Goal(s):
Introduce the OpenHarmony ArkWeb engine to the web community, and establish concrete paths for front-end and engine developers to participate in and contribute to it.

We have launched the Content and Originator Authenticity Community Group (COA CG) and would like to start the discussion in person at TPAC. Everyone interested in the topic is welcome, whether or not you have joined the group yet.
https://www.w3.org/community/coa-cg/

The CG's mission is to serve as a hub for a generalized authenticity architecture that fosters a vendor-neutral, decentralized trust model for digital content on the web. It aims to provide technical guarantees for two things: (1) verifiable attestation of originator identity attributes by third parties, and (2) detection of content alteration and tracking of content provenance. The group does not replace or duplicate work in C2PA, CAWG, the OP community, or other existing venues. It focuses on the web-platform layer (URLs, HTTP, HTML, and user agents) where these technologies meet the web and each other. Privacy is a first-class requirement: no mandatory verified identity, and support for selective disclosure and pseudonymous publication.

We plan to launch the new group with three co-chairs, to represent the wider community and ensure impartial leadership.

Who should attend: browser vendors and other user-agent implementers; publishers and news organizations; C2PA, CAWG and OP participants; Verifiable Credentials / DID experts; web security and privacy experts (e.g., WebAppSec, WICG, Privacy WG); platform and AI service providers; certification and attestation bodies; and researchers on trust and security indicators.

Goal(s):
1.Introduce the COA CG's mission and scope to the wider W3C community and collect feedback. 2.Discuss the longer-term aim of building a shared understanding of how technologies in this field relate to each other. We'd like to hear participants’ views. 3.Identify stakeholders and gather initial use cases, concerns, and gaps, especially from user-agent implementers and privacy reviewers.

See https://github.com/w3c/media-and-entertainment/issues/122 for proposal, context and approach.

This breakout would be an opportunity for the AIRFOT task force of the Media and Entertainment Interest Group to engage with W3C folk who wish to contribute new, or potential new, requirements for Timed Text, especially those enabled or made cost-effective by the use of LLMs ("AI").

Goal(s):
Gather new AI-related requirements for Timed Text

The HTTP Link header has functionality to initiate the resource preloading as the HTML <link> tag does. While preloading from main documents is useful and has well-defined behaviors in the spec, preloading from subresources is not used widely except for rel=preconnect nor defined clearly in the spec. We propose prohibiting Link header preloading (prefetch, preload, modulepreload, etc.) from subresources.

Note: Until recently Chrome supported this feature but don't support it now. Other major browsers do not support this feature.

Goal(s):
Get feedback from a wider audience for the new directions

Mozilla began prototyping peripherals APIs over a decade ago as part of the FirefoxOS project. Chromium-based browsers have shipped APIs for peripheral devices starting in 2017 with WebBluetooth, followed by WebUSB, WebNFC, WebSerial and WebHID. In 2026, Mozilla shipped WebSerial in Firefox. While these APIs have clear developer demand there have also been many concerns about their impact on user security and privacy. In this session we will look at these concerns, the mitigations that are currently shipped and have a discussion about where the peripheral ecosystem can go from here.

Goal(s):
Build an understanding of the current peripheral landscape and how it interfaces with the web.

AI tools are used more and more across W3C groups and repositories. Many organizations have adopted, or are in the process of adopting, AI policies. What general stance, specific provisions and guardrails should W3C adopt about the use of AI tools in W3C Standardization work?

To seed the discussion, I prepared an initial draft AI policy. It builds on the Use of Large Language Models in Standards Work document published by the Advisory Board. This breakout will present the draft proposal, invite feedback, and seek convergence on the general direction and specific provisions that such a policy could set, including:

• Contributor responsibility
• Contribution guidelines
• Possible disclosure requirements
• Handling of policy violations

Initial feedback and suggestions are welcome through comments on this issue.

Goal(s):
Seek convergence on a possible AI policy for W3C

The Open Web is shrinking. This is due to unprecedented structural shifts: the explosion of LLM-generated content, overwhelming LLM crawling traffic and the rise of autonomous AI agents. The role W3C has played to date is no longer sufficiently supporting the long-term health of an open, interoperable, and human-centric web.

Simultaneously, W3C's viability is at risk. Its value proposition has declined, leading to a multiyear drop in membership and concerning expenditures relative to income.

This breakout session invites community members to critically examine the W3C’s future strategic direction with the Board's Strategy as a starting point. We will confront core questions:

1. How can W3C focus on high quality, interoperable, world-relevant open web standards supported by user-impactful implementations? What does W3C need to do and do well, and (more importantly) what should W3C de-prioritize?
2. How can we evolve W3C's governance to facilitate such continuous prioritization, while staying aligned with our Vision and principles, to ensure W3C's financial sustainability?
3. W3C has lost engagement from the broader web community. Many consider open source projects either a replacement for or more important than open standards. How can W3C rebuild trust and relevance with the web community to work together to evolve the web? For example, how can W3C impact standards around emerging AI paradigms such as agentic web protocols?

Chairs: Chris Wilson, Tantek Çelik

Goal(s):
To gather candid community perspectives, surface diverging priorities across stakeholders, and synthesize key recommendations for the W3C Board of Directors and Team to consider as part of ongoing strategy and organizational evolution.

AI agents are becoming an important tool for assessing compliance with web accessibility standards. However, some success criteria remain difficult to verify using traditional evaluation tools or even AI agents. We conducted a study to evaluate whether AI tools (LLMs and AI agents) can assess robust content, such as video and blinking content. The results were presented at the 23rd International Web for All Conference (W4A’26), the premier venue for web accessibility research, on June 20th, in Dubai, United Arab Emirates.

This breakout session will demonstrate the research findings, showcase the tool we developed to consolidate the results, and open the floor for discussion.

• Paper: https://dl.acm.org/doi/10.1145/3800424.3800445
• Tool: https://github.com/cewebbr/mastif
• Video introducing the tool: https://www.youtube.com/watch?v=T47AmufeU10

Goal(s):
The goal of this breakout session is to foster discussion about the future of web accessibility compliance with AI, exploring both the opportunities and the limitations of using AI in this field.

Discuss agent security & get feedback on web platform security proposals.

Goal(s):
Discuss agent security & get feedback on web platform security proposals.

The Autofill CG was formed after a successful breakout in last year's TPAC. We wanted to come back to the TPAC crowd with updates on what we've been up to, experimental results on our proposals and to continue the conversation around autofill.

Goal(s):
Amplify the conversations around Autofill and standard proposals.

In September W3C announced the first pilot project of a new Open Source Program: the CanIVC dashboard contributed by Digital Bazaar. W3C is developing the program to support projects that foster the adoption and interoperability of Web technology, and to improve the operational side of W3C's standardization and incubation programs.

At this breakout session we'll share our experience leading up to the first pilot, and how you can get involved in the next stage of program development. We also hope to hear from people who might want to bring open source projects to this program.

Goal(s):
Raise awareness about the development of a W3C Open Source Program

Authors often want to use new web platform features before they reach Baseline, filling the gap in userland — whether that's called a shim, a polyfill, a ponyfill, or a fallback.

But polyfills[^1] are only attractive when their complexity is reasonable. Developers do not want a polyfill at any cost; beyond a certain level of complexity, a polyfill is as good as none.

Done right, polyfilling[^1] provides substantial downstream value to end users, the Web Platform's primary constituents: native features are typically more performant, more accessible, and more i18nclusive, and a good polyfill gets them to users sooner.

However, not all kinds of web platform features are equally amenable to this:

• JS is leading the way. Most JS features can be polyfilled well, and using them this way involves minimal or no additional friction.
• CSS is the biggest gap. Unknown syntax is ignored entirely, so a CSS polyfill must re-implement the browser's stylesheet fetching and parsing before it gets to any actual polyfill logic. Even then, a robust polyfill must react to changes, and the platform provides no primitives for that. We see over and over that even when CSS polyfills exist, authors avoid them: they are perceived as complex, large, insufficiently robust, and composing poorly with tooling, including other CSS polyfills.
• HTML sits in between. HTML features can be polyfilled reasonably well as a first approximation, but limitations (e.g. parser behavior, form association, focus/a11y semantics, shadow DOM boundaries) make these polyfills less robust and less performant than the native feature.

This session will explore:

• What are the platform gaps preventing good polyfills, and what is the plan to address them? Are there any low-hanging fruits, such as APIs that would help with polyfilling without being polyfilling-specific?
• How does improving polyfillability shift incentives across the ecosystem? If new features deliver value earlier, browsers have a stronger incentive to be first to ship but less pressure to be last, and the first implementation gains more influence over the feature's eventual shape. How do we keep premature polyfills from creating design lock-in without adding friction for appropriate polyfilling?

Out of scope: Whether individual features should be designed around polyfillability. This session is about platform-level primitives that make userland fallbacks possible, not about constraining feature design.

[^1]: "Polyfill" is used throughout for simplicity; the discussion covers all patterns for using new web features with a userland fallback when unsupported, including ponyfills, shims, and ad hoc fallbacks.

Note: Additional Chairs TBD

Goal(s):
Produce a list of high-level platform gaps that would make userland polyfills/fallbacks more viable across the platform, and identify what in the TAG's guidance on premature polyfilling needs revisiting if polyfills become more viable.

FedCM is seeing increasing deployment by identity providers and relying parties, alongside continued implementation and experimentation in Chromium. Current work also extends beyond the API's original relationship to third-party cookie deprecation, including multi-IdP user experiences, decentralized identity-provider discovery and registration, and related browser-mediated identity capabilities.

At the same time, there is not comparable implementation activity across the major browser engines.

As deployment and implementation continue, that gap may become increasingly significant. FedCM could develop into a widely used Web capability based largely on one browser-engine implementation, even while substantial architectural, privacy, security, user-experience, or product questions remain unresolved across the broader browser community.

We would like to use this breakout to establish a shared understanding of where FedCM is today and ask whether the growing implementation gap is a problem for the Web—and, if so, what might usefully be done about it.

Questions for discussion include:

• What problems does FedCM solve for the Web today, independently of third-party cookie deprecation?
• How do newer uses—including multi-IdP experiences, decentralized IdP discovery and registration, and related browser-mediated identity capabilities such as email verification affect that assessment?
• What can we learn from current FedCM deployment and implementation experience?
• Does increasing deployment without corresponding implementation across browser engines create interoperability, architectural, or governance risks?
• What concerns or missing pieces currently limit interest from other browser engines?
• Are there changes to FedCM's architecture, API, privacy model, security model, or user experience that would materially affect that assessment?
• What evidence, implementation experience, research, or interoperability work would help the broader community evaluate FedCM?
• Is there a plausible path toward broader browser engagement, and what could the FedCM community do to support it?

Suggested pre-reading

Participants may find the following useful background before the session:

• Federated Credential Management API](https://www.w3.org/TR/fedcm/) — the W3C specification.
• Working to Decentralize FedCM — work supported by Bluesky exploring how FedCM and IdP registration could work in decentralized environments where relying parties cannot start with a fixed list of identity providers.
• Email Verification — an experimental browser-mediated approach to verifying control of an email address that builds on FedCM infrastructure and concepts.

The pre-reading is intended to establish a common understanding of the current work so that the session can focus on areas of agreement, disagreement, and uncertainty rather than reconstructing the history of the proposal.

Goal(s):
The goal of this session is to make sure that continued deployment does not substitute for explicit discussion about whether FedCM is becoming a sound, interoperable Web platform capability.

With built-in AI APIs such as the Prompt API, inference moves from the server into the browser, and the telemetry that developers rely on to debug and evaluate AI features goes with it. We present an open-source proof of concept that traces Prompt API calls with OpenTelemetry, following the GenAI semantic conventions.

We then open three questions:

1. Web Machine Learning: what observability signals should built-in AI APIs expose natively?
2. Distributed Tracing: how should one trace connect on-device inference to the backend in a hybrid gen ai app?
3. Privacy: how can prompts, tool calls and media be observed without exposing user data?

Goal(s):
Gauge interest for observability, trace propagation and privacy questions that built-in AI APIs should address

Discussion and consensus-building for the new proposed Digital Policy Working Group Charter that will extend and build on the success of the W3C ODRL Recommendations.

After a very successful W3C ODRL Workshop in London where the community discussed the future options of ODRL, we will discuss a draft charter.

Goal(s):
Confirm the draft charter for the Digital Policy Working Group.

Users don't like restarting their browser and losing state, and commonly maintain very long running sessions (weeks/months). Since updates, including security patches, typically don't apply to running processes, this leaves such users exposed to known vulnerabilities for extended periods of time long after patches have been released. In the world of agentic scrutiny of open source codebases, there are many recently patched vulnerabilities at any given time! We will discuss how browser vendors and site authors can collaborate to close the "patch gap", with a specific focus on web-exposed APIs for extending the scope of "session" across tab restart.

Although couched above in terms of browser restart, resumability has utility for history navigation, reload, resumed tabs, OS restart, etc.

Note: Erik Anderson will chair the session.

Goal(s):
Gauge appetite for new session-linked or other short-term storage capabilities, and where site authors see pain points in providing seamless resumability.

WebVMT is designed for all video and audio use cases with additional information in any format, including binary. That additional information is attached to the outside of the media file so it's easily accessible, agnostic of video/audio encoding and metadata format, and integrated with HTML cues for web apps.

Example use cases include:

• Displaying an animated map with footage from drone cameras, dash cams, body cameras and smartphones.
• Searching metadata to quickly find relevant video content in a single file or in an online archive.
• Accessing ID3 tags or synchronising MIDI data with an audio file.
• Annotating video for training and testing an image recognition algorithm.
• Enhancing video with an AI-generated metadata stream to detect objects, smiling faces or body poses.
• Augmenting video with synchronised datasets such as maritime, flight or star trackers.

Breakout sessions offer an opportunity to engage with a broader audience to share ideas from OGC's innovation programme and identify new use cases from diverse web communities.

Join our discussion to discover how your media can be enriched with metadata on the web.

Goal(s):
Foster better understanding of how media metadata can be integrated with web apps, find new use cases and identify additional requirements for the web

We often find accessibility issues in AI output, and a big part of these issues may be resolved by improving the quality of the AI’s training. Problems include:

• Generated pages and software code as inaccessible as most of today's web

• Under- or otherwise mis-representation of people with disabilities

• Failing to respond to the needs of the user.

  • E.g. video description not taking into account a blind person’s needs; caption summaries not taking into account the needs of someone hard of hearing.

• Incorrect guidance on how to code accessible content

If we train AI on a largely inaccessible web, we are liable to get inaccessible output as a result.

This session is proposed to demonstrate some of these issues, and to ask the question: how can we improve the situation? What could we do to increase the quality of input to AI systems, such that we can expect better output?

Goal(s):
Suggestions for how we can improve the quality of training and thus output of AI systems, from an accessibility perspective

Accessibility Compat Data is expanding browser support data by including accessibility support. ACD is using existing testing infra (WPT, ARIA-AT) to inform developers about what is/isn't accessibility supported. We've been working with folks in the Interop Accessibility group, ARIA-AT, Baseline and BCD owners with the goal of integrating accessibility support information into Baseline and BCD. This raises a number of questions:

1. How do we evaluate support?
2. How do we present support status to developers?
3. What do we do with web features that are currently Baseline "widely available" or BCD "supported", but are not accessibility-supported?

We'd love to talk with browser vendors, accessibility professionals, and developer advocates.

Goal(s):
Collaborate with browser vendors about making web features accessibility supported.

Accessibility conformance for ebooks is required in the world but standards or best practices for "Manga" contents are not yet provided.
DPFJ (Digital Publishers Federation of Japan) started to discuss what kind of accessibility conformance should be done for "Manga" contents for global market.
In this session, we will show the current strategy of accessibility for "Manga" contents from Japan with difficulties and issues.

Yukio Tomikura (Kodansha) is expected to participate.

Goal(s):
The goal of this breakout session is to explain the approach of accessibility for "Manga" contents from Japan and to obtain opinions and issues for that through demos and discussions.

Over the past few years, we've shipped big UI features like View Transitions, Popover, Anchor Positioning, and customizable <select>. But when teams build multi-pane web apps, creative tools, or HTML-based browser interfaces, they still run into small interaction gaps that make web UI feel clunky next to native desktop and mobile apps.

Alongside the broader app sessions on cross-document navigation, overscroll areas, and Open UI accessibility, this session looks at three places where web apps still have to fight the browser with fragile JavaScript hacks or heavy WebAssembly runtimes:

• Clicking toolbars and secondary controls without stealing focus: In a desktop or mobile app, clicking a Bold button in a toolbar formats your text while keeping keyboard focus and the cursor inside the active editor. On the web, clicking a button pulls focus out of the editor unless developers intercept pointer events and juggle focus in JavaScript, which often breaks keyboard navigation and screen readers. Should HTML or Open UI have a declarative way to mark controls that act on another focused region without stealing focus?
• Keeping text selection visible when focus moves across inputs and panes: When you select text in an <input>, <textarea>, or embedded document and then click into a find bar, side panel, or formatting toolbar, the selection highlight disappears even though the text is still selected underneath. On some operating systems, clicking back in and dragging will still drag that hidden selection, while native apps just keep a dimmed highlight visible so you can see what's selected. What do we need in CSS or HTML so developers can keep inactive selections visible and styleable without drawing fake highlight overlays in JavaScript?
• Scrubbing vector animations to interaction state without heavy runtimes: Teams routinely ship a 5MB Lottie WebAssembly player just to get smooth vector icon animations that can scrub to a specific point on a timeline or switch states on hover and click. Rather than standardizing a third-party runtime format, what's missing in SVG and the Web Animations API that stops design tools from exporting scrubbable, state-driven vector animations directly to the platform?

We'll share brief examples from production web apps and HTML-based browser UI across engines, and we'd love to hear which other small UI interaction gaps are causing the most pain for app developers.

Goal(s):
Talk through how to support non-focusing toolbar controls, visible inactive text selections, and scrubbable SVG timelines, and figure out which pieces belong in Open UI, CSS WG, HTML, and SVG WG.

The current draft of the WebMCP specification allows websites to register tools that an agent can discover and invoke.

Extensions are currently one of the main ways that third party developers bring agentic features into web browsers. Such extensions work by scraping the DOM, generating an accessibility tree based on the DOM, capturing screenshots of page content, or driving the page through debugging and automation interfaces. WebMCP is an attractive alternative for these extensions, as it could provide a structured, site-sanctioned alternative.

This session aims to collect requirements from extension developers and browser vendors, and to check those requirements against WebMCP's current design. Questions we plan to work through:

1. Consuming site tools
   • Should extensions be able to enumerate and invoke a page's tools without injecting a content script?
   • Are any social considerations needed to expose navigator.modelContext to ISOLATED world content scripts?
   • Would a dedicated extension API add sufficient value beyond calling the web API from the page?
2. Providing tools
   • Should extensions be able to expose their own tools to the browser's agent?
   • Should extensions be able to expose their own tools to websites?
   • How does this relate to the iframe and embedding discussions in WebMCP? Are any design changes necessary to cover both use cases?
3. Permissions and trust
   • What (if any) permissions should gate an extension’s access to WebMCP tools?
   • Is a new permission warranted?
   • How (if at all) are users informed when an extension invokes a site's tools?
4. Lifecycle
   • How do event-driven background contexts (service workers, event pages) interact with tool registration, discovery, and long-running invocations?
   • Which events do extensions need when a page's tools change?
5. Gaps
   • What other use cases should be considered before stabilizing the API design?

This is a community discussion, not a group meeting. We especially want to hear from extension developers building agentic or automation features, WebMCP spec contributors, and browser engineers working on both Web and WebExtensions platforms.

Goal(s):
A shared list of extension use cases and requirements for WebMCP. For each item, identify whether it should be integrated into the WebMCP specification, WebExtensions specification, or both. Identify owners for any follow-up issues

I would like to help facilitate a discussion around the Translator and Language Detector APIs proposed by the WebML CG.

In particular, we have had some discussions within the Mozilla standards position repository, and I would like to gather folks to specifically discuss plain-text translator APIs compared to a DOM-aware translator APIs.

• https://github.com/mozilla/standards-positions/issues/1015
• https://github.com/webmachinelearning/translation-api/issues/60#issuecomment-5345000556

Goal(s):
Facilitate discussion and seek consensus on the shape and direction of translator APIs

JSON-LD is an essential data format powering SEO, Social, Credentials, IoT, Publishing, and AI authenticity. The JSON-LD is expanding to include YAML and CBOR based formats. YAML-LD provides a human and AI friendly format. CBOR-LD brings tight compression bringing JSON-LD documents into tight spaces (QR codes, message queues, etc.). Additionally, JSON-LD's core specifications are growing to include the latest graph super-powers arriving from the RDF 1.2 specifications. This breakout session will be an overview of the growing family and what's ahead for the JSON-LD WG and CG.

Goal(s):
Update W3C Members on the growing JSON-LD ecosystem.

Portable Web Content Format enables apps, games, and interactive presentations built with web technologies to be packaged as self-contained .pweb files that can be instantly opened and run on any device using a compatible viewer—even offline and without a web server.

In this session, we will

• Introduce the format
• Demonstrate its potential use cases
• Discuss its technical direction
• Gather feedback from the Web community.

Goal(s):
Gather feedback, identify related standards, refine PortableWeb’s technical direction, and connect with potential contributors.

ActivityPub, the social networking standard, lets users follow each other and receive a stream of content from their contacts. The Social Web Community Group is currently extending the standard to support membership in groups, including private groups.

Goal(s):
Discuss ActivityPub support for groups, solicit feedback, and decide on next steps

The arrival of AI is redrawing the talent bar for software engineers: execution-level work is being commoditized, while judgment — problem framing, architecture, trade-offs, and accountability — becomes the scarce, valuable skill. For computing educators, the question is no longer "how do we teach students to code faster," but "how do we teach the judgment that AI cannot supply."

This session shares a concrete, classroom-proven answer: Collective-Intelligence Co-education, a five-dimensional framework (school–enterprise, human–machine, course–competition, teacher–student, inter-university) anchored on a single meta-capability we call Generalized System Capability = Systems Thinking (ST) + Engineering Capability (EC). The framework is grounded in a 2026–2028 teaching-reform project at the Shenzhen Institute of Information Technology (SZIIT), where a Logic & Critical Thinking general-education course is being rebuilt so that AI output itself becomes the object of student scrutiny.

Crucially, the medium of this reform is the open Web. Instead of shipping a closed, proprietary teaching app, every learning artifact is a single, self-contained HTML page built with plain HTML / CSS / JavaScript / Canvas / SVG — no build step, no framework, openable in any modern browser and immediately shareable. Three interactive demos will be shown live:

• Eight Queens — a step-by-step, animated exploration of backtracking search;
• Feedforward Network · Hardcore Teardown — a math-first, interactive contrast of why a linear model cannot solve XOR and how a hidden layer can;
• Masked Multi-Head Self-Attention · Deep Dive — an interactive, quest-based walkthrough of the causal mask inside a Transformer decoder, including an error-vs-correction playground and a self-graded quiz.

Each demo is designed not to demonstrate AI, but to train judgment about AI: students manipulate the model, break it, fix it, and explain why.

We will also open a broader conversation with the Web community on what comes next.

Goal(s):
Three concrete goals: 1) Share a working model. Present the Collective-Intelligence Co-education framework and the Generalized System Capability (ST + EC) anchor, with the SZIIT teaching-reform project as the case, so participants can reuse or adapt it. 2) Show the Web as the medium. Demonstrate the three interactive learning artifacts and argue for the open Web — HTML/CSS/JS/Canvas/SVG, zero build step — as the right substrate for AI-era computing education, in contrast to proprietary or platform-locked teaching tools. 3) Seed collaboration. Identify shared interests with the Web community and gauge appetite for follow-on work — e.g., a W3C Community Group or workshop on "Web for Smart Education," open learning-artifact formats, or accessible interactive teaching components.

As we work towards a standard around Web Monetization, we are opening this session to other efforts. We intend it to be a round table of discussions and implementations. We will share more about:

• State of web Monetization ( stewarded by Interledger Foundatation)
• Other implementations x402, MPP
• Future challenges
• Recommendations for Web Monetization and other projects.

This session explores how Web Monetization and the agentic web still share the same goal. Web Monetization set out to let browsers stream small, automatic payments to creators as a third option alongside ads and subscriptions, and it is working now towards its native browser support. Generative AI answer engines and scraping agents now consume web content at scale without returning the clicks or revenue that used to flow back to creators, turning a slow sustainability problem into an acute one. Into that gap have stepped machine-native payment protocols — x402 reviving HTTP's dormant 402 status code, Google's AP2, and interoperable rails like Interledger's — built to let software pay for what it uses. The talk asks the W3C community to converge these two threads into one interoperable standard before competing protocols lock in a fragmented default.

Note: There may be co-Chairs representing the other technologies.

Goal(s):
Draft some future path of implementation for different Web Monetization streams

The Web Platform's design principles implicitly assume a human developer as the primary API consumer. As a growing share of web code is written by agents, these assumptions stop holding uniformly, and some pull in opposite directions.

Questions this session will explore:

• Should we take agent consumers into account at all? The counterarguments are that agents are not uniform — what is efficient for one model generation may not be for the next — and the landscape is still volatile, whereas Web APIs are permanent.
• What does agent DX mean? Token efficiency? Robustness/correctness? What else?
• Which existing design principles still hold for agents, and which actively hinder them?
• What makes a Web API token-efficient, both when writing code against it and when reading code that uses it?
• What makes a Web API robust for agents, i.e. harder to misuse?
• Where agent ergonomics and human DX conflict, how do we weigh them?
• Evaluation: An API's token cost is not an intrinsic property. An agent implementing an unfamiliar API spends tokens on lookup, trial and error, and correction, so a design that would be more token-efficient at parity of familiarity measures as worse until training data catches up — which takes years. Any evaluation we run today privileges familiar over better. How do we separate the two, and how do we evaluate API designs, or design principles, given such a delayed feedback loop?

Note: Additional Chairs TBD

Goal(s):
Make progress on the questions above and identify people interested in exploring this further.

What?

The University of Michigan has engaged Helix Opportunity LLC in an Innovative Partnership to develop an AI Application Programming Interface (API) for Neurodiverse STEAMM Students for Advancing Higher Education and Career Pathways

Who?

Helix Opportunity is a leading edge innovator in digital transformation, inclusive design, and digital accessibility.

The University of Michigan has performed ground-breaking work on career readiness training for the neurodivergent population.

Why?

This project combines expertise that will bridge gaps in the current AI ecosphere of product development, reducing bias and incorporating much needed insights from the disability population.

Historically, disability data has been omitted in the development of AI which
has caused systemic algorithmic bias and discrimination. Current AI systems
are largely trained on datasets that underrepresent or misrepresent the
disability community. This results in technologies that perpetuate stereotypes,
create accessibility barriers, and make inaccurate or unfair decisions in critical
areas like employment, education, and healthcare.

This project explores the development of AI technology specifically
trained on large datasets of the world’s most vulnerable population, as
described above, to improve societal outcomes related to vocational
rehabilitation.

Goal(s):
Inform the audience on cutting edge applications of AI in the disability inclusion space

“Never send a human to do a machine’s job”. Agent Smith had a point in The Matrix, at least for part of a standards review.

We are experimenting how AI can support human review of Web standards, particularly security review. Some parts of the review can be delegated to machines, other parts such as interpretation, judgment, and decisions are still on humans.

We have been building an experimental marketplace of portable AI skills to help W3C work. During a review, a skill can help us understand and model what a specification is building, another can ask what might go wrong and support threat modeling, or comparing the specification from its implementations. Others can gather and check evidence, fact-check a claim, suggest possible responses for a reviewer to consider, or prepare draft review material.

There are not fire-and-forget skills. A human still has to challenge, interpret, check it and decide.
The workflow can also start before the horizontal review. A Working Group can use these skills in earlier design phase, as a security-by-design sparring partner rather. Sometimes the skills will produce useful questions; sometimes they will produce poor ones or miss something entirely. Understanding that boundary is part of the experiment.

In the breakout, we will show the skills currently available, how they fit into the workflow, and one concrete example of working with their output.

This brings us back to the electric sheep. Think of these agents as electric sheep that can range over information, follow different paths, and sometimes bring back something useful. We still need to shepherd them: understand where they went, challenge what they found, decide what matters, and take responsibility for the review. The sheep do not replace the shepherds, and maybe we also need electric sheepdogs.

Goal(s):
Present and test a human-led workflow of portable AI skills for Web standards review, and find participants willing to experiment with it and help improve it.

This is a follow-up to last year's session with an overview of where things are at and an update of the progress that we have made since last year, specifically:

• Per TAG's guidance, an update on moving part of the work to the IETF
• What we have learned with implementation and deployment experience in Chrome and Gmail
• The browser API and integration with form filling (and open questions we have)
• An open invitation for participation from websites, email providers, browser vendors and protocol designers

Goal(s):
Raise awareness, find privacy/security/economic holes in the design and an open invitation for participation

Current on-device Generative UI solutions present a trade-off: Web engines (e.g., Chromium) offer superior layout flexibility and LLM compatibility but incur high performance costs and experience fragmentation. Native JSON routes (e.g., A2UI) are lightweight and performant but lack flexibility for complex layouts and are prone to parsing errors. This proposal explores whether we can combine the best of both worlds to create a new, efficient technical standard for Generative UI.

• First, at the syntax layer, we propose a Generative UI Baseline to constrain the syntax space, prioritizing core features like flexible layouts like Flexbox and Grid. This significantly would reduces LLM generation complexity and token consumption while preserving essential cross-device responsiveness, resolving syntax errors and layout adaptation issues at the source.

• Second, at the engine layer, we envision a Lightweight Web Engine stripped of legacy baggage. This would reduce memory footprint and cold-start latency by an order of magnitude, enabling smooth streaming rendering alongside LLM outputs within a minimal attack surface.

• Finally, at the rendering layer, we aim for OS-Unified Rendering by linking the engine’s display lists directly into low-level OS graphics pipelines. This would eliminate off-screen compositing overhead, allowing Generative UI to natively leverage OS gesture physics, font rendering, and high refresh rates.

Goal(s):
Collect community’s feedback on the technical and strategic feasibility of this approach, aiming for optimal convergence with current Web standards and meaningful contribution to the open web of the future.

Declarative Overscroll Actions (Explainer)

The web platform allows for sophisticated scrolling experiences, but it currently lacks a semantic way to utilize "overscroll" space (the area beyond the scroll or element boundary).

Common UI patterns like drawer-menus (swiping past the edge to reveal a menu) rely on complex nested scrollers or JavaScript gesture polyfills. These workarounds are difficult to implement, computationally expensive, and often fail to provide accessible alternatives for non-touch users.

We propose a set of HTML attributes and CSS properties that declaratively bind an element (the "overscroll content") to the scroll boundary of a container to support drawer-menu and bottom-sheet cases.

Goal(s):
Explain an upcoming feature and gather feedback.

The W3C WebTransport working group have recently extended our Charter to consider “ ..incubating mechanisms for peer-to-peer capability”. To this end, we are having two presentations on this topic, followed by discussion time. The first would be a remote presentation by Jan-Ivar Bruaroey from Mozilla on the concept of the leveraging the WebRTC handshake to initialize a p2p connection, prior to establishing a WebTransport connection. The second is an in-person presentation by Marten Seemann on “A p2p Vision for QUIC”, which offers an alternate approach of migrating a client-server connection to a peer. There will then be discussion time between participants and the audience.

The WebTransport WG encourages all W3C TPAC participants interested in QUIC-based options for moving real-time data between peers to please attend.

Goal(s):
Assess interest in QUIC-based options for moving real-time data between peers

The E-Commerce for Humans and AI Agents occurred on September 8-9. The workshop discussed merchants' context and views, legal accountability, protocols and data infrastructure, including trust and ownership. Using AI Agents, Web browsers, or some combination of both, e-commerce needs product data models and representations, user intent/alignment, identity and authorization, payment. A Web for humans and AI agents should be part of the future of customer interactions.

Goal(s):
Reporting on the workshop discussion and how to address the use cases

For three decades, web accessibility has been pursued almost everywhere except the one place every user already stands: the browser. We have asked authors to remediate, assistive technologies to compensate, and regulators to enforce — while the layer that renders the web to every person has stayed largely on the sidelines of universal personalization.

This session makes the case that the browser is the natural home for universal accessibility: a layer that could adapt any page to the individual needs, abilities, language, and preferences of the person using it, rather than requiring every author and every assistive technology to carry that burden separately. It is not a new idea — it was described in the research literature as early as 1996, and the "accessible framework as personal interpreter" concept predates the modern web.

What is new is that feasibility is no longer the open question. On-device AI now runs inside the browser on ordinary consumer hardware, and the browser has always been able to reach into the page it renders — the accessibility tree, the DOM, and the user's own style layer. A working prototype of a user-controlled "smart browser," built on a five-year-old laptop, already demonstrates the idea in practice. The pieces that were missing in 1996 are arriving.

So the question this breakout puts on the table is not whether browser-level personalization is possible, but how to do it well. When a general on-device AI interface was proposed for the web, the engines and the W3C TAG raised specific, documented concerns — interoperability, user consent, device cost, fingerprinting, and the viability of independent browsers. Those concerns are exactly the right starting point. A narrow, user-controlled accessibility capability answers several of them by construction and turns the rest into design requirements. This session is where the people who would build it can work through those questions together.

This session is grounded in the research paper Web Browsers as a Pervasive Accessibility Solution (Paciello). The "universal interpreter" lineage traces to the 1996 ASSETS paper (Laux, McNally, Paciello & Vanderheiden) and the Pervasive Accessible Technology concept introduced by David Stone at the 1991 World Congress on Technology for People with Disabilities.

Goal(s):
Build shared understanding that the browser is a viable accessibility layer now that on-device AI has shipped and the browser already exposes the page it renders; work through, candidly and with the people who would have to build it, the documented concerns the engines and the W3C TAG have already raised about a general AI interface, and how a narrow, user-controlled accessibility capability addresses them; and identify concrete next steps — what the major engines could prototype, and what standards or coordination work at W3C would unblock it. Success is leaving the room with at least one committed follow-up (a community group discussion, an explainer, or a cross-vendor conversation).

The web sustainability landscape has been rapidly evolving, with organizations and implementers seeking to take on the challenge of climate responsibility. There is tremendous interest and many implementations of the WSG Draft and its supporting materials.

This breakout will explore:

• The current impact of the Web Sustainability Guidelines
• How implementers are supporting conformity with the WSG
• An open discussion of WSG tooling and implementations

Goal(s):
Explore WSG related tooling, and consider how the Sustainable Web IG can make implementation more viable.

tl;dr: Let’s have a conversation about the intersection of modern Assistive Technologies, adaptations, proposed platform features, and the user’s privacy. We want the user to avoid being in a position where the adaptations they need to afford them access are also a fingerprinting risk - especially one that highlights the use of Assistive Technology - or that such features can’t be added to the platform safely. Can we learn anything from past impasses in these areas, to help us design a future web that is both more adaptive, as well as more privacy preserving?

User Agents are there to protect their users. We have always taken care to design new features and APIs to, as far as possible, discourage detecting if the user is using Assistive Technology to access the web. The user’s privacy - especially in relation to such personal information - is extremely important.

What an Assistive Technology actually is, though, can vary. It could be: a screen reader; the use of dark mode; or the desire to opt in to, or out of, specific fonts, font sizes, or aesthetic features. A range of minor-to-moderate impairments exists, and a range of assistance - be that a ‘traditional’ Assistive Technology, or an adaptation provided by the OS or UA - exists to meet these needs, and to personalize the web for the user.

The use - or non-use - of those features could increase fingerprinting surface, especially if the sizes of the populations using, or opting out of, a feature are very different in size. As a result, some features that might benefit some people can’t be developed and shipped, due to the privacy risk. That’s a reasonable stance to take on a feature-by-feature basis, but are there any patterns we can learn from, to inform changes that might make more such useful adaptive features possible in future?

Goal(s):
Establish interest and next steps in assessing the balancing act here, and how to involve the community in designs going forward.

Ask i18n is an experimental tool from the i18n WG exploring whether an AI-assisted, citation-grounded interface can make W3C Internationalization guidance easier to find. It indexes W3C i18n sources, retrieves relevant sections, and presents answers based on that evidence, with visible citations and warnings when the evidence is weak.

This breakout will demonstrate the current system. The session will also ask what safeguards and community oversight would be required, whether other approaches would be better, and whether further development is justified.

• Site: https://ask-i18n.onrender.com/
• GitHub repo: https://github.com/w3c/ask-i18n

Goal(s):
Assess whether it helps people find relevant W3C i18n guidance while keeping the underlying documents, rather than the generated answer, authoritative.

After beta testing earlier this year, we will demo updated designs for CG specifications and share progress on their implementation in respec and bikeshed.

The redesigned specifications include, inline, much more information about the technology’s implementation and adoption status. We will describe the new metadata tooling that supports the inclusion of this dynamic usage guidance.

We will also share plans for current work on the next enhancements: publication tools and plans to host more CG specifications on w3.org.

Goal(s):
Provide the community with updates on the CG specification redesign project and seek feedback

In August of this year, the Advisory Board published a position statement, Further Aligning W3C's Program of Technical Work with Human Rights. Subsequently, we have created a Community Group where we are starting to explore how to put some of this recommendations into action. This will be a working session to present the AB position paper as well as the current status and activities of that group, and to gather community feedback, raise awareness of this topic and engage additional contributors.

Goal(s):
Highlight the work that has gone on so far with regard to Human Rights at W3C, invite comment and question, and hopefully recruit participants for our ongoing efforts.

National identity systems tend to provide a vertically integrated solution, including issuer, holder and verifier. Interoperability remains a key challenge across systems adopting W3C Verifiable Credentials.

With support from WCAP, we held a Technical Interoperability Plugfest (TIP) for DIGITAL TRUST Thailand 2026 (See related public information, with agenda and methodology), with four system participants: MOSIP Inji, TWDIW, ETDA, and Bhutan NDI.

This session will share our findings, proposed interoperability task force in CCG, and initiate discussion on various topics, e.g., How could the W3C Digital Credentials API be integrated into this ecosystem?

Goal(s):
Identify and discuss key issues to support ongoing discussions with other stakeholders, such as solution providers and identity providers (e.g., government agencies).

Generative AI has heavily impacted many areas of the web, but one of the most impacted is authoring of content. Content of all kinds can now be produced faster than ever before, but without guardrails, we already see the risks to users in terms of inaccessibility and harm. Generative AI has also made some accessibility use cases more available to disabled users such as automated captioning and on-demand image descriptions, but many tools have no consideration for accessible content authoring at the time of creation. How do we balance the risks and the opportunities, and how might we write a standard for authoring tools that creates the necessary guardrails while supporting a more accessible authoring environment? In this session we want to discuss the different possibilities, concerns, and the wild potential of authoring tools in the AI age as we prepare for the development of ATAG 3.0.

Goal(s):
Discuss possible use cases, risks, and opportunities for ATAG 3.0.

The web is much more than browsers. Web standards are often designed and implemented first for browsers. If you look at embedding or different contexts like WebViews, MiniApps, Isolated Web Apps, JavaScript runtimes and more you sometimes find new challenges, questions, requirements or issues.

These areas have their own groups and communities that despite probably quite a few overlapping challenges and interests don't really get to talk and coordinate much between each other.

This breakout invites everyone to get to know each other and share issues, past and future work. We can start with a short introduction about your field of work by one representative of each group/project:

1. Please give a little introduction about you and your field of work
2. Please tell us about the things you would like to improve
3. What did you or group so far?
4. What are your plans for upcoming activities?

(If you want leave your introduction in this issue we can include it in the presentation that opens up the breakout.)

After hearing about the interesting things and possibly finding common interest we can discuss how to coordinate this. We have great discussions at TPAC but once a year is not enough to really move things forward. Should we create new groups or formats to work better together? Let's find out!

Goal(s):
A plan on how to do more and regular coordination between browsers, embedded contexts and more

Bring together:

• MiniApps
• WebViews
• Embedded Web Engines & Native Web Runtimes
• Embeeded Browsers like WPE WebKit
• Sub Apps API
• TAG
• more

The W3C has been collaborating with the OPC Foundation, maintainer of the OPC UA Industrial Interoperability IEC Standard, for many years now in two joint working groups, namely the Web of Things Connectivity working group and the Web of Things Binding working group. This session will give an overview of the collaboration and its outcomes to date, as well as work in progress and future work.

Goal(s):
Provide an overview of the W3C collaboration with the OPC Foundation

The Web of Things (WoT) WG/IG will run a PlugFest from 25-27 October. This breakout session will show the results of the PlugFest including live demos from different participants.

You will learn how WoT counters the fragmentation of the Internet of Things (IoT) by using and extending existing, standardized Web technologies. By providing standardized metadata and other re-usable technological building blocks, W3C WoT enables easy integration across IoT platforms and application domains.

Goal(s):
presenting live demos from the WoT PlugFest and learn, e.g., Plug&Play device onboarding with WoT

As AI agents move into the browser, whether built in, installed as extensions, or calling new web APIs, they're acting inside tabs where the user is already signed in. That shift raises hard questions across security, privacy, identity, and competition.

Last year's breakouts on Agentic Browsing and the Web's Security Model and Semantics for the Agentic Web started the conversation around user agency versus site control. This year, with early browser-agent trials underway and related breakouts exploring agent alignment, agent security, anonymous credentials, and verified agent commerce, we want to dig into three practical trade-offs around how the browser mediates between the user, the agent, and the site:

• Avoiding prompt fatigue without losing user control: Asking for permission before every tool call or form submission just trains people to click "Allow" without reading, like cookie banners. But we obviously can't let an agent buy things, move money, or delete data in the background without asking. How do we support a "gather, then commit" flow where an agent can research and stage a task on its own, and the browser steps in for a real human check before anything final happens?
• Browser-owned checkpoints vs. in-page confirmation modals: If a website builds its own "Are you sure?" modal in HTML, an agent driving the page can click that confirm button just like any other button. Where does the browser itself need to step in with confirmation UI that an agent can't click past? And how should risk hints from a site, like WebMCP's readOnlyHint or proposed hints for high-stakes actions, connect with existing browser gates like Autofill, Payment Request, and WebAuthn when a site forgets or mislabels a hint?
• Balancing site defense with agent neutrality: Websites and merchants reasonably want fraud protection, rate limits, and a way to shut off an agent that's misbehaving. At the same time, browser vendors and privacy groups worry that exposing which specific agent vendor is calling in client-side web APIs, or requiring partner allowlists for in-tab actions, makes it easy for sites to block user-chosen agents in favor of commercial partners. How can we give sites practical ways to manage automated traffic and revoke bad agent runs, like separate agent sub-sessions or privacy-preserving tokens, without turning the browser into a gatekeeper for which assistant a user is allowed to pick?

We'd like to get browser, security, privacy, and identity folks together with site owners to talk through these trade-offs openly and figure out what belongs in web specs versus what should be left to browser UI.

Goal(s):
Work toward shared principles across browsers, security and privacy groups, and site owners on how in-browser agents should handle user confirmation and site safety without causing prompt fatigue or locking users into partner-approved agents.

Smart glasses and AI devices are giving computers access to the physical world, digital twins are mapping factories and entire cities, physical AI is showing up in workplaces and homes, and robots are leaving their fixed positions on the factory floor. Many of these products and ecosystems are emerging within walled gardens. The Web lacks an integrated architecture for discovering and securely composing independently published spatial services. Enterprises need open infrastructure for deploying these services across products and platforms. W3C is the organization that should lead the way by extending the open infrastructure that the web provides to support spatial computing and connect the physical world with the virtual.

This session covers the specific needs of metaverse infrastructure, how the current web was not designed for spatial computing, and the technical evolution needed to make the web ready to handle this significant transition, including evolving the DOM and iframes, solving for multi-origin, geo-located content, native rendering, and updated security.

The web browser can and should evolve into both a 2D web browser and a 3D metaverse browser. Without this evolution, the Web risks losing its role as the open platform for the next generation of computing.

The Open Metaverse Browser Initiative (OMBI), an open project at the Metaverse Standards Forum (MSF), is building an open-source browser engine called Sneeze. It discovers independently published spatial services by location and composes their content and logic in 3D around the user in real time, with interoperability and security as core design goals. Sneeze is designed to run alongside existing browser engines (Blink, WebKit, and Gecko) for incremental deployment, with flexible compositing of live Web content within the 3D scene.

MSF does not create standards, so OMBI is bringing its proposed architecture and identified gaps to the relevant standards organizations and believes the W3C should lead the charge.

The live demo will ground discussion of three areas:

• Extending the Web with spatial browsing. Sneeze uses WebAssembly, and the project is evaluating Decentralized Identifiers (DIDs) and Verifiable Credentials. The engine does not use WebXR; it is a native spatial browser engine with a shared scene model, location-based discovery, and a service protocol.

• Securing shared 3D scenes. The Web isolates content by origin. A 3D scene shared by many publishers needs isolation within one scene, so OMBI proposes to identify each publisher by the key that signs its content, run its code in its own WebAssembly sandbox, and control access to its part of a unified scene graph.

• Defining the open standards needed for interoperability. Scene representation, service discovery and interaction, and identity and security.

OMBI also builds on standards from Khronos (glTF, OpenXR, ANARI, SPIR-V) and OGC (GeoPose), and uses emerging geolocation standards. The session will demonstrate the open-source Sneeze engine in the Rubidium browser.

Pre-reading is encouraged: see the OMBI overview. Slides will be linked in the agenda before the session, and attendees will receive a free copy of The Spatial Age, a book on this topic.

Note that Breakout #35 Web of Worlds, is a separate and complementary MSF proposal for a network of linked, addressable virtual worlds.

Goal(s):
Seek W3C feedback on OMBI's proposed architecture, identify priority standards gaps, and agree relevant groups and next steps for further discussion or incubation.

This session will be a discussion on the advantages and the pitfalls we have found when using artificial intelligence (AI) in our research work. We are also interested to find out how other groups are using AI.

We’ll explore how W3C task forces can integrate AI tools into standards and research workflows while maintaining quality, accessibility, and human oversight. It will include:

• Practical examples of AI integration in drafting research modules on user testing, triggers and artificial intelligence (AI).
• Challenges we have encountered and processes we are implementing.
• Cross-group discussion on how other groups are using AI to help their work at the W3C and shared insights.

The Cognitive and Learning Disabilities Accessibility Task Force (COGA) are hosting the session. Everyone is welcome. You do not need a background in cognitive accessibility or AI to take part.

Leonard Beasley will chair the session.

Goal(s):
Share experiences of using AI in W3C work, including successes and challenges and foster working together.

Pending approval of the charter, this informal meeting could be a chance to:

• recruit participants and other stakeholders (or sponsors!) from further afield than the DID WG community
• present (and debate potential modifications to) the draft evaluation criteria and process in anticipation of the first official meeting
• chat with browser vendors and W3C members about the specific use-cases they might be interested in supporting, and how their requirements could be codified as mandatory or optional factors in the evaluation process

Goal(s):
Recruit participants, issue-openers, and stakeholders for the upcoming new WG

This session will explore a collective project that Microsoft is proposing for how we're looking to prioritize work on the web platform. Using real world user journeys and early benefits we've found. Based on this we'll go over key categories that we believe warrant discovery, investment and prioritization to have a holistic view of how the web should evolve for agentic experiences with a human in the loop.

Goal(s):
Alignment on a joint initiative to incubate key solutions

The W3C Systems team just released a new W3C group feature: activity pages. These pages are meant to show what a group has been doing, month by month.

For an example, see the GPU for the Web activity page.

The goal of this session is to present these new pages, and gather feedback and ideas to improve this system further.

Goal(s):
Gather feedback and expectations on the new group activity pages

Recently, the Web of Things WG (WoT-WG) has started to discuss media handling capability for WoT as a possible use case [a, b], and the group would like to have joint discussion with the media experts including the Media and Entertainment IG (MEIG) during TPAC 2026.

For that purpose, the Chairs of the WoT-WG and the MEIG have been holding initial discussion about a possible breakout session on "Media for WoT" during TPAC. We think holding the discussion as an official TPAC breakout session would be very useful, because we'd like to invite all the experts from both the WoT world and the media world. Also we'd like to hear from all the other related/interested people attending TPAC 2026 in Dublin.

NOTE:
I've been suggesting the WoT WG should think about media handling capability for the WoT mechanism for years, and really would like to see what is still missing to make the Web Browser a WoT Thing and/or a WoT Consumer.

[a] WoT minutes: https://pad.w3.org/p/2026-08-0506-wot-td-minutes
[b] Expand media streaming analysis proposal: https://github.com/w3c/wot-thing-description/pull/2213

Goal(s):
Presenting the initial proposal on "Media for WoT", and gathering opinions/ideas about existing pain points and possible use cases

What could the Agentic Web look like? What do we need to do to standardize it?

More details coming soon...

Goal(s):
Directions for future work at the W3C around enabling the web to work well with AI agents.

The Web already delivers spatial and immersive experiences - via WebXR, WebGPU, WebAssembly, real-time communications, digital identity, geospatial technologies, 3D formats and the wider Web platform - but not yet an interoperable Web of linked spatial experiences, the way URLs and HTML link today's Web.

The Metaverse Standards Forum (MSF) Web of Worlds initiative frames this problem concretely. Instead of a new stack or 3D format, it composes existing standards around three concepts:

• Open Spatial Worlds: spatial experiences that can be addressed, linked and composed with Web technologies;
• Open Spatial Assets: independently hosted 3D/spatial resources that can be referenced and reused across experiences;
• Open User Manifests: mechanisms for users to carry identity, preferences, avatars, assets and other user-controlled data between worlds.

Much of the needed infrastructure already exists across the Web Platform and other standards ecosystems. The open questions are where existing standards suffice, where integration or profiling is needed and where genuine gaps remain.

Chair note: TBD - jointly organised W3C / Metaverse Standards Forum session. Additional facilitators from the MSF / Web3D Consortium to be confirmed.

Goal(s):
Create an initial mapping of W3C standards to support a Web of Worlds - connecting concrete spatial Web requirements to existing standards, relevant W3C groups and identify remaining gaps.

On 11 October 2026 the DNS root is scheduled to switch to a new key-signing key, KSK-2024. A validating resolver that does not trust the new key may leave its users unable to reach sites under any top-level domain. Validating resolvers are run by ISPs, enterprises and others on users' behalf, and users have little means to check their status.

Read also backgrounder

Further root key events are planned: revocation of KSK-2017 in 2027, a proposed algorithm rollover to ECDSA between 2027 and 2029, and a later post-quantum root key. Meanwhile the Credentials CG has discussed rooting DIDs in DNSSEC, leading to draft-ranjbar-dane-did-01, so credentials and agent identities may come to depend on the same anchor.

The session follows on from the TPAC 2025 "Future of the Open Web" discussion and from a submission to the Data Governance & Ownership mini-workshop (w3c/tpac2026-miniworkshops#39). It opens with what the rollover showed, then works through open questions:

• Does a stale resolver block publishing as well as reading?
• Can a resolver that was ready lose readiness after a reinstall or migration?
• How can a user, support desk or agent tell a trust-anchor failure from an ordinary outage?
• Who is accountable when a resolver operator misses a rollover?
• Would DNS-bound credentials and agent identities fail closed behind a stale resolver, and how would a relying party learn why?
• Which W3C specifications inherit trust from the DNS root, and do they say so?

References:

• Cloudflare on the KSK-2024 rollover(https://blog.cloudflare.com/root-ksk-2024-rollover/)
• Credentials CG thread(https://lists.w3.org/Archives/Public/public-credentials/2026Jul/0041.html)
• ICANN proposed algorithm rollover

Note: The proponent of this breakout session @starborn is not going to be attending in person, and is creating this issue, to raise awareness among w3c communities of the risks arising from the ney KSK key, Individuals who care for the open web attending TPAC in person, please come forward to co chair this breakout session or please, bring the topic up in relevant sessions that you may be organizing/attending

Goal(s):
Agree what W3C communities can do to reduce risks to users and agents from root key changes, and whether the topic warrants a W3C Workshop, a TAG review request or joint work between the Credentials CG, DID WG, Autonomous Agents on the Web CG and AIKR CG.