TPAC 2023 calendar - Breakout Sessions

WASM is the technology bringing more development languages, additional security and better performance to the Web. Javascript is the dominant language in developing Web applications, front frameworks and libraries. How to enhance the cooperation between the two technnologies for a more efficient Web?

This session intends to open up a discussion on an innovative proposal to compile and run Javascript code on WASM for better Web performance, and related standards work.

Annual Review: Community Group's Work on Accessibility in Overlay Technology

Agenda:

1. Year-in-Review: Our Achievements

2. Deep Dive: Guided Reading of the Capabilities Draft Report

3. Getting on the Same Page: Terminology Discussion

4. Looking Forward: Next Steps

Details:

• Year-in-Review:

  • We'll discuss the major milestones and progress we've made in the past year.

• Deep Dive:

  • Highlighting Key Capabilities: Understand the capabilities present in COTS (commercial off the shelf) products. These are essential in evaluating and contrasting current technologies.

  • Future Potential: We'll discuss aspirational capabilities that hold promise for advancing accessibility, especially when implemented as edge technology.

• Getting on the Same Page:

  • Let's dive deep into the vocabulary we've come across. We'll carefully explore terms like "overlay", "user agent", "assistive technology", "browser extensions", and other edge-located add-ons to ensure a shared understanding.

Link to the Capabilities Draft Report

Looking forward to an insightful session. See you there!

Reviewing and possibly improving chartering of Working Groups and Interest Groups is an AB priority for this year.

The goal of this session is to review the landscape, and have people share what they like and dislike about how it currently works, and share their experience.

We don't expect to resolve on anything in particular during this session, but it can be a good time to surface and socialize potential improvements.

The base requirements for message formatting and localization are experiencing some significant advancements as the MessageFormat 2 spec is being defined in the Unicode Consortium, and the Intl.MessageFormat API is being defined in TC-39 for JavaScript.

Building on these, work should start on defining a localization system for HTML that's reactive rather than imperative, and which allows for localization without any JS dependency. At Mozilla, we've been using a similar system based on Fluent to localize Firefox and our other projects, and have learned much about what works and what doesn't. Some of our ideas have been collected as a draft of what this could look like in practice.

Link to slides

Link to minutes

As third party cookies become less available, tracking will shift further towards fingerprinting and other forms of covert cross-site tracking.

While it is infeasible to fundamentally remove or change usage of IP addresses or web APIs which could be used for fingerprinting, it is possible to curtail access to these surfaces in scenarios that are sensitive for cross-site tracking.

Browsers have been developing and shipping mitigations using tracker lists as a pragmatic path forward -- spanning IP proxying and active fingerprinting mitigations. There are some common challenges and potential opportunities across browsers.

The Interop Project is designed to improve the real world interoperability of web browser implementations by producing shared public metrics that show the test pass rates of important features, based on a curated selection of web-platform-tests.

In this session we will describe the current state of Interop 2023 and describe the process for submitting proposals for Interop 2024, and how the proposal selection process works. We will also be looking for discussion and feedback on the process, to gauge how well Interop is working for working groups and their participants, and for any opportunities to make improvements going forward, or new ways to improve the interoperability of web implementations in the future.

As a follow-up to the first part of Meeting Facilitation Training (video is online at [link here]), this session will be an in-person and remote discussion covering the second part of the training. Participants in this session will be expected to have watched the first part of this training in advance of the session.

This session is open to all meeting facilitators (chairs, taskforce leads, or aspiring to be), and will be a collaborative session covering tip and tricks participants use to make running meetings easier, and discussion on how to handle difficult discussions or situations as a chair or meeting facilitator.

Due to the nature of topics that might come up during the meeting, we will not be minuting the part of the session on difficult conversations, but will minute the tips and tricks discussion.

Post-TPAC note: No minutes were taken at this session.

We have a number of rough areas, and while we might not be ready to figure out a solution yet, we would love to chat about the current issues we are seeting. @b1tr0t and @beverloo have most of the context here (although @beverloo won't be at TPAC this year)

• Abuse / spam / requiring install for notifications

  • Chromium is seeing a large quantity of abuse across the ecosystem. We don’t believe gating notifications to installed use is the answer for reasons.

  • We are considering rate limiting and other countermeasures

  • Are there opportunities for standards revisions that might help?

• "important" notifications (VOIP). @beverloo notes:

  • MSFT already working on this:

  • Intent to Prototype on blink-dev, explainer, initial implementation

  • Example hero use-case - empower Skype on the Web.

  • On Android this would require a permission (FOREGROUND_SERVICE_PHONE_CALL) that we probably don’t want to issue to Chrome itself. Limiting this functionality to installed experiences seems good in either case, as otherwise there would be complicated incentives.

• Notification sounds (ringing?)

  • Related to important notifications, some apps might want a ringing sound

  • Somewhat limited by OS support of custom notification sounds, however, may be possible to create a “Safe” set of standard notification sounds for developer to choose from e.g. “Chime” “Ringing” “Alarm”, and perhaps others

  • @beverloo notes: This was part of a Microsoft proposal that we provided feedback on

    • Explainer

    • Long story short, a (admittedly brief) joint investigation showed that very few sounds would actually be consistent across operating systems, which is hard to explain to developers. It’s important that these are OS-consistent: ideally an e-mail in Apple Mail and one in Gmail alert Apple users in exactly the same way.

    • For Chromium to support arbitrary sounds, the media team advised that the best way to achieve that would be to load a (background) tab with a <media> element in which we play the developer-provided URL. That’s a significant system health cost.

    • On Android such sounds are tied to the notification channel as opposed to individual notifications, and actually cannot be set for individual notifications anymore.

• Notification channels.

  • Allow sites to register and send to specific channels, similar to capabilities offered on Android and iOS platforms

    • Can be a useful way for users to reduce unwanted notification volume, for example on a messaging app like IG the user could choose to allow DMs but not receive notifications about new posts in the feed

  • beverloo@ note:

    • ChromeOS is also very interested in this, would like to see something like this supported. We might be able to mimic support in Windows through grouping.

      • Nuances to consider on Android: channels are declared once and are then permanent, i.e. updating the importance, sound, vibration etc. of a channel should not happen after it’s been created, even when the channel’s name changes.

• Reducing notification energy use (currently need to spin up JS)

  • The current web notifications spec was designed with maximum flexibility as the objective. With the current spec, notifications require a Service Worker and when a notification is received, the ServiceWorker wakes and can then take some action.

  • The solution is an amendment to the notification specification that optimizes for the most common notification usage pattern of simply displaying a notification on the user’s device. This change will improve performance and energy usage of notification delivery.

  • @beverloo note: We’ve always been supportive of receiving push messages and showing notifications w/o involving the service worker, this would bring major system health benefits.

    • There has been some resistance from partners to support this as they need the SW / analytics logic to run for monetization.

    • Android would be able to support high priority notifications in a declarative path. This is important because the framework deprioritises notifications for an entire app (i.e. the browser) based on show and interaction rates, which means that currently a single misbehaving site can negatively impact the holistic browser notification experience.

    • Big +1 to doing this if we can get broader ecosystem adoption.

When we speak about sustainability and climate change, we think about long-haul flights and solar panels. We do not realize that our day-to-day digital behavior, like mindless scrolling, dark vs bright backgrounds, and the online advertisements we see, also contributes to our carbon footprint. This open discussion is about how we, the people on the web, can build products and technologies that are sustainable and positively impact the user behavior in a way that contributes to a greener environment.

In this session, we will explore how the deployment of Computational Intelligence as a Service (CIaaS) is reshaping web technologies and impacting the global digital community. We will discuss essential web technologies underpinning CIaaS, including cloud computing infrastructure, data analytics tools, and advanced machine learning algorithms. Participants will gain insights into how these technologies drive computational intelligence capabilities on the web, enhance user experiences, and facilitate data-driven decision-making. The session will also provide a platform to foster dialogue, exchange ideas, and build a community centered around advancing the application of CIaaS on the web. Whether you are an industry practitioner, a researcher, or a tech enthusiast, this session promises to enrich your understanding of the transformative power of computational intelligence on the web.

Verifiable Credentials and Decentralized Identifiers have gained significant momentum since their publication as W3C recommendations. The goal of this breakout session is to provide a quick introduction to these technologies, and showcase a number of their deployments.

Post-TPAC note: No minutes were taken at this session.

The Web Components Community Group will share their 2023 report on the APIs and specs that are deserving of prioritization across implementors in 2023 going into 2023. This follows up on previous reports in 2021 and 2022. From there, we will have an open discussion on how the community group can support implementors in shipping, coming to consensus, or altering various specs in order to get them into the hands of developers and their site/application visitors in as prompt a manner as possible.

Last years discussion focused on browser parity and spec alignment. Implementor partnerships lead to x-browser support for Imperative Slotting and Constructible Stylesheets, expanded support for Form Associated Custom Elements, and progress on CSS module scripts, as well as the triumphant return of the Web Components Spring Face to Face (albiet virtual) to further flush out features like Cross-root Aria, Scoped Registries, and Declarative Shadow DOM. We look forward to what we can do in the next year as we continue to develop the relationship between implementors and web developers.

The first barcode went beep at a checkout in Ohio almost 50 years ago (1974-06-26T08:01:00+05:00). GS1, the global organization behind the numbering system embedded in billions of barcodes around the world, is working with industry to replace it with higher-capacity, more functional alternatives. You won't be surprised to learn that in many cases this will be a QR code that contains a URI. But the URI has additional structure that encodes not just the basic product identifier but things like batch numbers, serial numbers, expiry dates and more. The ambition is that by the end of 2027, the original 1970s barcode can begin to retire.

This presents substantial opportunities for the Web. Some claim it also presents opportunities for bad actors. This breakout session is about:

1. How do I recognize a "GS1 Digital Link URI" when I see it? (example: https://example.com/01/09506000134352/10/ABC)

2. What can I do with it? Linked Data? HATEOS? (try https://id.gs1.org/01/09506000134352/10/ABC?linkType=all)

3. Whaddyamean the domain name isn't part of the identifier?? That's nuts! (it's also true)

4. How does this tie in with product conformance certificates, trade digitization, the forthcoming EU Digital Product Passport regulation, traceability, sustainability and generally 'selling more stuff'

5. Ah, forget it, it's a URL so I can do what I like... (true)

Web developers report that keeping up with changes to the platform is a major issue for them. Developers have difficulty keeping up with changes in the web platform, such as the introduction of new features and the resolution of interoperability issues, and knowing when features are well-established in their users’ browsers.

Even though many developers enjoy access to detailed information about their audiences and the browsers they use (e.g., through site analytics, support metrics, user interviews, etc.), others don’t or work at a remove from end users. A new project won’t have a measurable audience until it launches. A library maintainer or application vendor might have, at best, an indirect view of the capabilities of users’ browsers.

Despite the glut of information about browser support, releases, and global usage, these developers are left on their own to draw a platform-wide support picture, with ample opportunity for errors and confusion.

The Baseline project is one way that intends to help these developers by offering a shortcut past the complexity.

This session will discuss the lessons we learned in the WebDX CG, open questions we have, and possible ways forward to serve the web developer community.

ECMAScript is core to the Web Platform, so collaboration between the W3C and Ecma International has been key for many evolution initiatives on both sides. Ecma TC39, the committee were ECMAScript (a.k.a. JS) is standardized, has an efficient and inclusive process for standards development, which shares many qualities with the W3C process.

The organizations have a formal liaison relationship (enabling representatives of one organization to participate in the other, for example), but on the ground, Ecma TC39 has relied heavily on certain individuals in each organization to bridge the gaps. Many TC39 proposals have significant architectural impact on the Web Platform, and these impacts have been reviewed in WHATWG HTML threads as well as W3C TAG reviews.

Like the W3C, Ecma is expanding in its work areas. For example, Ecma has a new initiative to standardize source maps in TC39-TG4. Overall, new work in the web space within Ecma tends to take TC39's success as a model to repeat. This is going well for source maps so far.

The idea of this session is to start with a short presentation of where Ecma and TC39 are today and how we work together, and then proceed to an open discussion about how we can work in the future, in what areas and working modes, etc.

Most user interactions on permission prompts are negative. For notifications (the most requested permission type), Google Chrome metrics data shows that the percentage of prompts that are ignored, dismissed or blocked by the user add up to approx 92% on desktop platforms and 85% on mobile devices.

A permission model designed to be initiated by the user would solve these issues. If the user initiates the permission request it ensures that:

• The user understands the purpose of the permission, or at least has enough context to feel comfortable engaging in an activity that uses this permission.

• The user’s current flow or task is related to granting this permission and as such it’s unlikely that the permission request could be interruptive.

• The user agent can ensure the subsequent UI is placed near the current focus of attention of the user. This is because the user has just interacted with some piece of UI to request the permission which means their focus is likely in the area. Because of the above, it is unlikely that such a placement is interruptive or annoying.

This breakout would discuss a proposal for Permission Embedded Permission Control [explainer] [deck] and intends to continue the dialog from the w3c Workshop on Permissions held December 2022.

Session notes

This session discusses scoped custom element registry proposal.

This session will go over ongoing strategy issues and discuss how we could engage with the community on strategy.

In this session, we will discuss the possible impacts of generative AI on the Web. As it is an emerging topic and its consequences still need to be better understood, we will focus on technical and governance challenges in three main dimensions: data collection on the Web, Integration of LLMs in a search engine; production and publication of synthetic contents on the Web.

To facilitate the discussion, we will start from three main questions, which can be discussed in different groups depending on the number of participants:

• What are the limits of scraping web data to train Generative AI and what technical measures should be implemented to ensure privacy, prevent copyright infringement, and effectively manage content creator consent?

• What are the potential impacts of incorporating LLMs (Large Language Models) as chatbot interfaces into search engines? How would this change the web traffic and digital economy once the chatbot could respond directly to users instead of providing links?

• How could Web technologies help detect AI-generated content posted on the Web, restrain the dissemination of sensitive content, and provide accountability?__

This session will introduce updates for the Trustable Internet (formerly Trusted Internet) project and discuss standardization aspects. We are trying to materialize Trustable Internet that makes data on the Internet more trustworthy. Last year, we introduced a concept that assembles an endorsement overlay layer on top of the Internet (or the Web). The endorsement layer has additional information (endorsement data) for data on the Internet that desires "endorsement," such as Social Network posts, to provide additional information to viewers to judge the credibility of the data. After the last W3C TPAC, we published <a href = "https://tial.sfc.keio.ac.jp/blob/Trustable_Internet_Whitepaper_V1.0.pdf">a white paper</a>, then demonstrated a prototype implementation based on the concept mentioned in the above at IETF 116, March 2023. We are refining the data model and the systems architecture of the overlay,

Exploration of the modern use cases for web vector graphics, the current solutions and their limitations, and potential future improvements. Responsive vector graphics. Parametric Shapes. Better CSS integration.

W3C Accessibility Maturity Model Task Force will present an update on our latest public working draft (https://www.w3.org/TR/maturity-model/), and our last 2 years of work. We will answer questions from participants, and present real world examples of our model being put to use.

WebRTC has been playing an increasingly important role in more high-demanding scenarios. As the industry is exploring innovative ways to leverage WebRTC, they also identify some potential issues and requirements for this technology.

This session is proposed by a few real-time communication service providers (including clouding service provider, mobile operators, social network platforms, e-commerce platforms, etc) and they would like to share the use cases, development experiences, pain points, and discuss possible solutions with global WebRTC community.

See current proposal.

An overview of AB projects and priorities, focusing on those to which W3C Members, Team, and IEs are invited and encouraged to participate. These include:

• W3C Process and Process CG

• Vision

• Incubation

• Code of Conduct and PWE CG

Post-TPAC note: This session did not take place.

AsyncContext is a stage 2 TC39 proposal that allows propagating values across an async execution flow, much like Node.js's AsyncLocalStorage. However, when building this capability into the web platform we must consider the integration with web APIs – should setTimeout propagate the async context from the point it is called into the callback? What about event registration?

Furthermore, Chrome has been working on associating script-initiated actions from their causes further up the async call stack (tracking a task's attribution), which is useful browser-internally to enable metrics and web API improvements that would not be possible otherwise. Task attribution is the same as propagating browser-internal values across an async execution flow, so if we can ensure all of the task attribution use cases are covered by AsyncContext, the former could be built on top of the latter, in the specs and in browser engines.

Following up on last year's breakout session on cookies we want to start hacking on cookie layering and make it more concrete.

We're aiming for a focused working session, not a presentation or large group discussion.

Post-TPAC note: No minutes were taken at this session. Participants collectively drafted some of the algorithms that could end up in Fetch and in the Cookie RFC.

The Interop 2023 Accessibility Investigation has yielded a new implementation-independent accessibility testing infrastructure, and over 500 new automated accessibility tests… And we aren't done yet.

In 2023, contributors from Apple, Mozilla, Google, Bocoup, Igalia, Adobe, and more kickstarted new work that is now actively running in every major browser engine.

Come hear a summary of the work so far, learn how to contribute new tests, and discuss future proposals (such as AOM #197) for improving automated, sustainable accessibility testing beyond what is possible today.

This is a session to discuss DOM / Template Parts API proposed in https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md.

Proposals:

• DOM Parts Declarative API

• DOM Parts Imperative API

Have you ever wondered if AI Ethics is an Engineering or a Product issue? Which software development life cycle phase should you start addressing ethics in your AI system? How do we ensure that ethics are integrated into the solutions by design and not only implemented on top as an afterthought?

Addressing the need for fairness and accountability in AI, this talk will explore our efforts to navigate cutting-edge technology while ensuring the ethical development of AI solutions. We will examine the requisite shift in perspective and straightforward, actionable measures that empower enterprises to seamlessly infuse ethical AI into their core values, steering clear of prevalent pitfalls.

A huge amount of media content is produced every day, including TV and radio programs, ebooks, and news articles. These are provided through various online distribution and broadcasting services.

However, the reach of such content is limited by the means of provision. This reduces the opportunity for users to access information.

Content providers expect that content will be widely distributed among media industries and other industries such as tourism, education and health care, thus creating an ecosystem in which users consume various types of media content through their daily life.

In this session, we will share use cases and challenges where media content is utilized across services and industries and consider how metadata can facilitate an advanced and evolving collaboration among media industry.

The focus of the session will be on the possibilities of utilizing metadata across industries and its challenges by sharing ideas from different media industries. Technical discussion such as metadata formats, schemas and ontologies within and outside of the W3C is positioned as a future activity.

Members of the MDN team and the Open Web Docs collective will present on the topic of technical documentation of web features, its importance for feature adoption, its process, and how you (as a spec editor or feature implementer) can collaborate with us on it.

Parties such as Sellers, Buyers, Traders and Transport operators engaged in the trading of goods internationally work predominantly in digital siloed systems. These are typically laborious and expensive to connect and hence much of the time, trade takes place over paper or at best digital file formats that assure neither authenticity nor provenance. Additionally, they would benefit immensely from 2 functions of:

• Enabling users to control commercially-sensitive information whilst not compromising the reliability of the Verifiable Credentials being presented, which is important in cross-border trade.

• Enabling Verifiable Credentials to be paper-friendly in order to ease the transition to the digital medium by the paper-centric cross-border trade community.

Singapore’s Infocomm Media Development Authority will introduce TradeTrust as a framework for interoperable verifiable and transferable trade documents. TradeTrust is powered by OpenAttestation, an open-source technology framework created by the Government Technology Agency of Singapore (GovTech) for issuing verifiable documents. In production since 2018, besides for cross-border trade uses, OpenAttestation has been implemented in other domains such as academic credentials and vaccination certs.

The session is going to be a presentation part and discussion part.

Starting ServiceWorkers is known to be a slow process, and web users need to wait for its startup if the ServiceWorker intercepts loading the page resources. At the same time, the ServiceWorker brings flexibility to the transport layer, and it behaves as a client-side proxy. Developers can implement offline support or provide client-side content modification with it.

We have a couple of early ideas to minimize the performance cost, such as the static routing API, and skip no-op fetch handler. For the first half of the session, we’re going to present performance problems that we’re observing, outline of proposed APIs and how it works, and estimated performance improvements.

For the second half, we’d like to discuss ServiceWorker and performance with the community and ask for feedback on our ideas.

Continuing the SocialWeb Test Suite discussion, including test suite challenges and strategies, as well as demos of the in-progress test suite approaches.

Powerful APIs have been a constant source of contention when balancing the needs of making the web platform competitive while still providing the fundamental guarantees such as security and privacy. Given the trend of web-platform derivative application runtimes such as Electron becoming popular, the potential and user needs of this is clear - but how we can deliver such functionality while providing the security and privacy guarantees of a browser remains an unsolved problem.

As a simple example of this being a problem - fundamental platform functionality, such as accessing files is still in an unsatisfying state, leaving the web platform as a less desirable platform for developers to target serious applications against. Is there a path where we can have a standardized replacement for Electron, and if so, what kind of fundamental architectural changes would that entail?

This session would like to invite members of the community who are interested in contributing towards a solution to this. Of the participants, we would like to create a task force to identify unmet user needs on the web platform, attempt to find a path forward to tackle this problem space, and compile a set of principles and requirements that solutions developed to address these needs should follow. This venture will function as a TAG-endorsed task force, and the participants will be invited by the TAG chairs. Members may include current or former members of the TAG.

The task force would be identifying ways to bridge the gap between the Web Platform and native application platforms, while protecting security and user privacy, aligning with the TAG's Ethical Principles, Design Principles, the in-development Privacy Principles and the Privacy & Security Questionnaire. We would need to ensure this effort has multi-stakeholder interest, while ensuring cross-browser and platform support.

The web platform includes lots of specifications, and we don't have an easy way of distinguishing the ones that are adequately maintained, vs the ones that need more investment.

Some considerations include (but aren't limited to):

• Stable specs might not need much investment for long periods of time.

• We should include specs that have only one implementation, so that:

  • If a group starts showing interest in writing a second implementation, their issues should be very visible.

• Specs should triage issues fairly quickly, but it could be ok for low priority issues to sit around.

• We probably need a consistent set of labels.

• Chrome needs to do a lot of the maintenance, but the whole community should buy into the system and see the results.

Future discussion will happen on the spec-prod@w3.org mailing list.

This is a session to discuss an alternative to customized builtins based on the outcome of https://github.com/WebKit/standards-positions/issues/97

A short introduction to the AT-Driver specification, what it is, why we're writing it and why assistive technology vendors, browsers and wider community should get involved. This will be an opportunity for people to ask questions, raise issues and learn more about the spec and its application.

This session is to define expectations & guidance for advancing work in incubation and when to move it out (both to a WG or to a closing report), and how we need to adjust various practices and Process (e.g. WG chartering) to support this. Also in scope is the topic of "how should CGs be used at the W3c?" More background to be found at https://github.com/w3c/AB-memberonly/issues/81.

Compare the current spec of CSS Anchor Positioning and the alternative proposal by Apple, list the individual issues where the current spec can be improved, and try to reach consensus or resolve those issues.

The Rhonda Weiss Center for Accessible IDEA Data is excited to host this breakout session on Design Tokens for Accessibility Settings. As an organization dedicated to promoting accessibility and inclusivity, we firmly believe in taking an accessibility-first approach in all aspects of the product development life cycle.

IDEA stands for the Individuals with Disabilities Education Act. It is a federal law in the United States that ensures students with disabilities receive appropriate special education and related services to meet their unique educational needs.

In this session, we will review our groundbreaking efforts to develop an open-source tool for generating accessible reports of IDEA data. Discover how design tokens take center stage in delivering essential digital accessibility accommodations to end-users. This interactive discussion will showcase the pivotal role of design tokens in ensuring inclusivity and usability in accessing and interpreting IDEA data reports.

Design tokens serve as reusable and platform-agnostic values that define the properties of a design system. By harnessing the power of CSS with design tokens, we can enhance the inclusivity and accessibility of the user experience, particularly for individuals with multiple disabilities or intersectionality.

We will explore the idea of utilizing CSS tokens specifically tailored to address different disabilities and user needs. We'll delve into the proposed tokens for digital accommodations, such as those for low vision, color-blindness, dyslexia, ADHD, deafness and hard of hearing, motor disabilities, cognitive disabilities, photosensitive epilepsy, aging-related impairments, blindness, and more.

The session will provide an opportunity to:

1. Discuss the benefits and challenges of using CSS tokens for accessibility settings.

2. Share experiences and best practices in implementing design tokens for accessibility.

3. Brainstorm additional design tokens and discuss their potential impact on improving accessibility.

4. Explore ways to integrate design tokens into existing design systems and development workflows.

5. Collaborate on strategies to promote the adoption of design tokens for accessibility in the web development community.

Join us for an engaging and interactive discussion where we aim to collectively gather ideas, insights, and practical approaches for leveraging CSS tokens to enhance accessibility. Whether you're a designer, developer, accessibility advocate, or simply interested in inclusive design, your perspectives and contributions are valuable.

To develop features and discuss alternative designs, standardization groups often ponder the needs of web app developers. To collect feedback from developers, ad-hoc mechanisms are being used, including:

• Invitations to participate in the group, in group meetings or in group discussions

• Presentations in developer conferences and podcasts

• Shoutouts on social networks, possibly associated with formal or more informal surveys

• Internal research programs run by a company

• Broader developer surveys such as State of CSS, State of JavaScript, or the older MDN DNA survey.

Could more systematic developer research be conducted and made available to groups when they need it? The WebDX Community Group proposes this breakout session to discuss providing developer research as a service in standardization groups and collect requests for research data that groups may need.

For additional background, the WebDX Community Group, created last year, conducts research to make available quantitative and qualitative data to all aspects of the web platform feature life cycle. Current research data is the result of MDN short surveys and contributions to existing survey programs.

ePub format is a powerful open web technology for digital books. Considering the standard's possibilities, digital books can be more interactive and provide different experiences without letting accessibility best practices out of this scenario.

In this session, we will present some experiments with ePub books and discuss the potential of ePub technology and the challenges and opportunities for publishers and users. Participants are welcome to present experiments to enrich the discussion.

To facilitate the discussion, we will work with three main questions the participants can discuss.

• How a more interactive book can improve or get worse the publication accessibility?

• What are the challenges and opportunities for publishers in this field?

• How can authors explore this kind of experience in digital books?

Post-TPAC note: No minutes were taken at this session.

The identity space has recently seen a surge in interest, particularly from governmental entities, in what is known as the three-party model. This model is seen as an advancement from the current two-party identity systems, and involves a verifier (website), a holder (wallets), and issuers working together to enable the exchange of identity documents such as ISO mDocs or W3C VCs. However, this ecosystem currently lacks native browser support, and instead relies on general purpose and cumbersome primitives like OS intents. In this session, we aim to explore the use cases and overall landscape of this growing ecosystem and consider whether and how browser APIs could be leveraged to support it.

An open discussion of the TAG privacy principles draft with its authors.

Coordination discussion for exporting and importing SocialWeb data, including accounts, contacts and social graphs, posts and other content, bookmarks, lists, and various metadata.

Home Assistant is a smart home platform with a very strong community. The W3C Web of Things standards can be used within Home Assistant in different ways and bring two communities together with the following potential benefits:

• Easier integration of future IoT devices to Home Assistant

• Cross Ecosystem Communication

• Other ways to communicate with Home Assistant

• Getting wider feedback and use cases for WoT standards

There is interest for this session by @mmcool, @joshco and @relu91. We will decide later for co-chairs.

Web Worker Quality of Service

Web Workers enable multithreading in web browsers. By offloading compute-intensive workload to worker threads, we can achieve better UI smoothness and responsiveness. Till now, we have been using a cookie-cutter approach to offload such "background" jobs to Web Workers. Compute workloads have varied characteristics, some tasks are latency sensitive while some can function better in a consistent level of performance for prolonged periods of time. To satisfy tasks with different performance expectations, modern CPUs incorporate a hybrid architecture with high-performance and high-efficiency cores. Operating systems have APIs to control a thread's Quality of Service (QoS). Under the hood, hardware schedulering tools look at various performance monitoring units and give hints to the Operating System which makes the decision to deploy the task to a performance core or an efficiency core.

We propose introducing a quality of service attribute to the Web Workers so that applications and libraries have a way to explicitly label a worker’s preference of performance. User Agents can take this hint to configure platform thread and possibly affect the scheduling policy.

See the Explainer.

This is a session to discuss ARIA support across shadow DOM boundaries. This is a continuation of https://github.com/WICG/webcomponents/issues/1005.

Haptic feedback technologies, which stimulates the users' sense of touch through vibration, motion, and forces, has enormous potential to make digital experiences more enriching and accessible.

In this session, we will explore the current state of haptics technology and dive into its applications for improving user experiences and accessibility in various digital contexts. We will also discuss the challenges and opportunities in integrating haptic technologies into WebApps and Native Apps.

Topics may include:

• Current status of haptics APIs, hardware capabilities, and global standardization efforts in this field;

• Experimental exploration in using haptics to convey non-visual information/experiences, such as directional navigation, notifications, etc;

• Design considerations for using haptics in a way that works for diverse users and latest research achievements;

We welcome everyone to participate in this brainstorming session to explore how to make full use of haptic technologies and benefit the community.

See Intro video

Trusted Web is a vision to improve trust in the Internet by expanding the area where data itself and data exchange activities can be verified without overly relying on a specific service. Trusted Web is an ongoing effort of the Trusted Web Promotion Council (TWPC) organized together by academia, enterprises, and the Headquarters for Digital Market Competition, a part of the Japanese Government.

TWPC published white papers (version 1.0 and 2.0) until last year. The white paper discusses the backgrounds, principles, systems architecture, governance mechanisms, and guidelines for practical implementation. Ongoing discussions on data security technologies at W3C, such as Verifiable Credentials and Decentralized Identifiers, heavily influenced the architecture and its discussion. Also, the white paper reflects various feedbacks from multiple experimental projects or use case discussions.

TWPC members are working on the new whitepaper version to be published this fall.

In this session, one of the members of the TWPC introduces the current discussion and current architectural and governance design.

This session will explore how the new Web Sustainability Guidelines can serve as a catalyst for advancing digital sustainability and reducing the Web’s overall environmental impact. It will also examine how the Sustainable Web Design—’sustyweb’—community group found inspiration in WCAG and other W3C specifications to create these guidelines. Finally, we’ll explore the benefits that adopting these guidelines could bring to the internet overall. See also the At a Glance resource about the guidelines.

Discussion topics will include:

• Onboard TPAC attendees to emerging digital sustainability and sustainable web design guidelines.

• Answer questions about the guidelines.

• Foster a discussion about what this could mean long-term for W3C and the Web overall.

This session will be a precursor to our upcoming workshop, Secure the Web Forward, which aims to increase the overall security of web applications by addressing the need for clear, guidelines for web developers, identifying key emerging technologies and gaps.

Potential discussion points include:

• the web developer security issues that were highlighted in the recent survey

• encouraging collaboration between web standards and open-source security initiatives

• better documentation and guides for web developers

• updates in commonly used libraries and web standard APIs

• potential for a new security-focused task force between W3C and other organisations focusing on software security such as the OpenSSF, OWASP and OpenJS Foundations

Most popular user agents support “enterprise management” features which gives device owners control over the user agent. These features can modify the user-facing behavior of the user agent, such as by automatically configuring bookmarks or the home page, or by disabling features such as integrated developer tools. They may also affect web-exposed behavior of the user agent such as by automatically granting or denying permissions. Recent incubations have also proposed new APIs which would only be exposed to sites when running on a managed browser.

In the first part of this session, the various browser vendors and browser contributors discuss their current understanding and implementation status of the concept of Installable Web Apps, including, but not limited to and not requiring, prerequisites for enabling "powerful features".

We want to discuss how the Login Status API could be used in FedCM and other Web APIs to enhance user privacy and user experiences.

Some helpful context from previous discussions:

https://github.com/privacycg/is-logged-in/issues/53

https://github.com/privacycg/is-logged-in/pull/54

https://github.com/privacycg/meetings/blob/main/2023/telcons/08-24-minutes.md#notes

View Transitions allows developers to create animated transitions for DOM changes. The spec currently defines the feature for DOM changes within the same Document but we're actively working on extending this to cross-document navigations.

This session would go into the details of concepts being added for View Transitions on cross-document navigations and a few other extensions/feature requests we're evaluating.

Agenda:

• Brief background: W3C Accessibility 2023 Context

• Review in-progress W3C Accessibility Mission: Vision, Mission, Objectives. Any big things missing from the High-Level Objectives?

• Exploring priorities for 2024: Discuss selected Discussion topics.

Note: Before the breakout, you can nominate topics for discussion by commenting in GitHub #70

In 2021, W3C organized a workshop on Smart Cities, and identified the stakeholders around Smart City standardization and reasonable applications for Smart City technologies. In addition, we got initial input on how to organize the draft Charter for a potential Interest Group for further discussions.

Then in 2022, based on the the workshop results, we organized a breakout session during TPAC 2022 with invited key stakeholders from related SDOs, e.g., ECHONET, IPA DADC, IEC SC3D, ISO/IEC JTC1 WG11, ITU-T SG20 and OGC.

During the session, we saw related SDOs' standardization activities so far, and identified the following:

• "Digital Twins" should be the key concept for Smart Cities standardization.

• Web standards, e.g., Web of Things (WoT), Decentralized Identifiers (DID) and Verifiable Credentials (VC), should be considered as possible key modules for the possible Web-based Digital Twins framework.

• Standard vocabulary for semantic interoperability is also required for the platform.

• Collaboration by related SDOs is necessary for further discussion, and W3C should become the central hub for the discussion given Web standards play very important roles.

Based on the discussion so far, we've been discussing how to improve the draft Charter of the proposed Web-based Digital Twins for Smart Cities Interest Group, and would like to get input during this session at TPAC 2023 to finalize the draft Charter.

You can encode and decode using WebCodecs. But how do you send the encoded media over the network? You need to serialize it first. A container format like CMAF is overkill. If you're interested in WebCodecs and would like to send encoded media over the network is a lightweight way, come to this breakout room.

• Related interest in a WebCodecs MoQ Media Format in the IETF

• Related Open Screen Protocol work

A large variety of schema languages exist, defined inside or outside of W3C; to name a few: RDF-Schema, OWL, SHACL, ShEx, XML-Schema, JSON-Schema... Each of these languages have been favored by different categories of users, who in turn ignore, neglect, sometimes even despise the other languages, deemed "too complicated", "less powerful" or simply "not fit for purpose".

It might be tempting to consider that any schema language is worth any other, and that the "best" one is a matter of technological preferences. We argue on the contrary that these languages differ in their core purpose, and should be seen as complementary rather than competitors. More precisely:

• ontology languages such as RDF-Schema and OWL focus on the conceptual modelling of the domain,

• shape languages such as SHACL and ShEx focus on the logical modelling of the data,

• structural schema languages such as XML-Schema and JSON-Schema focus of the physical modelling of exchange formats.

Sticking to one schema language to cover all these aspects is therefore suboptimal. Creating bridges between their user communities, to allow cross-fertilization and combined use, is a promising approach.

But it is also challenging, because it creates the need to maintain consistency across schemas at different levels. We will present different tools and methods that have been proposed to deal with this problem, and discuss the standardization opportunities in this area.

FIDO is seeking community insights to get feedback on the team’s findings from UX research and through conducting screen reader audits of live Passkey deployments. The Team will focus on 3 key accessibility areas exposed through our research and audits:

1. What we know about Passkey accessibility as it relates to accessibility of the website as a whole

2. What we anticipate needing by ways of standardized support as auto-fill becomes essential in Passkey experiences.

3. What we don’t know about alternative transport mechanism that are accessible and can replace/supplement/modify current solutions.

The background and a demonstration of the WAI-Adapt Symbols Module, the inaugural segment of the broader WAI-Adapt technical specification. This module offers markup for symbols based on underlying semantics such as "food" or "help." Users can enjoy personalized web content, with symbols rendered in their own preferred visual language. This is the first semantics codified for such symbols, allowing for the diversity in symbol choices across different institutions, regions, and cultures. A notable application is in video chapter headings, facilitating at-a-glance access. The result will likely benefit people of all types of abilities, including people with cognitive disabilities, AAC symbol users and a general audience alike, as the symbols enhance readability.

Many critical anti-fraud use cases depend on highly re-identifiable client information to discourage scaled abuse and detect specific attacks. Scaled abuse includes problems like bulk account creation, password guessing, and spam, and generally centers on one client misrepresenting themselves as many (i.e. Sybil attack). Although these anti-fraud use cases generally do not track users, the browser cannot distinguish these from information collected for the purpose of tracking. If we were to reduce fingerprinting by limiting access to entropy-rich information without solutions for anti-fraud, we would encumber the people fighting fraud and accidentally encourage access gating or degraded experiences for benign users. We would like to explore whether some of these use cases can be satisfied without the risk of cross-site user tracking.

We previously suggested a device attestation mechanism experiment (WEI) that tried to provide rate limiting and allow the platform to prove its authenticity without limiting browser modifications, devtools, extensions, and similar. The feedback we received made it clear that we did not adequately anticipate the openness and interoperability concerns of the web, which we now share. As an alternative, we would like to explore experimenting with a narrowed use case and discuss how we can address interoperability and access concerns in our design. Specifically, is there value in attesting that the request is associated with a single user by proof of a “scarce resource” such as a third-party identity or proof of hardware, in a way that preserves privacy and allows attesters to compete on the basis of their performance?

Specifically we want to ask:

1. Is there value in downscoping to “attestation of a scarce resource” (e.g. third-party identity, proof of hardware, etc) with some protection against scaled misrepresentation / over-claiming?

   1. Confirm: Enforce rate limiting against a scarce client resource is a capability that currently relies on collection of re-identifiable information.

   2. How scarce does this resource need to be?

   3. What latency-tolerant use cases are relevant?

   4. What other anti-fraud / defensibility requirements should we keep in mind?

2. In order to preserve the openness of the web, a diverse set of “sources of scarcity” should be available to users. In order for the confidence of all verdicts to not be compromised by a single source, a quality bar has to be upheld.

   1. Where should the discussion about how an issuer identifies suitable attesters take place?

   2. Opinions on high barrier to entry and no feedback on observed quality vs. lower barrier to entry and feedback on observed quality

Discussion rendering of existing HDR content (images/video), proposed HDR APIs (canvas/WebGL/GPU), the need for more expressive media queries, and interactions with CSS colors.

Slides.

Specific issues:

• Review of definitions of HDR displays and HDR content

• Standardize rendering of HDR content (issue)

• Add CSS property to limit HDR brightness (issue, proposal)

  • Default behavior for HDR content (no issue)

• More expressive queries about HDR screen capabilities (issue)

• WebGPU HDR support

  • Extended range support (proposal)

  • Tone mapped support to match HLG and PQ (no issue filed)

• 2D Canvas and WebGL HDR support

  • WebGL floating point support (drawingBufferStorage proposal)

  • 2D Canvas and ImageData floating point support (issue, proposal)

  • 2D canvas HDR support (proposal), or alternatively use same metadata from WebGPU proposal

We will discuss about options to install applications using the web platform. API? Install banners? cross platform support? tracking campaign ids? Let's discuss what installation on the web looks like.

This breakout session will:

• Briefly recap the Partitioning :visited links history explainer.

• Discuss the proposed solution, generate open questions, and get cross-browser feedback.

• Go over implementation progress in Chrome and highlight solutions that may be valuable to other developers.

• Discuss how to spec this proposal and how standardization choices now may affect future privacy improvements to CSS

• Determine what work remains towards removing the 2010 privacy mitigations.

A breakout session to report on the progress of the member relations program offered by W3C to its members. Panelists and participants will discuss how W3C can contribute to the community of the members.

• Do members want country or region-specific networking?

• Any issues when you joined?

• What is "Ambassador"? What is the environment in which they are created?

• Mutual aid among members?

• What support would members like W3C to provide?

• What do we want Chapters for members?

W3C specifications use a common set of stylesheets and markup conventions, which are documented at https://www.w3.org/StyleSheets/TR/2021/README and maintained at https://github.com/w3c/tr-design (Bikeshed and ReSpec output this format.)

In this breakout session we will:

• Do a quick review of what capabilities are already built into our site-wide CSS and HTML conventions, so that you can use them effectively (and avoid custom styles)

• Discuss when to put custom styles in your own CSS vs when to upstream them for everyone

• Answer questions about our technical report styling and templates

• Discuss possible improvements, and maybe draft some up!