-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathstar.html
5756 lines (5667 loc) · 476 KB
/
star.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Sustainable Tooling And Reporting (STAR)</title>
<style>
/* Fix for ReSpec table layout and overflow issue. */
.flow table { border-collapse:collapse; border-spacing:0; white-space: nowrap; }
.flow td, .flow th { border: 1px solid #000000; text-align: center; }
.red { color: #FF0000; }
/* Hint for expandable content. */
summary { cursor: pointer; }
</style>
<script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove" defer></script>
<script class="remove">
/* Chairs Listing */
function addChairs() {
document.querySelectorAll("div.head dt").forEach(function (node) {
if (node.textContent.trim() == "Authors:")
node.textContent = "Chairs:";
});
}
function fixContributors() {
document.querySelectorAll("#gh-contributors li a").forEach(function (node) {
if (node.textContent.indexOf("[bot]") > 0)
node.parentElement.parentElement.removeChild(node.parentElement);
});
}
</script>
<script class="remove">
var respecConfig = {
editors: [
{
name: "Alexander Dawson",
url: "https://alexanderdawson.com/",
w3cid: 49702,
},
],
authors: [
{
name: "Ines Akrap",
url: "https://inesakrap.com/",
company: "Storyblok",
},
{
name: "Mike Gifford",
url: "https://civicactions.com/",
company: "CivicActions",
},
{
name: "Tim Frick",
url: "https://www.mightybytes.com/",
company: "Mightybytes",
w3cid: 62394,
},
],
edDraftURI: "https://w3c.github.io/sustainableweb-wsg/star.html",
github: "https://github.com/w3c/sustainableweb-wsg/",
group: "sustainableweb",
latestVersion: "https://w3c.github.io/sustainableweb-wsg/star.html",
localBiblio: {
"WAI": {
title: "Web Accessibility Initiative",
href: "https://www.w3.org/WAI/",
status: "Informational",
publisher: "WAI",
}
},
specStatus: "ED",
postProcess: [addChairs],
}
</script>
</head>
<body>
<section id="abstract"> <!-- Abstract -->
<p>Sustainable Tooling And Reporting (<abbr title="Sustainable Tooling And Reporting">STAR</abbr>) provides information, examples, and metrics data to complement the Web Sustainability Guidelines (<abbr title="Web Sustainability Guidelines">WSG</abbr>) specification. Within this supplementary document, you will find implementation advice (for external groups wishing to incorporate sustainability in their work), an evaluation methodology (for testing conformance), a categorized series of techniques (potential implementations and case studies), and a test suite (metrics data on impact and machine automation capability).</p>
<p>As with the WSG, these features have been inspired by the work of the Web Accessibility Initiative ([[WAI]]). They have also been curated with a Web sustainability methodology, with the goal of better understanding the digital landscape's role in reducing harm to the wider ecosystem (regarding people and the planet).</p>
<p>For the normative technical specification, see <a href="https://w3c.github.io/sustainableweb-wsg/">https://w3c.github.io/sustainableweb-wsg/</a>.</p>
<p>Help improve this page by sharing your ideas, suggestions, or comments via <a href="https://github.com/w3c/sustainableweb-wsg/issues/">GitHub issues</a>.</p>
</section>
<section id="sotd" class="override"></section> <!-- Ignore -->
<section> <!-- Implementation -->
<h2>Implementation Advice</h2>
<p>The following section provides advisory guidance for other specification writers and external groups wishing to incorporate digital sustainability within their work (such as <abbr title="World Wide Web Consortium">W3C</abbr> Working and Community Groups). We are primarily a group dedicated to fostering sustainable change in Web technologies associated with the creation of websites and applications. While it is outside of our group's scope to conduct horizontal reviews of other group's specifications, we may request or accept requests to collaborate with or assist in coordination with other groups to implement sustainable change.</p>
<section> <!-- Considerations -->
<h3>Considerations</h3>
<p>The WSG have a broad appeal, designed to impact a wide range of Web technologies and related infrastructure as appropriate. With this in mind, when first starting to look to incorporate sustainability within a body of work you may find that certain guidelines more than others will apply to practices.</p>
<p>When designing any fledgling body of work it's worth considering the following:</p>
<ul>
<li>Can a sustainability policy be put in place to vet work appropriately?</li>
<li>If any guidelines are applicable, can they be included as "hard and fast rules"?</li>
<li>If not (due to a conflict), can this be resolved without impacting the benefit?</li>
<li>Can research to identify any sustainability benefits that are yet undiscovered be undertaken?</li>
<li>Is education for consumers on a work's environmental impact being provided?</li>
</ul>
<div class="note">
<p>When creating specifications or industry-specific documents, cross-reference to specific WSG guidelines that are appropriate for a body of work to connect elements of content to applicable sustainability goals.</p>
<p>Create new sustainability guidelines that are explicitly targeted for a technology (that may be too niche to be included within the WSG). This would provide additional Success Criteria for an audience to meet.</p>
<p>If you do wish to create additional targeted guidelines, please first consult the Sustainable Web Interest Group as we may be able to include them within the main WSG or provide guidance to avoid conflicts with other existing guidelines.</p>
</div>
</section>
<section> <!-- Methodology -->
<h3>Methodology</h3>
<p>With the above considerations taken into account, a good next step is to consider sustainability within content and treat sustainability as any other impact target (such as accessibility or performance) by trying to drive change through metrics data. If research exists to back a particular technique as more performant, it's likely to be more sustainable. Often there will be cases where evidence does not exist as Web sustainability is an evolving field and as such, a common sense approach (considering the variables that can impact people and the planet) will be the best method if metrics data cannot be provided to identify the most sustainable option.</p>
<p>Every body of work will have its approach to this and a progress over-perfection methodology is preferred (as doing something is ultimately better than waiting for an ideal fix), but as a general consideration for those who are creating documents that are relied upon by large numbers of individuals, the <abbr title="Planet, People, and Prosperity">PPP</abbr> model which doesn't just account for emissions and the environmental impact but also and human factors and issues surrounding good governance are an ideal template to work from. In the context of the Internet this accounts for everyday (but important) factors such as performance, accessibility, privacy by design, security, and reducing waste which all as a by-product have an environmental impact.</p>
<p>It's also important to note that different bodies will have their sustainability challenges, for example, those working on native <abbr title="Application Programming Interfaces">APIs</abbr> are more likely to encounter hardware resource consumption (energy usage), whereas language standards will be more considerate of implementors, accessibility, and improving developer workflows. As such, it's worth coordinating with other groups with aligned goals and discussing their sustainability approaches to align work and help improve theirs, accounting for different variables.</p>
<p class="note">Providing sustainability guidance within work can be presented in many ways. One option is to integrate it within existing guidance or specifications (amending the content). Another is to provide notes or in-page sections dedicated to sustainability providing coverage. Or to gently guide individuals into the subject, a dedicated supplement that will be adapted or merged into the specification at the next major version (giving individuals time to adapt) could be created.</p>
</section>
</section>
<section> <!-- Evaluation Methodology -->
<h2>Evaluation Methodology</h2>
<p>Evaluating the extent to which a website implements the Web Sustainability Guidelines (WSG) is a process involving several steps. The activities carried out within these steps are influenced by many aspects such as the type of website (e.g. static, dynamic, responsive, mobile, application, etc.); its size, complexity, and the technologies used to create the website (e.g. <abbr title="Hypertext Markup Language">HTML</abbr>, <abbr title="Cascading Stylesheets">CSS</abbr>, <abbr title="JavaScript">JS</abbr>, <abbr title="Portable Document Format">PDF</abbr>, etc.); how much knowledge the evaluators have about the process used to design and develop the website; and the main purpose for the evaluation (e.g. to issue a sustainability statement, to plan a redesign process, to perform research, etc.).</p>
<p>This methodology describes the steps that are common for comprehensive evaluation of the extent of websites and applications to implement WSG. It highlights considerations for evaluators to apply these steps in the context of a particular product or service. It does not replace the need for quality assurance measures that are implemented throughout the design, development, and maintenance of websites or applications to ensure their sustainability conformance. Following this methodology will help evaluators apply good practice, avoid commonly made mistakes, and achieve more comparable results. However, in the majority of situations using this methodology alone, without additional quality assurance measures, does not directly result in a sustainable product or service that meets the WSG success criteria and guidelines.</p>
<p><strong>This methodology does not in any way add to or change the requirements defined by the normative WSG specification</strong>, nor does it provide instructions on feature-by-feature evaluation of web content. The methodology can be used in conjunction with techniques and examples for meeting WSG success criteria, such as the techniques documented within this STAR supplement, but does not require this or any other specific set of techniques.</p>
<p>This methodology is intended for people who are experienced in evaluating Web sustainability using WSG and its supporting resources. It provides guidance on good practice in defining the evaluation scope, exploring the target website, selecting representative samples from websites where it is not feasible to evaluate all content, auditing the selected samples, reporting the evaluation findings, and if necessary - implementing sustainable change. It does not specify particular web technologies, evaluation tools, web browsers, or other software to use for evaluation. It is also suitable for use in different evaluation contexts, including self-assessment and third-party evaluation.</p>
<section class="notoc"> <!-- Purposes for this Methodology -->
<h3>Purposes for this Methodology</h3>
<p>In many situations it is necessary to evaluate the sustainability of a website or application, for example before releasing, acquiring, or redesigning the product or service, and for monitoring the sustainability of a website or application over time. This methodology is designed for anyone who wants to follow a common approach for evaluating the compliance of websites to WSG. This includes:</p>
<ul>
<li>Web consultants who want to analyze and report the sustainability conformance of websites or applications, to inform website owners.</li>
<li>Web sustainability evaluation service providers who want to evaluate products and services to validate sustainability compliance.</li>
<li>Website designers and developers who want to evaluate the sustainability compliance of their websites or applications to monitor or improve them.</li>
<li>Website owners, procurers, and suppliers who want to learn about the sustainability compliance of their websites.</li>
<li>Web compliance and quality assurance managers who want to ensure that they meet quality and policy requirements.</li>
<li>Web sustainability monitoring activities are used to benchmark and compare sustainability compliance over time.</li>
<li>Web sustainability researchers and environmental advocates or activists who want to explore sustainability compliance practices.</li>
<li>Web sustainability trainers and educators who want to teach approaches for evaluating the sustainability of websites and applications.</li>
<li>Webmasters, content authors, designers, developers, and others who want to learn more about web sustainability and evaluation.</li>
</ul>
</section>
<section> <!-- Usage and scope -->
<h3>Usage and scope</h3>
<p>This methodology is used to perform thorough evaluations of websites and applications using WSG. Before this, it may be useful to undertake a preliminary evaluation to identify obvious sustainability issues and to take a progress-over-perfection approach to tackling guidelines holistically (though note that such evaluations won't be as robust as a thorough evaluation).</p>
<section class="notoc"> <!-- Evaluators and Usage -->
<h4>Evaluators and Usage</h4>
<p>Different expertise may be required to evaluate a website or application, as such, one of the below or a combination of these at different stages of the project may assist with understanding and evaluating the sustainability of a website or application.</p>
<ul>
<li><strong>Required Expertise</strong> Users of this methodology are assumed to have a solid understanding of how to evaluate web content using WSG along with a reasonable understanding of sustainable web design and development, how web sustainability affects Internet infrastructure and business practices, and how sustainability issues affect both people and the planet. This includes a reasonable understanding of existing web technologies; and evaluation techniques, tools, and methods to identify sources of emissions, how to measure them accurately, and how to remedy issues that occur. In particular, it is also assumed that users of this methodology are deeply familiar with the WSG supplementary documents.</li>
<li><strong>Combined Expertise (Optional)</strong> This methodology can be carried out by an individual evaluator with the required expertise, or a team of evaluators with collective expertise. Using the combined expertise of different evaluators may sometimes be necessary or beneficial when one evaluator alone does not possess all of the required expertise.</li>
<li><strong>Involving Users (Optional)</strong> Involving people who are affected by real-world complications of sustainability may help identify digital issues that are not easily discovered by expert evaluation alone. While not required for using this methodology, it may sometimes be necessary for evaluators to involve real people from a wide variety of backgrounds during the evaluation process.</li>
<li><strong>Evaluation Tools (Optional)</strong> This methodology is independent of any particular web sustainability evaluation tool, web browser (user-agent), and other software tool. While some sustainability checks in the WSG are not fully machine-testable, evaluation tools can significantly assist evaluators during the evaluation process and contribute to more effective evaluation. For example, some web sustainability evaluation tools can scan entire products and services to help identify relevant pages for manual evaluation as well as identify those issues that fall under testability criteria. Tools can also be used to assist during manual (human) evaluation of sustainability checks, including those that aren't machine-testable.</li>
</ul>
<p>This methodology is designed for evaluating both websites and applications. This includes organizations, entities, persons, events, products, and services. Websites and applications can include publicly available or internal websites; applications, intranets, online shops, dedicated mobile websites, isolated sections of a larger website, or internationalization pages (on a subdomain for example). This methodology can apply equally to any collection of materials, regardless of whether it is a part of a larger project or a dedicated entity of its own.</p>
</section>
<section class="notoc"> <!-- Principle of Website Enclosure -->
<h4>Principle of Website Enclosure</h4>
<p>When a target website or application is defined for evaluation, all pages, states, and functionality within the scope of this definition must be considered for evaluation. Excluding such aspects of a website from the scope of evaluation would likely conflict with the WSG success criteria and conformance requirements or otherwise distort the evaluation results.</p>
<p>Example of Website Enclosure:</p>
<ul>
<li>index.html</li>
<li>news.html</li>
<li>services.html</li>
<li>portfolio.html</li>
<li>about.html</li>
</ul>
<p>In the above example, if a personal portfolio website in its entirety is defined as the target for evaluation, then all of the depicted areas are within the scope of the evaluation. This includes any aggregated and embedded content such as images of work undertaken, assets that are considered apart of the website, interactive materials created, maps to an office (if one exists), including when such parts originate from third-party sources. If only a specific website area, is defined as the target for evaluation then all the parts of this area are within the scope of the evaluation. One example could be to evaluate all of the portfolio items, as well as the individual web pages that are common to the work undertaken by the practitioner.</p>
</section>
<section class="notoc"> <!-- Particular Types of Websites -->
<h4>Particular Types of Websites</h4>
<p>This methodology applies to a broad variety of website and application types. The following provides considerations for particular situations, noting that products and services may combine several aspects. Thus the following list is non-exclusive and non-exhaustive:</p>
<ul>
<li><strong>Small Websites:</strong> Small websites that are comprised of fewer pages place a lot of their sustainability impacts upon fewer pages. Some examples of this include personal portfolios, blogs, fan sites, and project websites. Small websites may be connected to a larger website, but treated as an individual and separable entity for evaluation.</li>
<li><strong>Web Applications:</strong> Web applications are generally composed of dynamically generated content and functionality (see web page states). Web applications tend to be more complex and interactive. Some examples of web applications include webmail clients, document editors, and online shops. Web applications may be part of a larger website but can also constitute a website of their own in the context of this methodology. That is an individual and separable entity for evaluation. Due to the many possibilities of generating content and functionality in web applications, it is sometimes not feasible to exhaustively identify every possible web page, web page state, and functionality. Web applications will typically require more time and effort to evaluate, and they will typically need larger web page samples to reflect the different types of content, functionality, and processes.</li>
<li><strong>Website in Multiple Versions:</strong> In some cases websites may have clearly separable areas where using one area does not require or depend on using another area of the website. For example, an organization might provide an extranet for its employees only that is linked from the public website but is otherwise separate, or it might have sub-sites for individual departments of the organization that are each clearly distinct from one another. Such separable areas can be considered as individual websites for evaluation. Some websites also provide additional or different content and functionality depending on the user (typically after a log-in). This additional content and functionality is generally part of the essential purpose and functionality of the website and is thus not considered to be a separable website area.</li>
<li><strong>Website with Separable Areas:</strong> Some websites are available in multiple versions that are independent of one another in use, that is, using one version does not require or depend on using another version of the website. For example, a website may have versions of a website in different languages that meet this characteristic. Usually, each such website version has a different set of URIs. Such website versions can be considered as individual websites for evaluation. Websites using responsive design techniques (i.e. adapting the presentation according to user hardware, software, and preferences) as opposed to redirecting the user to a different location are not considered to be independent website versions.</li>
</ul>
<p><strong>Note:</strong> Responsive design techniques adjust the order, flow, and sometimes behavior of the content to best suit the device on which it is used. For example, to adjust the content and functionality according to the size of the viewport, screen resolution, orientation of the screen, and other aspects of a mobile device and the context in which it is being used. In this methodology, such changes to the content, functionality, appearance, and behavior are not considered to be independent website versions but rather web page states that need to be included in the evaluation scope. As such, considerations for mobile devices, operating systems, and assistive technologies need to be taken for websites using responsive design techniques during the evaluation process.</p>
</section>
<section class="notoc"> <!-- Situations and Contexts -->
<h4>Situations and Contexts</h4>
<p>This methodology is designed to be flexible to facilitate its applicability in different situations and contexts. The following considerations apply to particular situations and contexts for an evaluation:</p>
<ul>
<li><strong>Self-Assessment:</strong> In-house evaluators and evaluators who are part of the development process have the benefit of internal access to the team, environments, documentation, and codebases.</li>
<li><strong>Third-Parties:</strong> Independent external evaluators will have less access to internal processes and information, but can come with expertise and experience that may not exist within internal teams.</li>
<li><strong>Evaluating During Development:</strong> While evaluation must take place during both ideation and implementation, it's important to be aware that such evaluations can become obsolete, and constant reevaluations should occur during the development process to maintain currency.</li>
<li><strong>Third-Party Content:</strong> Third-party content is not under the control of the website or web service providers. WSG provides specific considerations for the conformance of such type of content. In such cases, evaluators will need to determine whether such content is regularly monitored and repaired.</li>
<li><strong>Re-Running Website Evaluation:</strong> Website evaluation, according to this methodology, may be re-run after a short period; for example, when issues are identified and repaired by the website owner or website developer, or periodically to monitor progress.</li>
<li><strong>Large-Scale Evaluation:</strong> Carrying out mass evaluation of many websites or applications, for example for national or international surveying, is typically carried out by primarily using automated evaluation tools. Relatively few web pages undergo full manual inspection. Such evaluations do not usually address the necessary qualitative depth of conformance review per product or service for which this methodology is designed.</li>
</ul>
</section>
</section>
<section> <!-- Evaluation procedure -->
<h3>Evaluation procedure</h3>
<p>This section describes the stages and activities of an evaluation procedure. The stages are not necessarily sequential. Also the exact sequence of the activities carried out during the evaluation stages depends on the type of application or website, the purpose of the evaluation, and the process used by the evaluator. Some of the activities can overlap or may be carried out in parallel.</p>
<p>There are five sequential steps defined in this section:</p>
<ol>
<li>Define the Evaluation Scope;</li>
<li>Explore the Target Website;</li>
<li>Test or Sample the Website;</li>
<li>Audit the Selected Pages;</li>
<li>Report the Evaluation Findings.</li>
</ol>
<p>Evaluators should proceed from one step to the next, and may return to any preceding step in the process as new information is revealed to them during the evaluation process.</p>
<section class="notoc"> <!-- Internal Knowledge -->
<h4>Internal Knowledge</h4>
<p>Due to the requirements of sustainability reporting and the success criteria contained within the WSG, in order to conform to certain aspects of the specification it may be required to obtain or have access to internal knowledge of the website or application or a business behind the product or service. If such access is possible, this knowledge should be used by evaluators in accordance to any policies in-place regarding data use. If access however is not available or cannot be provided, the use of publicly available data may serve as a general estimation of comparability; though the accuracy of results may be in question. In addition, in cases where no replacement for data can be found, conformance evaluators should aim to identify other methods of meeting success criteria or identify the lack of knowledge as a failure point (until such a time that the organization can disclose the information publicly).</p>
</section>
<section class="notoc"> <!-- Machine Testability -->
<h4>Machine Testability</h4>
<p>While many of the success criteria in the WSG will withstand machine testing (automation) without human intervention, others cannot be reproduced without manual examination. In such cases, to assist with a large volume of pages, rather than sampling a subset of the website or application (which could bias the results due to the potential for missing important pages), creating a semi-automated structure around human testability to assist with such tasks through tooling (such as the use of a wizard interface) may help reduce pinch points in the evaluation process.</p>
</section>
<section class="notoc"> <!-- Step 1: Define the Evaluation Scope -->
<h4>Step 1: Define the Evaluation Scope</h4>
<p>During this step the overall scope of the evaluation is defined. It is an important step as initial exploration of the target application or website may be necessary to better know specifics (and to ensure common expectations) of the product or service and the required evaluation.</p>
<ol>
<li><strong>Define the Scope of the Website:</strong> During this step the web pages (and states) that are in scope of the evaluation are defined. To avoid later mismatches of expectations between the evaluator, commissioner, and readers of the resulting evaluation report, it is important to define unambiguously what aspects of the website or application are within its scope. Documentation of URIs are recommended where possible and to list aspects of the website that support its identification such as third-party content and services, or content that may have a different web address but is still considered to be part of the target website.</li>
<li><strong>Define the Target:</strong> Because the WSG favor a progress-over-perfection approach to conformance, it does not use any strict levels for compliance in meeting the guidelines. As such, during the evaluation process, evaluators should set defined targets based on a level they believe is achievable between client and the workers involved in making the website or application sustainable.</li>
<li><strong>Define a Sustainability Support Baseline:</strong> Depending on the type of website or application being developed, it may not always be possible to implement every aspect of the WSG (or they may not always be applicable to every situation). WSG does not pre-define which combinations of features and technologies must be supported as this depends on the particular context of the website or application, the web technologies that are used to create the content, and the user agents currently available. During this step the evaluator in consultation with the website owner (and or commissioner) and developer determines the minimum level of sustainability implementations or improvements to be established over a given period (or as a starting point in first-cases). It should be noted that setting a baseline doesn't imply that such expectations cannot be exceeded with new goals and including further targets to reach.</li>
<li><strong>Define Additional Evaluation Requirements (Optional):</strong> An evaluator or commissioner may be interested in additional information beyond what is needed to determine the extent of compliance to WSG. This may include submitted reports of issues, analysis of use-cases or interactions, descriptions of solutions beyond the scope of the evaluation, or reporting templates. Such additional requirements should be clarified early on and documented, and reported as such in any resulting report that is produced.</li>
</ol>
</section>
<section class="notoc"> <!-- Step 2: Explore the Target Website -->
<h4>Step 2: Explore the Target Website</h4>
<p>During this step the evaluator explores the target website or application to be evaluated, to develop an initial understanding of the product or service and its use, purpose, and functionality. Much of this will not be immediately apparent to evaluators, in particular to those from outside the development team. In some cases it is also not possible to exhaustively identify and list all functionality, types of web pages, and technologies used to realize the website and its applications. The initial exploration carried out in this step is typically refined in the later steps as the evaluator learns more about the target website. Involvement of website owners and website developers can help evaluators make their explorations more effective.</p>
<div class="note">
<p>Carrying out initial cursory checks during this step helps identify web pages that are relevant for more detailed evaluation later on. For example, an evaluator may identify web pages that seem to be lacking sustainable features and note them down for more detailed evaluation later on.</p>
<p>To carry out this step it is also critical that the evaluator has access to all the relevant parts of the website. For example, it may be necessary to create accounts or otherwise provide access to restricted areas of a website that are part of the evaluation. Granting evaluators such internal access may require particular security and privacy precautions.</p>
</div>
<ol>
<li><strong>Identify Web Pages of the Website:</strong> Explore the target website to identify its web pages, which will also include any states in web applications. The outcome of this step is a list of all web pages of the target website or application.</li>
<li><strong>Identify the Variety of Web Page Types:</strong> Web pages and web page states with varying styles, layouts, structures, and functionality often have varying support for sustainability. They are often generated by different templates and scripts, or authored by different people. They may appear differently, behave differently, and contain different content depending on the particular website user and context. During this step the evaluator explores the target website to identify the different <em>types</em> of web pages and web page states. The outcome of this step is a list of noteworthy variables that may have a baring on the results on any sustainability auditing that can be used when evaluating web pages.</li>
<li><strong>Identify Web Technologies Relied Upon:</strong> During this step, the web technologies relied upon within the website or applications technology stack should be identified. This includes base web technologies such as HTML and CSS, auxiliary web technologies such as JavaScript and WAI-ARIA, as well as specific web technologies such as SVG and PDF. The outcome of this step is a list of technologies that may contain sustainability issues of their own, or contribute towards overarching goals. Where possible, any content management system, libraries, components, or frameworks should also be mentioned as these can have sustainability implications that may need to be addressed during the evaluation process.</li>
<li><strong>Identify Other Relevant Web Pages:</strong> Some web pages and web page states including features that are specifically relevant for improving the sustainability of your website or application. The outcome of this step is a list (with relevant explanations and information) regarding how such implementations benefit a product or service's visitors and users.</li>
</ol>
</section>
<section class="notoc"> <!-- Step 3: Test or Sample the Website -->
<h4>Step 3: Test or Sample the Website</h4>
<p>In cases where it is feasible to evaluate all web pages and web page states of a website, which is highly recommended for websites under 1,000 pages, the "selected sample" in the remaining steps of this evaluation process is the entire website. In some cases, such as for small websites, this sampling procedure may result in selecting all web pages and web page states of a website.</p>
<p>In cases where over 1,000 pages exist and the number of pages exceeds the ability to physically test every instance (or in cases where increased complexity reduces the capability to audit pages effectively), the evaluator selects a sample of web pages and web page states that is representative of the target website or application to be evaluated. The purpose of this selection is to ensure that the evaluation results reflect the sustainability of the product or service with reasonable confidence.</p>
<ul>
<li>In such samples, it must be structured in a way to include all assets and content relating to the selected web page or web page state.</li>
<li>The sample selected should be randomly chosen (a blind method such as script selection could be used as an example) to avoid bias and should be comprised of <strong>10-20%</strong> of the total website or applications structure (for example, a website comprised of 2,000 pages could test 400 pages).</li>
</ul>
</section>
<section class="notoc"> <!-- Step 4: Audit the Selected Pages -->
<h4>Step 4: Audit the Selected Pages</h4>
<p>During this step the evaluator audits (detailed evaluation of) all of the web pages and web page states selected. Carrying out this step requires the expertise described in section Required Expertise.</p>
<ol>
<li><strong>Check All Initial Web Pages:</strong> For each web page and web page state, check its conformance with each of the defined success criteria in WSG as denoted in <em>Step 1</em>. This includes all components of the web page or web page state, including any functionality and interactions that may affect the sustainability or state of the web page. Remember to include third-parties where necessary in processing and account for infrastructural and internal access requirements as the processing to meet success criteria requests to identify sustainability solutions occurs.</li>
<li><strong>Non-Interfering Verification:</strong> Ensure that any existing implementations or solutions being utilized are non-interfering. This requires that remedies do not cause compatibility issues or problems with other critical aspects such as accessibility that may otherwise prevent the page from loading or being able to be understood.</li>
</ol>
<p class="note">There are typically several ways to determine whether WSG Success Criteria have been met or not met. One example includes the set of (non-normative) <strong>Techniques</strong> for WSG provided within STAR that documents ways of meeting particular WSG Success Criteria using testable statements that will either be true or false when applied to specific web content. While evaluators can use such documented guidance to check whether particular web content meets or fails to meet WSG Success Criteria (and include this within reports), it is not required and evaluators may use other approaches to evaluate whether WSG Success Criteria have been met or not met.</p>
</section>
<section class="notoc"> <!-- Step 5: Report the Evaluation Findings -->
<h4>Step 5: Report the Evaluation Findings</h4>
<p>While evaluation findings are reported at the end of the process, documenting them is carried out throughout the evaluation process to ensure verifiable outcomes. The documentation typically has varying levels of confidentiality. For example, documenting the specific methods used to evaluate individual requirements might remain limited to the evaluator while reports about the outcomes from these checks are typically made available to the evaluation commissioner. Website or application owners might further choose to make public statements about the outcomes from evaluation according to this methodology.</p>
<ol>
<li><strong>Document the Outcomes of Each Step:</strong> Documenting the outcomes for each of the previous steps (including all sub-sections) is essential to ensure transparency of the evaluation process, replicability of the evaluation results, and justification for any statements made based on this evaluation. Evaluation reports should include names of evaluators, dates of the evaluation, the scope and requirements (of sustainability), the pages and state being tested along with any technologies being identified and relied upon, plus the results of sustainability issues identified and any key factors that have contributed to meeting (or failing to meet) targets in the WSG success criteria. In certain instances, it may be useful to offer a list of every failure occurrence for every web page and web page state for transparency reporting along with the causes and repair suggestions to remedy the failures.</li>
<li><strong>Record the Evaluation Specifics (Optional):</strong> While optional, it is good practice for evaluators to keep record of the evaluation specifics, for example to support conflict resolution in the case of dispute. This includes archiving the web pages and web page states audited, and recording the evaluation tools, web browsers, other software, and methods used to audit them. A table or grid may be useful to record what was used for the different web pages and web page states audited. When such records contain sensitive information, they need particular security and privacy precautions. Records could include copies of files, assets, and resources of the web pages stated, screenshots (screen grabs), descriptions of the path to locate a page or state during a process (or information to use when testing interactive components), names and versions of tooling; or methods, procedures, and techniques used to evaluate conformance to WSG.</li>
<li><strong>Provide an Evaluation Statement (Optional):</strong> In the majority of situations, using this methodology alone does not result in WSG conformance claims for the target websites. Website owners may wish to make public statements about the outcomes from evaluations following this methodology. If they wish to do so, they should follow the advisory guidance provided in the WSG conformance section in order to provide a statement relating to the level of sustainability they have achieved.</li>
</ol>
</section>
</section>
</section>
<section class="informative"> <!-- WSG Techniques -->
<h2>WSG Techniques</h2>
<section> <!-- Techniques overview -->
<h3>Techniques overview</h3>
<p>WSG guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc.</p>
<p>STAR techniques guide web content authors and evaluators on meeting WSG success criteria and guidelines, which include code examples, resources, and tests. Techniques are updated periodically to cover additional current best practices and changes in technologies and tools.</p>
<p>The three types of techniques for STAR are explained below:</p>
<ul>
<li>Sufficient techniques</li>
<li>Advisory techniques</li>
<li>Failures</li>
</ul>
<section class="notoc"> <!-- Techniques are Informative -->
<h4>Techniques are Informative</h4>
<p>Techniques are informative, meaning they are not required. The basis for determining conformance to WSG is the success criteria from guidelines within the specification and not the techniques themselves. We also caution against requiring specific techniques or tests mentioned within this document. The only thing that should be required is meeting the WSG success criteria.</p>
</section>
<section class="notoc"> <!-- Technique Types -->
<h4>Technique Types</h4>
<p><em>Sufficient techniques</em> are reliable ways to meet the success criteria.</p>
<ul>
<li>From an author or evaluator's perspective: If you use sufficient techniques for a given criterion correctly and it is sustainable within the context of its wider application and usage, you can be confident that you met the success criterion.</li>
</ul>
<p><em>Advisory techniques</em> are suggested ways to improve sustainability. They are often very helpful and maybe a significant way of reducing emissions or meeting primary PPP objectives.</p>
<p>Advisory techniques are not designated as sufficient techniques for various reasons such as:</p>
<ul>
<li>They may not be sufficient to meet the full requirements of the success criteria;</li>
<li>They may be based on technology that is not yet stable;</li>
<li>They may not be testable;</li>
</ul>
<p>Authors are encouraged to apply all of the techniques where appropriate to best address the widest range of sustainability benefits.</p>
<p><em>Failures</em> are things that cause sustainability issues and fail specific success criteria. The documented failures are useful for:</p>
<ul>
<li>Authors to know what to avoid,</li>
<li>Evaluators to use for checking if the content does not meet WSG success criteria.</li>
</ul>
<p>Content that has a failure does not meet WSG success criteria unless an alternate version is provided without the failure.</p>
</section>
<section class="notoc"> <!-- Scope and Limitations -->
<h4>Scope and Limitations</h4>
<p>In addition to the techniques, there are other ways to meet WSG success criteria. STAR techniques are not comprehensive and may not cover newer technologies and situations. Web content does not have to use STAR techniques to conform to WSG. Content authors can develop different techniques. For example, an author could develop a technique for an existing, or other new technology. Other organizations may develop sets of techniques to meet WSG success criteria. Any techniques can be sufficient if they satisfy the success criterion.</p>
<p>Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WSG success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is sustainable on multiple levels.</p>
<p>The <a href="https://github.com/w3c/sustainableweb-ig/">Sustainable Web Interest Group</a> encourages people to submit new techniques so that they can be considered for inclusion in updates of the STAR document. Please submit techniques for consideration using <a href="https://github.com/w3c/sustainableweb-wsg/issues/">GitHub issues</a>.</p>
</section>
<section class="notoc"> <!-- Testing Techniques -->
<h4>Testing Techniques</h4>
<p>Each technique has tests that help:</p>
<ul>
<li>Authors verify that they implemented the technique properly, and</li>
<li>Evaluators determine if web content meets the technique.</li>
</ul>
<p>The tests are only for a technique, they are not tests for conformance to WSG success criteria.</p>
<ul>
<li>Failing a technique test does not necessarily mean failing WSG, because the techniques are discrete (that is, they address one specific point) and they are not required.</li>
<li>Content can meet WSG success criteria in different ways other than STAR published sufficient techniques.</li>
</ul>
<p>While the techniques are useful for evaluating the content, evaluations must go beyond just checking the sufficient technique tests to evaluate how content conforms to WSG success criteria (considerations such as accessibility, privacy, security, etc).</p>
<p>Failures are particularly useful for evaluations because they do indicate non-conformance (unless an alternate version is provided without the failure).</p>
</section>
<section class="notoc"> <!-- Using the Techniques -->
<h4>Using the Techniques</h4>
<p>Techniques for WSG are not intended to be used as a standalone document. Instead, it is expected that content authors will usually use our quick reference to read the WCAG success criteria and follow links from there to specific guidelines within the specification (including examples and techniques).</p>
<p>Some techniques may describe how to provide alternate ways for visitors to get content. Alternative content, files, and formats must also conform to WSG and meet relevant success criteria, thereby becoming sustainable.</p>
<p>The code examples in the techniques are intended to demonstrate only the specific point discussed in the technique. They might not demonstrate best practices for other aspects of sustainability, accessibility, usability, or coding not related to the technique. They are not intended to be copied and used as the basis for developing web content.</p>
<p>Many techniques point to "working examples" that are more robust and may be appropriate for copying and integrating into web content.</p>
</section>
</section>
<section> <!-- User Experience Design -->
<h3><dfn data-lt="UX">User Experience Design</dfn></h3>
<p>Each of the below can be shown or hidden by clicking on the technique you wish to display.</p>
<ol>
<li> <!-- UX01-1: Produce a list of variables to monitor for sustainability impacts -->
<details>
<summary id="UX01-1">UX01-1: Produce a list of variables to monitor for sustainability impacts</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#display-any-variables-that-have-a-negative-impact-on-your-project">2.1 Display any variables that have a negative impact on your project</a>.</p>
<p><strong>Description</strong></p>
<p>Create a maintainable list of different variables that may impact the sustainability of a product or service over time. By having this list in place, everyone in the creation process can closely monitor the application or website against each variable to determine if an PPP variable present on the list will require resolution either before, during, or after a product or service is launched.</p>
<p>This list should be created during ideation if possible but can also be machine-generated from a pre-determined list of known PPP factors using evidence and research. The content of this material could be further tested through automation if such variables can be aligned with product capabilities however at a bare minimum, this list must be publicly visible (such as within a sustainability statement) and utilized in-house to enact sustainable change.</p>
<p><strong>Examples</strong></p>
<ol>
<li><a href="https://websitesustainability.com/cache/files/variables.pdf">The Variables of Website Sustainability</a> provides a comprehensive map of the various carbon traps that exist on the Internet. From business and external elements to development and rendering, it provides a visual representation of the energy usage that can trigger emissions.</li>
<li>The <a href="https://blog.scottlogic.com/2024/02/13/announcing-the-proposed-technology-carbon-standard.html">(Proposed) Technology Carbon Standard</a> is an approach to classify an organization's technology carbon footprint. It's based on the Greenhouse Gas Protocol (GHG) and aligns with Scope 1, 2, and 3 emissions.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Identify all machine-generated variables (hardware / software, etc).</li>
<li>Identify all human-generated variables (business / user, etc).</li>
<li>Create a checklist to be published within sustainability processes.</li>
<li>Circulate among employees as part of the testing workflow.</li>
<li>Check that all variables have been accounted for before publication.</li>
<li>Report the findings within your sustainability statement.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX02-1: Use quantitative research to measure the needs of visitors and affected communities -->
<details>
<summary id="UX02-1">UX02-1: Use quantitative research to measure the needs of visitors and affected communities</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#understand-visitor-requirements-or-constraints-resolving-barriers-to-access">2.2 Understand visitor requirements or constraints, resolving barriers to access</a>.</p>
<p><strong>Description</strong></p>
<p>Provide a mechanism for application and website owners to better curate their products and services around the needs of their visitors and those affected by what has been created and in doing so, reduce the PPP burden which can impact the sustainability of the website, especially around Social, people-centered (and user experience) impacts.</p>
<p>It should be noted that for machine automation, only quantitative feedback will be able to be processed (and therefore useful) and all information gathering must be done sustainably and ethically. It should also be noted that because information is being requested, internal access may be required to formally identify certain characteristics necessary for processing.</p>
<p><strong>Examples</strong></p>
<ol>
<li><a href="https://www.hotjar.com/quantitative-data-analysis/software/">Quantitative data analysis</a> allows you to identify how your website or application is doing, find patterns in visitor behavior, and make decisions that can benefit your visitors and optimize your product or service to reduce emissions over time.</li>
<li><a href="https://www.nngroup.com/articles/user-feedback/">Feedback forms</a> are a great way to get qualitative measurements to reinforce the numbers to ensure that any changes you are considering are wanted, satisfy the needs of visitors, and meet the sustainability challenge.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check to see if deliverables require internal access (if so, permission is given).</li>
<li>Gather metrics data through browser APIs, analytics, or third-party software.</li>
<li>Identify resolvable variables that are causing PPP issues.</li>
<li>Once validated as accurate, test further using non-machine testable qualitative methods such as A / B measurement or feedback forms.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>If #1, #2 and #3 above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX02-2: Identify visitor constraints using browser detection and the User-Agent -->
<details>
<summary id="UX02-2">UX02-2: Identify visitor constraints using browser detection and the User-Agent</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#understand-visitor-requirements-or-constraints-resolving-barriers-to-access">2.2 Understand visitor requirements or constraints, resolving barriers to access</a>.</p>
<p><strong>Description</strong></p>
<p>Provide a mechanism so that websites and applications can offer contingency processes for visitors who have constraints such as an older device, an out-of-date operating system, an unusual or out-of-date browser, or a slow Internet connection. Other contingencies exist (such as geo-blocking or mobile data costs) and these can also be taken into account if detection is possible. Each of these issues can burden the user experience and cause added conflict along the pipeline in terms of emissions.</p>
<p>If detection is not available (such as in cases where the Internet is unavailable), Non-digital investigation should be conducted where possible (such as through the use of mail or telephone feedback). Once the constraint has been detected, it will often be up to the developer to create a solution that will involve compatibility features or reducing the load on the visitor's device to increase ease of access. If there are questions regarding the potential compatibility or availability of services due to a certain configuration, seek the manufacturer's advice for further guidance.</p>
<p><strong>Examples</strong></p>
<ol>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Browser_detection_using_the_user_agent">Using</a> <a href="https://developer.mozilla.org/en-US/docs/Web/API/Navigator/userAgent">UserAgent</a> to identify visitor characteristics that might impact their experience when using your product or service such as an issue of compatibility or performance.</li>
<li>Certain political situations may result in the inability for visitors to access your product or service hassle-free such as geo-blocking restrictions, the cost of bandwidth, or government-enacted firewalls, filters, or authentication requirements.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check that all visitor constraints have been detected.</li>
<li>Ensure that a suitable solution is in place to handle each such event.</li>
<li>Check other contingencies that may affect the availability of your product or service.</li>
<li>Check if a solution can be offered for contingencies, otherwise, try working with partner groups to find solutions.</li>
<li>Check that visitors can trigger the constrained environment manually.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX02-3: Test against specific disability profiles for more calibrated accessibility -->
<details>
<summary id="UX02-3">UX02-3: Test against specific disability profiles for more calibrated accessibility</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#understand-visitor-requirements-or-constraints-resolving-barriers-to-access">2.2 Understand visitor requirements or constraints, resolving barriers to access</a>.</p>
<p><strong>Description</strong></p>
<p>Go beyond the remit of <abbr title="Web Content Accessibility Guidelines">WCAG</abbr> and accessibility by default and to encourage designers and developers of products to test their creations against a range of specific named types of disabilities to both better understand the conditions and to be able to more structurally and sustainably better test for the unique issues each disability brings to technology in terms of adaptation.</p>
<p>It is strongly encouraged that teams work with individuals with disabilities when attempting this task as they will have the lived experience to help you better adapt your products and services to their needs. If this isn't possible or you wish to theorize against certain pre-built profiles, you can refer to established medical texts to identify potential symptoms and refer these against issues that may cause technology issues, building solutions, and / or simulators (see color blindness) to help test for issues along the creation process.</p>
<p><strong>Examples</strong></p>
<ol>
<li>The use of a color-blind filter such as the one built into browser DevTools or another <a href="https://github.com/interaktivarum/rgblind?tab=readme-ov-file">third-party solution</a> potentially helps to identify contrast issues that might not otherwise be detected within an existing website.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Identify visitors or individuals with disabilities who can help you become more accessible.</li>
<li>Create testable profiles from symptom / issue lists that cause issues.</li>
<li>Check that potential solutions don't interfere with existing functionality.</li>
<li>Create and implement newly calibrated accessibility features.</li>
<li>Check that the features work as implemented against all existing functionality.</li>
<li>Report the findings within your accessibility statement.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX03-1: Use third-party APIs to measure any passive external impact -->
<details>
<summary id="UX03-1">UX03-1: Use third-party APIs to measure any passive external impact</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#understand-the-impact-of-non-visitors">2.3 Understand the impact of non-visitors</a>.</p>
<p><strong>Description</strong></p>
<p>Utilize the tooling and resources provided by external parties to help you identify any efficiency and sustainability savings when having to use such services, or when non-digital forces come into play, such as if your product or service involves the physical delivery of goods.</p>
<p>Getting the PPP equation of the sustainability of such forces can be difficult to track, especially as third parties may omit data or not provide a complete picture of their scope emissions. Therefore, care must be taken when choosing providers from the offset and consideration must also be given to the impact of using the API to gather such data together.</p>
<p><strong>Examples</strong></p>
<ol>
<li>Using third-party tooling you can <a href="https://www.cocooncarbon.co.uk/">calculate</a> the carbon emissions from logistics and delivery of physical shipping which can be integrated into your calculations. They also have a <a href="https://developer.cocoonfms.co.uk/">public <abbr title="Application Programming Interface">API</abbr></a> you can use as well.</li>
<li>Non-users who are affected by a service can be identified by technical support teams and responses required are added to a list for the developers to machine test for compliance at the next release version.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Identify providers who will offer transparent PPP measurements.</li>
<li>Check the impact of utilization of third-party APIs (if possible).</li>
<li>Check the impact of non-users or passive users affected by your service.</li>
<li>Check that impacted visitors are accounted for in compliance checks.</li>
<li>Report the findings within your sustainability statement.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX06-1: Measure interaction cost to reach every page in the information architecture -->
<details>
<summary id="UX06-1">UX06-1: Measure interaction cost to reach every page in the information architecture</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#minimize-non-essential-content-interactivity-or-journeys">2.6 Minimize non-essential content, interactivity, or journeys</a>.</p>
<p><strong>Description</strong></p>
<p>Reduce the cognitive load for visitors between the initial visit to a website or application and reaching their final destination where the information they are seeking is located. The path to locating such information can be routed through multiple interactions such as a search mechanism, hyperlinks, form controls (where appropriate), and progressive disclosure features (reducing the complexity involved in reaching a destination will reduce the rendering load leading to sustainability benefits).</p>
<p>While there is no hard and fast rule regarding the number of clicks required to meet a visitor's expectations, including clear way-finding (breadcrumbs can be machine-identified as can landing page regions to guide visitors along the path). It is therefore a sensible precaution to ensure that the steps required are well documented to avoid overwhelming a visitor. If required, click-through testing can be measured to identify bottlenecks in complex applications.</p>
<p><strong>Examples</strong></p>
<ol>
<li>While the <a href="https://www.nngroup.com/articles/3-click-rule/">three-click rule</a> is a false heuristic, employing common navigation patterns within a header or footer can help visitors traverse a product when multiple click-throughs are necessary to reach a destination faster.</li>
<li>In complex websites, where multiple levels of documents and potentially thousands of pages may exist, <a href="https://blog.hubspot.com/marketing/navigation-breadcrumbs">having breadcrumbs</a> so that visitors can track their progress through the layers of a system (and even having dropdown navigation menus through each layer) can help with navigating the information architecture of a product or service with fewer barriers to access.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check that the information architecture has been designed with clarity in mind.</li>
<li>Check the page for identifiable way-finding processes along a route such as breadcrumbs and landing regions / page patterns.</li>
<li>Check that the number of choices for each action doesn't exceed a set amount.</li>
<li>Check that every action is well documented and that the expected action occurs.</li>
<li>Check the visitor flow path for achieving set goals and optimize with shortcuts if necessary.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX06-3: Check for content obscuring materials that occur upon pageLoad -->
<details>
<summary id="UX06-3">UX06-3: Check for content obscuring materials that occur upon pageLoad</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#minimize-non-essential-content-interactivity-or-journeys">2.6 Minimize non-essential content, interactivity, or journeys</a>.</p>
<p><strong>Description</strong></p>
<p>Ensure that visitors can read the materials produced for your website or application and click on interactive content (such as links or buttons) that would otherwise be impaired by other content that due to positioning obscures the material by preventing the page from functioning correctly (wasted clicks, especially if JavaScript functions monitor them could lead to emission costs so its best to avoid unnecessary actions).</p>
<p>There will be occasions when content should be obscured to progressively disclose additional content, but for unintentional overlapping, obscuring deliberately for attention (unnecessary), and all cases where the visitor did not ask to be impacted, the visibility of the content should be assured (either manually or mechanically through identifying object locations and dimensions plus where conflicts arise, issue remedial advice).</p>
<p><strong>Examples</strong></p>
<ol>
<li>Advertising is often a cause of content that temporarily overlaps content with the intent of requesting clicks or attention-grabbing to monetize the material on the website or application. While such actions may be financially reasoned, they are rarely sustainably minded.</li>
<li>Consent managers are an example of obscuring materials for the good as they ensure that visitors to the page authorize potentially invasive technologies before they become active. An example of this is the cookie consent banner that asks for their allowance before they can be used to store sensitive information on the visitor's machine.</li>
<li>Scrollable content in which the scrollbar has been obscured, replaced (with a non-functional, obscured, or hidden replacement), or hidden entirely making it impossible to detect where additional content may occur beyond just the window (such as in overflowing boxes) will be unavailable to visitors making its use of hardware to render a waste of resources.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check the page's content to ensure none is clipped by other materials or an overflow issue (with a scrollbar lacking).</li>
<li>Check that all links and buttons are functioning.</li>
<li>Check that progressive disclosing content only appears when requested.</li>
<li>Check that necessary disclosing materials that obscure content can be easily removed.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX06-4: Break large pieces of content down using progressive disclosure -->
<details>
<summary id="UX06-4">UX06-4: Break large pieces of content down using progressive disclosure</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#minimize-non-essential-content-interactivity-or-journeys">2.6 Minimize non-essential content, interactivity, or journeys</a>.</p>
<p><strong>Description</strong></p>
<p>Help increase the readability of content within a website or application by breaking down larger pieces of content into smaller constituent pieces. In the same way that a book is broken down into chapters, using progressive disclosure you can reveal sections when the reader is ready, avoiding information overload (the same can be done with long tasks).</p>
<p>For machine testability, identification of such progressive disclosure markers can be found using the HTML details or dialog element, the CSS target selector (and its accompanying HTML ID attributes), the CSS checkbox hack, the use of JavaScript HashBangs, and also the use of state (and content) changes through various frameworks. Each of these can build a picture of how content displays on-screen during the user experience, and some can load content only when it is requested which can reduce data transfer and rendering requests leading to sustainability improvements.</p>
<p><strong>Examples</strong></p>
<ol>
<li>Tabs can be a simple way in which <a href="https://www.gov.uk/bank-holidays">you can showcase</a> different pieces of information to an audience. By using a mechanism such as the CSS target selector you can reveal information based on its related HTML ID.</li>
<li>Dropdown menus such as the one you will find on many websites disclose from a single link several additional roadmapped locations which are grouped children in the information architecture of the product or service.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check that progressive disclosure is used appropriately with your content or tasks to perform.</li>
<li>Check that progress can be made from one disclosure to another.</li>
<li>Check that each disclosure element can be closed successfully.</li>
<li>Check that the disclosure method you use is compatible with visitor's browsers.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX06-5: Remove any non-user initiated pop-up or model windows -->
<details>
<summary id="UX06-5">UX06-5: Remove any non-user initiated pop-up or model windows</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#minimize-non-essential-content-interactivity-or-journeys">2.6 Minimize non-essential content, interactivity, or journeys</a>.</p>
<p><strong>Description</strong></p>
<p>Reduce problematic friction within the user experience and help reduce the number of dark patterns which might occur onLoad and during the interaction process as these can cause considerable sustainability issues as a result of wasted emissions. By ensuring that the visitor remains in control of the interface and that websites and applications work as expected, a more ethical and optimized product or service is likely to result.</p>
<p>Machine testing can analyze JavaScript for the use of popup events, the appearance of "_blank" within hyperlinks or frames, or other functionality that exists that may produce overlays. It's important to question the acceptability of such usage for example, opening links in new windows may be acceptable for non-web formats like PDF, otherwise, it's best to advise against its use.</p>
<p><strong>Examples</strong></p>
<ol>
<li>While not as common today, popup advertisements which appear in a new window or in a separate frame used to be a fixture of the early web and required heavy visitor management to close multiple banners that would trigger.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check for CSS and JavaScript overlays that may occur onLoad and remove when identified.</li>
<li>Check that any popup events can only be initiated with the visitor's consent.</li>
<li>Check all hyperlinks for new window opening triggers (and action as appropriate).</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX07-1: Decorative design elements can be disabled if they are not done so by default -->
<details>
<summary id="UX07-1">UX07-1: Decorative design elements can be disabled if they are not done so by default</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#use-decorative-design-with-care">2.7 Use decorative design with care</a>.</p>
<p><strong>Description</strong></p>
<p>Provide a mechanism in which visitors can reduce their impact by choosing to have a more basic experience (to what extent will be up to the developer) by downloading fewer external resources, scripts, and other assets to their machine to be processed and rendered. With this action, a website or application that is already optimized for sustainability can go one step further in providing a barebones format for those wishing to prioritize lowering their footprint over having added functionality.</p>
<p>This action could be performed by defining what assets have been added to the product or service to enhance the experience but are not of critical importance (such as background images, or decorative flourishes that can be machine identified). Other forms of decoration can also be machine-identified such as CSS flourishes to content and images, background sounds, custom cursors, custom scrollbars, etc.</p>
<p><strong>Examples</strong></p>
<ol>
<li>Web browsers can <a href="https://csscursor.info/">change CSS cursors</a>, and while there may be functional reasons to do so under certain circumstances, such as to indicate loading progress, zoom, or click-ability, in most circumstances, you should leave it at the system default as this is the expected behavior.</li>
<li>CSS scrollbars <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scrollbars_styling">can be customized</a> or replaced but this can be problematic for visitors. Changes in scroll speed or its mechanics can affect impact readability and the way things render, and color changes can impact visibility and affect overflow regions within elements of the page. In such cases, the system default always functions better than a custom solution.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check decorative images are clearly labeled using ARIA so assistive technologies can skip them.</li>
<li>Check that CSS decoration can be disabled if it may interfere with readability.</li>
<li>Check that custom scrollbars and cursors can be disabled as they may interfere with a visitor's ability to interact with the screen.</li>
<li>Check that background sounds can be disabled and do not auto-load or auto-play.</li>
<li>Check that decorative features can be disabled at the visitor's request.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX08-1: Making your navigation menu accessible and well-structured -->
<details>
<summary id="UX08-1">UX08-1: Making your navigation menu accessible and well-structured</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#ensure-that-navigation-and-way-finding-are-well-structured">2.8 Ensure that navigation and way-finding are well-structured</a>.</p>
<p><strong>Description</strong></p>
<p>Verify that your navigation menu is crafted in such a manner that it is both accessible to visitors and user-agents and functions correctly so that when implemented it doesn't lead to issues when attempting to browse the information architecture of a website or application. If the information architecture were to fail, this would lead to PPP failings as your visitors would no longer be able to use the product or service without encountering barriers to access and risk further emissions attempting to solve the issue.</p>
<p>Machine testing the structure of a navigation menu will usually involve the nav, ul, or ol elements within the header of a product or service which repeats across pages and assuming that links function as expected and click ratios (sizes) are large enough on both desktop and mobile platforms, any search functionality will also need to be tested to ensure that results are provided upon submission.</p>
<p><strong>Examples</strong></p>
<ol>
<li>The hamburger design is often considered the stereotype of <a href="https://www.smashingmagazine.com/2022/11/navigation-design-mobile-ux/">mobile functionality</a>, a three-lined icon that represents a menu upon clicking it reveals a full-screen list of options. Employing good patterns is key to reducing confusion and abandonment from visitors.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check that the structure of the navigation menu is semantically correct.</li>
<li>Check that the structure of the navigation menu is repeated across all pages.</li>
<li>Check that the click sizes / ratios of anchors in navigation menus are large enough on both mobile and desktop to be comfortable.</li>
<li>Check that the <abbr title="Uniform Resource Locators">URLs</abbr> provided within links do not lead to errors.</li>
<li>Check that any search functionality provides results (not errors) upon submission.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX08-2: Provide a human-readable sitemap to improve the information architecture -->
<details>
<summary id="UX08-2">UX08-2: Provide a human-readable sitemap to improve the information architecture</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#ensure-that-navigation-and-way-finding-are-well-structured">2.8 Ensure that navigation and way-finding are well-structured</a>.</p>
<p><strong>Description</strong></p>
<p>Increase the findability of the content within your website among search engines and social networks. By creating a <abbr title="Extensible Markup Language">XML</abbr> sitemap in the base directory of your website, and potentially having a human-readable) HTML sitemap to supplement it, you provide an index of all the publicly available pages. This acts as a potential signpost for individuals who may find themselves seeking information but not knowing exactly where it is stored.</p>
<p>When creating an HTML sitemap it will be important to categorize pages into lists based on what section of the website they appear in (for human readability) rather than providing everything in a single long list. Structurally, you could use lists within lists to provide this distinction or use subheadings with individual lists. Both methods should ensure to be semantically correct and accessible to meet the human requirements of PPP targets.</p>
<p><strong>Examples</strong></p>
<ol>
<li>The <a href="https://www.sitemaps.org/protocol.html">Sitemaps protocol</a> showcases a basic XML sitemap format that can be used within the base directory of a website. It is supported by search engines like Google and can be submitted for indexing which can increase findability and potentially help visitors find your product or service quicker.</li>
<li>An <a href="https://www.semrush.com/blog/html-sitemap/">HTML sitemap</a> is a more visually organized showcase of the pages publicly available within your product or service. The idea behind it is to be as comprehensive as possible but not to overwhelm the visitor. This might be the ideal place to use a system like progressive disclosure so that you can guide individuals through the materials you provide interactively.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check for a sitemap.xml file in the base directory of a website.</li>
<li>Check that the markup of the file is semantically correct.</li>
<li>Check that all of the links held within don't produce any errors.</li>
<li>Check for the existence of a publicly visible HTML sitemap.</li>
<li>Check that the file exists alongside a sitemap.xml format.</li>
<li>Check that the HTML sitemap is semantically correct.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX08-3: Provide a method of keeping up-to-date with product or service updates -->
<details>
<summary id="UX08-3">UX08-3: Provide a method of keeping up-to-date with product or service updates</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#ensure-that-navigation-and-way-finding-are-well-structured">2.8 Ensure that navigation and way-finding are well-structured</a>.</p>
<p><strong>Description</strong></p>
<p>Ensure that visitors and users of an application or website can monitor changes and events that occur over time. The need to be able to track such events is critical as customers become reliant on products and services. This reliance on such features means that time will have been invested into learning how to set up and use the product, which if it fails could have a sustainability impact not just for the product or service owner, but for those reliant on its ability to function.</p>
<p>Every product or service will have its own update schedule and there will be no hard and fast rule in terms of how often a website or application should be offering new releases. That being said, there should be a mechanism in place to describe news events both in a syndicated format and on the website, and a system status mechanism to identify any current issues with the product or service.</p>
<p><strong>Examples</strong></p>
<ol>
<li><a href="https://www.apple.com/newsroom/">Apple has a newsroom</a> that is very minimalistic yet it contains all that you would expect from a news category from a major website. It has grouped stories with useful headlines, dates, categories, and a picture. Having something similar for your website can help visitors find new material quickly and reduce churn digging through archives.</li>
<li><a href="https://www.w3.org/blog/feed/">Syndication feeds</a> come in multiple different formats but the most common is the <a href="https://www.rssboard.org/rss-specification"><abbr title="Really Simple Syndication">RSS</abbr> format</a>. They are compatible with readers on every platform and can be a useful way to get news to subscribers quickly. While these make regular requests to websites, they request less data and result in visitors spending less time browsing overall which is an emissions-positive event.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check for a news page or category of a website.</li>
<li>Check the news section has been updated within 12 months.</li>
<li>Check for a syndication feed in RSS, Atom, or <abbr title="JavaScript Object Notation">JSON</abbr>.</li>
<li>Check the syndication feed has been updated within 12 months.</li>
<li>Check for other syndicated events (podcasts, <abbr title="Outline Processor Markup Language">OPML</abbr>, etc).</li>
<li>Check the syndication feed is semantically correct.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX09-1: Request permission for invasive access to interact with content -->
<details>
<summary id="UX09-1">UX09-1: Request permission for invasive access to interact with content</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#be-attentive-rather-than-distracting">2.9 Be attentive rather than distracting</a>.</p>
<p><strong>Description</strong></p>
<p>Use the least amount of permission requests required to achieve a given task. Allowing the visitor to control when they receive information is critically important but it's also important not to burden them with requests to access hardware or do things that might prove invasive (such as triggering notifications or a pop-up window).</p>
<p>For mechanical testability, JavaScript APIs can check using methods such as requestPermission() to identify if a website or application has been granted access to use various hardware or potentially abusable features within the web browser. Unsubscribe, and delete / freeze account links could also be identified (with internal access being granted).</p>
<p><strong>Examples</strong></p>
<ol>
<li>Cookie notification messages are required by law (the <abbr title="European Union">EU</abbr> Cookie Directive) and could be identified by a script. These are heavily featured within websites and allow visitors to prioritize privacy over the availability of functionality assuming that they are implemented correctly.</li>
<li>Customizing or removing functionality within applications can help simplify the workflow of a visitor and increase the productivity within an interface (which will have sustainability benefits as it could reduce the weight from unnecessary features loading and visitors spending less time at the screen).</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check which permissions from the available APIs are being granted.</li>
<li>Check if products or services have unsubscribe / account freezing and removal options.</li>
<li>Check if cookies are used and if so, if notifications are triggered appropriately (with the option to disable all).</li>
<li>Check if applications plug-in functionality and allow for customization.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX09-2: Encourage features that help visitors achieve tasks -->
<details>
<summary id="UX09-2">UX09-2: Encourage features that help visitors achieve tasks</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#be-attentive-rather-than-distracting">2.9 Be attentive rather than distracting</a>.</p>
<p><strong>Description</strong></p>
<p>Lower the barriers to entry with content. When dealing with complex, multi-page websites it becomes increasingly important to have features in place to allow visitors to bypass repeated elements that they have already prefilled to achieve goals quicker (this is a key variable for sites who have large membership numbers).</p>
<p>There are functional ways to increase the flow through a website and allow visitors to accomplish a task that can also be machine-testable. This technique is most useful when dealing with complex pieces of content, multi-step products, or services that have a lot of functionality that may require shortcuts to allow faster decision-making under certain conditions.</p>
<p><strong>Examples</strong></p>
<ol>
<li><a href="https://goodlinks.app/">Read-It-Later</a> software may be provided by third-parties but they allow for both offline access to content on a variety of platforms and customization of the materials visually based on the visitor's requirements.</li>
<li>Quick purchase features (such as Amazon's famous "Buy Now" button) allow for the immediate purchase of a product, skipping past the shopping basket steps and using prior purchase knowledge to reduce friction.</li>
<li>Shortcut links and patterns can be used to skip ahead or over information and / or pages when it is recognized that the information may not be relevant or required in a multi-step process (such as form filling).</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check for read-it-later compatibility within articles.</li>
<li>Check for purchasable products and the option to quickly purchase (bonus points if no login is required).</li>
<li>Check if the HTML head contains landmark links of relevance to be identified.</li>
<li>Check for recognized landmark shortcuts (skip links, etc) and that they are functional.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX09-3: Avoid mechanisms that promote excessive screen time -->
<details>
<summary id="UX09-3">UX09-3: Avoid mechanisms that promote excessive screen time</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#be-attentive-rather-than-distracting">2.9 Be attentive rather than distracting</a>.</p>
<p><strong>Description</strong></p>
<p>Allow the visitor to achieve the task they initially set out to do and not trigger unnecessary issues in the user experience which would undermine their ability to complete the said task. Issues such as infinite scrolling can promote a need for continued browsing (which can load excessive data and have a sustainability impact on rendering) and loading overlays that deviate visitors from their path will have wider societal impacts on PPP targets which need to be considered.</p>
<p>Within this technique, machine testability can be considered by examining if common link pagination landmarks (previous, next, <numbers>, etc) exist within category listings and if overlays or attention-keeping features are detected for common patterns (such as those mentioned in the examples below). If screen addition mechanisms are determined to be in use within a website, this should be considered a failing mark against the related success criteria.</p>
<p><strong>Examples</strong></p>
<ol>
<li>Sale promotional overlays are a common theme that displays upon loading a page and requests the visitor take notice of them before dismissing them to view the content they want to examine.</li>
<li>Information request overlays are another model window that often appears during a browsing session such as requesting your email address for a newsletter or your details to encourage sign-up after a timed period.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check if infinite scrolling is being used through pagination landmark links.</li>
<li>Check for recognized attention-keeping patterns that obscure content.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX10-1: Build using established design patterns that use known conventions -->
<details>
<summary id="UX10-1">UX10-1: Build using established design patterns that use known conventions</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#use-established-design-patterns-and-appropriate-components">2.10 Use established design patterns and appropriate components</a>.</p>
<p><strong>Description</strong></p>
<p>Use repeating patterns that visitors are likely to recognize from visits to other websites to build a sense of comfort and identification with your products and services. By using established design patterns that are repeatable, recognizable, and testable, you can reduce the amount of confusion likely to occur within a user-interface and this will increase the speed of adaptability (which has sustainability benefits).</p>
<p>It should be noted that for machine testability, heuristic recognition (identification of patterns in code) will likely allow product creators to recognize the implementation of certain patterns, especially when libraries or design systems are utilized as the backbone of a product or service. Through this, recommendations can be made to improve layouts.</p>
<p><strong>Examples</strong></p>
<ol>
<li>A website layout could follow a <a href="https://htmlburger.com/blog/website-layout-ideas/">conventional design pattern</a> aimed at a recognized reading flow such as the F or Z pattern. They are based on established scientific studies of how people first identify and then read content on a screen. The mechanics behind such layouts are designed using CSS and can be identified based on the grid or flexbox pattern used to reduce the time visitors spend scanning the screen.</li>
<li><a href="https://ui-patterns.com/patterns">Individual components</a> that aim to be repeatable conventions across products and services can take many forms (some are often provided as third-party services due to the build complexity involved) and should aim to be visually recognizable even if stylistic differences occur for branding which will help reduce wasted screen time.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check for common in-page design patterns or libraries.</li>
<li>Verify page components and overall design against established conventions.</li>
<li>Check for and implement solutions for layout flow issues that could be optimized using an established pattern.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX11-1: Eliminate deceptive design patterns or manipulative techniques -->
<details>
<summary id="UX11-1">UX11-1: Eliminate deceptive design patterns or manipulative techniques</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#avoid-being-manipulative-or-deceptive">2.11 Avoid being manipulative or deceptive</a>.</p>
<p><strong>Description</strong></p>
<p>Prevent the visitor from being manipulated being a recognized dark pattern that falls under the umbrella of deceptive design. While there are a large number of ways to code ethically, using any one of these named practices would constitute a failure against WSG guidelines and as such, ensuring that practices are not used is worthy of inclusion.</p>
<p>Machine testability for deceptive patterns will vary based on the type in use however the potential to integrate artificial intelligence to assist with more subtle uses of manipulation within tooling could be used. More obvious issues derided from code injection can be flagged and reported as problematic.</p>
<p><strong>Examples</strong></p>
<ol>
<li>Disabling interface functionality such as the ability to highlight / select the text, right-click on content, copy the content to the clipboard, print, or paste passwords from management software can cause significant problematic friction.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check for bad practices such as those mentioned in the examples.</li>
<li>Check against a library of <a href="https://www.deceptive.design/">deceptive design</a> patterns.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX11-3: Determine if analytics can be sustainably improved or removed -->
<details>
<summary id="UX11-3">UX11-3: Determine if analytics can be sustainably improved or removed</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#avoid-being-manipulative-or-deceptive">2.11 Avoid being manipulative or deceptive</a>.</p>
<p><strong>Description</strong></p>
<p>Eliminate the PPP human (third-party emissions, privacy, and performance) issues that relate to the use of analytics software. While this technique doesn't advocate that such software needs to be removed in all instances, the potential to flag poor-performing options and recommend more optimized solutions (or request removal) will be recommended.</p>
<p>This should take into consideration the need for analytics in other success criteria (for research metrics) before recommending removal and identifying low-carbon options for third-party solutions (where data exists). Additional criteria based on PPP values (such as privacy and security) should also be considered.</p>
<p><strong>Examples</strong></p>
<ol>
<li>Some <a href="https://bejamas.com/blog/best-ga4-alternatives-for-2023">analytics providers</a> have made steps to become more sustainable which would potentially make them a better replacement for bulkier, more intrusive packages.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check to determine if an analytics script is being used within the page.</li>
<li>Check against a list of suppliers of software to determine viable alternatives.</li>
<li>Check to determine if data being gathered complies with GDPR and other privacy legislation.</li>
<li>If no viable alternative exists and it still performs poorly, recommend removal.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX11-4: Eliminate Any Manipulative SEO Techniques From Your Source Code -->
<details>
<summary id="UX11-4">UX11-4: Eliminate any manipulative <abbr title="Search Engine Optimization">SEO</abbr> techniques from your source code</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#avoid-being-manipulative-or-deceptive">2.11 Avoid being manipulative or deceptive</a>.</p>
<p><strong>Description</strong></p>
<p>Proof your code and content for practices that might detract from the user experience but are done, purely in an attempt to gain higher rankings from within search engines. While getting such a position would be beneficial, using such techniques will often get the reputation of your site on these services tarnished and your rank will suffer significantly.</p>
<p>Your visibility in search engines and social media matters. Visibility is how people find you on the web. If people cannot find you or sections of your website or application, they will consume resources in that effort (or trying to find a replacement). Additionally, bad SEO practices targeting only machines consume visitor resources for rendering and produce excess emissions.</p>
<p><strong>Examples</strong></p>
<ol>
<li>Keyword stuffing is a practice in which the terms you want to be recognized for get repeated throughout your documents. While mentioning it occasionally is good, going over the top can hurt readability and bloat pages further, which is why it isn't considered sustainable.</li>
<li>Hiding content, for example, using small font sizes, making the text the same color as the background, hiding text behind images, or generating CSS or JavaScript content purely for search engines is considered bad practice.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check for the keywords <abbr title="Metadata">META</abbr> tag and recommend its removal.</li>
<li>Check for the refresh META tag and recommend replacement with a page redirect header.</li>
<li>Check for hidden content as identified in the above example and promote visibility or removal.</li>
<li>Check for duplicate content and flag it for removal.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX12-1: Provide deliverables in reusable, self-isolated components -->
<details>
<summary id="UX12-1">UX12-1: Provide deliverables in reusable, self-isolated components</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#enable-others-to-understand-and-reuse-your-deliverables">2.12 Enable others to understand and reuse your deliverables</a>.</p>
<p><strong>Description</strong></p>
<p>Allow for code that has been produced for an individual project to be re-used and reapplied across future work to reduce redundancy. This is most commonly seen in frameworks and libraries but isn't limited as such and can also apply to documentation and snippets.</p>
<p>This technique is most useful when it is housed within an open source location to foster a culture of contribution, remixing, and improving of the work. While machine testing of code to determine functionality based on its apparent need would prove problematic, the ability to use importable code can be verified.</p>
<p><strong>Examples</strong></p>
<ol>
<li>A library like <a href="https://getbootstrap.com/">Bootstrap</a> can be imported as a whole into a project, but it can also be stripped back, eliminating all but the components that are in use by the website or application powering its functionality.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check to see if deliverables require internal access (if so, permission is given).</li>
<li>Check to determine if these deliverables are housed in an open source environment.</li>
<li>Check projects for multiple CSS files (or use of @imports).</li>
<li>Check JavaScript for the use of imports or self-isolating functions.</li>
<li>Check documentation for section separation as markdown files.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX12-2: Provide documentation to guide the deliverables -->
<details>
<summary id="UX12-2">UX12-2: Provide documentation to guide the deliverables</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#enable-others-to-understand-and-reuse-your-deliverables">2.12 Enable others to understand and reuse your deliverables</a>.</p>
<p><strong>Description</strong></p>
<p>Guarantee that those without a working knowledge of an aspect of design or development will be provided with the information they require so that they can safely work with the files being presented to them during the creation and maintenance process.</p>
<p>Because emissions do not start or stop at website usage, and emissions are created during the ideation and creation process, it is crucial that all involved with the project, even clients who may not be used to the types of technology to which this specification refers to, can optimize their ability to produce high-quality output, as this will reflect in sustainable websites and applications.</p>
<p><strong>Examples</strong></p>
<ol>
<li>Many large projects have manuals or documentation that describe in detail how to work with the creations of a group of people either during the handoff (from one department to another) stage or during the completion (from the creators to the clients) stage.</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check to see if deliverables require internal access (if so, permission is given).</li>
<li>Check that the instructions, manual, or documentation exist.</li>
<li>If the documentation does not exist, flag a request to produce materials.</li>
<li>Check for multiple format types such as HTML, PDF, checklists, slideshow, and video.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX12-3: Create code comments to describe the functionality of features -->
<details>
<summary id="UX12-3">UX12-3: Create code comments to describe the functionality of features</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#enable-others-to-understand-and-reuse-your-deliverables">2.12 Enable others to understand and reuse your deliverables</a>.</p>
<p><strong>Description</strong></p>
<p>Provide internal or external developers with the information they require to understand the justification behind certain coding choices, and what individual pieces of code exist for. While such features can be itemized within the documentation, code comments are useful for providing a portable library of notes with the source code itself.</p>
<p>Every language will have its own descriptive mechanism for producing code comments and developers should prescribe to such best practices. Conventions could be utilized within comments such as including links to provide added context. Comments can be machine-detected by their opening and closing statements and paired with the code that follows them.</p>
<p><strong>Examples</strong></p>
<ol>
<li>In the source code for <a href="https://swhook.com/">Semantic Web Hook</a>, code comments are available for the un-minimized version to help developers identify the purpose behind each function (so they can decide if they require it).</li>
</ol>
<p><strong>Tests</strong></p>
<p>Procedure</p>
<ol>
<li>Check for code comments within the source code of pages.</li>
<li>Check the formatting of comments for conventions such as links, images, and bullets.</li>
<li>If publicly facing, flag it for removal, if internal access is required or a developer release, keep it in place.</li>
</ol>
<p>Expected Results</p>
<ol>
<li>All checks above are true.</li>
</ol>
</div>
</details>
</li>
<li> <!-- UX13-1: Implement an up-to-date design system -->
<details>
<summary id="UX13-1">UX13-1: Implement an up-to-date design system</summary>
<div class="note" title="About this technique">
<p><strong>Applicability</strong></p>
<p>This technique is <strong>Advisory</strong> to meet <em>Success Criteria</em> within <a href="https://w3c.github.io/sustainableweb-wsg/#use-a-design-system-to-prioritize-interface-consistency">2.13 Use a design system to prioritize interface consistency</a>.</p>