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, has adopted the Community Group Charter template provided by W3C. It provides important governance information relevant to this community group.
This group will create guidelines, tools, and resources for web and digital professionals to incorporate environmental sustainability and related principles into their workflows and work practices. Our goal is to make the process of creating digital products more sustainable, while the use of digital products should also encourage better practices for users.
The group will provide evidence-based, peer-reviewed recommendations on how to create more sustainable digital products and services. While the group’s primary responsibility is to create environmental guidelines, we acknowledge the importance of intersectional social and governance principles as essential elements of a holistic ESG (Environmental/Social/Governance) strategy and will reference those when relevant.
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 procurement requirements for organizations commissioning web projects.
Out of Scope
This group will not create Specifications.
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 ongoing participation and supports leadership transitions as needed.
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.
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 for this work will be based on evidence-driven research and defined as the group grows and evolves.
This group has several committees dedicated to specific subtopics of the parent topic:
Business Strategy, Product management
Analytics, Measurement, Reporting
Hosting, Infrastructure, Systems
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 organisation, 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:
The group’s primary goal
Define roles, timelines, next steps
To get added to the calendar invite for this meeting, please email firstname.lastname@example.org 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.
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.
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 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?
With Mozilla’s 2018 Internet Health Report finally shining a light on sustainability, and thanks to Chris Adams’ presentation at MozFest last year, I’ve been inspired to seriously up my game in terms of helping wherever I can in this field.
As a first step, I’ve put together a very simple WordPress widget that allows users to easily add The Green Web Foundation’s badge to their website. I think of the widget more as a marketing tool than anything else – i.e. it gets The Green Web Foundation into WordPress’ shop window.
You can see the widget in action on my blog (bottom of the sidebar).
My next steps within WordPress are to create a theme that incorporates all of the sustainable web design techniques. My goal is to make a theme that can theoretically score 100 with Ecograder. I say theoretically because some things are dependent on the host, MozRank etc. But if, for example, I could get the demo site for the theme near to 100, that’d be awesome. And I could also centre all of the content on the demo site around Internet sustainability.
What’s needed for better sustainability is a library that allows lookup of JS library by version, with known vulnerabilities. At the very least, design and maintenance documents for websites should include a strategy for fixing outdated JS libraries in the mix.