#1181: WG New Spec: Web Sustainability Guidelines
Discussions
Log in to see TAG-private discussions.
Discussed
Jan 12, 2026 (See Github)
Jeffrey: I put together an initial draft for the beginning of the document in a Google Doc, which is easier to collaborate on (https://docs.google.com/document/d/19K0CXPUvPaeM7OxaciOZl2gNoAQTK16SMWcUY6VZc7M/edit?tab=t.0#heading=h.ud7dyes4v2k). A lot to comment on.
… Overall, it could use some editing, they should have a look at a tech styleguide. Don’t have a definition of sustainability in this document, and they should have one.
…A lot of details: The talk about the guidelines and regulatory compliance, seems kind of backwards. Suggest to drop that they do this because of regulations.
…They talk about measurability, point at the WSG organization. They don’t justify how much impact things have. Suggested that they double-check that. They have a spreadsheet where they rated things along three axes (datacenter, network, device). Not every guideline breaks down well to those axes. For each of the guidelines, there’s a bunch of questions. Some seem redundant and could probably be merged.
… It may be better for people to skim the comments offline, and then I’d like to post it to see what they come back with, before we continue with the next sections.
Lola: Anything in particular you want things to double-check or comment on?
Jeffrey: Not really.
Lola: Should we say, "we've reviewed the first two sections" and then go on? Or do it internally, and give them a whole document?
Jeffrey: Normally, I would like to do the whole thing at once. As I found so many comments, I would like to do it step by step.
Lola: Wonder if we could split up that work. It might be good to have two or three more people on this, with every person reviewing a section. Suspect they want us to review everything. I don’t mind being assigned as well.
Jeffrey: Would love more people to review. Didn’t stop because it was so big, but the quantity of comments. May not be worth reviewing something that would have to change significantly.
Ehsan: I could also help.
Lola: Let’s give them your comments, and maybe it’s worth having a discussion with them. It may tie in with the societal impact questionnaire. Maybe there’s even an opportunity to collaborate here.
… We will have a look at your comments, post it, and figure out the rest later.
Discussed
Jan 19, 2026 (See Github)
Sarven: Skip for me, I know Jeffrey did some work. It’s a giant document.
Hadley: Are we ok on timelines? Do they have a deadline?
Sarven: I don’t know, will look at this after Data Shapes.
Hadley: Ok, let’s have a quick look at the issue.
… They are looking for feedback in February, aim to publish in April. Seems realistic?
Sarven: I think so.
Hadley: If you and Jeffrey could get a first pass until next week, we should be able to sign it off and get it out the door?
Sarven: Ok!
Discussed
Jan 26, 2026 (See Github)
Jeffrey: In addition to my detailed comments I was wondering if we wanted to say something about regulation being an appropriate way to push the community towards sustainability, to avoid the situation where individuals opt to be more sustainable, at some cost, but others do not, and do not experience the cost.
Lola: I think there are concerns about talking about regulation because of the risks this poses.
Hadley: TAG sometimes talks about current regulation, which is more than other parts of the W3C can do. Talking about areas where regulation may be helpful is an easier thing to do - e.g. if email spam was foreseen, raising the concern that that area may need regulation would've helped.
Jeffrey: Will work on something. Think it's worth sending the bulk of it. Need to know if this is a TAG position or not before I post it - please review.
Returning to this after completing the agenda...
Jeffrey: Main thing is to check that TAG agrees (or not). It is unclear as to whether the current set of guidelines are the most imporatnt ones. Some seem to be too low-impact to include.
Hadley: Sounds like this has been a long-running conversation.
Jeffrey: They have been talking about it for a while, and I've been reviewing it for a while.
Discussing the point on monopolies specifically...
Hadley: Ultimately monopolies end up with no competition and thus a lack of improvements. But up until that point, they may be investing more than others in their services.
Jeffrey: They hadn't really discussed this when I brought it up.
Lola: I agree with Hadley that a lot of the comments in your review are editorial. The document they've given us to reiew is quite long - I don't think we should be doing their editorial review, but we should let them know that they'll need to do that.
... I do think it's worth asking them how they got to this list. I am not sure what we'd be looking for as TAG.
Hadley: I was wondering that too. Relation to architecture of the web. I would've said what Lola just said before you did the copy editing. For what you've done, fine to share it with them. But it doesn't need to be our role in reviewing documents.
Lola: I wonder if they brought it to us because of the relationships with documents we've written, such as societal impact.
Matthew: I think we have consensus that it's a good thing that the web is human-editable (plain text formats etc.) but that represents an architectural choice with sustainability consequences (of some amount). Last year we talked about adding zstd to the platform, which was a no-brainer due to the improvements it brings vs. the overhead on UAs to ship it etc. We make lots of trade-offs around formats. I read that the web needs to become both vastly more resliiant, and consume far less power in future. We make decisions that have ramifications here too. I think we're all making architectural decisions with sustainability implications a lot of the time.
Lola: As the TAG, what feeedback would we be giving - do we know enough to know how resources are used in the networking of things. Do we know enough to comment on some of the specific things that they are advising, good or bad. Should we be asking sustainability experts to chime in and review this document (similar to the AI APIs above).
Jeffrey: This is the group of sustainability experts. We could go outside of W3C to people who aren't participatinog to make sure they asked for review on the appropriate set of things.
... To Matthew's comment: when designing the architecture of the web, we have to think about the goals we have. This group is adding a new set of goals. So this is a bit different to what we usually review.
Hadley: My concern re architecture was to find the parts that are relevant to architecture (of which I expect several). Also we added [2.9: The web is an environmentally sustainable platform] (https://www.w3.org/TR/ethical-web-principles/#sustainable) to the Ethical Web Principles.
Matthew: Sometimes our architectural goals will conflict. A sustainability goal might conflict with an accessibility or security goal. Do we need a priority-of-constituencies-type thing to prioritize? Is it the priority of constituencies itself? We should consider how to arbitrate when these conflict.
Hadley: re efficiency, a lot of what we put in Ethical Web Principles, and what we ask for in our design reviews, etc. is to go against efficiency. It's very efficient to ignore accessibility, or internationalisation, or to create a feature by yourself and not bother with standardisation at all. We often strive to go against efficiency to build a better web.
Ehsan: Usability is at the centre of that, if you've got the most efficient system but nobody uses it, you have not got an efficient system. Similar with security - the most secure system that nobody uses isn't secure. We have a balance.
Lola: Agree we are pushing for the balance. I'm still stuck on the question of, as TAG, what can we advise? I think the experts are coming to the wrong group with this question. With charters, we're not reviewing them in the same way as the Team or other groups will review it. We're reviewing it in ways that we know about, e.g. we can connect groups that are solving similar problems but don't know about each other. I feel like we're not the right people.
Jeffrey: On the one hand, they're coming to us because they're doing wide review, and we're part of the process. The question that I'm trying to answer is: 'can I use this in design reviews?' and my current answer is 'no' - so I'm giving them feedback on those lines.
Lola: That contextualisation helps. I'm wondering if they consider this document as one that can be used in design processes. We want people to think of these things as they're developing this technology. Who's the audience for this document? Is it spec authors? How can we use this document to hold the spec authors to account?
Hadley: That makes sense. If their plan is to make this a W3C Statement, then whether we are doing the enforcement, or it's being done through charter reviews... It will be done one way or another.
Jeffrey: They're thinking about becoming a horizontal group eventually. Like the others, they need to prove themselves first, but that's a long-term goal.
Lola: Trying to understand how this document could be used in design reviews... I'd like to know if that's something they're comfortable with, or intend.
Hadley: I agree that it might change their editorial slant. But even if they don't intend us to use it, if they're planning to make it a statement, the outcome is the same. Flipping it around, if someone was going to write a key technical document for the community and we didn't have any input into it, how would we feel? We need to be involved even if we won't be enforcing it.
Jeffrey: Been trying to summarize this part of the converastion into a couple of paragraphs at the start of the Google Doc - does that capture what we are saying?
Hadley: I'm not sure if this group would be aware of the design review process and thus not fully understand the meaning behind the additions.
Jeffrey: Tzviya is in the group, so understands the process.
Lola: ____ opened this issue and is a staff member.
Yves: HIdde (AB member) is involved too.
Lola: We could ask if they need clarification on this. Do you feel like you have enough?
Jeffrey: Need review from TAG of the detailed comments. Then I can post.
Hadley: would it help to put the paragraphs at the top in as TAG and the rest as you?
Jeffrey: I'd like to check the TAG agrees with all the comments.
Lola: I can get feedback to you
Jeffrey: We may want to let people read this for 5min
group works on the google doc
Lola: Re Greenwashing, it's described as a threat - does it make sense to connect this to threat modelling work going on in W3C?
Jeffrey: It's a threat to the authors of this document, so not something spec authors need to be worrying about very much.
... I'll apply the comments to the doc and then ping the Slack.
Lola: Reminder that Nick Doty is joining us this week for plenary. We will probably be talking about f2f topics at Plenary as well. If there are docs that you want to spend time working on, or topics we haven't spent enough time on between Hong Kong and now, let us know.
Jeffrey: Plenary specifically is about age verification and requriements, and how that should affect the architecture of the web _____ will also be there.
Lola: ISO just made their age verification stuff public.
Discussed
Feb 2, 2026 (See Github)
Jeffrey: Think this is ready to post. The people who have been most active in reviewing my draft aren't here, but I think it's about ready. Will post to design reviews channel, and wait a couple of hours.
Christian: I'll take a look at the proposed comment.
Comment by @jyasskin Feb 5, 2026 (See Github)
Thanks for bringing this review to us. We appreciate that this work is happening and approve of the overall direction of the document.
This feedback covers the document through section 2. A lot of these comments are editorial, and some may apply to other parts of the document. We don't have capacity to do an editorial review of the entire document, but we recommend that you do seek such a review. Please let us know when you think the other sections of the document are ready for our review.
Overall
We've approached this review by asking "how can we use this in design reviews?" When we review specs and feature ideas for the web, we think about how they might impact our existing technologies and our users. Documents like this (and the Ethical Web Principles, the Societal Impact Questionnaire, and others) can help us organise our thoughts and let spec authors read about it all in advance. Does that align with your goals for this document? Do you mean for spec authors to use this as a constraint on their designs?
How did you come up with this overall list? Are these the most important sustainability goals or just the issues people have had time to write up so far?
This document could use some copy-editing. E.g. "not all environmental improvements are met by these guidelines" (is an improvement "met"?), "make informed sustainable development decisions" (is the goal to inform sustainable-development decisions or to make the development decisions sustainable?), and "Remove identified barriers to access, provided they do not introduce or increase security or safety risks or exposure." (you probably mean "provided that doing so does not").
In general, we've found that the TAG Style Guide at https://github.com/w3ctag/process/blob/main/style-guide.md is helpful in writing readable documents. It's difficult to follow perfectly, but the attempt usually improves documents.
It would be nice if the "Resources" (e.g. https://w3c.github.io/sustainableweb-wsg/resources.html#UX01-1) were organized to help a reader pick the right entry point, instead of the current flat list of document titles.
It would be good to start with a definition of sustainability, like the one in https://w3c.github.io/sustainableweb-wsg/summary.html#what-is-web-sustainability: "The goal of Web Sustainability is to design, develop, and operate digital products and services such that they meet the needs of the present while ensuring future generations can meet their own needs." Then every section should address how it contributes to that definition. As it is, it's unclear which sections are meant to improve environmental sustainability vs the sustainability of other sorts of systems. There were some sections for which we couldn't find a sustainability link at all.
The GRI scores seem based on the spreadsheet at https://docs.google.com/spreadsheets/d/12nGydnSv24fvmvCM-665_pFGPG9u3RgTwe1sCz4eiGk/edit, but we don't see information about how those scores were picked. Some of the values also don't seem to have been propagated into the main document: "Consider Sustainability In Early Ideation" is 0/0/0, but "2.3 Integrate sustainability into every stage of the ideation process" is marked as Medium for all GRI categories.
By section
1. Introduction
We like that there's a plain-language summary, although I wonder if the text it's summarizing could be made more accessible.
The summary says "The guidelines feature Success Criteria you MUST comply with", but the abstract said "It is not expected that organizations will adhere to every guideline within the specification." I think the summary is more aggressive than the Introduction justifies. Also, in general a non-normative summary shouldn't be using normative language like MUST.
Background on WSG
"more sustainable for people and the planet": "prosperity" should probably be listed here too. Several of the guidelines do cover economic sustainability beyond just fairness to the people involved.
You should omit hedges like "The Interest Group considers". The document should just state what you believe.
I'm uncomfortable with "WSG may be helpful to comply with existing and upcoming worldwide regulatory frameworks, reporting schemes, and compliance requirements (laws and policies)." as part of the guidelines themselves. A compliance team needs to consult the regulations directly and not assume the WSG accurately summarizes them. Perhaps this should address regulators instead. E.g. "WSG may also be helpful to regulators who are working out what sustainability obligations they want to enforce in their jurisdiction."
The "While content within WSG has been categorized" paragraph confused me. I don't see how the various clauses are related to each other, it should probably use more active voice, and I don't know what "prescribed labels" are.
The "Web sustainability depends" paragraph seems to list 3 kinds of products that need to be sustainable—websites, browsers, and authoring tools—but it doesn't list them in parallel. It also incorrectly implies that browsers and authoring tools aren't products.
"Coverage should not be restricted" should say who might be restricting coverage … and what "coverage" is.
WSG layers of guidance
"make content more sustainable": The goal seems to be making projects or systems more sustainable, not just the HTML.
1.4.3 Greenwashing
I like that you've considered this threat. It's probably worth calling this out in the security considerations section, as you're effectively treating this as an attack.
2. User Experience Design
I feel like this section's introduction should explain how UX design contributes to sustainability, bringing it back to the definition ("ensuring future generations can meet their own needs"). There's a mention of wasted time and resources, but surely the wasted resources are minimal and don't affect future generations. But I could imagine that bad UX would reduce user trust over time, leading users to avoid similar systems in the future, which undercuts the support those systems need to sustain themselves.
2.1 Examine and disclose any external factors interacting with your project
Please define "external factors".
"Examine and disclose", in the guideline, is narrower than the second success criterion, which requires implementers to "Establish a plan of action". The relation should be the opposite: guidelines should establish the broad direction of action, and success criteria should test particular aspects of the guidelines.
2.2 Understand user requirements or constraints, resolving barriers to access
What's unsustainable about barriers that exclude part of the audience? Certainly accessibility is important, and part of the W3C's mission, but guidelines in this document need a connection to sustainability.
"give them an equal role in decision making" also seems disconnected from the guideline itself. It's part of "5.16 Share decision-making power with affected parties" and shouldn't be repeated here unless there's an aspect specific to UX design.
2.10, 2.14, and 2.18 look redundant with this section and should be merged in here, or all removed.
2.3 Integrate sustainability into every stage of the ideation process
"Optimize … in line with sustainability best practices" feels circular, since this document is meant to be stating the sustainability best practices. I think it's actually not so circular, and that the linked resources point at branding sustainability guidelines that are distinct from web sustainability guidelines, but it would be good for the Success Criterion to have a normative reference to such branding guidelines instead of leaving it open-ended.
2.4 Minimize non-essential content, interactivity, or journeys
Some organizations try to follow this guideline, and wind up removing content that's non-essential for most people, but that some people really need. It then takes a lot more resources for those people to recover. The guideline isn't wrong, but perhaps it could use a warning to be careful about what's essential?
I think the sustainability implications of this are basically the same as 2.5, 2.6, and 2.9… I feel like there's a simpler guideline that covers all 3, and then the details can be Success Criteria or sub-guidelines. Perhaps something like "Ensure users can accomplish their goals without wasted steps" or "... without getting confused, lost, or distracted".
2.5 Ensure that navigation and wayfinding are well-structured
See 2.4.
2.6 Design to assist and not to distract
See 2.4.
2.7 Avoid being manipulative or deceptive
I don't like "and waste energy" in this guideline: the sustainability implications of manipulation and deception are more around how lost trust undermines future relationships, than the environmental resources used to recover from the bad behavior.
2.9 Use a design system for interface consistency
See 2.4.
2.10 Provide clear, inclusive content with purpose
See 2.2.
2.11 Optimize media for sustainability
"for sustainability" looks circular in this document. Is this "Optimize media to reduce resource use" or perhaps just "Optimize media"?
I like the body text, although "managed effectively" should be more precise.
2.12 Ensure animation is proportionate and easy to control
The right design here also has some details about defining animation in CSS rather than JS so that browsers can run it on the most efficient processors. If that's covered in section 3, it'd be useful to cross-link.
2.14 Offer suitable alternatives for every format used
See 2.2.
2.15 Provide accessible, usable, minimal web forms
This document overlaps a lot with the W3C's WCAG work. At TPAC, we remember hearing that this group would work with the AGWG to harmonize more. How is that going?
What's the sustainability impact of "Clearly communicate why a form is necessary, the value it provides, the number of steps required for completion, and what will be done with the collected data. Also disclose if the data will be shared with third parties."?
I'm uncomfortable with the discouragement of auto-suggest. It's true that it uses server and network resources, but it tends to save human time. It's not a sustainability thing, but I wish more forms would fill in my city and state based on my zip code, even though that takes extra data transfer.
2.16 Provide useful notifications
The guideline text seems to encourage sending notifications, but the body is all about reducing notifications and letting users control which ones they get. Perhaps a title more like "Omit unwanted notifications" or "Only send desired notifications"?
The "Would you prefer a banana or cherry?" example in Additional Information doesn't seem to match this guideline.
2.17 Reduce the impact of downloadable and physical documents
"Reduce the need for physical documents as much as possible by … having a print style sheet." doesn't seem quite right. Maybe the print style sheet belongs in a separate sentence?
2.18 Involve users and contributors early in the project
See 2.2. "Contributors" might be distinct, but the body of the guideline doesn't mention why all of them need to be involved early.
2.19 Audit and test for bugs or issues requiring resolution
This seems like more a development guideline (section 3) than a UX guideline.
What's the sustainability connection here? Is it about ensuring that the system maintains compliance with the earlier guidelines over time? If so, say that.
"Non-regression tests" isn't clear: almost all projects I work on use the same test suite to check both that new features are correct and that old features stay correct. If you're advising that projects identify tests that only need to be run in order to dig into correctness, and not routinely to block regressions, you should say that explicitly … and I think I'd disagree.
"Compliant measurement" doesn't seem to fit in this document. Projects must follow laws, but doing so isn't about sustainability.
2.20 Verify that real-world users can successfully use your work
The title here looks redundant with 2.2, but I think this is more about watching actual use over time to catch places the UX needs to be improved. Try to be clearer about that.
2.21 Regularly test and maintain compatibility
The title here looks redundant with 2.19, but I think the sustainability goal of this section is about allowing people to use their existing equipment. Can you focus it?
The PWA advice doesn't seem to fit here. It might belong somewhere in section 3 instead, and it could perhaps be broadened to something like "choose an application format (PWA, native, Electron, etc.) to minimize download costs" or similar.
3.2 Remove unnecessary or redundant information
All of the GRI impact scores are "Low" for this, indicating that "This will have a minimal impact". As such, it's probably not worth including, unless there's another link to sustainability ("ensuring future generations can meet their own needs"), and if so, that link should be cited.
OpenedDec 17, 2025
Specification
https://www.w3.org/TR/web-sustainability-guidelines/
Explainer
https://github.com/w3c/sustainableweb-wsg/blob/main/explainer.md
Links
The specification
Where and by whom is the work is being done?
Feedback so far
You should also know that...
We are looking for feedback by February, we aim to publish in April.
Other comments that may be relevant:
- Metrics are a work in progress and will be added in. https://github.com/w3c/sustainableweb-ig/issues/178
- We are working on a conformance model, this could still shift a few things.
- We’re not adding a metric for carbon intensity, we’ll use SCI-Web from the Green Software Foundation. Related, we have a MOU relationship with Green Software Foundation (ask @TzviyaSiegman for questions).
<!-- Content below this is maintained by @w3c-tag-bot -->Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1181