Green IT, performance, usability & accessibility — a convergence of goals?
“The problems are solved, not by giving new information, but by arranging what we have known since long.”
― Ludwig Wittgenstein, Philosophical Investigations
Introduction
The Sustainable Web Manifesto¹ calls for a „Clean, Efficient, Open, Honest, Regenerative and Resilient” Web:
„From websites to cryptocurrencies, the Internet consumes large amounts of electricity in data centres, telecoms networks, and end user devices. If the Internet was a country, it would be the 4th largest polluter in the world and is expected to grow considerably by 2030.”
— states the Manifesto.
According to scientists from the French Centre national de la recherche scientifique (CNRS), the digital networks and devices consumed between 10 and 15% of the global electric power.²
Changing the existing state of things requires a lot of thought. Thankfully, guidelines to this end exist and can provide the appropriate guidance. The most obvious go-to place would be the Web Sustainability Guidelines (WSG) 1.0³. Other resources are also available, such as the French „Référentiel général d’écoconception de services numériques”⁴ or „General purpose benchmark for designing sustainable digital services”.
Those guidelines pertain, among others, to areas such as architecture, UX/UI, content creation, frontend and backend development and storage. As the Guidelines promise their followers:
„you can minimize your environmental impact through a mixture of user-centered design, performant web development, renewable infrastructure, sustainable business strategy”
…and most interestingly:
„Following these guidelines will often make Web content more accessible, usable, and performant as a by-product.”⁵
In this article, I would like to explore the commonalities of green-IT, accessibility, usability and performance.
Dark mode savings
The display of colors is one area where the convergence of sustainability in energy consumption and accessibility for end-users can be observed. Applications can offer different color themes, in order to cater to user preferences. Text can be displayed as black on a white background or white on a black background. The difference that this makes can be quite significant, both in terms of user comfort and energy savings. As a Purdue University study has shown⁶, OLED type screens (such as the ones used in smartphones) can provide savings as high as 47% in dark-mode. The energy savings can be compounded by the fact that users who prefer dark-mode tend to use their applications in a darker environment, therefore using less energy for lighting overall.
Dark mode can have accessibility benefits as well. It has been shown⁷ that hypersensitivity to light or photophobia might disproportionately affect users in the autistic spectrum. Bright backgrounds might cause irritation, migraines and sensory overload. Evidence seems to show that people in the autism spectrum have a lower neurological threshold for environmental stimuli, including light.
While introducing dark mode themes into applications can certainly have strong benefits, such as energy savings at scale (think about millions of users) and the inclusion of users hypersensitive to light, it must be remembered that it is no way a silver bullet and will not always provide the expected benefits. The energy savings will only affect OLED screens, where the dark pixels do not consume any energy. This is not the case of LCD monitors and displays, which are always back-lit by a panel regardless of the colors displayed. Furthermore, users with myopia and astigmatism could actually suffer from using the dark mode, as text and other details would be less clear for them because of the increased diffusion of light as a result of the dilation of eye pupils in dark environments⁸.
ADHD and user distraction
Users with attention deficit disorder experience various challenges that can be compounded by badly designed interfaces⁹. As it happens, the same bad practices can lead to unnecessary energy consumption.
Automatically playing videos and superfluous animations have the compound negative effects of consuming energy by needlessly transferring video streams over the network and using processing power on the local device to decompress data and display animations, as well as — at the same time — distracting users from the tasks they were supposed to perform. Some poorly implemented animations could cause performance problems and excessive CPU usage¹⁰. This clearly does not mean that no animations or videos can be used, but certain considerations have to be taken into account.
Web Content Accessibility Guidelines (WCAG)¹¹ provide various criteria, which need to be adhered to by accessible applications. These include Success Criterion 2.2.2: Pause, Stop, Hide:
„For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential.”¹²
Furthermore, user preferences should be taken into account, by using the prefers-reduced-motion media queries to define animations¹³:
@media (prefers-reduced-motion) {
/* styles to apply if a user's device settings are set to reduced motion */
}These are not optional requirements, as excessive movement on the screen can create hazardous conditions for users suffering from vestibular disorders.¹⁴
There are many ways in which web applications can be improved, as described in this article: How to Make Your Website More Accessible for People with ADHD. Some subtle changes in animations can be introduced, which allow to preserve the essential usability function of animations, while retaining accessibility. This is delightfully demonstrated in this article: Creating Accessible UI Animations.
Distracting content, such as ads, can be costly in terms of energy usage. Blocking it can offer huge savings. As a study found, „ad-blocking offers significant battery savings (around 30%)”¹⁵.
Clear content organization can prevent excessive scrolling, data download and browser screen re-rendering (all of which consume energy), as users find the information they need faster, without being distracted by tangentially related topics.
Cognitive load and round trips to the server
Filling forms is probably everyone’s least favorite activity on the web. It is also one of the most demanding tasks and the most forbidding for users with cognitive disabilities. Badly designed forms can cause input errors and incorrect submissions, which often lead to unnecessary round-trips to the server and wasted bandwidth and processing time, both on the user’s computer and the data-center infrastructure.
Many improvements can be made:
- decreasing the information overload by dividing the form in navigable steps,
- retaining information already entered,
- providing clear hints on data formats,
- shifting attention to validation error messages,
- providing summaries of already entered data (so that users don’t have to rely on their short-term memory)
- preventing form submission with incorrect data.
Some of the best practices are described here:
- Best Practices to Reduce Cognitive Effort on Checkout Forms
- Alert Users to Errors that Prevent Form Validation
Device performance and sustainability
It is estimated that it takes roughly 1 gigajoule of energy to create a new smartphone and 4.5 gigajoule to create a new laptop.¹⁶ This includes mining, material extraction and refining and the manufacturing process. The average lifetime of a laptop is 3 years. The average lifespan of smartphones is currently 2.5 years. However, other sources claim that it could be closer to 15–18 months for newer generation devices.¹⁷ This pace of device replacement puts unsustainable strain on our planet’s resources. It doesn’t need to be so, as those devices could easily have more years of use ahead of them with appropriate support. Application design and development must therefore take into account the ability to use older devices, using older versions of operating systems and software, lower resolutions and device performance characteristics.
The right balance needs to be struck between web standards adoption (which allows for more efficient code development) and device compatibility, as many new features might not be supported on older hardware. Not an easy task. Device operating system and browser fragmentation only makes it harder to strike that balance:
As an article by BrowserStack stated in 2019:
„For 70–80% global coverage, your website/app needs to work across:
- 3 device types — mobile, desktop, and tablet
- 2 iOS versions
- 5 stock Android versions
- 8–10 custom implementations of stock Android versions
- 6 browser families
- Popular browser versions within each browser family
- 10 screen resolutions”¹⁸
This is not a new challenge. Responsive Web Design, as defined in 2011 by Ethan Marcotte in his seminal book of the same title¹⁹, has long been used by frontend developers to provide for the needs of users of mobile devices and the variety of various screen sizes that they offer. An additional benefit of responsive design is that it automatically caters to users with low vision. Those users need to zoom in text on web applications, in order to be able to see it. Being able to resize text up to 200% is a key requirement of WCAG Success Criterion 1.4.4.²⁰ In fact, zooming-in on a high resolution screen is the exact same thing as using a low-resolution screen on a small device. This is where accessibility meets support for older devices — thereby extending device lifespan and making it a little less painful on the planet, its people and its resources. A win-win.
One size does not fit all: offline first
It might seem counter-intuitive to claim that a website should be designed to be offline first. However, it would be wrong to assume that every user and every place is permanently connected. For some users in remote areas, even in developed countries, this is still not a reality.
„When it comes to building apps, we often assume our users are very much like us. We picture them with the latest devices, the most recent software, and the fastest connections.” — writes Alex Feyerke²¹. This assumption is very often untrue and excludes many users because of their location or the providers and devices they are able to afford. A truly inclusive design must take that into consideration.
Fast connections and modern devices all consume energy to produce and operate. If our applications are not usable without them, we are creating a world in which we are driving demand for even more energy consumption. Some design principles outlined by the Offline First organization aim at providing better user experience when the network is down or unavailable or it would be too expensive to use it. Basically, lack of connectivity should not be considered as an error, but as a legitimate state of the application. It should still be usable. Think of e-mail programs that already allow users to compose e-mails offline and send them later, when the network becomes available. This is discussed at length in this article: Designing Offline-First Web Apps.
Even if the network is available, it is not always a high-bandwidth connection. This is extremely important when the size of downloaded images is considered. One thing to keep in mind is that it is incredibly wasteful to download large images meant for large screens on mobile devices, only to display their scaled-down versions (using even more processing power during the scaling process in the browser). This can be avoided using appropriate coding techniques, which are discussed in this article: A Guide to the Responsive Images Syntax in HTML.
A CSS media query, called prefers-reduced-data could be used in the future to enable users to reduce their network usage²². It is not currently supported by any browser. Ironically, when the support is finally there, it will require new browser versions and new devices, all of which will take more energy to produce and operate.
The good ol’ Web
The Web was built as an infrastructure to deliver HTML documents made of native HTML elements, identified by URLs, styled with CSS files and connected with links. All of the underlying technical infrastructure has been optimized with this architecture in mind. Built-in accessibility features were meant to work with it.
However, many of those assumptions have been put into question in an effort to provide more customized and modern user experiences. In so doing, many web applications have lost sight of accessibility concerns and energy efficiency. Single-Page-Applications, which run entirely in the browser memory, cannot leverage the caching of server rendered pages on the network infrastructure and rely solely on the processing power of the user’s machines to render their content. Instead of using cached CSS files, CSS-in-JS is used, which provides convenient solutions during development, but consumes a lot more energy in the rendering phase²³. Javascript components not only consume more browser processing power than native HTML elements, but often forgo the accessibility features that the native elements provide out-of-the-box.
Conclusion
Robust web application design, which takes into account end-to-end energy consumption on the servers, networks and consumer devices, one which is based on web standards and respectful of the users’ preferences and limitations, can deliver accessible experiences and put less strain on our planet’s resources.
[1] https://www.sustainablewebmanifesto.com/
[2] https://www.pourlascience.fr/sd/environnement/le-vrai-cout-energetique-du-numerique-20490.php
[3] Web Sustainability Guidelines, https://w3c.github.io/sustyweb/
[4] Référentiel général d’écoconception de services numériques https://ecoresponsable.numerique.gouv.fr/publications/referentiel-general-ecoconception/
[5] Web Sustainability Guidelines, Abstract, op. cit.
[6] How much battery does dark mode save? https://dl.acm.org/doi/pdf/10.1145/3458864.3467682
[7] https://www.theraspecs.com/blog/light-sensitivity-autism/
[10] https://css-tricks.com/browser-painting-and-considerations-for-web-performance/
[11] https://www.w3.org/WAI/standards-guidelines/wcag/
[12] https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide.html
[13] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion
[14] https://alistapart.com/article/designing-safer-web-animation-for-motion-sensitivity/
[15] On the Battery Consumption of Mobile Browsers https://arxiv.org/pdf/2009.03740.pdf
[16] The Energy and Emergy of the Internet https://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final56.pdf
[17] https://everphone.com/en/blog/smartphone-lifespan/
[18] https://www.browserstack.com/blog/understanding-browser-os-and-device-fragmentation/
[19] Responsive Web Design by Ethan Marcotte, A Book Apart, New York, 2011
[20] https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html
[21] https://alistapart.com/article/offline-first/
[22] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data
[23] Why We’re Breaking Up with CSS-in-JS https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-4g9b
