Back to the blog Web Development

WCAG 2.2: common accessibility errors and how to fix them

What changed in WCAG 2.2, how to fix the most common accessibility errors with HTML and CSS, how to test, and what the rules require in Chile and the European Union.

David López · CEO - Fundador November 4, 2026 10 min read

In February 2026, the WebAIM Million project reviewed the home pages of the top one million websites according to the Tranco ranking. 95.9% had automatically detectable WCAG 2 failures, with 56.1 errors per page on average. 96% of those errors fall into six categories.

Almost all of them can be fixed with basic HTML and CSS. But they affect people who browse with a keyboard, a screen reader or low vision, and they are rarely noticed in a visual review.

This guide summarizes what WCAG 2.2 is, how to fix the most common errors, how to test, and what the rules require in Chile and the European Union, based on official texts reviewed in November 2026.

What WCAG 2.2 is

The Web Content Accessibility Guidelines (WCAG) are a W3C standard. Version 2.2 was published on October 5, 2023, with an update on December 12, 2024. The 2023 version is also the ISO/IEC 40500:2025 standard.

It has four principles (perceivable, operable, understandable and robust), 13 guidelines and testable success criteria at three levels: A is the minimum; AA requires the A and AA criteria, and is the target of this guide; AAA requires all three, and the W3C does not recommend requiring it as a general policy for entire sites.

What changed from WCAG 2.1

It adds nine criteria:

Criterion	Level
2.4.11 Focus Not Obscured (Minimum)	AA
2.4.12 Focus Not Obscured (Enhanced)	AAA
2.4.13 Focus Appearance	AAA
2.5.7 Dragging Movements	AA
2.5.8 Target Size (Minimum)	AA
3.2.6 Consistent Help	A
3.3.7 Redundant Entry	A
3.3.8 Accessible Authentication (Minimum)	AA
3.3.9 Accessible Authentication (Enhanced)	AAA

And it removes one: 4.1.1 Parsing, which the W3C declares obsolete because assistive technology no longer needs to parse HTML directly. WCAG 2.0 and 2.1 received a note: the criterion is considered always satisfied for content using HTML or XML. The rest of the 2.1 criteria are unchanged.

What about WCAG 3?

It is a Working Draft; the latest version is dated September 10, 2026. According to the W3C, it will not be a completed standard for a few more years, it will not replace WCAG 2, and the best way to prepare is to meet WCAG 2.2 now.

The most common errors

Percentage of home pages with each error, according to WebAIM Million 2026:

Error	Pages	Related criterion
Low contrast text	83.9%	1.4.3
Images missing alternative text	53.1%	1.1.1
Missing form input labels	51%	1.3.1, 3.3.2, 4.1.2
Empty links	46.3%	2.4.4, 4.1.2
Empty buttons	30.6%	4.1.2
Missing document language	13.5%	3.1.1

We add three topics worth checking by hand: visible focus, focus order and touch target size.

Insufficient contrast

Criterion 1.4.3 (AA) requires 4.5:1 between text and background, and 3:1 for large text (18 point, or 14 point bold; about 24 px and 18.5 px according to the W3C). Values are not rounded: 4.499:1 does not pass. Placeholder text counts too; disabled controls are exempt. User interface components and graphics needed to understand content, such as field borders and icons, require 3:1 (criterion 1.4.11, AA).

WebAIM found 34 instances of low-contrast text per page on average: fix the design system's palette rather than page by page.

Images without alternative text

Criterion 1.1.1 (A) requires a text alternative that serves the same purpose. According to WebAIM, 16.2% of images were missing one. If the image informs, describe what it adds; if it is a link or button, describe the function; if it is decorative, use alt="". Omitting the attribute is a documented failure (F65).

<img src="process.png" alt="Three-step checkout: choose, pay and receive">
<a href="/"><img src="logo.svg" alt="Example Company home"></a>
<img src="divider.svg" alt="">

Unlabeled fields

Criterion 3.3.2 (A) requires labels or instructions when users enter data; the association in code is assessed under 1.3.1 and the accessible name under 4.1.2. Use <label> with for and id, and <fieldset> with <legend> for groups. Placeholder text is not a replacement for a label: it disappears as you type and screen readers do not treat it as a label.

<label for="email">Email</label>
<input id="email" name="email" type="email">

<fieldset>
  <legend>Contact method</legend>
  <input type="radio" id="c-email" name="contact" value="email">
  <label for="c-email">Email</label>
  <input type="radio" id="c-phone" name="contact" value="phone">
  <label for="c-phone">Phone</label>
</fieldset>

Empty links and buttons

A link or button that contains only an icon is announced without a name. For a link whose only content is an image without an accessible name, that is failure F89 (criteria 2.4.4, 2.4.9 and 4.1.2); for a button, it is F68 (criterion 4.1.2). Use visible text, alt on the image or aria-label. A "Read more" link can pass if the paragraph explains the destination, but the W3C prefers links that make sense on their own. If you use aria-label, it replaces the visible text for screen readers, so start it with that text.

<a href="/news/new-branch" aria-label="Read more about the new branch">Read more</a>

<button type="button" aria-label="Close menu">
  <svg aria-hidden="true">…</svg>
</button>

Be careful with ARIA: pages that used it had more detected errors (59.1 on average) than pages that did not (42), according to WebAIM. That is an association, not a cause. The W3C's ARIA Authoring Practices Guide reminds you that an ARIA role does not add keyboard behavior; prefer <button> and <a href> over a <div> with roles.

Missing page language

Criterion 3.1.1 (A) requires that the page's default language can be programmatically determined: lang on <html>, with a BCP 47 code. Passages in another language are marked too (criterion 3.1.2, AA).

<html lang="en">
  …
  <p>In Spanish, the standard is called <span lang="es">Pautas de Accesibilidad para el Contenido Web</span>.</p>

Invisible or hidden focus

Criterion 2.4.7 (AA) is meant to let keyboard users know where focus is. The classic error, :focus { outline: none }, is the literal example of failure F78. Replace the outline; do not remove it. :focus-visible shows it when navigating by keyboard but not when clicking a button with a mouse, and has worked across major browsers since March 2022.

The new criterion 2.4.11 (AA) requires that the focused element is not entirely hidden by sticky headers, cookie banners or non-modal dialogs. One recognized technique is scroll-padding (C43).

:focus-visible {
  outline: 3px solid #1a56db;  /* check 3:1 against the background */
  outline-offset: 2px;
}

html {
  scroll-padding-top: 80px;     /* height of the sticky header */
  scroll-padding-bottom: 64px;  /* height of the cookie banner */
}

Illogical focus order

Criterion 2.4.3 (A) requires a focus order that preserves meaning. MDN recommends using only tabindex="0" and "-1", avoiding positive values and avoiding CSS that reorders focusable elements: the HTML should already be in a logical order. A <div> with tabindex is not a substitute for a button, because it does not appear as a control in the accessibility tree.

<!-- Avoid -->
<div tabindex="1" onclick="send()">Send</div>

<!-- Use -->
<button type="submit">Send</button>

Small touch targets

Criterion 2.5.8 (AA), new in 2.2, requires targets of at least 24 × 24 CSS pixels. There are exceptions: a smaller target passes if it has free space equivalent to a 24 px circle, if another control on the page does the same thing and passes, if it is a link inside a sentence, if its size is set by the browser, or if that presentation is essential or legally required. For important controls, the W3C suggests aiming for 44 × 44 px (criterion 2.5.5, AAA).

.pagination a,
.social a {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 24px;   /* technique C42 */
  min-height: 24px;
}

How to test

Keyboard. Move through the page with Tab and Shift+Tab; activate links with Enter, buttons with Enter or Space, and close dialogs with Esc. Check that focus is always visible, moves in a logical order and never gets trapped (criterion 2.1.2, A).
Screen reader. NVDA is free and open source for Windows; VoiceOver is built into macOS.
Automated tools. They are a good first filter, but the W3C warns that they cannot check everything, that human judgment is required and that they sometimes produce misleading results. WebAIM adds that the absence of detected errors does not mean a page is accessible. A tool can see a missing alt, but it cannot judge whether an existing one describes the image well.

What Chilean regulations require

Government bodies. Decree 1 of 2015 of the Ministry General Secretariat of the Presidency approves the technical standard on systems and websites of the bodies of the State Administration, except public companies created by law. Its article 5 requires applying the guidelines on universal accessibility, taking into account the Convention on the Rights of Persons with Disabilities, Law 20,422 and "the international standards defined by the W3C". It does not set a WCAG version or level. The National Congress Library (BCN) lists it as not repealed.
Law 21,180 on Digital Transformation. It amended Law 19,880, whose article 19 requires State Administration bodies to use electronic platforms for case files and tasks a regulation with setting their standards, taking into account "accessibility conditions for interested parties". This also binds the State, not private companies.
Law 20,422. It regulates equal opportunities and social inclusion of persons with disabilities, defines universal accessibility and tasks the State with setting accessibility requirements (article 8). We did not find in its text a specific obligation for private websites.

In short: we did not find a rule in force that requires a private Chilean company to meet WCAG on its website. For the State there is a mandate, with no version or level defined.

If you sell in Europe

Directive (EU) 2019/882, or European Accessibility Act, applies from June 28, 2025. It covers, among others, e-commerce, consumer banking services, e-books, and the websites and apps of several passenger transport services.

It may matter to you from Chile because it defines a service provider as anyone who provides a service on the Union market or makes offers to provide it to consumers in the Union. If your online store sells to European consumers, you could fall within scope.

It requires websites and apps to be perceivable, operable, understandable and robust, the same principles as WCAG, and requires identification and payment in e-commerce to be accessible. Microenterprises providing services (fewer than 10 persons and up to EUR 2 million in annual turnover or balance sheet total) are exempt. Each country applies it through its national law, so check with local counsel.

Checklist

Check	Criterion
Text contrast of 4.5:1 (3:1 if large), placeholder included	1.4.3
Field borders, icons and focus indicator at 3:1	1.4.11
Every image with descriptive, functional or empty `alt` if decorative	1.1.1
Every field with a `<label>`; groups with `<fieldset>` and `<legend>`	1.3.1, 3.3.2
No link or button without an accessible name	2.4.4, 4.1.2
`<html lang="en">` and `lang` on passages in another language	3.1.1, 3.1.2
Focus visible by keyboard, no `outline: none` without a replacement	2.4.7
Sticky headers and banners do not hide the focus	2.4.11
No positive `tabindex`; HTML in logical order	2.4.3
Targets of 24 × 24 px or with enough spacing	2.5.8
Full pass with keyboard and screen reader	2.1.2 and others

Sources

If you want to review your site's accessibility and decide what to fix first, let's talk.