Los 10 errores WCAG más comunes y cómo corregirlos

Introducción

Cada año, el informe WebAIM Million analiza la accesibilidad de las páginas de inicio de un millón de sitios web y los resultados son desalentadores: más del 95 por ciento presenta al menos un error de accesibilidad detectable de forma automática. Lo revelador es que los mismos errores aparecen una y otra vez. No se trata de fallos oscuros ni de criterios complejos de WCAG que requieran conocimientos avanzados. Son problemas básicos que cualquier desarrollador puede corregir en minutos una vez que sabe qué buscar.

En este artículo analizamos los 10 errores de accesibilidad más comunes según las WCAG 2.2, explicamos por qué cada uno constituye una barrera para las personas con discapacidad, mostramos ejemplos de código incorrecto y correcto, y proporcionamos instrucciones claras para corregirlos. Si eres desarrollador web, diseñador o responsable de un producto digital, esta guía te dará las herramientas prácticas para eliminar la mayoría de las violaciones de accesibilidad de tu sitio.

1. Texto alternativo faltante en imágenes (WCAG 1.1.1)

El criterio de conformidad 1.1.1 de WCAG, denominado "Contenido no textual" (Nivel A), exige que todo contenido no textual que se presente al usuario tenga una alternativa de texto que cumpla un propósito equivalente. Para las imágenes, esto se traduce en el atributo alt del elemento <img>.

Cuando una imagen carece de texto alternativo, los lectores de pantalla no tienen forma de comunicar qué representa esa imagen al usuario. En muchos casos, el lector de pantalla anuncia el nombre del archivo o la URL de la imagen, lo que resulta completamente inútil. Para una persona ciega, es como si esa parte de la página no existiera o, peor aún, como si contuviera ruido sin sentido.

Incorrecto:

<!-- Sin atributo alt: el lector de pantalla
anuncia "imagen" o el nombre del archivo -->
<img src="/fotos/equipo-trabajo.jpg">

<!-- Alt vacío en imagen informativa:
el lector de pantalla la ignora por completo -->
<img src="/graficos/ventas-2024.png" alt="">

Correcto:

<!-- Alt descriptivo para imágenes informativas -->
<img src="/fotos/equipo-trabajo.jpg"
     alt="Equipo de desarrollo reunido en la oficina
          revisando el prototipo del nuevo producto">

<!-- Alt vacío SOLO para imágenes decorativas -->
<img src="/decoracion/linea-separadora.svg" alt="">

<!-- Gráficos complejos: alt breve + descripción larga -->
<img src="/graficos/ventas-2024.png"
     alt="Gráfico de ventas trimestrales 2024"
     aria-describedby="desc-ventas">
<p id="desc-ventas">
  Las ventas crecieron de 120.000 en Q1 a 185.000 en Q4,
  con un pico de 210.000 en Q3.
</p>

Cómo corregirlo: revisa todas las imágenes de tu sitio y añade un atributo alt descriptivo a las que transmitan información. Las imágenes puramente decorativas deben tener alt="" (vacío, no ausente) para que los lectores de pantalla las ignoren. Para gráficos complejos, usa aria-describedby para enlazar una descripción detallada.

2. Contraste de color insuficiente (WCAG 1.4.3)

El criterio 1.4.3 "Contraste mínimo" (Nivel AA) exige una relación de contraste de al menos 4.5:1 entre el texto y su fondo para texto de tamaño normal, y de 3:1 para texto grande (18pt o 14pt en negrita). Este es el error más frecuente en la web: según WebAIM, más del 80 por ciento de las páginas analizadas lo presentan.

El contraste insuficiente afecta directamente a personas con baja visión, daltonismo o que navegan en condiciones de iluminación desfavorables (por ejemplo, al sol). Un texto gris claro sobre fondo blanco puede resultar imposible de leer para millones de usuarios, aunque a un diseñador le parezca estéticamente agradable.

Incorrecto:

/* Contraste de solo 2.5:1 — muy por debajo del mínimo */
.texto-sutil {
  color: #999999;
  background-color: #ffffff;
}

/* Texto sobre imagen sin capa de contraste */
.hero-text {
  color: #ffffff;
  background-image: url('/hero.jpg');
}

Correcto:

/* Contraste de 7:1 — cumple incluso AAA */
.texto-principal {
  color: #333333;
  background-color: #ffffff;
}

/* Contraste de 4.6:1 — cumple AA para texto normal */
.texto-secundario {
  color: #595959;
  background-color: #ffffff;
}

/* Texto sobre imagen con overlay de contraste */
.hero-text {
  color: #ffffff;
  background-image:
    linear-gradient(rgba(0,0,0,0.6), rgba(0,0,0,0.6)),
    url('/hero.jpg');
}

Cómo corregirlo: usa herramientas como el WebAIM Contrast Checker o las DevTools de Chrome (que señalan automáticamente los problemas de contraste) para verificar cada combinación de colores de tu sitio. Ajusta los tonos hasta alcanzar al menos 4.5:1 para texto normal y 3:1 para texto grande. No olvides verificar el contraste en estados interactivos como :hover y :focus.

3. Etiquetas de formulario ausentes (WCAG 1.3.1, 4.1.2)

Los criterios 1.3.1 "Información y relaciones" (Nivel A) y 4.1.2 "Nombre, función, valor" (Nivel A) exigen que cada campo de formulario tenga una etiqueta programáticamente asociada que describa su propósito. Esto permite que los lectores de pantalla anuncien el nombre del campo cuando el usuario navega hasta él.

Sin una etiqueta asociada, un usuario de lector de pantalla llega a un campo de texto y solo escucha "campo de edición, en blanco". No sabe si debe escribir su nombre, su correo electrónico, una contraseña o cualquier otra cosa. Depender únicamente de texto visual como placeholder no es suficiente porque el placeholder desaparece al escribir y no es anunciado de forma fiable por todos los lectores de pantalla.

Incorrecto:

<!-- Sin etiqueta: solo placeholder visual -->
<input type="email" placeholder="Tu correo electrónico">

<!-- Etiqueta presente pero NO asociada al campo -->
<label>Nombre completo</label>
<input type="text" id="nombre">

<!-- Div en lugar de label: no tiene asociación -->
<div class="etiqueta">Teléfono</div>
<input type="tel">

Correcto:

<!-- Etiqueta asociada mediante for/id -->
<label for="email">Correo electrónico</label>
<input type="email" id="email"
       placeholder="[email protected]">

<!-- Etiqueta envolvente (implícita) -->
<label>
  Nombre completo
  <input type="text" name="nombre">
</label>

<!-- Campo con etiqueta oculta visualmente
     pero accesible para lectores de pantalla -->
<label for="buscar" class="sr-only">
  Buscar en el sitio
</label>
<input type="search" id="buscar"
       placeholder="Buscar...">

Cómo corregirlo: asegúrate de que cada <input>, <select> y <textarea> tenga un elemento <label> asociado mediante el atributo for que coincida con el id del campo, o envuelve el campo dentro del <label>. Si el diseño no permite una etiqueta visible, utiliza la clase sr-only (visually hidden) para que solo sea accesible a lectores de pantalla.

4. Enlaces o botones vacíos (WCAG 2.4.4, 4.1.2)

Los criterios 2.4.4 "Propósito del enlace (en contexto)" (Nivel A) y 4.1.2 "Nombre, función, valor" (Nivel A) exigen que los enlaces y botones tengan un nombre accesible que describa su propósito. Un enlace o botón vacío es aquel que no tiene texto visible, texto alternativo ni atributo aria-label que los lectores de pantalla puedan anunciar.

Esto ocurre con frecuencia en botones que solo contienen un icono (como una hamburguesa de menú, un carrito de compras o un icono de cerrar) y en enlaces que envuelven una imagen sin texto alternativo. El usuario de lector de pantalla escucha "enlace" o "botón" sin ninguna indicación de qué hace ese elemento, lo que convierte la navegación en un juego de adivinanzas.

Incorrecto:

<!-- Enlace con imagen sin alt -->
<a href="/inicio">
  <img src="/iconos/logo.svg">
</a>

<!-- Botón solo con icono, sin nombre accesible -->
<button onclick="toggleMenu()">
  <i class="fa fa-bars"></i>
</button>

<!-- Enlace vacío: solo contiene un span decorativo -->
<a href="/perfil">
  <span class="avatar-circle"></span>
</a>

Correcto:

<!-- Enlace con imagen: alt describe el destino -->
<a href="/inicio">
  <img src="/iconos/logo.svg" alt="Ir a la página de inicio">
</a>

<!-- Botón con icono: aria-label describe la acción -->
<button onclick="toggleMenu()" aria-label="Abrir menú">
  <i class="fa fa-bars" aria-hidden="true"></i>
</button>

<!-- Enlace con texto oculto visualmente -->
<a href="/perfil">
  <span class="avatar-circle" aria-hidden="true"></span>
  <span class="sr-only">Ver mi perfil</span>
</a>

Cómo corregirlo: todo enlace y botón debe tener un nombre accesible. Si contiene texto visible, ese texto es el nombre. Si contiene solo un icono o una imagen, añade aria-label al enlace o botón, o proporciona alt en la imagen. Usa aria-hidden="true" en los iconos decorativos para evitar que los lectores de pantalla los anuncien de forma redundante.

5. Idioma del documento no declarado (WCAG 3.1.1)

El criterio 3.1.1 "Idioma de la página" (Nivel A) exige que el idioma predeterminado de cada página web pueda ser determinado programáticamente. Esto se logra con el atributo lang en el elemento <html>.

Los lectores de pantalla dependen del atributo lang para seleccionar el motor de voz correcto. Si una página en español no declara lang="es", el lector de pantalla puede intentar pronunciar el texto en español con un motor de voz en inglés, produciendo una pronunciación incomprensible. Además, los traductores automáticos de los navegadores usan este atributo para decidir si ofrecer la traducción de la página.

Incorrecto:

<!-- Sin atributo lang -->
<html>
  <head>
    <title>Mi sitio web</title>
  </head>
  ...
</html>

<!-- Idioma incorrecto: la página está en español
     pero declara inglés -->
<html lang="en">
  <head>
    <title>Bienvenido a nuestra tienda</title>
  </head>
  ...
</html>

Correcto:

<!-- Idioma declarado correctamente -->
<html lang="es">
  <head>
    <title>Bienvenido a nuestra tienda</title>
  </head>
  ...
</html>

<!-- Cambios de idioma dentro del contenido -->
<html lang="es">
  <body>
    <p>Este concepto se conoce como
       <span lang="en">responsive design</span>
       en la industria.</p>
  </body>
</html>

Cómo corregirlo: añade el atributo lang con el código de idioma correcto (por ejemplo, es para español, en para inglés, fr para francés) al elemento <html> de cada página. Si tu página contiene fragmentos de texto en otro idioma, envuélvelos en un elemento con el atributo lang correspondiente.

6. Encabezados vacíos (WCAG 1.3.1)

El criterio 1.3.1 "Información y relaciones" (Nivel A) exige que la estructura y las relaciones del contenido sean determinables programáticamente. Los encabezados (<h1> a <h6>) son fundamentales para esta estructura porque dividen la página en secciones lógicas que los lectores de pantalla presentan como un índice de navegación.

Un encabezado vacío (que no contiene texto ni nombre accesible) aparece en ese índice como un elemento sin contenido, lo que confunde y frustra a los usuarios que dependen de los encabezados para orientarse en la página. Los encabezados vacíos suelen aparecer cuando se usan elementos de encabezado únicamente para conseguir un estilo visual (tamaño de fuente grande, negrita) sin contenido real, o cuando el contenido se genera dinámicamente y falla la carga.

Incorrecto:

<!-- Encabezado completamente vacío -->
<h2></h2>

<!-- Encabezado que solo contiene espacios en blanco -->
<h3>   </h3>

<!-- Encabezado usado solo como separador visual -->
<h2 class="linea-separadora"></h2>

<!-- Encabezado con imagen sin alt -->
<h2><img src="/iconos/seccion.png"></h2>

Correcto:

<!-- Encabezado con texto descriptivo -->
<h2>Nuestros servicios</h2>

<!-- Si necesitas un separador visual, usa CSS en un div -->
<div class="linea-separadora" role="presentation"></div>

<!-- Encabezado con imagen: incluye alt o texto -->
<h2>
  <img src="/iconos/seccion.png" alt="">
  Planes y precios
</h2>

<!-- Jerarquía lógica de encabezados -->
<h1>Guía de accesibilidad</h1>
  <h2>Fundamentos</h2>
    <h3>¿Qué es WCAG?</h3>
    <h3>Niveles de conformidad</h3>
  <h2>Implementación</h2>

Cómo corregirlo: asegúrate de que cada elemento de encabezado contenga texto visible o un nombre accesible. Nunca uses encabezados como elementos decorativos. Si necesitas un estilo visual particular sin estructura semántica, usa un <div> o <span> con clases CSS. Mantén una jerarquía de encabezados lógica y secuencial (h1, h2, h3...) sin saltar niveles.

7. Título de página ausente (WCAG 2.4.2)

El criterio 2.4.2 "Página titulada" (Nivel A) exige que las páginas web tengan títulos que describan su tema o propósito. El título de la página es el contenido del elemento <title> dentro del <head> y aparece en la pestaña del navegador, en los resultados de búsqueda y, crucialmente, es lo primero que anuncia un lector de pantalla al cargar la página.

Sin un título descriptivo, un usuario de lector de pantalla que tiene múltiples pestañas abiertas no puede distinguir entre ellas. Los títulos genéricos como "Sin título" o repetitivos como "Mi sitio" en todas las páginas son casi tan inútiles como no tener título. Cada página debe tener un título único que refleje su contenido específico.

Incorrecto:

<!-- Sin elemento title -->
<head>
  <meta charset="UTF-8">
  <link rel="stylesheet" href="estilos.css">
</head>

<!-- Título genérico en todas las páginas -->
<head>
  <title>Mi sitio web</title>
</head>

<!-- Título vacío -->
<head>
  <title></title>
</head>

Correcto:

<!-- Título descriptivo y único por página -->
<head>
  <title>Planes y precios - Accessibility Checker</title>
</head>

<!-- Página de resultados con contexto dinámico -->
<head>
  <title>Resultados de accesibilidad para ejemplo.com
         - Accessibility Checker</title>
</head>

<!-- Patrón recomendado: Específico - General -->
<head>
  <title>Contacto - Accessibility Checker</title>
</head>

Cómo corregirlo: añade un elemento <title> descriptivo y único en el <head> de cada página. Usa el patrón "Contenido específico - Nombre del sitio" (por ejemplo, "Carrito de compras - Mi Tienda"). En aplicaciones de una sola página (SPA) y frameworks como Next.js o React, asegúrate de que el título se actualice dinámicamente con cada cambio de ruta.

8. Elementos inaccesibles por teclado (WCAG 2.1.1)

El criterio 2.1.1 "Teclado" (Nivel A) exige que toda la funcionalidad del contenido sea operable a través de una interfaz de teclado sin requerir tiempos específicos para las pulsaciones individuales. Este es un requisito absoluto: si un usuario no puede llegar a un elemento o activarlo con el teclado, ese elemento es inaccesible para personas que no pueden usar un ratón, lo que incluye a usuarios ciegos, personas con discapacidades motoras y usuarios de tecnologías de asistencia.

El problema suele aparecer cuando los desarrolladores crean elementos interactivos con <div> o <span> en lugar de usar los elementos HTML nativos correspondientes (<button>, <a>, <input>). Los elementos nativos son focusables y operables con teclado de forma predeterminada; los <div> no lo son.

Incorrecto:

<!-- Div con click handler: no es focusable ni operable
     con teclado -->
<div class="boton-comprar" onclick="comprar()">
  Añadir al carrito
</div>

<!-- Span como enlace: no se puede alcanzar con Tab -->
<span class="enlace" onclick="navegar('/ofertas')">
  Ver ofertas
</span>

<!-- Menú desplegable que solo se abre con :hover -->
<div class="menu-desplegable">
  <span>Categorías</span>
  <ul class="submenu">...</ul>
</div>

Correcto:

<!-- Usa <button> para acciones -->
<button class="boton-comprar" onclick="comprar()">
  Añadir al carrito
</button>

<!-- Usa <a> para navegación -->
<a href="/ofertas" class="enlace">Ver ofertas</a>

<!-- Menú que funciona con teclado y ratón -->
<button aria-expanded="false"
        aria-controls="submenu-cat"
        onclick="toggleMenu()">
  Categorías
</button>
<ul id="submenu-cat" role="menu">
  <li role="menuitem"><a href="/ropa">Ropa</a></li>
  <li role="menuitem"><a href="/calzado">Calzado</a></li>
</ul>

<!-- Si DEBES usar un div (raro), añade
     tabindex y manejo de teclado -->
<div role="button" tabindex="0"
     onclick="accion()"
     onkeydown="if(event.key==='Enter') accion()">
  Acción personalizada
</div>

Cómo corregirlo: usa siempre los elementos HTML semánticos nativos: <button> para acciones, <a> para enlaces de navegación, <input> y <select> para formularios. Si por alguna razón excepcional necesitas un elemento personalizado, añade tabindex="0" para hacerlo focusable, role para comunicar su función, y manejadores de teclado (Enter y Space) para hacerlo operable. Verifica la accesibilidad por teclado de tu sitio navegando con la tecla Tab sin usar el ratón.

9. Navegación por salto ausente (WCAG 2.4.1)

El criterio 2.4.1 "Evitar bloques" (Nivel A) exige que exista un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas. En la práctica, esto significa proporcionar un enlace de "Saltar al contenido principal" (skip link) que permita a los usuarios de teclado y de lectores de pantalla ir directamente al contenido de la página sin tener que navegar por la cabecera, el menú de navegación y otros elementos que se repiten en cada página.

Imagina que en cada página de un sitio tienes que escuchar o navegar por 20 enlaces de navegación antes de llegar al contenido real. Para un usuario de lector de pantalla, esto puede convertir una experiencia de 5 segundos con ratón en un proceso de más de un minuto. El skip link es una solución simple que elimina esta barrera.

Incorrecto:

<!-- Sin skip link: el usuario debe pasar
     por toda la navegación -->
<body>
  <header>
    <nav>
      <a href="/">Inicio</a>
      <a href="/productos">Productos</a>
      <a href="/servicios">Servicios</a>
      <a href="/blog">Blog</a>
      <a href="/contacto">Contacto</a>
      <!-- ... 15 enlaces más ... -->
    </nav>
  </header>
  <main>
    <h1>Contenido de la página</h1>
    ...
  </main>
</body>

Correcto:

<body>
  <!-- Skip link: primer elemento focusable de la página -->
  <a href="#contenido-principal" class="skip-link">
    Saltar al contenido principal
  </a>

  <header>
    <nav aria-label="Navegación principal">
      <a href="/">Inicio</a>
      <a href="/productos">Productos</a>
      ...
    </nav>
  </header>

  <main id="contenido-principal" tabindex="-1">
    <h1>Contenido de la página</h1>
    ...
  </main>
</body>

<!-- CSS para el skip link -->
<style>
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  padding: 8px 16px;
  background: #000;
  color: #fff;
  z-index: 100;
}
.skip-link:focus {
  top: 0; /* Se hace visible al recibir foco */
}
</style>

Cómo corregirlo: añade un enlace de salto como primer elemento focusable del <body> que apunte al id del contenido principal. Ocúltalo visualmente con CSS posicional y hazlo visible cuando reciba el foco con :focus. El destino del enlace (generalmente <main>) debe tener tabindex="-1" para que pueda recibir el foco programáticamente en todos los navegadores.

10. Uso incorrecto de ARIA (WCAG 4.1.2)

El criterio 4.1.2 "Nombre, función, valor" (Nivel A) exige que para todos los componentes de la interfaz de usuario, el nombre y la función puedan ser determinados programáticamente, los estados y propiedades puedan ser establecidos programáticamente, y los cambios en estos elementos sean comunicados a los agentes de usuario, incluidas las tecnologías de asistencia.

ARIA (Accessible Rich Internet Applications) es una herramienta poderosa para mejorar la accesibilidad de componentes complejos, pero su uso incorrecto es peor que no usar ARIA en absoluto. La primera regla de ARIA dice literalmente: "Si puedes usar un elemento HTML nativo con la semántica y el comportamiento que necesitas, úsalo en lugar de añadir un role de ARIA". Un ARIA mal aplicado puede crear una experiencia completamente confusa para los usuarios de lectores de pantalla.

Incorrecto:

<!-- role="button" en un enlace: confunde la semántica -->
<a href="/comprar" role="button">Comprar ahora</a>

<!-- aria-label contradice el texto visible -->
<button aria-label="Enviar formulario de contacto">
  Cancelar
</button>

<!-- aria-hidden="true" en contenido importante -->
<h1 aria-hidden="true">Título principal de la página</h1>

<!-- role incorrecto: un div no puede ser "checkbox"
     sin manejar estado y teclado -->
<div role="checkbox">Acepto los términos</div>

<!-- ARIA redundante: el lector ya sabe que es un nav -->
<nav role="navigation" aria-label="navigation">
  ...
</nav>

Correcto:

<!-- Usa el elemento nativo correcto -->
<button onclick="comprar()">Comprar ahora</button>

<!-- aria-label coherente con el contexto -->
<button type="submit">Enviar</button>

<!-- aria-hidden solo en contenido decorativo -->
<span aria-hidden="true" class="icono-decorativo">★</span>
<h1>Título principal de la página</h1>

<!-- Checkbox nativo: accesible por defecto -->
<label>
  <input type="checkbox" name="terminos">
  Acepto los términos
</label>

<!-- ARIA solo cuando aporta información adicional -->
<nav aria-label="Navegación principal">
  ...
</nav>
<nav aria-label="Navegación del pie de página">
  ...
</nav>

<!-- Widget personalizado con ARIA completo -->
<div role="checkbox"
     tabindex="0"
     aria-checked="false"
     aria-labelledby="label-terminos"
     onkeydown="if(event.key===' ') toggleCheck()"
     onclick="toggleCheck()">
  <span id="label-terminos">Acepto los términos</span>
</div>

Cómo corregirlo: sigue las cinco reglas de ARIA: (1) usa HTML nativo siempre que sea posible; (2) no cambies la semántica nativa a menos que sea necesario; (3) todos los controles ARIA interactivos deben ser operables con teclado; (4) no uses role="presentation" ni aria-hidden="true" en elementos focusables o visibles; (5) todos los elementos interactivos deben tener un nombre accesible. Valida tu uso de ARIA con herramientas como axe-core y prueba con un lector de pantalla real.

Preguntas frecuentes

¿Cuántos errores de accesibilidad puede detectar un escáner automático?

Las herramientas automatizadas de accesibilidad pueden detectar aproximadamente entre el 30 y el 40 por ciento de todos los problemas de WCAG. Son especialmente eficaces para encontrar los 10 errores descritos en este artículo: texto alternativo faltante, contraste insuficiente, etiquetas de formulario ausentes, enlaces vacíos, idioma no declarado, encabezados vacíos, títulos de página faltantes, problemas de teclado, navegación por salto ausente y uso incorrecto de ARIA. Para una evaluación completa, combina el escaneo automatizado con pruebas manuales y pruebas con usuarios con discapacidad.

¿Cuál es el error de accesibilidad más común en la web?

Según el informe anual WebAIM Million de 2024, el contraste de color insuficiente es el error de accesibilidad más frecuente, presente en más del 80 por ciento de las páginas de inicio analizadas. Le siguen el texto alternativo faltante en imágenes, las etiquetas de formulario ausentes, los enlaces vacíos y el idioma del documento no declarado. Estos cinco errores representan la gran mayoría de las violaciones de WCAG detectadas automáticamente.

¿Qué nivel de WCAG cubren estos 10 errores?

Los 10 errores descritos en este artículo corresponden a criterios de conformidad de WCAG 2.2 de Nivel A y Nivel AA. La mayoría son de Nivel A, que representa la accesibilidad mínima indispensable. Corregirlos es el primer paso para cumplir con el Nivel AA, que es el nivel de conformidad exigido por la mayoría de legislaciones como la ADA, la European Accessibility Act y la Section 508.

¿Cómo puedo verificar si mi sitio web tiene estos errores?

La forma más rápida es usar un escáner automatizado de accesibilidad como el de Accessibility Checker, que analiza tu página con axe-core y genera un informe detallado con la lista de violaciones, su gravedad y recomendaciones de corrección. También puedes usar extensiones de navegador como axe DevTools o WAVE, inspeccionar el código manualmente, navegar con el teclado y probar con lectores de pantalla como NVDA o VoiceOver.

¿Corregir estos 10 errores garantiza el cumplimiento total de WCAG?

No. Corregir estos 10 errores elimina las violaciones más frecuentes y mejora significativamente la accesibilidad de tu sitio, pero WCAG 2.2 Nivel AA contiene 58 criterios de conformidad en total. Muchos criterios requieren evaluación manual, como verificar que el texto alternativo sea significativo, que el orden de lectura tenga sentido lógico o que los widgets interactivos complejos sean realmente usables con tecnologías de asistencia. Estos 10 errores son el punto de partida esencial, no el destino final. Consulta nuestro blog de accesibilidad para guías más detalladas sobre criterios específicos de WCAG.