W3C China organized a Web Technology Forum in June 2023, which was held as a hybrid event with the main in-person hub in Beijing. We are now pleased to share the report of the event, including recorded videos of the 20 talks during the forum (English and Chinese captions are available).

The forum gathered the Web community in China, nearly 100 onsite attendees and over 17,000 watching the live streaming, discussed the latest Web technologies and identified the possible requirements for Web standards.

The forum was kicked off by Philippe Le Hegaret (W3C Strategy and Project Management Lead) giving an overview of the Web standardization work on Web Neural Network, Machine Learning, Security, Private Advertising, WebRTC, WebAssembly, WebGPU, WebTransport, WebCodecs, WCG, HDR, Incremental font transfer, DID/VC, WCAG and Sustainability.   

For a few weeks now we have been hearing concern in the Web community in regard to Web Environment Integrity, and are asked more and more about it. Our silence is due to the fact that the Web Environment Integrity API is not being worked on in W3C, nor has there been any submission to W3C for W3C Technical Architecture Group (TAG) review.

In the rest of this article, I want to take the opportunity to explain generally how new work is brought to the World Wide Web Consortium, and how several W3C work groups coordinate what we call "horizontal review". This review and other safeguards we have in place, transcends a particular technology by focusing on aspects that impact people and the Web: Web accessibility, architecture, internationalization, privacy, and security.

Bringing new work to W3C

Candidate W3C work arises from W3C Workshops or Member Submissions, or tracking the activity in public W3C Community Groups. New work starts at W3C by initiating new working groups based on interest from W3C Members and Team, or landing in existing working groups (in which case, the groups' charters are updated.) New charters and revised charters both require Member consensus.

Passing W3C "horizontal review"

The W3C Process Document enshrines "horizontal review" as a requirement. For a new working group, the review is done internally before any proposed charter is brought to W3C Members for approval. For new technology or specifications, the review must be done as part of publication on the W3C Recommendation track (i.e., the progression stages from an idea to a Web Standard.)

In the ever-evolving landscape of web development, security remains a key concern for developers. A recent survey gathered responses from 297 developers visiting MDN, asking them to rate the challenge they face with various security aspects in their development workflows. These responses offer a clear indication of the complexities and challenges encountered in daily development tasks.

60% of developers find the addressed security aspects 'Somewhat challenging' or 'Very challenging'. It's evident from this that we have a problem. There is a substantial need for enhanced education, tools, and best practices to assist developers with security issues across the board.

Delving deeper into the individual security aspects:

• Detecting security vulnerabilities was highlighted as the most challenging aspect, with 71% of developers marking it as 'Somewhat challenging' or 'Very challenging'. An area with clear scope for improvement, it further emphasizes the need for better tools and education.
• Understanding security threats followed closely, gathering 69% of 'Somewhat challenging' or 'Very challenging' responses. As threats evolve continuously, this response underscores the crucial requirement for up-to-date education and efficient tools.
• The intricacy of understanding the web browser's security model came third, seen as challenging by 66% of developers. The ongoing evolution of web technologies may contribute to the difficulty in understanding the security model.
• Safely integrating third-party services received mixed responses. While 55% found it challenging, 27% felt neutral about it. This perhaps reflects the trust developers place in identified companies offering these services.
• Keeping frameworks and libraries up-to-date was another mixed bag, with 54% finding it challenging but 20% considering it easy. This suggests that while the actual updating of dependencies remains challenging, the tools alerting developers about new dependency releases have become mainstream.
• HTTPS Configuration was rated the least challenging aspect, with 45% finding it challenging and 31% considering it easy. It indicates that either server configuration is seen as a well-known task, or hosting services may be assisting developers with these issues.

The survey also highlighted the challenges of staying updated with new security threats, integrating third-party code securely, the lack of cybersecurity content in formal education, and other issues such as regulatory compliance.

One thing is clear: if we want to address these challenges we need to do so holistically. That means we need to get people talking to each other across silos.

To further address these concerns and foster an open dialogue, we're inviting you to participate in the W3C, OpenSSF, OpenJSF, and OWASP workshop: “Secure the Web Forward.” If you would like to participate in this groundbreaking workshop you have one week left to submit position statements. It’s clear that the ecosystem needs to come together to address these challenges. We hope that this workshop can be a step along the road to building a secure future for web development.

The redesigned W3C website is now live! 

There is more to do, but this deployment concludes the four months the site was available in Beta, which followed a year of internal preparation, and two years of work with UK-based digital agency Studio 24, to whom we awarded the website redesign project in early 2020. For me personally, this is a milestone of the “action item” I took over 4 years ago to communicate more effectively what our organization does with a more modern, inclusive, usable website. 

Redesigning a website and content that has been building up since 1994 is a massive undertaking, so we chose to break it down into phases and focus first on a subset of the public-facing pages most useful to key audiences: 

• W3C homepage 
• /Standards, /Participate, /Membership, /Consortium 
• W3C Blog & Blog article 
• Business ecosystem landing pages 
• Work Groups 'profile' pages (new) 
• /TR homepage 
• Account pages 
• Others as determined by Information Architecture 

This as well as goals and other related elements are documented in a slide deck I created at the start of the project. 

On the surface, the new site implements current web best practices and technologies, donned a cleaner and elegant visual design, and provides information (in many cases rewritten and consolidated) in a more user-friendly fashion. 

Under the hood, everything changed. From the complete information architecture to the CMS and the tools that make all of our sub-sites work together. 

Feedback on the site itself and the content is expected as issues on our GitHub repository. 

We will gradually work to address existing non-blocking issues (in association with Studio 24 who now help us with support and maintenance), and to include the rest of the site as part of this design, starting with deploying the Chinese and Japanese localized sites for which we have seeded a lot of the work already. 

Finally, I want to acknowledge the considerable help I got along this captivating project from the entire W3C Systems Team, in particular this project could not have happened without the contributions from Vivien Lacourba, Jean-Guilhem Rouel, Gerald Oskoboiny, Laurent Carcone, Denis Ah-Kang. Thank you. 

More information on the W3C Website redesign: 

The goals of the redesign were to achieve a cleaner and modern look and greater usability, better accessibility, as well as ultimately simplifying how the site is managed. We also want to offer integrated Japanese and Chinese versions. 

Studio 24 documented the collaboration and process on the redesign of our website in a “work in the open” site, notably today's update. You can read more about today’s milestone from Studio 24’s blog post. 

The convergence of web innovation, light app technologies, and mobile devices is transforming the digital landscape. The “Web Technologies for Applications” workshop and coding contest, organized the Systematic Paris-Region cluster and the Open-Source Software for Information Systems (OW2) in coordination with W3C, brings together industry professionals, web developers, researchers, programmers, and technology enthusiasts to explore the latest trends and advancements in web applications in a mobile context.

Take part in this exciting day and register free of charge for June 13, 2023, in Paris !

Starting from the mid-2000s, web access through mobile devices experienced a remarkable surge, driven by the popularity of smartphones and the availability of affordable, high-speed mobile data networks. At that time, W3C launched the Mobile Web Initiative to make browsing the Web from mobile devices a reality. In parallel, mobile native apps were adapting to user expectations, including seamless connectivity, smooth interactivity, etc. To orient developers and content providers who wanted to create the same or even a better experience on mobile, W3C maintained and published roadmaps of Web Applications for Mobile collecting information about standardization and implementation status of features described in W3C specifications and others.

As society embraces an “always on, always connected” real-time paradigm, coupled with the emergence of smart homes, smart cities, AR/VR, AI bots, etc., new challenges have arisen. These challenges prompt us to evolve existing global standards and forge new ones, while addressing concerns such as data privacy, cyber security, online harassment, and more. Simultaneously, we must strive to maintain an accessible and user-friendly development process.

At the event (9h00 – 14h00), renowned experts will deliver engaging sessions:

• Dominique Hazaël-Massieux (Head of DevRel, W3C) will review and compare how Web technologies are used across ecosystems, and highlight opportunities for greater convergence among them.
• Martin Alvarez-Espinar (Head of Web Standards, Huawei) will present the background and current status of the W3C MiniApp specifications, developed collaboratively by industry leaders and stakeholders within the W3C MiniApps Working Group.
• Alex Bourlier (Co-founder, Startin’blox) will explore how Data Interoperability and Data Sovereignty can be enhanced among the MiniApps ecosystem by making use of initiatives like the Solid Project, International Data Spaces (IDS) or Gaia-X.
• Simon Phipps (Standards & Policy Director, OSI) will suggest some definitions and principles over what open source and open standards have in common, and what distinguishes them.
• Fabien Benetou (Prototypist, consultant in WebXR for the European Parliament innovation team) will demonstrate how an immersive experience can take place directly in the browser we are already so familiar with.
• Romain Vailleux (Partnership & Ecosystem Manager, Apizee) will explore the possibilities offered by WebRTC, with a particular focus on use cases and applications.

With an informative workshop, a challenging coding contest, and opportunities for networking and recognition, this event is a must-attend for those looking to expand their knowledge, showcase their skills, and take their web development career to new heights.

Join us to shape the future of web and mobile experiences, ensuring inclusivity, security, and accessibility for all. The event is located at 16-18 Rue Vulpian, 75013 Paris.

The afternoon will be devoted to a code contest for students, who will have to develop and test a lightweight application (PWA, Quick App) to promote a city’s resources. The 3 best projects will win cool prizes! Register here.

In your materials for Global Accessibility Awareness Day (GAAD), we encourage you to include relevant resources from the W3C Web Accessibility Initiative (WAI).

WAI Resources for GAAD

For a list of free online resources to support digital accessibility, see WAI Resources.

Resources particularly relevant for GAAD include:

• Making Events Accessible – Checklist for meetings, conferences, training, and presentations that are remote/virtual, in-person, or hybrid
• Introduction to Web Accessibility
• Digital Accessibility Courses

WAI Updates

For monthly updates on current WAI work, see What We’re Working On – Accessibility Activities and Publications.

For those interested in Web Content Accessibility Guidelines (WCAG):

• An updated draft of WCAG 2.2 was published on 17 May 2023. See WCAG 2 Overview and What’s New in WCAG 2.2 Draft.
• WCAG 3.0 is exploring a different approach. It is years away from being completed. See WCAG 3 Introduction.
• You can get announcements of WCAG updates via e-mail. See Get WAI News.

WAI Leadership

W3C accessibility work is led by:

• Kevin White, Development and Operations Lead
• Michael Cooper, Strategy and Technical Lead
• Shawn Lawton Henry, Education and Communications Lead

WAI staff also includes Ruoxi Ran and Daniel Montalvo.

To reach WAI staff, you can e-mail wai@w3.org.

本帖也有简体中文版本 (This post also exists in Simplified Chinese)

New! AT support tables in the Authoring Practices Guide (APG)

The ARIA and Assistive Technologies Community Group (ARIA-AT CG) and ARIA Authoring Practices Task Force (APG TF) are excited to announce the launch of “Assistive Technology Support” tables in the ARIA Authoring Practices Guide (APG). This initial release includes tables showing JAWS, NVDA, and VoiceOver support levels on four pages that demonstrate pattern implementations, including Button Examples, Link Examples, Radio Group Example Using aria-activedescendant, and Alert Example. More are coming soon.

This “Can I Use…” like data showing how three screen readers support four UI pattern implementations represents a sea change in accessibility engineering. The data are the first taste of the fruits of nearly five years of collaboration, learning, community building, and process and infrastructure development.

That fruit makes predictable screen reader behavior possible. That possibility portends a world where any web developer can build rich web experiences that work well with any assistive technology as readily as they can create experiences that work in any browser for people who do not rely on assistive technology.

The problem of the “accessibility supported” puzzle

It has always been a struggle, often a monumental and expensive one, for web developers to find ways of coding experiences that are understandable by users of any assistive technology (AT). You get your site working with one AT and it ends up not working as well with another. Then the experience of your site with an important AT degrades because the latest version of that AT includes changes to better support a popular site that has encoded a similar experience in a different way. Of course, the degradation was unintentional. As is often the case, accessibility experts frequently have conflicting understandings of how to satisfy relevant specifications. Consequently, unintentional negative side effects are difficult if not impossible to avoid.

Web, browser, operating system, and AT developers are all attempting to cut pieces of a puzzle. Everyone hopes that, when assembled, the puzzle will picture a usable web built from accessibility supported experiences. Unfortunately, while browser and operating system developers get pretty clear and stable maps showing where to draw their cutting lines from specifications for ARIA, HTML, and various accessibility APIs, web and AT developers do not. They do their best, but the act of drawing moves the puzzle board, messing up the lines being drawn by others. What’s worse is they occasionally discover ink has randomly disappeared. So, the way the picture is divided constantly changes. Sometimes pieces fit together, giving users a good experience, but far too often, they don’t.

Understanding WCAG conformance defines what we need for a new technology, like an ARIA-enabled UI pattern, to be accessibility supported:

“When new technologies are introduced, two things must happen in order for people using assistive technologies to be able to access them. First, the technologies must be designed in a way that user agents including assistive technologies could access all the information they need to present the content to the user. Secondly, the user agents and assistive technologies may need to be redesigned or modified to be able to actually work with these new technologies.”

So, even when browsers and accessibility APIs are perfectly implementing their specs, we don’t yet have everything necessary to design and build web UI patterns that are “accessibility supported.” For that, we also need:

1. Consistent understanding across web development communities of “all the information assistive technologies need to present” a given pattern, which accessibility semantics best represent that information, and which ways of coding the pattern accurately express those semantics.
2. Consistent interpretation and rendering of accessibility semantics across the AT industry, such that there are shared expectations for acceptable AT responses to a given semantic in a given pattern.
3. All stakeholders having sufficiently similar understanding of the meaning of “actually works” for any given pattern.

In other words, web developers and AT developers need to be on the same page, and that page must not only synthesize information from a wide variety of specifications but also include information about what “actually works” for AT users that has not been available anywhere.

Helping map the rest of the “accessibility supported” puzzle

The ARIA-AT CG and APG TF have been jointly working to align the web development and AT developer communities. They are building missing pieces of the foundational infrastructure needed to generate the information and consensus that can make “accessibility supported” web UI patterns available to any web developer and users of any AT.

First, to foster harmonization of how accessibility semantics are used in practice by web developers, the APG TF has been transforming the Authoring Practices Guide into a platform that supports the multiple facets of that goal. To start, it provides thirty patterns for using ARIA semantics. To demonstrate how to apply those patterns in practice, it also includes more than 60 example implementations of the patterns. As of the time of this announcement, the APG also provides the equivalent of “can I use …” data, i.e., AT support tables, for four of the reference implementations.

That “can I use …” type of data comes from the ARIA-AT project. The objective of ARIA-AT stated in terms of “WCAG accessibility supported” is to build consensus for definitions of “actually works” that are specific to every accessibility semantic defined within a specification related to ARIA. It is starting with semantics employed in APG patterns.

The challenge of defining and testing AT behavior that “actually works”

Figuring out how to define, develop consensus for, and test baseline expectations for AT behaviors has proven to be as fantastically challenging as anyone might have imagined. In 2018, the ARIA-AT CG set a five-year goal of testing 60 APG examples with three desktop screen readers and two mobile screen readers. Even with the scope limited to a select few screen readers, the goal was more ambitious than we anticipated. Last year, we had to dial back our end of 2023 target to testing 30 examples with three desktop screen readers. The good news is that progress is solid, and the community group is proving that 1) AT interoperability is a realistic industry goal, and 2) if we can keep the work funded, universally available accessibility supported web sites can one day be a reality.

At a high level, the major elements of the APG TF and ARIA-AT CG AT interoperability work are:

1. Build the supply of sufficient, robust, and stable test cases that represent real-world usage of accessibility semantics. The initial source is the APG. There could be many more in the future.
2. Craft statements of expected AT behaviors in the form of test plans. This is very difficult work that is executed by community group members from Prime Access Consulting, which you can read about on the PAC blog.
3. Develop systems for managing the stakeholder consensus process, manually running tests, and serving reports. These systems are being delivered by community group members who work at Bocoup, and you can learn more about that work in this post on their blog.
4. Develop and implement an AT automation standard that enables tests to be re-run within continuous integration systems for every new version of an assistive technology or browser. As described in the two previously referenced posts, Bocoup is leading development of the AT Driver standard, and PAC is developing the NVDA implementation.

All that is enablement. The deliverables from those workstreams make it possible for community group members and stakeholders to run tests, gather feedback on test plans, define issues, negotiate consensus solutions, incorporate resolutions into test plans, and finally raise and resolve AT bugs.

Screen reader partnership

Given that the community group is kickstarting AT interoperability with an initial focus on the three most popular desktop screen readers, progress depends on effective collaboration with the developers of those screen readers. One of the critical enablers of today’s launch has been the involvement and responsiveness of Vispero and Apple.

Negotiating the details of how to test interoperability and adjusting screen reader behaviors to align with the expectations defined by the tests is substantive work. The community group is seeking ways of helping NVAccess (developer of NVDA) build the capacity it would need to support it as well.

What’s next

In coming months, AT support tables will be added to more APG example pages. The ARIA-AT CG is developing a quarterly schedule for covering the rest of the APG, and we plan to make it publicly available soon. Over the course of 2023, as we integrate automation into the process, the tables will include data for more screen reader and browser combinations.

In 2024, as we complete the first round of test plans for desktop screen readers, we plan to start adding test plans for mobile screen readers. Assuming continued success and funding, the project will expand to support more types of assistive technologies and test more accessibility semantics.

Get involved

To learn more about how you or your organization can participate or support the project, visit our wiki page about contributing to the project.

The World Wide Web Consortium’s Technical Architecture Group (TAG) has recently established a task force to create a set of privacy principles for the web. This initiative is part of the W3C’s ongoing efforts to promote and protect privacy on the web. The Privacy Principles document lays out a set of principles that aim to guide the development of new specifications for the web platform, with the goal of eventually publishing it as a W3C Statement. This effort builds on previous work by the W3C’s Privacy Interest Group and the TAG’s Security & Privacy Questionnaire and Ethical Web Principles, which underscore the importance of respecting users’ privacy in web design and development.

We welcome your feedback on the document. We encourage you to leave that feedback in the document’s Github repository. We would like comments before the end of April.

It is with bittersweet emotions, that I share that Karen Myers’ time as W3C Business Development Leader for the Americas and Australia is ending.

After 18 years, Karen has chosen to retire from the World Wide Web Consortium to pursue personal endeavors. We want to take this opportunity to thank Karen and to reflect upon her contributions to W3C over her many years of service.

We welcomed Karen Myers in 2004 to assume the role of Acting Director of Communications, and we were fortunate to later gain her help with marketing and business development for memberships. In both areas, Karen’s technology marketing experience, her positive energy and love of learning were strengths which enabled her to accomplish the challenge to create business value propositions that made clear both the power of the Web and the value of Membership so that organizations would consider joining W3C.

Karen’s achievements over the years, allocating her time between marketing, media coordination, and business development were numerous. To name only a few:

• coordinating the communications of our Director Tim Berners-Lee’s knighthood by Her Majesty Queen Elizabeth in 2004.
• planning the W3C ten-year anniversary events and gala.
• working with Tim on some of his speeches —including his first TED talk.
• putting together international W3C events at the Consumer Electronics Show (CES) in Las Vegas (USA) and Mobile World Congress (MWC) in Barcelona (Spain), the first Web and TV W3C Workshop in Hollywood (USA) where we began the work to “make video a first-class citizen of the web”, which in turn led a few years after to W3C receiving one of 3 National Academy of Television Arts and Sciences (NATAS) technical Emmy® Awards.
• coordinating with W3C Evangelists and Chapters in publishing, media and entertainment, automotive and accessibility, and supporting global outreach and educational events.
• recruiting and onboarding hundreds of new members to participate in W3C standards activities and more.

Going forward, I, Alan Bird, Global W3C Business Development Lead, will resume Karen’s day-to-day responsibilities immediately. Naomi Yoshizawa, Global W3C Member Relations Lead, will handle member relationship and other administrative questions. And Philippe Le Hégaret, W3C Project Management Lead is the contact for operational questions regarding W3C groups charters, W3C process, and participation in work groups.

Farewell and best wishes to Karen in whatever new adventures she chooses to pursue next!

With the start of the year 2023 we pass a milestone in the evolution of the global collaboration project that is the World Wide Web Consortium: In our 29th year of operation, we are operating now as World Wide Web Consortium Inc, continuing with Beihang University (China), ERCIM (France), and Keio University (Japan) as partners.

At the broadest level our mission continues unchanged, with the W3C Advisory Board leading a project to renew the expression of that mission.

Our community – our Members, non-Member contributors, Team, and all who use the results of our collective work – will continue to refine their expectations of this project and we will continue to adapt to those expectations.

Our strength derives from the diversity of our global inclusion. This should be our guide as we continue to refine the best arrangement of the elements of this project.

Thank you for your continued engagement in this global effort to maintain one world wide web with equitable access for all its users.

–Ralph Swick, W3C Interim CEO

Latest EPUBCheck 5.0.0 preview is available!

We are pleased to announce the latest preview release of the next major version of EPUBCheck, v5.0.0. For the first time, this version fully implements the new rules in EPUB 3.3 (W3C Candidate Recommendation Draft).

We encourage users to effectively test this version of EPUBCheck in their production workflows to get ready for EPUB 3.3!

The full change log is available on the EPUBCheck preview release page.

Please file comments, bug reports, and feature request to our issue tracker. Or, come help with the translation of EPUBCheck into your favorite language!

When surveyed, 38% of developers in general seem to dread using Web technologies (HTML & CSS, JS in StackOverflow 2022 survey); and when asking Web developers and designers more specifically, 23% aren't satisfied with the Web platform (MDN DNA 2020 survey). This could be worse - but how can we make it better?

As a development platform, the Web platform is fairly unique in being provided through competing browsers which implement a shared set of standardized technologies. This combination of cooperation in defining the technologies and competition in implementing them has long been recognized as an important driver of improvements for the platform as a whole, as implementers innovate on new user facing features and protections, improved developer tools, and increased performance.

While competing implementations are a great driver of innovation, it also creates fragmentation, a regular top pain point that developers report (e.g. browser compatibility pain point in MDN DNA survey 2020). What feature can developers rely on to ensure that their app will work on the combination of devices, operating systems and browsers that they need to serve?

Understanding and monitoring what constitutes the interoperable surface of the Web platform is a non-trivial task, especially as browsers now get updated on a very regular basis.

The Interop project is an ongoing effort to bring cooperation not just about the definition of technologies, but also about their deployment, with the clear goal of reducing fragmentation developers most suffer from.

Similarly, Open Web Docs provides home for cooperation in developing another key part of the developer experience, documentation, through contributions to MDN Web Docs.

To build on these positive patterns, the WebDX Community Group was launched a couple of weeks ago with a mission to facilitate coordinated approaches to improve the overall experience of developing for the Web platform. The group will initially focus on two key areas.

First, it will enable shared research on the pain points that developer face. Previous shared research efforts include the MDN Web Developer Need Assessment surveys that ran in 2019 and 2020. Their results unambiguously highlighted the cost of fragmentation for developers, and with additional complementary research, were key drivers of improvements in this space, in particular via the Interop project. The WebDX Community Group intends to provide a home to discuss topics and infrastructures for shared research on developer needs and wants. Our efforts start with a collaboration on short surveys that will run on a regular basis on MDN (with our deep gratitude to Mozilla and the MDN team). During W3C TPAC unconference in September, we also collected a number of other suggestions about how shared and curated research could help us take better decisions for the platform.

In complement to that, we want to provide structural improvements in how developers can understand and manage fragmentation: reducing fragmentation (as proposed by the Interop project) is the preferred approach, but some fragmentation is unavoidable (e.g. because hardware capabilities may differ across devices), and some of it is probably a necessary consequence of the competitive model of the platform.

We want to make it easier for developers to track the list of features that are widely available and those that are under development. My colleague and WebDX Community Group co-chair François Daoust developed an analysis of how features get described and their implementation tracked across a variety of tools and systems, including MDN Browser Compatibility Data and Can I Use that many developers already call upon to answer these questions. We believe that we can improve our approaches towards reducing fragmentation and making sure that developers know about it, provided that we can describe and agree on features that compose the Web platform.

It's still early days! If you want to contribute and improve the developer experience of the most popular platform, please join the WebDX Community Group or bring your input to our GitHub repositories.

Associated with several WAI transitions, it has been announced that I will take over some aspects of Judy Brewer's role, in order to ensure continuity of the WAI program after her departure in January. I want to share with everyone what I know so far about what this means for WAI. This is an interim assignment for now, for which I feel well-positioned to bring my experience in W3C to help WAI and W3C evolve through the current transitions.

My priority is to keep the work moving forwards, including working groups and projects associated with WAI, as well as the behind-the-scenes activities that enable the staff to support that work. I will need to make time for this work, and am glad my colleagues Shawn Henry, Daniel Montalvo, and Roy Ran will expand their responsibilities as well. For those of you who know how embedded I am in the Accessibility Guidelines work, be reassured that I plan to continue active involvement in that group so I can continue to provide institutional memory, and my characteristic approach at understanding issues, to this challenging work.

Another transition is that Kevin White rejoined WAI this week, bringing a great deal of experience in program management and digital accessibility. Our respective strengths and experience will help us ensure the work progresses smoothly. We will also work with WAI staff and W3C to determine what roles the program needs going forwards, and how we might fill those with current and future staff. My own role after the transition will be addressed in those discussions as well.

Many of you know me mostly in my role as staff contact to the Accessibility Guidelines Working Group, as well as to the APA and ARIA groups. I've been involved in this work for over 20 years, and have vision for how to move WAI forward through the staff and W3C transitions. I look forward to engaging with a broader set of stakeholders than I have so far, and to helping lead WAI into its next phase!

Several changes are in progress at the W3C Web Accessibility Initiative (WAI), each exciting in different ways. W3C and WAI staff are supporting our accessibility work on the current path during this transition.

WAI Staff and Roles

Judy Brewer will be leaving WAI for a new opportunity. She shared more in a WAI Transitions message. From 24 October 2022 to 13 January 2023, Judy will be available part-time to help the transition for stability and continuity of WAI at W3C.

Kevin White rejoined the WAI Team in October as Accessibility Development and Operations Lead. Kevin will contribute his accessibility, technical, and program management experience to WAI's work in Europe and internationally.

Michael Cooper has taken up some interim leadership responsibilities to ensure smooth transition of the WAI program. He will also remain the primary team contact for the Accessibility Guidelines Working Group, to help guide that challenging work. Michael shared more in Stepping Forward on WAI Management.

Shawn Lawton Henry, Roy Ran, and Daniel Montalvo are also taking up additional responsibilities in the interim.

Over the next few months, WAI will refine roles and responsibilities for W3C accessibility work, and explore coverage by current and future staff.

W3C Supports WAI Going Forward

"W3C is proud of WAI's successes under Judy's leadership," said Ralph Swick, W3C COO. "W3C is committed to continuing the important accessibility work of WAI to advance the Web for All."

WAI staff will work on WAI vision and strategic plan in early 2023, with input from the WAI community and the broader W3C community. Core accessibility work will continue, and we look forward to defining the focus and priorities for 2023 and beyond.

Current WAI Work and Updates

To get up-to-date information on active projects, upcoming publications, and more, see:
What We’re Working On – Accessibility Activities and Publications
To get future updates, see: Get WAI News
To learn about existing accessibility standards and supporting material, see: WAI Resources

Please feel free to reach out to any of us directly with questions and suggestions. (and please be patient if we are slow to respond:) To send e-mail to all W3C WAI Team, you can use: wai@w3.org

We look forward to working together with the community to advance digital accessibility through WAI at W3C.

W3C's annual conference TPAC 2022 concluded in September when our Community was able to meet in person for the first time in three years.

The conference was in hybrid format. The main in-person hub was in Vancouver, Canada, with over 360 on-site participants. Meanwhile, TPAC 2022 fully included the remote participants in our meetings and offered them the possibility to be participate actively in the discussion.

What attendees said - How TPAC 2022 went

“TPAC is taking Covid measures extremely seriously.”
Our Events Planning team always puts the safety and experience of attendees at the very first place. They worked hard to set up appropriate health rules, carefully taking into account various requirements such as the evolution on the health situation and its impact on the attendees.

"Just really nice to see everyone again and have somewhat organic conversations over some coffee or a lunch, or during a walk." - Though hallway and informal conversations are the main TPAC assets, this year we gave higher priority to making sure TPAC was a safe place and therefore had to limit the contacts among participants. To support attendees' social demands to the biggest extent, lunches and breaks were more staggered than usual and attendees were given the option to have their breaks and meals outdoors.

"Also the organizers did an awesome job ensuring people could participate in every meeting remotely." - Provided by our technical support team, audio and video equipment was available in each meeting room ensuring a good experience both for onsite and remote participants. The remote participants were also able to attend the plenary sessions which have been video-broadcasted.

"It’s great to see so many important players gather around the same table..." - The event brought together W3C technical groups, the W3C Advisory Board, TAG, Advisory Committee, and the public, to network and work to resolve challenging technical and social issues. During TPAC 2022, the Working Groups, Interest Groups, and Community Groups held 90 meetings gathering a global community of web developers, architects, and product teams to advance standards development on emerging web technologies, to make the web work for everyone.

The technical plenary day, consisting of 45 breakout sessions, offered a great opportunity for everyone to meet and liaise, brainstorm ideas, and coordinate on a wide variety of topics relating to W3C activities, ranging from Web Components, Privacy, Accessibility, WoT, Open UI, Web Monetization, Digital Twins, WebViews, Trusted Web, Multicast, Web3, Sustainability, W3Cx Online Courses, Web Developer Experience, W3C Member Support, just to name a few.

During the AC open session, W3C CEO Jeff Jaffe presented “W3C Strategy, past, present, and future” on the W3C launch as a new legal entity in January 2023, and the AB proactively communicated with members about the transition plan and progress.

The Developer Meetup gathered the global Web community to coordinate the development of Web standards, and delivered four talks during the event, which illustrated how W3C community paves the path of creating solid Web standards, from incubating an idea to a deployed standard that people can reliably use and adopt. See more in W3C DevMeetup report – Vancouver, 2022.

Given the travel restrictions and time differences, W3C/Beihang Host organized a TPAC China Hub in Hangzhou to provide an in-person gathering place to support sessions that are particularly relevant to the Chinese community, covering topics around metaverse & Web 3.0, multimedia & WebTransport, Web Editing, MiniApps and Accessibility. The Chinese Member meeting also debriefed about the W3C Legal Entity transition plan and its potential impact.

Next meetings

We are looking forward to the next annual conference, which will be held in Europe. More information coming soon.

On September 13, 2022, in Vancouver BC, Canada, the W3C developer relations team organized a developer meetup as part of  the annual W3C TPAC2022 (Technical Plenary /  Advisory Committee) week for the global Web community to coordinate the development of Web standards.

Today, we are pleased to share the recorded videos of the four talks that were delivered during the event. They illustrate how W3C community paves the path of creating solid Web standards, from incubating an idea to a deployed standard that people can reliably use and adopt. Each of these videos come accompanied by their transcripts and the set of slides the speakers used:

• Greg Whitworth (SalesForce) related the research and incubation work happening in the W3C Open UI Community Group [ video, transcript, slides].
• Aram Zucker-Scharff (The Washington Post) gave an overview of the work done in the Private Advertising Technology Community Group, as it is transitioning into a more formal part of the standardization process  [ video, transcript, slides].
• Within the standardization track, new CSS features are emerging from the W3C CSS Working Group and Miriam Suzanne (W3C Invited Expert) demonstrated what intrinsic Web design allows as an evolution of responsive Web design and where container queries & units play an important role [ video , transcript, slides].
• Finally, illustrating the work that remains to be done once Web standards are well developed, Rachel Andrew (Google) presented the Interop 2022 initiative which aims to make specified web platform features work exactly the same across browsers, a key requirement Web developers have before they can adopt new features [ video, transcript, slides].

This event was made possible thanks to the support of our sponsors, to which we want to express again our gratitude: Yubico, Igalia, Samsung Internet, FTG, WithYou and Legible.

Follow us on @w3cdevs and subscribe to our YouTube channel to track new Web technology development, and to learn of opportunities to contribute to W3C work!

After a three-year hiatus, W3C held TPAC 2022 in person in Vancouver. It was really great to be back in person, and I heard that sentiment from just about everyone. More than 360 people registered to attend TPAC in person and another 250 joined remotely.

Below I summarize discussions of the meetings I attended: the Web Payments Working Group, the Web Payment Security Interest Group, and joint meetings with the Web Authentication Working Group and the Antifraud Community Group.

Web Payments Working Group

The Web Payments Working Group agenda opened with a focus on Secure Payment Confirmation (12 September minutes):

• Adyen and Airbnb shared some information about their SPC pilot. The discussion led us to topics such as the importance of user education (for the new user experience), some ideas for the timing of user registration (post-transaction), and the potential value of sharing a FIDO attestation when using SPC in a delegated authentication flow.
• Google presented their current work to bring SPC to Chrome on Android. That led to discussion about (and strong interest in) SPC availability beyond browsers in native Android apps.
• FIS shared thoughts on three topics of interest: shops making the transition from brick and mortar to digital-first, online stores looking to create a seamless shopping experience, and merchants that prefer strong control over the user experience. Across these topics there were three main themes:
  • Merchants want to know who their customers are prior to authorization. On this point we discussed the impact of tokenization and potential benefits of ensuring that the Payment Account Reference (PAR) can be communicated during an EMV® 3-D Secure transaction that involves SPC.
  • Data is not always available based on payment types or implementations.
  • Cart abandonment is a problem due to extra friction and payment problems.
• Microsoft shared some perspectives as a merchant that adopted strong customer authentication in Europe. They emphasized the important of frictionless authentication and indicated (as FIS also indicated) that stronger authentication can lead to cart abandonment; see the Microsoft slides for details. Key takeaways were thus that a great SCA user experience is very important (hence our emphasis on SPC) but that frictionless risk assessment is still very important. Microsoft reiterated during the talk that merchants do not like to hand over the authentication experience to banks, which, to me, reinforced the value proposition of SPC where merchant controls the authentication ceremony, and the bank can still validate the results.
• We then revisited some EMVCo observations about SPC and some changes that the EMVCo 3-D Secure Working Group has requested, including support for non-payments use cases, recurring payments, and more alignment with user experience requirements defined in the EMV® 3-D Secure specification.

We opened the second day of the WPWG meeting (13 September minutes) with discussion about the Payment Request API, which advanced to Recommendation just before the start of TPAC. Both Apple and Google expressed interest in restoring some capabilities related to address collection that are implemented in their respective browsers, but that were removed from version 1 of the specification for privacy-related reasons. I expect the features will be re-introduced so that interoperable implementations are documented, even if not recommended in their current form. The Working Group is likely to try to evolve the feature to address the previously registered privacy concerns.

After that:

• Apple then described some changes to ApplePay.js over the past couple of years that could be integrated into Payment Request. This was useful for helping the group develop a potential roadmap for new work on the API.
• We then discussed some upcoming changes to browsers related to "Bounce Tracking Mitigations." Bounce tracking refers to very quick redirects from one site to another and back, usually without the user knowing that the redirect has happened. As with previous discussions about privacy-related changes to browsers (e.g., IP address masking, user agent string masking, removal of third party cookies) we discussed the likely impact on user recognition and fraud prevention.
• In the same vein, we then heard about changes that the Chrome team plans to make to their Payment Handler implementation based on other changes on the Web related to privacy. The theme of data collection and risk mitigation continued into the Thursday joint meeting (below).

Tuesday Joint Meeting

On Tuesday afternoon, four groups met: the Web Payments WG, the Web Payment Security IG, the Web Authentication WG, and the Antifraud CG (13 September joint meeting minutes):

• The Antifraud CG, launched in early 2022, has developed as set of use cases; these include both payments and advertising use cases. Proposals to address these use cases are emerging, and we heard about several of them during the joint meeting, in particular about device integrity attestations. We also discussed trust tokens, currently in development in the Web Incubator CG.
• The Web Authentication Working Group summarized the state of specification and deployment of passkeys (cross-device FIDO credentials) and device public keys. I have the impression that device public keys —not yet implemented— could play an important role in payments use cases so that a Relying Party make make risk decisions based on previously seen devices. Those decisions may also rely on attestation availability, and it was pointed out that attestations are optional with Device Public Keys and may not always be available. We then discussed technology developments around a user experience question that we've heard before: if, for privacy reasons, a party cannot query the browser to determine whether the user has already enrolled credentials, how does that party know when to offer the user a registration experience?
• In the final session of the joint meeting, we discussed the status of SPC and broached several topics of ongoing coordination with the Web Authentication WG. We heard that our proposed "cross-origin bit" is now part of FIDO CTAP (and will be made public soon). The Web Payments Working Group next needs to register the extension with IANA. The WPWG re-raised the topic of cross-origin credential creation, which is permitted in SPC but not in Web Authentication. While there is some support within the Web Authentication WG to reconsider this capability in Web Authentication Level 3, there is not yet consensus.

Antifraud discussion, in particular about Device Public Keys used for fraud prevention, continued during a Wednesday breakout on Antifraud.

Thursday Joint Meeting

On Thursday, both the Web Payment Security Interest Group and the Antifraud Community Group held individual meetings as well as a 90-minute joint session on patterns of payment fraud (15 September WPSIG/Antifraud minutes):

• Entersekt presented some payment fraud patterns (e.g., account takeover through phishing, SIM swap, or social engineering; chargeback fraud, and card skimming attacks). We discussed current mitigation techniques (e.g., IP address monitoring) with attention to how those might be affected by privacy-related changes to browsers. As it was put in the meeting, "Browser fingerprinting is not good enough anymore." Our colleagues from Entersekt evaluated some of the Antifraud CG Proposals in development to see which might help with payments fraud use cases. I anticipate we will soon discuss a proposed new risk signal based on the joint discussion.
• Our colleague from the University of Illinois Chicago presented findings from research Phish in Sheep's Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting. One interpretation of the research is that it illustrates the limits of current approaches data collection used for payment fraud mitigation.

We made good progress at TPAC in understanding use cases, formulating the value proposition of SPC, and emphasizing the need for more fraud prevention tools (with some useful whiteboarding in the mix). I anticipate the groups will want to meet again in person well before TPAC 2023.

TPAC 2022 will be a hybrid event: in-person in Vancouver, with remote participation. I believe more than 600 people have registered, and it looks like more than 350 people will attend in person. This will be my first in-person meeting in about 3 years.

I have been working with multiple groups on a coordinated agenda about payments, authentication, and fraud prevention:

• Monday and Tuesday morning: Web Payments Working Group
• Tuesday afternoon: joint meeting of WPWG, Web Payment Security Interest Group, Web Authentication WG, and Antifraud CG
• Wednesday afternoon: Breakout sessions
• Thursday: Web Payment Security IG, with joint discussion about payment fraud patterns with the Antifraud CG. That agenda link requires W3C Member access.

I'm looking forward to discussion about Secure Payment Confirmation (SPC). We expect to hear about a pilot from Airbnb/Adyen, emerging support for SPC on Android, and other industry perspectives about the current version as well as next use cases.

I'll summarize the meetings in a few weeks!

Why Does Accessibility Need a Maturity Model?

It’s not enough to get a product accessible. The entire product experience should be accessible, and organizations need to implement processes and systems that can objectively measure whether the correct steps have been taken to keep the product experience accessible. This maturity model additionally includes employee-facing communications, training, documentation, and tools. Incorporating Information and Communications Technology (ICT) accessibility into an organization’s workflow and quality governance can be a complex process. While some organizations have individuals or departments that support accessibility, many do not yet recognize the importance of ICT accessibility as a requirement or the need for accessibility governance systems. This can limit these organizations’ ability to produce accessible products and services and their associated training and documentation on an ongoing basis.

In an organization of moderate or large size, no one department can be responsible for accessibility. It takes a collaborative effort from numerous departments to establish and implement accessibility governance systems throughout the organization. These systems integrate ICT accessibility criteria into policies, key business processes, organizational culture, and management structures in a consistent, repeatable, and measurable fashion. Only then can organizations address the complexities related to enabling ICT accessibility on an ongoing basis.

Maturity models have been around since the 80s. They generally contain a number of levels with increasing levels of maturity. Each level contains a definition, controls, a list of processes, and proof points that can be produced for an organization to legitimately claim that they are at a particular level of maturity.

This proposed W3C Accessibility Maturity Model describes an overall framework for establishing a robust, repeatable ICT accessibility program and identifying areas for organizational improvement. The W3C Accessibility Maturity Model is a tool that:

• helps people, groups, or organizations assess their accessibility practices
• identifies gaps between the current capabilities and the next level of accessibility maturity
• encourages improving overall accessibility performance over time

Accessibility Conformance Reports / Voluntary Product Accessibility Templates (ACR/VPATs) look at a snapshot of single version of a product frozen in a point of time. There are no guarantees about the accessibility of that product later in the product release timeline because ACR/VPATs don’t assess whether accessibility can be repeated.

Organizations know when they are doing well (or poorly) with product accessibility using audit reports and bug counts. However, these metrics don’t indicate how the organization is doing operationally to continue to produce accessible products. Examining key corporate processes is critical to making this determination, and ACR/VPATs, audits, and defects don’t do that. The W3C Accessibility Maturity Model is a big part of a “shift-left” methodology of preventing problems from recurring, not fixing them after they have happened.

Accessibility maturity modeling is very different than accessibility conformance testing

• Conformance testing provides information about the level of accessibility conformance of a particular product at a particular time. The results of a conformance test provide a picture of a particular version of a product (or a subcomponent of a product).
• Maturity modeling provides information about the ability of an organization to produce accessible products over the long term. The results of a maturity modeling assessment provide a holistic picture of an organization’s accessibility initiatives; where the organization is doing accessibility well and where improvements can be made to remove barriers.

We encourage people and organizations who could benefit from implementing the W3C Accessibility Maturity Model to review the Group Note and provide comments back to help us refine and improve the document.

W3C invites the vibrant Vancouver-based tech community to its Developer meetup, on Tuesday 13 September 2022 (6:00 -8:45pm PT). This event is free of charge but registration is mandatory and operates under COVID-19 health rules.

We are very much looking forward to connecting with local developers, designers, product and project managers, etc., who are interested to learn about Web standards under development, as well new initiatives put forward to shape the future of an even better Web.

A great line-up of speakers

As an opportunity to discover and learn what is making the Web an exciting development platform, we are proud to introduce this year’s devmeetup speakers:

• Rachel Andrew, technical writer at Google, will explain how the Interop 2022 effort will improve the experience of developing for the web in key areas.
• Aram Zucker-Scharff, The Washington Post, will explain the ambition of the proposed Private Advertising Technology Working Group to specify web features and APIs that support advertising while acting in the interests of users, in particular providing strong privacy assurances.
• Miriam Suzanne, W3C Invited Expert, will show how CSS Container Queries have a lot to offer, how to start using them in production, and what to look forward to as Container Queries continue to evolve.
• In “Open UI: unlocking creativity”, Greg Whitworth, Sr. Director of Product on the Web and Mobile Platform team at Salesforce, will present the Open UI initiative under the auspices of the W3C Open UI community group to allow web developers to style and extend built-in web UI controls.

Thanks to our sponsors!

Follow us on @w3cdevs  to read more about our speakers and discover sponsors’ demos between now and the #w3cdevs2022 meetup.

We recently announced that we are planning to start redirecting all of www.w3.org to https, as is commonly done elsewhere.

To get an understanding of whether this change is feasible for our site and what issues might arise, we conducted some limited tests of this configuration change, on August 1 and August 18-19.

Here are some notes on what we have learned so far, and answers to some questions we have received.

We receive a lot of automated requests for machine-readable resources on our site and have for many years, see for example this blog post from 2008. Due to the huge amount of traffic (hundreds of millions of requests per day) and the generic user-agent headers that are commonly in use (for example Java/xx), it’s hard to identify the source of most of this traffic. Also the generic user-agent strings make it difficult to do targeted outreach to the developers of the software making these requests.

Therefore we decided to do some limited tests of redirecting our entire site to https so any issues could be discovered and understood. We weren’t sure if this would only impact a handful of people who could easily adapt with some simple configuration changes, or if it had the possibility of being more disruptive.

During our initial tests we heard from a few people that this was causing issues with their systems that make automated requests to our site, for example when doing XML Schema validation. We are hoping these systems can be reworked to either follow the redirects to https, or use an XML catalog to keep local copies of any files needed to avoid making unnecessary requests to our site.

Questions we have received include: what action are we expecting from Web developers? Is it necessary to update all references starting with http://www.w3.org/ to https?

In general that is not necessary, and in fact in many cases those references to our site starting with http://www.w3.org/ must be preserved exactly as is, for example in a reference to an XML namespace that must be an exact match for a given string.

If you maintain a software system that retrieves resources from www.w3.org, please check whether it has the ability to handle redirects and https and update the software if needed. Also consider carefully whether you want to keep this dependency on our site or if it would be worthwhile to rework your systems to remove it, for example using an XML catalog. We do our best to keep our systems available and performant but we have occasional service outages like any other site. We expect most people would not want their production systems to be impacted by issues with our site.

We plan to continue limited tests of this change to our site over the coming weeks and months to gather more feedback in order to understand its impact before deploying it more permanently. Depending on the results of these tests we may decide to defer this change until more software can be updated, or deploy it with specific exceptions for example continuing to serve .xsd files via HTTP while redirecting the rest of the site.

To stay informed of future tests and other updates to our systems please stay tuned to our systems status page.

W3C's main web site www.w3.org has been available via https for over a decade, but until now we have not been redirecting all requests to https as is commonly done on most other sites.

The primary reason for this is that we wanted to avoid causing issues for software requesting machine-readable resources from www.w3.org such as HTML DTDs, XML Schemas, and namespace documents.

We believe enough time has passed for most such software to have been updated to handle redirects and https, so we are planning to start redirecting all requests received over http to https within a month or two.

In order to discover any potential remaining issues and to give some advance notice in case there are software systems that still have issues with redirects and https, we plan to conduct some limited tests before fully deploying this change to our site, where we redirect all http traffic to https for a few hours at a time.

The first such test is planned for Monday August 1, for 8 hours starting at 14:00 UTC (14:00 UTC to 22:00 UTC)

Update 16 Aug 2022: The second test is planned to run from Thursday August 18 to Sunday August 21, for 72 hours starting at 14:00 UTC on Thursday.

Update 19 Aug 2022: We ended the second test early, at 17:30 UTC today due to several complaints that this change was impacting production services. We plan to conduct another test in two weeks, for 48 hours starting at 17:00 UTC on Sep 1, ending at 17:00 UTC Sep 3. If you have dependencies on our web site in your production services please work to remove them, or update them to handle redirections and https.

If you have any questions or comments about this planned change, please post a comment here or contact us by email at sysreq@w3.org

W3C WAI announces publication of the Group Note Accessibility of Remote Meetings. It is a companion to the more succinct W3C resource: How to Make Your Presentations and Meetings Accessible to All.

The impact of COVID-19 has seen a substantial increase in usage of remote meeting platforms. Before 2020, software-based remote meeting applications were available, but not necessarily viewed as critical. The shift to remote meetings from a complementary tool to a replacement for face-to-face contact, has driven significant innovation in this space, including improvements in the provision of accessibility for people with disabilities. More recently, hybrid meetings, combining in-person attendance with remote participation, have become more common.

Yet despite the rapid growth of remote meeting platforms and innovation, there has been little formalized guidance to date on how to ensure remote meetings are accessible. Part of the issue lies with determining who is ultimately responsible for ensuring accessibility. To take the provision of captions as an example, it is necessary for a remote meeting platform to support captions, a process to be put in place to create them, and for the meeting host and participants to know not only that captions are available, but also how to ensure the they are included. This demonstrates the shared responsibility, across different audiences, for remote meetings to be accessible. It is with this in mind, that this guidance has been created to gather important accessibility considerations in the one publication.

This W3C Group Note is sectioned into different audience groups and includes, guidance on vendor procurement planning. It is critical for organizations to make informed decisions about the accessibility of remote meeting platforms they choose to use. The document covers the need for remote meeting platforms to adhere to accessibility standards in their development, and the need to ensure content used in a remote meeting is accessible to all participants. There is also guidance for hosts and participants regarding how to make all accessibility features of the platform available during an online or hybrid meeting.

The Research Questions Task Force (RQTF) of the Accessible Platform Architectures (APA) Working Group considered how best to support these different audiences, while also linking guidance back to relevant W3C standards where applicable. Accessibility of Remote Meetings captures knowledge and experience gained in the last several years on how to support the diverse needs of people with disabilities in the software, organizations and activities through which remote and hybrid meetings take place. Thus, by encompassing the entire process of delivering accessible meetings (not just the technical aspects of Web standards and software implementation), this work builds on and complements the earlier RTC Accessibility User Requirements.

Accessibility of Remote Meetings is expected to be of broad interest to a variety of audiences, including meeting platform developers, meeting organizers, and participants with disabilities. In addition, it has the potential to influence subsequent work of W3C Web Accessibility Initiative including future formal accessibility guidance.