Web Environment Integrity has no standing at W3C; understanding new W3C work

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.)

Self-review for Web platform designers

As a starting point and as part of web developer advocacy, most W3C horizontal review groups have created guides and self-review documents so that key aspects can be resolved autonomously:

• The Technical Architecture Group exists to help ensure that the Web makes sense as a platform, and that the design is coherent. Among the criteria of any TAG review is evaluation against the Design Principles (which includes the priority of constituencies), the Privacy Principles, and the Ethical Web Principles.
• The Framework for Accessibility in the Specification of Technologies (FAST) explains by types of features how to ensure that a technology is accessible to users with disabilities.
• A short i18n review flags areas to pay particular attention to in the Internationalization (i18n) quality approach taken early to avoid costly and sometimes prohibitive obstacles when rolling out products or a technology to meet the needs of people in different cultures, or who use different languages or writing systems.
• The Security and Privacy self-review questionnaire helps specification authors as they think through the security and privacy implications of their work designing new features for the Web platform.

From an idea to a Web standard

If there is interest in describing more the various steps new work takes at W3C, we can start a series of articles. In the meantime, I thought I would leave you with a final note on how any specification becomes a "standard" in W3C: it needs to show multiple, interoperable implementations.

Let us know via email if you have questions or what you would like to hear more about.