From 9b2f255b632d16528613ec81fdc26828e0698f0b Mon Sep 17 00:00:00 2001 From: LaurentDev Date: Fri, 29 Nov 2024 21:24:17 +0100 Subject: [PATCH 1/6] Added the Web Ecodesign Reference Framework (#3931) * Added the Web Ecodesign Reference Framework * Update sustainability.md * Update src/content/en/2024/sustainability.md --------- Co-authored-by: Barry Pollard --- src/content/en/2024/sustainability.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/content/en/2024/sustainability.md b/src/content/en/2024/sustainability.md index 667d597b9be..5bac8ff0522 100644 --- a/src/content/en/2024/sustainability.md +++ b/src/content/en/2024/sustainability.md @@ -123,6 +123,7 @@ For further information on specific regulations and standards, refer to: - WSG: Draft Sustainable Tooling And Reporting (STAR) 1.0 - GRI: Global Reporting Initiative - GR491, The Handbook of sustainable design of digital services | ISIT +- WERF: Web Ecodesign Reference Framework - Apolitical: Keeping tech sustainable ## Evaluating the environmental impact of websites From 498ca2cb3f465f7a6b5584e6b070e9f09c7820be Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Sat, 30 Nov 2024 09:02:00 +0000 Subject: [PATCH 2/6] Add Cookies title to featured chapter (#3935) * Add Cookies title to featured chapter * Remove dupe --- src/templates/en/base.html | 1 + src/templates/es/base.html | 1 + src/templates/fr/base.html | 1 + src/templates/hi/base.html | 1 + src/templates/it/base.html | 1 + src/templates/ja/base.html | 1 + src/templates/nl/base.html | 1 + src/templates/pt/base.html | 1 + src/templates/ru/base.html | 1 + src/templates/tr/base.html | 1 + src/templates/uk/base.html | 1 + src/templates/zh-CN/base.html | 1 + src/templates/zh-TW/base.html | 1 + 13 files changed, 13 insertions(+) diff --git a/src/templates/en/base.html b/src/templates/en/base.html index 5df049256c8..05f7f09a698 100644 --- a/src/templates/en/base.html +++ b/src/templates/en/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Markup", "media": "Media", "third-parties": "Third Parties", diff --git a/src/templates/es/base.html b/src/templates/es/base.html index 9974d4489dc..1b4e3fd20cf 100644 --- a/src/templates/es/base.html +++ b/src/templates/es/base.html @@ -176,6 +176,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Marcado Web", "media": "Media", "third-parties": "Contenido de Terceros", diff --git a/src/templates/fr/base.html b/src/templates/fr/base.html index d8c2109b47d..eac1f879021 100644 --- a/src/templates/fr/base.html +++ b/src/templates/fr/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Balisage Web", "media": "Média", "third-parties": "Tierces Parties", diff --git a/src/templates/hi/base.html b/src/templates/hi/base.html index b45b4ad44a4..be0b8f034f5 100644 --- a/src/templates/hi/base.html +++ b/src/templates/hi/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "मार्कअप", "media": "मीडिया", "third-parties": "तीसरे पक्ष", diff --git a/src/templates/it/base.html b/src/templates/it/base.html index 283d3266ce2..b77322e4a70 100644 --- a/src/templates/it/base.html +++ b/src/templates/it/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Markup", "media": "Media", "third-parties": "Terze parti", diff --git a/src/templates/ja/base.html b/src/templates/ja/base.html index 5f7cfe35bd0..00557045eb6 100644 --- a/src/templates/ja/base.html +++ b/src/templates/ja/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "マークアップ", "media": "メディア", "third-parties": "サードパーティ", diff --git a/src/templates/nl/base.html b/src/templates/nl/base.html index f9a011efebe..a3b880f84b7 100644 --- a/src/templates/nl/base.html +++ b/src/templates/nl/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Opmaak", "media": "Media", "third-parties": "Derden", diff --git a/src/templates/pt/base.html b/src/templates/pt/base.html index 30c29331258..4e3684ee42b 100644 --- a/src/templates/pt/base.html +++ b/src/templates/pt/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Marcação", "media": "Mídia", "third-parties": "Terceiros", diff --git a/src/templates/ru/base.html b/src/templates/ru/base.html index 2a1117fe120..7dfe98e0ea0 100644 --- a/src/templates/ru/base.html +++ b/src/templates/ru/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Разметка", "media": "Медиа", "third-parties": "Сторонний код", diff --git a/src/templates/tr/base.html b/src/templates/tr/base.html index c20e8564b1f..5d27d1f331a 100644 --- a/src/templates/tr/base.html +++ b/src/templates/tr/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Markup", "media": "Media", "third-parties": "Üçüncü Partiler", diff --git a/src/templates/uk/base.html b/src/templates/uk/base.html index 53a97653c06..aaa73a9cf76 100644 --- a/src/templates/uk/base.html +++ b/src/templates/uk/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "Розмітка", "media": "Медіа", "third-parties": "Сторонні ресурси", diff --git a/src/templates/zh-CN/base.html b/src/templates/zh-CN/base.html index 61cc674d1b3..50faa0113fb 100644 --- a/src/templates/zh-CN/base.html +++ b/src/templates/zh-CN/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "标记", "media": "媒体", "third-parties": "第三方", diff --git a/src/templates/zh-TW/base.html b/src/templates/zh-TW/base.html index 30bee941abc..788c48326a2 100644 --- a/src/templates/zh-TW/base.html +++ b/src/templates/zh-TW/base.html @@ -177,6 +177,7 @@ set localizedChapterTitles = { "javascript": "JavaScript", "css": "CSS", + "cookies": "Cookies", "markup": "標記", "media": "媒體", "third-parties": "第三方", From 4261e304deb9aad0dc582e3d87b46cc3e2e9f777 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Sat, 30 Nov 2024 09:16:23 +0000 Subject: [PATCH 3/6] Update Timestamps (#3936) Co-authored-by: tunetheweb <10931297+tunetheweb@users.noreply.github.com> --- src/config/last_updated.json | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/config/last_updated.json b/src/config/last_updated.json index 4c770387d1a..784e40fd354 100644 --- a/src/config/last_updated.json +++ b/src/config/last_updated.json @@ -753,8 +753,8 @@ }, "en/2024/chapters/accessibility.html": { "date_published": "2024-11-11T00:00:00.000Z", - "date_modified": "2024-11-22T00:00:00.000Z", - "hash": "db405edaff762e930358c9471d3fd358" + "date_modified": "2024-11-30T00:00:00.000Z", + "hash": "d437f8d0a37f119170da4d0eb0b1bfe9" }, "en/2024/chapters/cdn.html": { "date_published": "2024-11-11T00:00:00.000Z", @@ -848,13 +848,13 @@ }, "en/2024/chapters/sustainability.html": { "date_published": "2024-11-11T00:00:00.000Z", - "date_modified": "2024-11-18T00:00:00.000Z", - "hash": "bb49d876d3e33811819746edc96ed447" + "date_modified": "2024-11-30T00:00:00.000Z", + "hash": "48be7a85f0dfefe06c709a2ff9f5449b" }, "en/2024/chapters/third-parties.html": { "date_published": "2024-11-21T00:00:00.000Z", - "date_modified": "2024-11-21T00:00:00.000Z", - "hash": "075bec99b73be68c6fa7b97b97808182" + "date_modified": "2024-11-30T00:00:00.000Z", + "hash": "f5e703ed3f81f6969d2000e33d06a7fd" }, "en/2024/chapters/webassembly.html": { "date_published": "2024-11-11T00:00:00.000Z", From 08495ae0193179732dab4baaefad6e78c73fc580 Mon Sep 17 00:00:00 2001 From: Nurullah Demir <13475745+nrllh@users.noreply.github.com> Date: Sat, 30 Nov 2024 18:39:26 +0100 Subject: [PATCH 4/6] fix featured text (#3938) --- src/content/en/2024/markup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/en/2024/markup.md b/src/content/en/2024/markup.md index 9d5c007782a..5c82aa87c9e 100644 --- a/src/content/en/2024/markup.md +++ b/src/content/en/2024/markup.md @@ -13,7 +13,7 @@ results: https://docs.google.com/spreadsheets/d/1TtOMr_w58HvqNBv4RIWX021Lxm6m5aj featured_quote: Every website, every web application, and every online interaction starts with HTML at its core, making it one of the most essential web standards. featured_stat_1: 92.8% featured_stat_label_1: Documents using the HTML doctype -featured_stat_2: 32 MB +featured_stat_2: 32 KB featured_stat_label_2: Median HTML document transfer size featured_stat_3: 29% featured_stat_label_3: Elements that are `div`s From 605d8e9179a9820a0739d30f43bc5a8961c8d110 Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Mon, 2 Dec 2024 10:59:11 +0000 Subject: [PATCH 5/6] Homepage -> home page (#3941) --- src/content/en/2019/markup.md | 4 +-- src/content/en/2019/security.md | 8 +++--- src/content/en/2020/accessibility.md | 2 +- src/content/en/2020/capabilities.md | 2 +- src/content/en/2020/css.md | 2 +- src/content/en/2020/ecommerce.md | 8 +++--- src/content/en/2020/markup.md | 2 +- src/content/en/2020/mobile-web.md | 4 +-- src/content/en/2020/security.md | 24 +++++++++--------- src/content/en/2021/accessibility.md | 6 ++--- src/content/en/2021/ecommerce.md | 20 +++++++-------- src/content/en/2021/http.md | 2 +- src/content/en/2021/markup.md | 2 +- src/content/en/2021/mobile-web.md | 2 +- src/content/en/2021/security.md | 4 +-- src/content/en/2021/seo.md | 34 +++++++++++++------------- src/content/en/2021/structured-data.md | 10 ++++---- src/content/en/2021/webassembly.md | 2 +- src/content/en/2022/accessibility.md | 6 ++--- src/content/en/2022/markup.md | 2 +- src/content/en/2022/privacy.md | 2 +- src/content/en/2022/security.md | 6 ++--- src/content/en/2022/seo.md | 12 ++++----- src/content/en/2022/structured-data.md | 2 +- src/content/en/2022/sustainability.md | 2 +- src/content/en/2024/accessibility.md | 6 ++--- src/content/en/2024/fonts.md | 2 +- src/content/en/2024/markup.md | 4 +-- src/content/en/2024/performance.md | 4 +-- src/content/en/2024/security.md | 2 +- src/content/en/2024/sustainability.md | 2 +- src/content/it/2022/structured-data.md | 6 ++--- 32 files changed, 98 insertions(+), 98 deletions(-) diff --git a/src/content/en/2019/markup.md b/src/content/en/2019/markup.md index 4372a70dbf3..3d38dca120f 100644 --- a/src/content/en/2019/markup.md +++ b/src/content/en/2019/markup.md @@ -36,7 +36,7 @@ Names of elements on each page were collected from the DOM itself, after the ini Looking at a raw frequency count isn't especially helpful, even for standard elements: About 25% of all elements encountered are `
`. About 17% are ``, about 11% are `` -- and those are the only elements that account for more than 10% of occurrences. Languages are generally like this; a small number of terms are astoundingly used by comparison. Further, when we start looking at non-standard elements for uptake, this would be very misleading as one site could use a certain element a thousand times and thus make it look artificially very popular. -Instead, as in Hixie's original study, what we will look at is how many sites include each element at least once in their homepage. +Instead, as in Hixie's original study, what we will look at is how many sites include each element at least once in their home page.

Note: This is, itself, not without some potential biases. Popular products can be used by several sites, which introduce non-standard markup, even "invisibly" to individual authors. Thus, care must be taken to acknowledge that usage doesn't necessarily imply direct author knowledge and conscious adoption as much as it does the servicing of a common need, in a common way. During our research, we found several examples of this, some we will call out.

@@ -249,7 +249,7 @@ So, are all of those elements used by less than 1% of pages "useless"? Definite Many elements, even the native ones, appear on fewer than 1% of pages and are still very important and successful. ``, for example, is an element that I both use and encounter a lot. It's definitely useful and important, and yet it is used on only 0.57% of these pages. Part of this is skewed based on what we are measuring; home pages are generally *less likely* to include certain kinds of things (like `` for example). Home pages serve a less general purpose than, for example, headings, paragraphs, links and lists. However, the data is generally useful. -We also collected information about which pages contained an author-defined (not native) `.shadowRoot`. About 0.22% of desktop pages and 0.15% of mobile pages had a shadow root. This might not sound like a lot, but it is roughly 6.5k sites in the mobile dataset and 10k sites on the desktop and is more than several HTML elements. `` for example, has about equivalent use on the desktop and it is the 146th most popular element. `` appears on 0.04% of homepages and it's the 201st most popular element. +We also collected information about which pages contained an author-defined (not native) `.shadowRoot`. About 0.22% of desktop pages and 0.15% of mobile pages had a shadow root. This might not sound like a lot, but it is roughly 6.5k sites in the mobile dataset and 10k sites on the desktop and is more than several HTML elements. `` for example, has about equivalent use on the desktop and it is the 146th most popular element. `` appears on 0.04% of home pages and it's the 201st most popular element. In fact, over 15% of elements we're counting as defined by HTML are outside the top 200 in the desktop dataset . `` is the least popular "HTML5 era" element, which we can define as 2004-2011, before HTML moved to a Living Standard model. It is around the 1,000th most popular element. ``, the most recently introduced element (April 2016), is only around the 1,400th most popular element. diff --git a/src/content/en/2019/security.md b/src/content/en/2019/security.md index f0c58e57e5f..3253c0ce900 100644 --- a/src/content/en/2019/security.md +++ b/src/content/en/2019/security.md @@ -669,16 +669,16 @@ NEL provides incredibly valuable information and you can read more about the typ ### Clear Site Data With the increasing ability to store data locally on a user's device, via cookies, caches and local storage to name but a few, site operators needed a reliable way to manage this data. The Clear Site Data header provides a means to ensure that all data of a particular type is removed from the device, though it is not yet supported in all browsers. -Given the nature of the header, it is unsurprising to see almost no usage reported - just 9 desktop requests and 7 mobile requests. With our data only looking at the homepage of a site, we're unlikely to see the most common use of the header which would be on a logout endpoint. Upon logging out of a site, the site operator would return the Clear Site Data header and the browser would remove all data of the indicated types. This is unlikely to take place on the homepage of a site. +Given the nature of the header, it is unsurprising to see almost no usage reported - just 9 desktop requests and 7 mobile requests. With our data only looking at the home page of a site, we're unlikely to see the most common use of the header which would be on a logout endpoint. Upon logging out of a site, the site operator would return the Clear Site Data header and the browser would remove all data of the indicated types. This is unlikely to take place on the home page of a site. ## Cookies Cookies have many security protections available and whilst some of those are long standing, and have been available for years, some of them are really quite new have been introduced only in the last couple of years. ### `Secure` -The `Secure` flag on a cookie instructs a browser to only send the cookie over a secure (HTTPS) connection and we find only a small % of sites (4.22% on desktop and 3.68% on mobile) issuing a cookie with the Secure flag set on their homepage. This is depressing considering the relative ease with which this feature can be used. Again, the high usage of analytics and advertisement [third-party](./third-parties) requests, which wish to collect data over both HTTP and HTTPS is likely skewing these numbers and it would be interesting research to see the usage on other cookies, like authentication cookies. +The `Secure` flag on a cookie instructs a browser to only send the cookie over a secure (HTTPS) connection and we find only a small % of sites (4.22% on desktop and 3.68% on mobile) issuing a cookie with the Secure flag set on their home page. This is depressing considering the relative ease with which this feature can be used. Again, the high usage of analytics and advertisement [third-party](./third-parties) requests, which wish to collect data over both HTTP and HTTPS is likely skewing these numbers and it would be interesting research to see the usage on other cookies, like authentication cookies. ### `HttpOnly` -The `HttpOnly` flag on a cookie instructs the browser to prevent JavaScript on the page from accessing the cookie. Many cookies are only used by the server so are not needed by the JavaScript on the page, so restricting access to a cookie is a great protection against XSS attacks from stealing the cookie. We find that a much larger % of sites issuing a cookie with this flag on their homepage at 24.24% on desktop and 22.23% on mobile. +The `HttpOnly` flag on a cookie instructs the browser to prevent JavaScript on the page from accessing the cookie. Many cookies are only used by the server so are not needed by the JavaScript on the page, so restricting access to a cookie is a great protection against XSS attacks from stealing the cookie. We find that a much larger % of sites issuing a cookie with this flag on their home page at 24.24% on desktop and 22.23% on mobile. ### `SameSite` As a much more recent addition to cookie protections, the `SameSite` flag is a powerful protection against [Cross-Site Request Forgery (CSRF)](https://en.wikipedia.org/wiki/Cross-site_request_forgery) attacks (often also known as XSRF). @@ -787,7 +787,7 @@ As the web grows in capabilities and allows access to more and more sensitive da In the recent years, the web has made the most progress on the encryption of data in transit. As described in the [TLS section](#transport-layer-security) section, thanks to a range of efforts from browser vendors, developers and Certificate Authorities such as Let's Encrypt, the fraction of the web using HTTPS has steadily grown. At the time of writing, the majority of sites are available over HTTPS, ensuring confidentiality and integrity of traffic. Importantly, over 99% of websites which enable HTTPS use newer, more secure versions of the TLS protocol (TLSv1.2 and TLSv1.3). The use of strong [cipher suites](#cipher-suites) such as AES in GCM mode is also high, accounting for over 95% of requests on all platforms. -At the same time, gaps in TLS configurations are still fairly common. Over 15% of pages suffer from [mixed content](#mixed-content) issues, resulting in browser warnings, and 4% of sites contain active mixed content, blocked by modern browsers for security reasons. Similarly, the benefits of [HTTP Strict Transport Security](#http-strict-transport-security) only extend to a small subset of major sites, and the majority of websites don't enable the most secure HSTS configurations and are not eligible for [HSTS preloading](#hsts-preloading). Despite progress in HTTPS adoption, a large number of cookies is still set without the `Secure` flag; only 4% of homepages that set cookies prevent them from being sent over unencrypted HTTP. +At the same time, gaps in TLS configurations are still fairly common. Over 15% of pages suffer from [mixed content](#mixed-content) issues, resulting in browser warnings, and 4% of sites contain active mixed content, blocked by modern browsers for security reasons. Similarly, the benefits of [HTTP Strict Transport Security](#http-strict-transport-security) only extend to a small subset of major sites, and the majority of websites don't enable the most secure HSTS configurations and are not eligible for [HSTS preloading](#hsts-preloading). Despite progress in HTTPS adoption, a large number of cookies is still set without the `Secure` flag; only 4% of home pages that set cookies prevent them from being sent over unencrypted HTTP. ### Defending against common web vulnerabilities diff --git a/src/content/en/2020/accessibility.md b/src/content/en/2020/accessibility.md index 82a7aa80bc4..6a7d5ca228b 100644 --- a/src/content/en/2020/accessibility.md +++ b/src/content/en/2020/accessibility.md @@ -379,7 +379,7 @@ HTML5 introduced many new native elements, all which have `s and ``s have been given this role, there is a significant chance one or more of the 5 rules of ARIA have been broken. diff --git a/src/content/en/2020/capabilities.md b/src/content/en/2020/capabilities.md index 44f7653fdd7..feccc3003cd 100644 --- a/src/content/en/2020/capabilities.md +++ b/src/content/en/2020/capabilities.md @@ -248,7 +248,7 @@ Over the course of 2020, the `getInstalledRelatedApps()` API shows a steady grow Web apps can store content offline using various ways, such as Cache Storage, or IndexedDB. However, for users it's hard to discover which content is available offline. The Content Indexing API (WICG Editor's Draft) allows developers to expose content more prominently. Currently, Chrome on Android is the only browser to support this API. This browser shows a list of "Articles for you" in the Downloads menu. Content indexed via the Content Indexing API will appear there. -The Content Indexing API extends the Service Worker API by providing a new `ContentIndex` interface. This interface is available via the `index` property of the Service Worker's registration. The `add()` method allows developers to add content to the index: Each piece of content must have an ID, a URL, a launch URL, title, description, and a set of icons. Optionally, the content can be grouped into different categories such as articles, homepages, or videos. The `delete()` method allows for removing content from the index again, and the `getAll()` method returns a list of all indexed entries. +The Content Indexing API extends the Service Worker API by providing a new `ContentIndex` interface. This interface is available via the `index` property of the Service Worker's registration. The `add()` method allows developers to add content to the index: Each piece of content must have an ID, a URL, a launch URL, title, description, and a set of icons. Optionally, the content can be grouped into different categories such as articles, home pages, or videos. The `delete()` method allows for removing content from the index again, and the `getAll()` method returns a list of all indexed entries. {{ figure_markup( image="content_indexing_api.png", diff --git a/src/content/en/2020/css.md b/src/content/en/2020/css.md index a89fe3b9cac..b30a5e7a138 100644 --- a/src/content/en/2020/css.md +++ b/src/content/en/2020/css.md @@ -1025,7 +1025,7 @@ If we look at [Grid layout](https://developer.mozilla.org/docs/Web/CSS/CSS_Grid_ sql_file="flexbox_grid.sql" ) }} -Note that unlike most other metrics in this chapter this is actual measured Grid usage, and not just grid-related properties and values that are specified in a stylesheet and potentially not used. While at first glance this may seem more accurate, one thing to keep in mind is that HTTP Archive crawls homepages, so this data may be skewed lower due to grids often appearing more in internal pages. +Note that unlike most other metrics in this chapter this is actual measured Grid usage, and not just grid-related properties and values that are specified in a stylesheet and potentially not used. While at first glance this may seem more accurate, one thing to keep in mind is that HTTP Archive crawls home pages, so this data may be skewed lower due to grids often appearing more in internal pages. So, let's look at another metric as well: how many pages specify `display: grid` and `display: flex` in their stylesheets? That metric puts Grid layout at significantly higher adoption, with 30% of pages using `display: grid` at least once. It does not however affect the number for Flexbox as significantly, with 68% of pages specifying `display: flex`. While this sounds like impressively high adoption for Flexbox, it is worth noting that CSS tables are still far more popular with 80% of pages using table display modes! Some of this usage may be due to certain types of clearfix which use `display: table`, and not for actual layout. diff --git a/src/content/en/2020/ecommerce.md b/src/content/en/2020/ecommerce.md index 4ee86aa1486..6da37b499f1 100644 --- a/src/content/en/2020/ecommerce.md +++ b/src/content/en/2020/ecommerce.md @@ -47,7 +47,7 @@ This change in methodology provides enhanced coverage for enterprise platforms a Our methodology has the following limitations: - Headless ecommerce platforms like commercetools may not get detected as ecommerce platform but if we are able to detect presence of cart on such sites, we will still include sites using such platforms in our overall coverage stats. -- Technologies which are typically deployed outside homepages (e.g. WebAR on product detail pages) are not detected. +- Technologies which are typically deployed outside home pages (e.g. WebAR on product detail pages) are not detected. - Due to our crawl originating from US, there may be some bias towards US specific platforms. For example, if a global business has ecommerce sites built on different platforms for different countries (using country specific domains/sub-domains), it may not show these regional differences in our analysis. - It's common for B2B sites to hide the cart functionality behind a login and due to that this study is not a correct representation of B2B market. @@ -243,7 +243,7 @@ The figures above show that the median ecommerce page has 34 images and an image

Note that some image services or CDNs will automatically deliver WebP (rather than JPEG or PNG) to platforms that support WebP, even for a URL with a .jpg or .png suffix. For example, IMG_20190113_113201.jpg returns a WebP image in Chrome. However, the way HTTP Archive detects image formats is to check for keywords in the MIME type first, then fall back to the file extension. This means that the format for images with URLs such as the above will be given as WebP, since WebP is supported by HTTP Archive as a user agent.

-PNG usage remained roughly at the [same level as 2019](../2019/ecommerce#png) (at 27% for both desktop and mobile). We observed drop in JPEG usage (4% for desktop and 6% for mobile). Out of this drop, most of it went towards increased GIF usage. GIFs are quite common on ecommerce homepages whereas GIFs may not be much used on product detail pages. Since our methodology only looks at homepages, this explains the significantly high usage of GIFs across ecommerce sites. Lighthouse has an audit which recommends using "video formats for animated content". This is a technique ecommerce sites can use to optimize for performance but still retain animation properties of GIFs. See this article for more details. +PNG usage remained roughly at the [same level as 2019](../2019/ecommerce#png) (at 27% for both desktop and mobile). We observed drop in JPEG usage (4% for desktop and 6% for mobile). Out of this drop, most of it went towards increased GIF usage. GIFs are quite common on ecommerce home pages whereas GIFs may not be much used on product detail pages. Since our methodology only looks at home pages, this explains the significantly high usage of GIFs across ecommerce sites. Lighthouse has an audit which recommends using "video formats for animated content". This is a technique ecommerce sites can use to optimize for performance but still retain animation properties of GIFs. See this article for more details. WebP usage across ecommerce sites still remains very low though usage doubled and went from a total of 1% usage in 2019 to 2% usage in 2020. WebP format is now nearly 10 years old and even after allowing for progressive enhancement using the `picture` element, usage has remained low. In 2020, WebP got a new lease of life when Safari introduced support in Safari 14. However, the Web Almanac for this year is based on August 2020 and Safari support came in September 2020 so any stats presented here don't reflect the impact of support added by Safari. @@ -500,7 +500,7 @@ It will also be interesting to look at adoption of native apps by ecommerce site This year's [SEO](./seo) chapter includes analysis of websites using `hreflang` and `lang` attributes, and `content-language` HTTP header. This combined with Wappalyzer detection of cross-border commerce solutions like Global-e, Flow, Borderfree can provide opportunity to just look at Cross border commerce aspects of the ecommerce websites. Currently Wappalyzer doesn't have a separate category for 'Cross-border commerce' and hence this type of analysis is not possible unless we build a repository of such solutions ourselves. -Wappalyzer also provides detection of payment solutions (Apple Pay / PayPal / ShopPay etc.) but based on the types of implementation and solution, it's not always possible to detect this just by looking at homepage but for solutions where detection can be done by just looking at homepage, such an analysis can be useful to look at year of year trends. +Wappalyzer also provides detection of payment solutions (Apple Pay / PayPal / ShopPay etc.) but based on the types of implementation and solution, it's not always possible to detect this just by looking at home page but for solutions where detection can be done by just looking at home page, such an analysis can be useful to look at year of year trends. ## Conclusion @@ -508,4 +508,4 @@ Covid-19 massively accelerated the growth of ecommerce in 2020 and lot of smalle Improving core web vitals score will be a priority for ecommerce businesses due to changes announced by Google and marketing teams using Web Push Notifications should keep an eye on their notifications stats using CRUX to not get caught by upcoming abusing notifications changes. Tag Managers still seem to cause a lot of friction between marketing and engineering teams and solutions like Google Tag Manager server side tagging will make some inroads but we don't expect a lot to change in 2021 and this will be more like 3-5 years journey but community need to ask their respective third parties to provide compatible solutions to further evolve this ecosystem. -While remembering the limitation that we are looking only homepage data for this analysis, we would like to hear from community what else we should cover in next year's analysis. We have covered some possibilities of further analysis in section above and any feedback is greatly appreciated. +While remembering the limitation that we are looking only home page data for this analysis, we would like to hear from community what else we should cover in next year's analysis. We have covered some possibilities of further analysis in section above and any feedback is greatly appreciated. diff --git a/src/content/en/2020/markup.md b/src/content/en/2020/markup.md index f5e64abb388..91aaa76d07a 100644 --- a/src/content/en/2020/markup.md +++ b/src/content/en/2020/markup.md @@ -610,7 +610,7 @@ In our mobile dataset of 6.3 million pages, around 0.9 million pages (14.01%) co
{{ figure_link(caption="Obsolete elements with more than 10,000 uses.", sheets_gid="1972617631", sql_file="pages_element_count_by_device_and_obsolete_elements.sql") }}
-Even `spacer` is still being used 1,584 times, and present on every 5,000th page. We know that Google has been using a `center` element on their homepage for 22 years now, but why are there so many imitators? +Even `spacer` is still being used 1,584 times, and present on every 5,000th page. We know that Google has been using a `center` element on their home page for 22 years now, but why are there so many imitators? #### `isindex` diff --git a/src/content/en/2020/mobile-web.md b/src/content/en/2020/mobile-web.md index db8ebb01dc3..8db1a1640ef 100644 --- a/src/content/en/2020/mobile-web.md +++ b/src/content/en/2020/mobile-web.md @@ -37,7 +37,7 @@ Please visit the links above to learn more about the methodology and caveats wit In addition to the above, we also used a non-public Chrome data source in the section on page loads in Chrome. For more information on this, read about Chrome's data collection API. -While this data is only collected from a subset of (opted in) Chrome users, it does not suffer from being limited to homepages. It is pseudonymous and consists of histograms and events. +While this data is only collected from a subset of (opted in) Chrome users, it does not suffer from being limited to home pages. It is pseudonymous and consists of histograms and events.

NOTE: Reporting is enabled if the user has enabled a feature that syncs browser windows, unless they have disabled the "Make searches and browsing better / Sends URLs of pages you visit to Google" setting.

@@ -252,7 +252,7 @@ Simple design tweaks go a long way, for instance a clear call-to-action, and mak ) }} -Research has shown that auto-forwarding carousels are detrimental to the user experience. Auto-forwarding carousels on the homepage should be avoided or their frequency should be decreased. +Research has shown that auto-forwarding carousels are detrimental to the user experience. Auto-forwarding carousels on the home page should be avoided or their frequency should be decreased. ##### Color and contrast diff --git a/src/content/en/2020/security.md b/src/content/en/2020/security.md index 215450e43b3..7eb34dcc75d 100644 --- a/src/content/en/2020/security.md +++ b/src/content/en/2020/security.md @@ -34,7 +34,7 @@ We not only look at the adoption of security mechanisms in individual websites. ### Methodology -Throughout this chapter, we report on the adoption of various security mechanisms on the web. This analysis is based on data that was collected for the homepage of 5.6 million desktop domains and 6.3 million mobile domains. Unless explicitly stated otherwise, the reported numbers are based on the mobile dataset, as it is larger in size. Because most websites are included in both datasets, the resulting measurements are mostly similar. Any significant difference between the two datasets are reported throughout the text or is apparent from the figures. For more information on how the data has been collected, please refer to the [Methodology](./methodology). +Throughout this chapter, we report on the adoption of various security mechanisms on the web. This analysis is based on data that was collected for the home page of 5.6 million desktop domains and 6.3 million mobile domains. Unless explicitly stated otherwise, the reported numbers are based on the mobile dataset, as it is larger in size. Because most websites are included in both datasets, the resulting measurements are mostly similar. Any significant difference between the two datasets are reported throughout the text or is apparent from the figures. For more information on how the data has been collected, please refer to the [Methodology](./methodology). ## Transport security @@ -209,7 +209,7 @@ To overcome these issues, browsers have provided additional features that can be #### HTTP Strict Transport Security -The first one is HTTP Strict Transport Security (HSTS), which can easily be enabled by setting a response header consisting of several attributes. For this header we find an adoption rate of 16.88% within the mobile homepages. Of the sites that enable HSTS, 92.82% do so successfully. That is, the max-age attribute (which determines how many seconds the browser should *only* visit the website over HTTPS) has a value larger than 0. +The first one is HTTP Strict Transport Security (HSTS), which can easily be enabled by setting a response header consisting of several attributes. For this header we find an adoption rate of 16.88% within the mobile home pages. Of the sites that enable HSTS, 92.82% do so successfully. That is, the max-age attribute (which determines how many seconds the browser should *only* visit the website over HTTPS) has a value larger than 0. {{ figure_markup( image="security-hsts-max-age-values-in-days.png", @@ -286,7 +286,7 @@ The attribute that was introduced most recently, `SameSite`, can be used to rest Our results, which are based on 25 million first-site cookies and 115 million third-party cookies, shows that the usage of the cookie attributes strongly depends on the context in which they are set. We can observe a similar usage of the `HttpOnly` attribute on cookies for both first-party (30.5%) and third-party (26.3%) cookies. -However, for the `Secure` and `SameSite` attributes we see a significant difference: The `Secure` attribute is present on 22.2% of all cookies set in a first-party context, whereas 68.0% of all cookies set by third-party requests on mobile homepages have this cookie attribute. Interestingly, for desktop pages, only 35.2% of the third-party cookies had the attribute. +However, for the `Secure` and `SameSite` attributes we see a significant difference: The `Secure` attribute is present on 22.2% of all cookies set in a first-party context, whereas 68.0% of all cookies set by third-party requests on mobile home pages have this cookie attribute. Interestingly, for desktop pages, only 35.2% of the third-party cookies had the attribute. For the `SameSite` attribute, we can see a significant increase in their usage, compared to [last year](../2019/security#samesite), when only 0.1% of the cookies had this attribute. As of August 2020, we observed that 13.7% of the first-party cookies and 53.2% of third-party cookies have the `SameSite` attribute set. @@ -776,7 +776,7 @@ Another mechanism to make adoption of CSP easier is the use of nonces: in the `s The two other keywords, `unsafe-inline` and `unsafe-eval`, are present on the majority of the CSPs: 97.28% and 77.79% respectively. This can be seen as a reminder of the difficulty of implementing a policy that can thwart XSS attacks. However, when the `strict-dynamic` keyword is present, this will effectively ignore the `unsafe-inline` and `unsafe-eval` keywords. Because the `strict-dynamic` keyword may not be supported by older browsers, it is considered best practice to include the two other unsafe keywords to maintain compatibility for all browser versions. -Whereas the `strict-dynamic` and `nonce-` keywords can be used to defend against reflected and persistent XSS attacks, a protected page could still be vulnerable to DOM-based XSS vulnerabilities. To defend against this class of attacks, website developers can make use of Trusted Types, a fairly new mechanism that is currently only supported by Chromium-based browsers. Despite the potential difficulties in adopting Trusted Types (websites would need to create a policy and potentially adjust their JavaScript code to comply with this policy), and given that it is a new mechanism, it is encouraging that 11 homepages already adopted Trusted Types through the `require-trusted-types-for` directive in CSP. +Whereas the `strict-dynamic` and `nonce-` keywords can be used to defend against reflected and persistent XSS attacks, a protected page could still be vulnerable to DOM-based XSS vulnerabilities. To defend against this class of attacks, website developers can make use of Trusted Types, a fairly new mechanism that is currently only supported by Chromium-based browsers. Despite the potential difficulties in adopting Trusted Types (websites would need to create a policy and potentially adjust their JavaScript code to comply with this policy), and given that it is a new mechanism, it is encouraging that 11 home pages already adopted Trusted Types through the `require-trusted-types-for` directive in CSP. ### Defending against XS-Leaks with Cross-Origin Policies @@ -883,7 +883,7 @@ In the previous sections we explored the adoption rate of various browser securi ### Country of a website's visitors -There can be many different factors that affect security at the level of a country: government-motivated programs of cybersecurity may increase awareness of good security practices, a focus on security in higher education could lead to more well-informed developers, or even certain regulations might require companies and organizations to adhere to best security practices. To evaluate the differences per country, we analyze the different countries for which at least 100,000 homepages were available in our dataset, which is based on the Chrome User Experience Report (CrUX). These pages consist of those that were visited most frequently by the users in that country; as such, these also contain widely popular international websites. +There can be many different factors that affect security at the level of a country: government-motivated programs of cybersecurity may increase awareness of good security practices, a focus on security in higher education could lead to more well-informed developers, or even certain regulations might require companies and organizations to adhere to best security practices. To evaluate the differences per country, we analyze the different countries for which at least 100,000 home pages were available in our dataset, which is based on the Chrome User Experience Report (CrUX). These pages consist of those that were visited most frequently by the users in that country; as such, these also contain widely popular international websites. {{ figure_markup( image="security-adoption-of-https-per-country.png", @@ -894,7 +894,7 @@ There can be many different factors that affect security at the level of a count sql_file="feature_adoption_by_country.sql" ) }} -Looking at the percentage of homepages that were visited over HTTPS, we can already see a significant difference: for the top 5 best-performing countries 93-95% of the homepages were served over HTTPS. For the bottom 5, we see a much smaller adoption in HTTPS, ranging from 71% to 76%. When we look at other security mechanisms, we can see even more apparent differences between top-performing countries and countries with a low adoption rate. The top 5 countries according to the adoption rate for CSP score between 14% and 16%, whereas the bottom 5 score between 2.5% and 5%. Interestingly, the countries that perform well/poorly for one security mechanism, also do so for other mechanisms. For instance, New Zealand, Ireland and Australia consistently rank among the top 5, whereas Japan scores worst for almost every security mechanism. +Looking at the percentage of home pages that were visited over HTTPS, we can already see a significant difference: for the top 5 best-performing countries 93-95% of the home pages were served over HTTPS. For the bottom 5, we see a much smaller adoption in HTTPS, ranging from 71% to 76%. When we look at other security mechanisms, we can see even more apparent differences between top-performing countries and countries with a low adoption rate. The top 5 countries according to the adoption rate for CSP score between 14% and 16%, whereas the bottom 5 score between 2.5% and 5%. Interestingly, the countries that perform well/poorly for one security mechanism, also do so for other mechanisms. For instance, New Zealand, Ireland and Australia consistently rank among the top 5, whereas Japan scores worst for almost every security mechanism. {{ figure_markup( image="security-adoption-of-csp-and-xfo-per-country.png", @@ -909,9 +909,9 @@ Looking at the percentage of homepages that were visited over HTTPS, we can alre Country-level incentives can drive the adoption of security mechanisms to a certain extent, but perhaps more important is the technology stack that website developers use when building websites. Do the frameworks easily lend themselves to enabling a certain feature, or is this a painstaking process requiring a complete overhaul of the application? Even better it would be if developers start with an already-secure environment with strong security defaults to begin with. In this section we explore different programming languages, SaaS, CMS, ecommerce and CDN technologies that have a significantly higher adoption rate for specific features (and thus can be seen as driving factors for widespread adoption). For brevity, we focus on the most widely deployed technologies, but it is important to note that many smaller technology products exist that aim to provide better security for their users. -For security features related to the transport security, we find that there are 12 technology products (mainly ecommerce platforms and CMSs) that enable the `Strict-Transport-Security` header on at least 90% of their customer sites. Websites powered by the top 3 (according to their market share, namely Shopify, Squarespace and Automattic), make up for 30.32% of all homepages that have enabled Strict Transport Security. Interestingly, the adoption of the `Expect-CT` header is mainly driven by a single technology, namely Cloudflare, which enables the header on all of their customers that have HTTPS enabled. As a result, 99.06% of the `Expect-CT` header presences can be related to Cloudflare. +For security features related to the transport security, we find that there are 12 technology products (mainly ecommerce platforms and CMSs) that enable the `Strict-Transport-Security` header on at least 90% of their customer sites. Websites powered by the top 3 (according to their market share, namely Shopify, Squarespace and Automattic), make up for 30.32% of all home pages that have enabled Strict Transport Security. Interestingly, the adoption of the `Expect-CT` header is mainly driven by a single technology, namely Cloudflare, which enables the header on all of their customers that have HTTPS enabled. As a result, 99.06% of the `Expect-CT` header presences can be related to Cloudflare. -With regard to security headers that secure content inclusion or that aim to thwart attacks, we see a similar phenomenon where a few parties enable a security header for all their customers, and thus drive its adoption. For instance, six technology products enable the `Content-Security-Policy` header for more than 80% of their customers. As such, the top 3 (Shopify, Sucuri and Tumblr) represent 52.53% of the homepages that have the header. Similarly, for `X-Frame-Options`, we see that the top 3 (Shopify, Drupal and Magento) contribute 34.96% of the global prevalence of the XFO header. This is particularly interesting for Drupal, as it is an open-source CMS that is often set up by website owners themselves. It is clear that their decision to enable `X-Frame-Options: SAMEORIGIN` by default is keeping many of their users protected against clickjacking attacks: 81.81% of websites powered by Drupal have the XFO mechanism enabled. +With regard to security headers that secure content inclusion or that aim to thwart attacks, we see a similar phenomenon where a few parties enable a security header for all their customers, and thus drive its adoption. For instance, six technology products enable the `Content-Security-Policy` header for more than 80% of their customers. As such, the top 3 (Shopify, Sucuri and Tumblr) represent 52.53% of the home pages that have the header. Similarly, for `X-Frame-Options`, we see that the top 3 (Shopify, Drupal and Magento) contribute 34.96% of the global prevalence of the XFO header. This is particularly interesting for Drupal, as it is an open-source CMS that is often set up by website owners themselves. It is clear that their decision to enable `X-Frame-Options: SAMEORIGIN` by default is keeping many of their users protected against clickjacking attacks: 81.81% of websites powered by Drupal have the XFO mechanism enabled. ### Co-occurrence of other security headers @@ -924,9 +924,9 @@ With regard to security headers that secure content inclusion or that aim to thw sql_file="feature_adoption_by_other_features.sql" ) }} -The security "game" is highly unbalanced, and much more in the favor of attackers: an adversary only needs to find a single flaw to exploit, whereas the defender needs to prevent all possible vulnerabilities. As such, whereas adopting a single security mechanism can be very useful in defending against a particular attack, websites need multiple security features in order to defend against all possible attacks. To determine whether security headers are adopted in a one-off manner, or rather in a rigorous way to provide in-depth defenses against as many attacks as possible, we look at the co-occurrence of security headers. More precisely, we look at how the adoption of one security header affects the adoption of other headers. Interestingly, this shows that websites that adopt a single security header, are much more likely to adopt other security headers as well. For instance, for mobile homepages that contain a CSP header, the adoption of the other headers (`Expect-CT`, `Referrer-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options` and `X-Frame-Options`) is on average 368% higher compared to the overall adoption of these headers. +The security "game" is highly unbalanced, and much more in the favor of attackers: an adversary only needs to find a single flaw to exploit, whereas the defender needs to prevent all possible vulnerabilities. As such, whereas adopting a single security mechanism can be very useful in defending against a particular attack, websites need multiple security features in order to defend against all possible attacks. To determine whether security headers are adopted in a one-off manner, or rather in a rigorous way to provide in-depth defenses against as many attacks as possible, we look at the co-occurrence of security headers. More precisely, we look at how the adoption of one security header affects the adoption of other headers. Interestingly, this shows that websites that adopt a single security header, are much more likely to adopt other security headers as well. For instance, for mobile home pages that contain a CSP header, the adoption of the other headers (`Expect-CT`, `Referrer-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options` and `X-Frame-Options`) is on average 368% higher compared to the overall adoption of these headers. -In general, websites that adopt a certain security header are 2 to 3 times more likely to adopt other security headers as well. This is especially the case for CSP, which fosters the adoption of other security headers the most. This can be explained on the one hand because CSP is one of the more extensive security headers that requires considerable effort to adopt, so websites that do define a policy, are more likely to be invested in the security of their website. On the other hand, 44.31% of the CSP headers are on homepages that are powered by Shopify. This SaaS product also enables several other security headers (`Strict-Transport-Security`, `X-Content-Type-Options` and `X-Frame-Options`) as a default for virtually all of their customers. +In general, websites that adopt a certain security header are 2 to 3 times more likely to adopt other security headers as well. This is especially the case for CSP, which fosters the adoption of other security headers the most. This can be explained on the one hand because CSP is one of the more extensive security headers that requires considerable effort to adopt, so websites that do define a policy, are more likely to be invested in the security of their website. On the other hand, 44.31% of the CSP headers are on home pages that are powered by Shopify. This SaaS product also enables several other security headers (`Strict-Transport-Security`, `X-Content-Type-Options` and `X-Frame-Options`) as a default for virtually all of their customers. ## Software update practices @@ -945,7 +945,7 @@ A very large part of the Web is built with third-party components, at different height="575" ) }} -As one of the most popular [Content Management Systems](./cms), WordPress is an attractive target for attackers. As such, it is important for website administrators to keep their installation up-to-date. By default, updates are performed automatically for WordPress, although it is possible to disable this feature. The evolution of the deployed WordPress versions are displayed in the above figure, showing the latest major versions that are still actively maintained (5.5: purple, 5.4: blue, 5.3: red, 5.2: green, 4.9: orange). Versions that have a prevalence of less than 4% are grouped together under "Other". A first interesting observation that can be made is that as of August 2020, 74.89% of the WordPress installations on mobile homepages are running the latest version within their branch. It can also be seen that website owners are gradually upgrading to the new major versions. For instance, WordPress version 5.5, which was released on August 11th 2020, already comprised 10.22% of the WordPress installations that were observed in the crawl for August. +As one of the most popular [Content Management Systems](./cms), WordPress is an attractive target for attackers. As such, it is important for website administrators to keep their installation up-to-date. By default, updates are performed automatically for WordPress, although it is possible to disable this feature. The evolution of the deployed WordPress versions are displayed in the above figure, showing the latest major versions that are still actively maintained (5.5: purple, 5.4: blue, 5.3: red, 5.2: green, 4.9: orange). Versions that have a prevalence of less than 4% are grouped together under "Other". A first interesting observation that can be made is that as of August 2020, 74.89% of the WordPress installations on mobile home pages are running the latest version within their branch. It can also be seen that website owners are gradually upgrading to the new major versions. For instance, WordPress version 5.5, which was released on August 11th 2020, already comprised 10.22% of the WordPress installations that were observed in the crawl for August. {{ figure_markup( image="security-evolution-of-wordpress-5-3and5-4-after-update.png", @@ -973,7 +973,7 @@ Another interesting aspect that can be inferred from the graph is that within a sql_file="feature_adoption_by_technology.sql" ) }} -One of the most widely used JavaScript libraries is jQuery, which has three major versions: 1.x, 2.x and 3.x. As is clear from the evolution of jQuery versions that are used on mobile homepages, the overall distribution is very static over time. Surprisingly, a significant fraction of websites (18.21% as of August 2020) are still running an old 1.x version of jQuery. This fraction is consistently decreasing (from 33.39% in November 2019), in favor of version 1.12.4, which was released in May 2016 and unfortunately has various medium-level security issues. +One of the most widely used JavaScript libraries is jQuery, which has three major versions: 1.x, 2.x and 3.x. As is clear from the evolution of jQuery versions that are used on mobile home pages, the overall distribution is very static over time. Surprisingly, a significant fraction of websites (18.21% as of August 2020) are still running an old 1.x version of jQuery. This fraction is consistently decreasing (from 33.39% in November 2019), in favor of version 1.12.4, which was released in May 2016 and unfortunately has various medium-level security issues. ### nginx diff --git a/src/content/en/2021/accessibility.md b/src/content/en/2021/accessibility.md index 5a5bd93bdb8..27821794b45 100644 --- a/src/content/en/2021/accessibility.md +++ b/src/content/en/2021/accessibility.md @@ -33,7 +33,7 @@ Products and services are also rapidly shifting online as a result of the pandem Web accessibility is about giving complete access to all aspects of an interface to people with disabilities by achieving feature and information parity. A digital product or website is simply not complete if it is not usable by everyone. If a digital product excludes certain disabled populations, this is discrimination and potentially grounds for fines and/or lawsuits. Last year lawsuits related to the Americans with Disabilities Act were up 20%. -Sadly, year over year, we and other teams conducting analysis such as the WebAIM Million are finding very little improvement in these metrics. The WebAIM study found that 97.4% of homepages had automatically detected accessibility failures, which is less than 1% lower than the 2020 audit. +Sadly, year over year, we and other teams conducting analysis such as the WebAIM Million are finding very little improvement in these metrics. The WebAIM study found that 97.4% of home pages had automatically detected accessibility failures, which is less than 1% lower than the 2020 audit. The median overall site score for all Lighthouse Accessibility audit data rose from 80% in 2020 to 82% in 2021. We hope that this 2% increase represents a shift in the right direction. However, these are automated checks, and this could also potentially mean that developers are doing a better job of subverting the rule engine. @@ -89,7 +89,7 @@ Users with low vision may rely on zooming and scaling the page using system sett sql_file="viewport_zoom_scale.sql" ) }} -We found that 24% of desktop homepages and 29% of mobile homepages attempt to disable scaling by setting either `maximum-scale` to a value less than or equal to 1, or `user-scalable` set to `0` or `none`. +We found that 24% of desktop home pages and 29% of mobile home pages attempt to disable scaling by setting either `maximum-scale` to a value less than or equal to 1, or `user-scalable` set to `0` or `none`. {{ figure_markup( image="pages-zooming-scaling-disabled-by-rank.png", @@ -619,7 +619,7 @@ Currently 69% (up from 65% in 2020) of desktop pages have at least one instance One of the most common misuses of ARIA roles is adding a button role to non-interactive elements such as `
`s and ``s, or to `` elements. A native HTML `