- From: Jeffrey Yasskin <notifications@github.com>
- Date: Thu, 05 Feb 2026 13:40:52 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1181/3856405135@github.com>
jyasskin left a comment (w3ctag/design-reviews#1181)
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](https://www.w3.org/TR/ethical-web-principles/), the [Societal Impact Questionnaire](https://www.w3.org/TR/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](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](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](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.
--
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1181#issuecomment-3856405135
You are receiving this because you are subscribed to this thread.
Message ID: <w3ctag/design-reviews/issues/1181/3856405135@github.com>
Received on Thursday, 5 February 2026 21:40:57 UTC