The Sustainable Web Design Community Group is now closed. Its activities are now under the direction of the W3C Sustainable Web Interest Group. This includes the curation of the Web Sustainability Guidelines. Thank you for supporting us as we reached this stage in our journey and we hope you will continue to support our work as it develops at our new home (where you are welcome to get involved).
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
We’re excited to share that a draft report of this group’s Web Sustainability Guidelines (WSGs) has been published.
Inspired by W3C’s work on the Web Content Accessibility Guidelines, the specification includes 93 guidelines with 232 success criteria, references, examples, and more. It represents nearly two years of work from about 50 volunteers across five different committees:
UX Design
Web Development
Hosting & Infrastructure
Product & Business Strategy
Metrics
The guidelines reflect ESG principles outlined in the Sustainable Web Manifesto. They also align with GRI standards to help organizations more easily incorporate the impact of digital products and services into broader sustainability reporting initiatives.
Want to help us spread the word about the WSGs? Please consider sharing the links above with your networks, writing a blog post, or including them in presentations you give.
To that end, we’re presenting a guidelines walkthrough followed by a Q&A session on Wednesday, September 13th at TPAC. See the full TPAC schedule for details.
Feedback and Next Steps
We welcome your participation and feedback. Please post any issues you might find to our GitHub repository.
Also, this work has just begun. The report is a first draft. We’re still conducting monthly meetings about how best to improve and promote the guidelines. Everyone is welcome. Hope to see you at the next meeting on September 27th at 8am CT/3pm CEST.
Finally, and most importantly, a massive thank you to all who contributed. This is a monumental leap forward in advancing web sustainability. It wouldn’t have been possible without the help of those who volunteered their time and expertise.
We’re a global group of digital professionals who aim to make the web more sustainable. The group is currently collaborating on a set of guidelines to help web teams create greener digital products and services. You can help!
Here are some quick links to get you started:
Read the Group Charter to learn why this group exists and what we hope to accomplish.
Review the wiki to catch up on meeting notes, review draft guidelines, and learn about various committees within the group.
Join the Slack Community to meet other community members, share ideas, and request an invite to our monthly meetings.
This document has been reviewed by community group members and, where applicable, adopted the Community Group Charter template provided by W3C. It provides important governance information relevant to this community group.
Mission
This group will create guidelines, tools, and resources for web and digital professionals to incorporate sustainability and related principles into their workflows and work practices. Our goal is to make the process of creating and managing the entire life cycle of digital products and services more sustainable, while the use of digital products should also encourage better practices for users.
We ground all our work in the three pillars of sustainability:
Environmental: We prioritize the health of ecosystems and the planet overall.
Social: Similarly, people should have access to resources, information, and opportunities necessary for their well-being.
Economic: Financial stability and equitable economic development—in this case, through the digital economy—ensures shared prosperity for the planet and its inhabitants.
Scope
The group will provide evidence-based, peer-reviewed recommendations on how to create more sustainable digital products and services as defined above.
Success criteria includes:
The guidelines are used by digital professionals across sectors to create more sustainable digital products and services.
The guidelines are adopted by schools, bootcamps, universities, and other educational institutions as best-in-class.
The guidelines are also included in future legislation and procurement requirements for organizations commissioning digital projects.
Out of Scope
This group will not create Specifications.
Duration
Sustainability is an ongoing and evolving concern. New topics emerge regularly. As such, this group should remain relevant for as long as the issues it addresses are. To accomplish this, we envision an organizational structure that encourages collaboration and ongoing participation and supports leadership transitions as needed.
Deliverables
Understanding that this work is intersectional:
The group will offer guidelines for common digital sustainability practices in creating, managing, measuring, maintaining, and retiring digital products and services.
Where applicable, it will also suggest business and project management resources to guide organizations on broader sustainability principles.
Similarly, the group also acknowledges that non-browser based variables are sometimes relevant to our work and should be addressed on a case-by-case basis. Examples include: green web hosting, renewable energy pricing and availability, OS-specific issues, government policies, and so on.
Whenever possible, the group will recommend indicators to measure success based on their ability to yield consistent results and create broad impact.
Finally, the team will also seek to build alliances between other initiatives that work to build a better web. For example, a more sustainable web should also be more accessible for everyone while also respecting user privacy and data ownership.
Deliverables
Non-Normative Reports
The group may produce other Community Group Reports within the scope of this charter but that are not Specifications, for instance use cases, requirements, or white papers.
Milestones
Milestones for this work will be based on evidence-driven research and defined as the group grows and evolves.
Committees
This group has several committees dedicated to specific subtopics of the parent topic:
UX Design
Business Strategy, Product management
Analytics, Measurement, Reporting
Hosting, Infrastructure, Systems
Web Development
Committees will review and approve individual suggested lists and resources first before submitting them for a broader group vote to be included in our overall recommended guidelines. If you would like to join a committee or create a new one, please reach out to propose a topic.
Dependencies
Generally, we will suggest a list of guiding principles similar to WCAG’s principles (perceivable, operable, understandable, robust), along with specific suggestions for each individual discipline. This feeds into a master list of guidelines.
The group will take advantage of existing resources and compiled lists to create our recommendations. We also look forward to collaborating with other W3C groups working on intersectional topics.
Confidentiality
This work will be created publicly and transparently using open source principles. We will also abide by W3C’s level of confidentiality guidelines.
Meetings & Cadence
Individual committees will meet as often as is necessary to move their suggested guidelines forward under the timeline suggested by the main group. The main group will meet at least once per quarter to discuss progress.
Communications
We will share updates in this community group.
More formal proposals, records, and resources will be housed in this group’s GitHub repository.
Ongoing discussions will take place in the #sustainability channel of the W3C Slack Workspace.
Voting Procedures
Committees will vote on issues relevant to their topics, then present the outcomes to the main group. If needed, the main group can also vote on them.
Time Commitments
This community group is comprised of busy, working professionals. Committees will meet at the cadence and velocity that works best for each group, taking into consideration the time needed to prepare and review materials before and after each meeting. The main group will meet at least once quarterly for no less than an hour.
Intellectual Property
This group adheres to open source practices. Under the W3C banner, we will follow its policies and legal guidelines. However, we will pursue the most open and freely available licensing for anything the group produces.
Community and Business Group Process
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization’s legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual’s first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
Transparency
The group will conduct all of its technical work in public. If the group uses GitHub, all technical work will occur in its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group’s public mailing list, or to a GitHub issue if the group uses GitHub.
Decision Process
This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn’t clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue).
If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with.
Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group’s public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the decision process.
It is the Chairs’ responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.
Chair Selection
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organization, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.
Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes, no two from the same organisation, is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs.
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
Amendments to this Charter
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.
To kickoff our collaboration, we created a draft charter for a sustainable web design interest/working group. This is required by W3C to provide recommendations. We thought it might be a good place to start our collaboration.
You can find the draft in this Google Doc. It is unfinished and very rough. Please add comments, content, edits, and suggestions to the document when you can. We’ll close comments at the end of June.
An hour-long kickoff meeting will be held on Tuesday, June 21st at 8am CDT in the U.S. where we’ll review progress on the charter and also discuss:
Introductions
The group’s primary goal
Charter review
Define roles, timelines, next steps
To get added to the calendar invite for this meeting, please email tim@mightybytes.com with your interest.
A few members of this group recently met with W3C to discuss creating sustainable web design recommendations, perhaps similar to the WAI‘s Web Content Accessibility Guidelines (WCAG) or perhaps something new entirely. For many of us who have worked in web/digital sustainability for some time, this seems like a natural next step.
Primary Take-Aways
Here are the main take-aways we pulled from the W3C conversation:
Sustainability is already included as part of W3C TAG group. There is potential overlap with other groups as well, which might mean more possible collaborators.
Standards and recommendations are two different things (WCAG is the latter, we might want to start there).
Community groups are great to get as many people involved in discussing a topic, shared ideas, etc. as possible (That’s what this group is).
Interest groups bring together people who wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.
I’ve been working with XR (Virtual Reality, Augmented Reality, Mixed Reality), specifically investigating design, usability, and sustainability. Here is a talk from about a year ago on the topic:
The current push in XR is to a “mirror world” – making XR as hyper-real as possible. That requires perhaps a 6G network plus 20x per user power consumption. The current XR design community is oblivious to sustainability issues. It is quite possible that an alternative XR design theory could be developed, following the trajectory from “skeuomorph” to more efficient “flat design” using abstract signifiers and idioms.
Hi everyone, the team at Mightybytes is kicking off a redesign of our free web sustainability tool, Ecograder. We’re actively seeking feedback on what the new version could or should become. Our goal is to make it more useful and help people better understand how to improve their digital products to become both high-impact and low-carbon.
This group’s insights would be incredibly helpful. If you’re up for it, would you mind answering a few questions? Here’s the survey. It will stay open for at least the next week or so.
I’ve been reading a bit about Conversational Design, and want to suggest some talking points about its relation to web sustainability:
Conversational Design uses text interaction, which reduces the complexity of the Ui
Conversational Design may provide a more natural way of user interaction for many apps, currently download gobs of JavaScript to create an elaborate, animated visual Ui that uses lots of visual symbols instead of a few words
Conversational Design creates a dialogue between user and a “Site Persona”, which fits nicely into many Ux models. We’ve been calling these, “Design Personas”, as part of Emotional Design:
Conversational Design outputs a text stream ordered in time, which means you naturally support visually impaired uses with screen readers. In contrast, we need to put ARIA roles on visual pages to make sure they let screen readers parse content in the correct order
Conversational Design deliverables look a LOT like a Ux user storyboard, scenario, or Customer Journey.
Conversational Design supports those without visual screens, which includes IoT devices like Alexa. But it also supports, in theory “smart” web spiders and related AIs trying to make sense of a web page, if they can also engage in a dialogue with the Site Persona.
Conversational Design will be used heavily in VR and AR. The reason? VR and AR environments are too complex to control except via voice interaction.
So, I’m suggesting that instead of “Mobile First”, “Conversation First” as a new route to Web Sustainability. Thoughts?