Web accessibility: the six errors almost every website makes

Every year, WebAIM, a nonprofit focused on web accessibility, runs the WAVE evaluation engine over the home pages of the top 1 million websites in the world¹. The sample is global. In the 2026 edition, 95.9% of those home pages had detectable WCAG failures, up from 94.8% in 2025¹. The average was 56.1 errors per page¹.

The error count rose 10.1% in a single year¹. Page size is part of the story: the average home page reached 1437 elements, up 14.3% year over year¹. Bigger pages, with more third-party components, give errors more places to hide.

WebAIM spells out the limit of its own method: automated tools cannot detect every failure, and a page with no detected errors is not necessarily accessible¹. That is why the study concludes that full WCAG 2 Level AA conformance was certainly below 4.1%¹.

According to WebAIM, the list of most common errors has not changed in seven years¹. The table below shows the share of home pages where each error showed up in the 2026 edition. The shares add up to more than the total number of pages because a single page usually carries several error types at once. Fixing just these six removes most of what an automated scan reports.

Two details show how deep the problem runs inside each page. On average, every home page had 34 distinct instances of low-contrast text. And 16.2% of all images were missing alternative text¹. In forms, 33.1% of inputs had no associated label¹.

The fix for all six errors is known and documented by the W3C, the consortium that publishes WCAG. None of them calls for a redesign: they are changes to color, HTML markup, and content. The order below follows how often each error shows up in the WebAIM Million, and each item says what to check and what to change in the code or the content management system.

1. 01
   Low contrast. Body text needs a contrast ratio of at least 4.5:1 against its background; large text, meaning 18 points or 14 points bold and up, can go down to 3:1². Fix the palette in the brand guidelines, not page by page.
2. 02
   Missing alt text. Every informative image gets an alt attribute that says what it communicates. Decorative images get alt="" so screen readers skip them. An image that works as a link describes the destination, not the picture.
3. 03
   Missing labels. Every form field needs a <label> tied to it, or an aria-label. Placeholder text disappears as soon as someone types and does not replace the label.
4. 04
   Empty links. A link that holds only an icon, or an image without alt, has no name for a screen reader. Give it visible text or an aria-label that says where it goes.
5. 05
   Empty buttons. Same issue as links: icon buttons (search, menu, close) need an accessible name. An aria-label="Search" does the job.
6. 06
   Missing document language. Declare <html lang="en"> in the page template. Without it, a screen reader may read English text with another language's pronunciation.

Accessibility laws rarely list technical criteria; they usually point to international guidelines. Brazil is a clear example. Law 13,146 of 2015, the Brazilian Inclusion Act, makes accessibility mandatory for websites run by companies headquartered or commercially represented in the country and by government bodies³. Its Article 63 sets the bar at internationally adopted best practices and guidelines, a role WCAG fills today.

The same article also requires sites to display the accessibility symbol prominently. It sets no conformance level and no checklist of criteria of its own. In practice, that makes WCAG at Level AA the technical reference a company uses to show that its site meets the requirement.

The audience is not small. Brazil's 2022 Census counted 14.4 million people with disabilities, or 7.3% of the population aged 2 years or older⁴. Of those, 7.9 million had difficulty seeing, the group hit hardest by low contrast and undescribed images⁴.

Tools like WAVE, Lighthouse, and axe catch only the failures that can be measured in code, such as contrast, missing attributes, or unlabeled fields. They cannot judge whether alt text actually describes the image, whether the keyboard tab order makes sense, or whether a form error gets announced to a screen reader. That part takes manual testing.

WebAIM documents a clear example of the gap: 10.8% of images that had alternative text used questionable or repetitive descriptions, such as "image" or a file name¹. To the tool, the attribute exists and the error goes away. To a screen reader user, the image still has no description.

That is why we treat automated testing as the floor. Clearing the six errors in the table is step one. Step two is moving through the site with only a keyboard and with a screen reader, such as NVDA on Windows or VoiceOver on Mac and iPhone.

Start with the pages that drive business results: the home page, product or service pages, the contact form, and the checkout flow. Run WAVE, free at wave.webaim.org, on each one and log every instance of the six errors in the table. Then open one ticket per error type, not per page, because the fix usually lives in the template.

1. 01
   List the five pages with the most traffic or conversions in your analytics dashboard.
2. 02
   Run WAVE on each and record the count for each of the six errors in a spreadsheet.
3. 03
   Fix what lives in the site template first: color palette, the lang attribute, form labels, and icon button names.
4. 04
   Review image alt text with whoever owns the content, one image at a time.
5. 05
   Go through the same pages using only the Tab key and with a screen reader on, and note where navigation gets stuck.
6. 06
   Repeat the scan after every major release so fixed errors do not creep back.