Go to content

In February 2024, WebAIM evaluated the home page accessibility of the top 1 million websites. This was the sixth consecutive year of analysis, which uses WebAIM’s WAVE web accessibility evaluation tool to automatically detect errors.

What do we know?

Since 2023

In the year since the last evaluation, the average number of detected errors per page increased by 13.6% to 56.8. Errors are defined as “WAVE-detected accessibility barriers having notable end user impact, and with a very high likelihood of being WCAG 2.2 Level A/AA conformance failures.”

It is worth noting that some of this change may be due to a minor change in page sampling by WebAIM and a slightly expanded test logic in WAVE. However, overall, they feel that their 2024 analysis is more thorough and accurate.

Also noted over the past year:

  • the average number of HTML elements used on home pages increased by 11.8% to 1173. The most popular pages were among the most complex.
  • ARIA (Accessible Rich Internet Applications) usage increased by 15% to an average of 89 attributes per page. Pages typically had more errors when ARIA was present.

Since 2019

In the five year period since the first WebAIM Million:

  • the average number of elements has grown by 50%
  • the average number of ARIA attributes has grown by 132%

Meanwhile, the number of home pages with automatically detectable failures of WCAG (Web Content Accessibility Guidelines) has decreased by a meagre 1.9%. Now “just” 95.9% of the top 1 million home pages fail to conform to WCAG. The true figure is likely to be higher, given that not all accessibility issues can be identified by automated testing on its own.

We cannot infer causation from correlation, but it’s clear that developers are producing more and more code while accessibility remains poor overall and comparatively stagnant. The vast majority of all WCAG failures detected fall into six categories, which have remained unchanged since 2019:

  • Low contrast text
  • Missing alternative text for images
  • Missing form input labels
  • Empty links
  • Empty buttons
  • Missing document language

Addressing just these few types of issues would significantly improve accessibility across the web.

A study of HTML

We might hope that the growth in code is at least adding some semantics and meaning, helping to ensure that the page is well understood by assistive technology, but the data says otherwise. In 2020, a large-scale HTML study crawled 11 million web pages (from the top of the Google search results list) and recorded the frequency of usage of HTML elements.

The average web page comprised 32 different element types. Here’s the top 10, when these elements were ordered by frequency of appearance:

  1. <html> (100%)
  2. <head> (100%)
  3. <body> (99.1%)
  4. <title> (97.9%)
  5. <meta> (96.5%)
  6. <div> (95.1%)
  7. <a> (93.7%)
  8. <script> (93.5%)
  9. <link> (92.7%)
  10. <img> (89.2%)

The <html> element represents the top-level element of an HTML document. All other elements must be descendants of this element. The <head> element contains machine-readable information (meta-data) about the document. It holds things like scripts and links to stylesheets as well as the <title> element, which determines the title that is shown in a browser’s title bar or a page’s tab. The <body> element represents the content of an HTML document. The <a> element (or anchor element) is how we hyperlink to web pages, files, email addresses and so on. All pretty useful, I think we can contend.

The <div> element has no meaning beyond being a generic container for other things. It is an empty vessel, as mundane – and as prolific – as the Ford Mondeo was at its peak. The best thing you can do with it is to use it, sparingly, to hold some content so as to apply some visual styling. The worst thing you can do is use it instead of a link or a button, but this is something I see all too often.

A note about ARIA

As noted already, ARIA usage is also on the rise. On the surface ARIA sounds like a good tool; “Accessible” is right there in the name, after all. When used correctly, ARIA attributes can help to fill gaps in HTML semantics – but it is intended as a bridging technology. The first rule of ARIA is to not use ARIA if you can use HTML instead. Cramming a bunch of ARIA into HTML without understanding what it’s doing is likely to cause as many accessibility issues as it solves.

Complexity and accessibility

To be creating ever more complex home pages is somewhat obscene when we haven’t nailed the basics.

Screen readers may struggle to correctly interpret complex web pages built with convoluted code, excessive JavaScript, or non-standard HTML structures. This has a direct and negative impact on people who rely on assistive technology to understand and navigate the web.

Web pages with dense content, confusing and intricate navigation and cluttered layouts can impose a higher cognitive load on everybody, but particularly on people with cognitive or learning disabilities.

Furthermore, complex web pages often require more resources to load, which can increase page load times. This is another access barrier, one which disproportionately affects people with low-end devices, slow internet connections, and capped data allowances.

Getting back to basics

I guess there are a number of factors at play: bootcamps that fail to explain the fundamentals of HTML, CSS and JavaScript, let alone accessibility; a propensity to pick up the latest massive framework or lean on automation to solve everything and ‘ship it fast’, rather than taking a more considered approach and applying the rule of least power.

The fact that nowadays we talk about the the web as an industry says a lot about the direction of travel. With the focus so heavily on frameworks, JavaScript and components – and on clicks, conversions and revenue – where is the space for considering the needs of the people who have to (try to) use what we build? For reflecting on the principles, values, and philosophies that constitute the web platform?

More guff, generated more quickly, is not the answer. We need a large-scale shift in our values, our priorities and how we approach our work. We need to reclaim the heart and soul – and joy – of web design and development. We need to act mindfully rather than mindlessly and reconnect with the fundamentals of what the web should be.

It’s the only way to combat the endless conveyor of websites that are overproduced and yet all look the same; that demand so much from the people who create and use them but offer so little in return, besides choking search engines and degrading the planet.

We believe in keeping the front-end simple and using tried and tested technology to build accessible, resilient websites that work for everyone. Let’s have a chat about your web project and we can build a better web together.