|WebAIM Million Study
Here's one cool thing that happens every year: Web Accessibility in Mind, best known as WebAIM, analyzes the top 1,000,000 home pages to check for accessibility errors. The stats are not great, but compared with previous years, they are (very slowly) improving.
- 96
- percentage of home pages with accessibility bugs
- 57
- number of average accessibility bugs per page
- 31
- percentage of home pages with 10 or fewer errors
- 1173
- average number of elements per home page
Note: With readability in mind, all numbers from the report are rounded here to the nearest whole number. The percentage 96 comes up in two places. As the percentage of home pages with detected failures, it was rounded up from 95.9%. As the percentage of all errors that these 6 bugs account for, it was rounded down from 96.4%.
WebAIM audits these pages using an automated tool, the WAVE accessibility engine. Automated tools fail to detect all accessibility barriers and guidelines violations. As a result, the actual number of bugs is likely to be higher.
What are accessibility bugs?
These are issues that make it difficult or impossible for people with disabilities to use your site. To make sure it's accessible, you need to understand how disabled users interact with it.
In this article, as well as the rest of the website, the discussions around bugs and code errors that create bugs will be centered mostly around the negative impact they have on users with disabilities. While we'll also reference the international standards for web accessibility Web Content Accessibility Guidelines, better know as WCAG, the focus will be on the user experience and not so much on a specific guideline or rule.
The WCAG structure is a bit different then the name suggests. There are four principles: perceivable, operable, understandable, and robust. Each principle has a set of guidelines, and each guideline has a set of success criteria. The success criteria are in fact the specific rules we use to determine if a website is accessible.
Each success criterion has one of the three levels of conformance: A, AA, and AAA. Usually, a specific accessibility goal is addressed by a success criterion with a given level of conformance. For example, the requirement that every web page has a title is a level A criterion.
We can also have two criteria, each at a different level, addressing the same goal. For example, when it comes to the size of clickable areas, we have a level AA criterion that requires a minimum of 24 by 24 pixels. We also have a AAA level criterion that sets the minimum size to 44 by 44 pixels. In this way, the guidelines establish a minimum level of accessibility, while also recommending a desirable level that will benefit the largest number of users.
For an overview of the WCAG guidelines, the article WCAG primer by Léonie Watson is a great start. As your understanding of accessibility grows beyond the introductory level presented here, these guidelines will have to become part of your development process to help you fine tune your code for accessibility.
The full WebAIM Million report makes for an interesting and informative read, do check it out! In the meantime, let's go over the list with the 6 most common bugs found in the 2024 study. Here's what do we know about them:
They accounted for 96% of all bugs found.
They've been the "most common bugs" for the last 5 years.
The good news? These are some of the easiest bugs to avoid or fix!
Low contrast text
Found on 81% of pages, this bug involves text without enough contrast against its background. This text is hard to read, especially for users with visual impairments.
Example: text with low contrast ratio
Users with vision problems would have a hard time reading this sentence if we changed the font color to certain shades of blue.
Press the button to test it.
Missing "alt" text for images
More than half of the home pages audited had this bug! When images lack the alt attribute, screen reader users do not know what the purpose of the image is. Usually, when this attribute is missing, the screen reader will read the source file name.
An empty alt is NOT a missing alt!
An important distinction to make:
Missing: screen readers read the source file name. When you have an image, the alt attribute is required!
Empty: screen readers ignore the image. If your image is purely decorative, the attribute should be empty.
Missing input labels
Almost half of the pages lacked input labels. Without labels, assistive tech users struggle to understand or use the input.
Example: an input without a label
<label><input type="text" id="email"></label>The input is wrapped in label tags without inner text. There's no visible or visually-hidden text, and no ARIA attribute to provide an accessible name.
The label tells the user what the input is for. For a sighted user, there might be clues on the page, but for a screen reader user, the input is a mystery.
True, a lot of inputs have placeholder text. One of the (many) problems with placeholder text is that browsers can't be trusted to use it to compute the accessible name. So if placeholder text is the only text, not everyone will know what the input is for.
Empty links
Almost half of the home pages tested had links without a name. This is a problem because screen reader users rely on a descriptive name to understand the purpose and the destination of a link.
Follow this link to review the accessible name, the name by which an interactive element is known to assistive technologies.
Avoid vague text as well!
Vague link text like click here or learn more is not very helpful either.
Instead of reading through an entire page, some screen reader users prefer to navigate through the various links provided on the page.
As a result, the links are announced separately from their surrounding text and users will not understand their purpose if the text is vague.
A good example of a link text: "Learn more about our services"
Missing document language
This bug was found on 17% of the home pages audited.
If a webpage doesn't have a lang attribute, the screen reader defaults to the operating system's language. This can be a problem for multilingual users accessing content in various languages.
For example, let's say a screen reader user with a device set to English wants to read a webpage in French. If the page's lang attribute is missing, the screen reader will read the French text as if it were English.
The lang is added to the html tag!
<html lang="en">Done with the 6 most common accessibility bugs! Do you have time for a bonus bug? Too important to leave it out!
Misused headings
About 17% of all home pages had more than one <h1>. Skipped heading levels (e.g., jumping from <h2> to <h4>) were found on more than 38% of all pages. About 11% of pages had no headings at all.
Why headings are important
Headings help break down a webpage into sections, kind of like chapters in a book. If you're looking at the screen, you can quickly glance over the headings to find the part you're interested in.
Someone using a screen reader relies on headings as well. Pressing the h key allows them to jump from one heading to another. This way, they can get a sense of what's on the page and decide what to read.
As a good practice, we have to use <h1> at the start of the page. Also, we should not skip heading levels, and use <h1> to <h6> in descending order.
Recommended read
Learn how screen reader users navigate the web to find information on a page from the WebAIM's Screen Reader User Survey.
What next?
We just looked at the most common accessibility bugs as reported by the WebAIM Million Study. Fortunately, these are also the easiest to avoid, and now you can take a look at your portfolio site to see if any of these bugs are present.
Read next: Fixing the 6 most common bugs