(Note: this article was previously published in French a few days before this translation –if you have any feedback on the translation made by Coralie Mercier, please let us know.)

OpenWeb echoed an article published on A List Apart, entitled "Sustainable Web Design", translated into French under the title "Web Design Durable" and published on the Web Développement Durable Website. In essence, it explains that the "heavier" a page is, the biggest its carbon footprint. The notion of heaviness refers of course to the total number of bytes embedded in the page (code, styles, images, media…). But should also be accounted for, the number of HTTP requests to the server (usually a hundred per page), as well as various requests from third-party servers, notably, to retrieve data on social networks or to display advertisements.

Why such a footprint? While conceptually immaterial, the Web relies on a very real and very energy intensive infrastructure: data servers, cache servers, domain name servers, interconnection routers, access providers, wired networks (copper or optical fiber), mobile networks, WiFi, ADSL boxes or modems, terminals and users’ displays… The slightest byte delivered by a Web server engages an entire chain of electrical equipment before it reaches the RAM of the user’s terminal. A 2008 study estimated that for every gigabyte of data transmitted via the "land-line" Web, 7 kilos of carbon dioxide were emitted and that amount soared up to 35 kilos for "mobile" Web data (mobile broadband oblige). And yet, this does not take into account the end-user power needs (terminals, screens, local WiFi, internet box, LAN components…)

Storage power also needs to be accounted for: equipments remain powered even though data isn’t downloaded, considerable power is devoted to cooling servers and infrastructure. According to a document from the CNRS, dated 2011 and entitled "Environnement des serveurs : datacentres (PDF, 1414 kb)" ("Servers environment: data centers"), this is in the range of half the power needed by a typical data center… On top of this is the need to renew and expand the hardware to store and serve data that becomes heavier and thicker.

Here is a telling comparison: today’s Web weighs as much in terms of greenhouse gas emissions as the entire aviation industry, again, regardless of impact on the end user. It will not get better: the aforementioned document anticipates 30 times more data over 10 years, and a thousand times more servers than in 2011. And by 2020, the Web will account for twice the amount of greenhouse gas emissions.

The rationale is: if "only" 40% of the people in the world today have access to the internet, this proportion is growing steadily, driven by developing countries. Debit rates and power increase in the chain. Means to generate and upload video and high resolution photos become more democratic, to the point that almost every one carries in their pocket a formidable megabyte generator, in the form of a mobile phone featuring a camera and internet access.

However, the more you get, the more you want, and this causes a race for power that the economy carefully cultivates: a PC is used 4 years on average, a smartphone is usually replaced every 2 or 3 years depending on battery life. We should reasonably be alarmed by the effects on environment of this headlong rush: the electronics industry consumes large quantities of power, water, scarce or toxic materials, which are relatively less well mastered than in earlier industries such as automotive or construction.

The picture is very dark, but what can we, makers of the Web, do about it? A List Apart estimates our share of responsibility in the carbon footprint to be 40%, be that direct or indirect, and supplies a few hints to reduce the amount of bytes moved by Web pages.
Interestingly, when working on Web accessibility, one finds frequently that some practices result in reducing the size of pages, or the amount of data transferred to the user. Furthermore, an accessible Web site is generally simpler and therefore faster to view, not only for users with disabilities. Let’s explore how.

Sort to better recycle

One of the key principles of Web accessibility is that any content must be accessible in the way that best suits the user, not only in the form desired and imposed by the content author. This leads to separating content and presentation. For the Web, this means supplying presentation solely via styles. Usually, it is advantageous to use CSS style sheets that the HTML code fetches.

Backward worry for 2014? Everyone does it already, you think? You would be surprised how many times an audit points out the use of presentation attributes or tags. Edges of images, size and alignment of layout tables, color or positioning attributes… old habits die hard.

In this case, using CSS is the proper way to go, and reduces the weight of data transferred in two different ways.

First, the HTML pages are mechanically lighter. We factor indeed the presentation attributes in style sheets instead of repeating them in each element.

Secondly, when the user returns to the site, in principle their browser detects that the attached style sheets were previously downloaded and stored in the cache, sparing therefore further transfers.

Historical yet infamous example: the ESPN.com Web site which adopted standards for its home page in 2003. Namely: replacing table layout by semantic code and CSS. Daring at the time… but rewarding: with a saving of 50 KB on the home page only, the gain was 2 TB of bandwidth per day… Or, 14 tons of CO2 according to the A List Apart article.

So, admittedly, one needs not an accessibility audit to do this… But it turns out that it is often an indicator of small defects of that sort which had been conveniently forgotten, or perpetually postponed.

Reduce waste

Another pillar of Web accessibility: your code must be interpreted by the largest possible number of user agents (this is called code robustness). And the only reliable way to do this is to comply with the standard, namely HTML as defined by the W3C.

Beyond mere compliance, one has to use code well: title tags for headings, lists and links… Obvious? Not for everyone, apparently. For the fun of it, have a look at the code of your favourite sites. According to Alexa, for the top 5 most visited editorial Web sites in France (Wikipedia, Yahoo, LeMonde.fr, LeFigaro.fr, and Commentcamarche.net), the validator reports between 40 and 300 errors on the home pages. Also, at least 4 of them show acute symptoms of "divML", i.e. an excessive usage of div tags, compared to what is actually needed to structure a page.
Now this is one of the benefits of Web accessibility: to discover or realise the power of HTML, and the amount the basis syntax only can achieve, without going through stodgy and, most importantly, unnecessary tangles. Again, something one could become aware of earlier… But as always, one needs good reasons to go over code that seems to work well; and improving Web accessibility may be one of them.

Again, benefits are two-fold.

First, better organised code is lighter. To my knowledge, there isn’t any confirmed metric for this, although we frequently hear an estimation of 30%. For my part, I’ve observed that implementing Web accessibility while keeping the original design (extremely rare situation…), resulted in saving between 30 and 50% of the HTML code. This may seem trivial given the small proportion HTML represents in the total weight of data transferred. But hear about the second benefit.

One of the strengths of HTML, compared to other computer languages, is its high tolerance towards code errors. The browser handles (to the extent possible) error corrections and syntax approximations. Such flexibility comes at a price: a poorly coded page is certainly displayed, but the browser takes much longer to interpret it. During which time the terminal, computer, tablet or smartphone runs unnecessarily. We’re talking about a few seconds difference… to be multiplied by the number of times a page is loaded. Bonus: anyone prefers a page that loads immediately over one that makes us wait a few more seconds.

Switch off the lights

It probably hasn’t escaped you that the Web is now populated mostly with multimedia content: images, videos, sounds, animations, documents… it is far from the pure textual medium it used to be! And it is all the better. Nevertheless, this is the primary reason for the growth of page weight referred to by the article.

It is the case that all users are not equal in the eyes of multimedia. Some can not hear, or not well enough; others can not see, or not well enough; some are hampered, or stuck when handling interactive content. The aim of Web accessibility is to allow everyone to access the information associated with these contents. To achieve this, we offer alternative text for images, text transcripts for video and audio files, or HTML and PDF versions embedded in pages.

Furthermore, links to download additional content specify the weight and format of their content, leaving it to the user to download these files, or not.

Of course, this does not remove these contents: they remain present and available to users who can and want to see them. But it is also an opportunity for others to obtain similar information at lower cost. When disabling images, we remain aware of their function through alternative text that the browser displays. Instead of watching a one-hour conference video when looking for a specific part, we can go directly to the transcript, which is drastically lighter and faster to consult. Rather than wrestling to download this very pretty but very memory intensive PDF document, an HTML version will suffice, if the information alone is what we are after. Here too, such measures can be taken for reasons such as content indexing, referencing, machine translation handling… However, accessibility prompts them in a compelling manner; and while it is often seen as a constraint, it is also an opportunity for a wider and more effective distribution of content, and reduced bandwidth requirements. {{{Optimise travel}}} Well-driven Web accessibility often leads to addressing the real needs of users. It is thus seen an opportunity to rethink the information architecture. Of course, again, this is not its primary function. But from my experience, an Accessibility audit or implementation is often an opportunity to reconsider decisions taken in the past, at a time when we might have overlooked that a website is made primarily for the people who consult it. One of the most noticeable benefits from the point of view of users, is that a site made accessible is simpler to read: better structured pages, more explicit links, information easier to find, clearer forms, less data input errors… In the end, the same task takes less time on a site that has been better thought-out and made accessible. The winning is even more spectacular for disabled users, of course. Web accessibility doesn't guarantee your site will be more user-friendly; but as long as you're investing, embrace the opportunity to also address this aspect. Need it be mentioned? All the time saved on the user side is less CPU time, and therefore less carbon dioxide in the atmosphere.
In the same vein, a disabled user is more likely to use the hotline if a site is not accessible. Besides the financial cost thereof, a help-desk requires staffing, often abroad, as well as extensive and long distance telephone calls, which a more accessible site can avoid.

EcoLogo-skeptical?

Yes, there are two acceptable objections to this article. First, the benefits are very marginal. A few kilobytes here, a few HTTP queries there… True. But keep in mind that these benefits are, in some way, gained at no cost, since they come with the implementation of Web accessibility, without any specific additional effort. Therefore it adds up to the good list of "collateral benefits" attributed to Web accessibility.

The second is, there was no need to come to accessibility for it. Effective optimisation techniques achieve the same result, or better. Also true. However, remember that Web accessibility is a fundamental right of the user, and therefore your duty to visitors of your site. If you still can decide willfully to not optimise the weight of your pages, it is not true for accessibility. Legally mandatory for public sector content, Web accessibility –a component of equality, applies to all content producers, public or private. Missing it could expose you to condemnation from your users… or worse: their desertion in favour of your competitors.

What are we waiting for?

Just as well as it can not protect a Web site from commercial failure, dullness, or mediocrity, Web accessibility will not save the planet. But every small earnings, effortlessly obtained, add to each other, and humbly contribute to the global effort. Much rather like those soda cans you throw in the right recycling bin: this is not what will fundamentally change things; but things will not change unless we do at least our share.

So, what are we waiting for?