Errores comunes de accesibilidad a evitar

Por qué siguen apareciendo los mismos problemas de accesibilidad

La mayoría de las barreras no son exóticas. Año tras año, las auditorías automáticas y manuales sacan a la luz la misma lista corta de errores: texto alternativo ausente, contraste bajo, campos de formulario sin etiqueta, trampas de teclado y estructura defectuosa. Se repiten porque se introducen de forma silenciosa — un desarrollador publica un nuevo componente, un responsable de marketing sube una imagen, un diseñador elige un color de marca — y nada en el flujo de trabajo habitual señala el problema. El resultado visual parece correcto para alguien que usa un ratón y una vista aguda, así que la barrera sale a producción.

Este catálogo recorre los incumplimientos de WCAG 2.2 más frecuentes que vemos en auditorías reales. Para cada uno encontrarás por qué importa, a quién afecta, el criterio de éxito correspondiente y una corrección concreta de antes y después. En conjunto, estos problemas representan la inmensa mayoría de las barreras que bloquean a las personas con discapacidad, y la inmensa mayoría de las quejas legales presentadas en virtud de la European Accessibility Act, la ADA y la Section 508.

Algo que conviene aclarar antes de la lista: las herramientas automáticas no pueden encontrar todos estos problemas. La investigación independiente demuestra de forma constante que incluso los mejores escáneres detectan de forma fiable solo el 30–40 % de los problemas de WCAG. Son excelentes para detectar atributos alt ausentes, fallos de contraste programáticos y etiquetas de formulario inexistentes, pero no pueden juzgar si un texto alternativo es preciso, si el orden de foco es lógico o si un widget personalizado realmente funciona con un lector de pantalla. Por eso, todo programa creíble combina el escaneo con la revisión manual. Nuestro software de escaneo de accesibilidad se encarga de la capa automatizable; las auditorías manuales y las auditorías realizadas por personas con discapacidad cubren el resto.

Una forma rápida de encontrar tu propio punto de partida antes de seguir leyendo: ve la página con las imágenes desactivadas, lee cada palabra como un único párrafo sin estructura e intenta completar cada tarea usando solo el teclado. Allí donde la experiencia se derrumbe, habrás encontrado una barrera.

Perceptible: contenido que las personas no pueden ver o leer

Texto alternativo ausente o inexacto en las imágenes

A quién afecta: personas ciegas o con baja visión que usan lectores de pantalla; cualquiera con una conexión lenta en la que las imágenes no se cargan.

Criterio WCAG: 1.1.1 Contenido no textual (Nivel A).

Las imágenes sin un atributo alt son invisibles para la tecnología de asistencia: el usuario puede ni siquiera saber que la imagen existe. Peor que un atributo ausente es uno inexacto: nombres de archivo como IMG_4821.jpg, palabras genéricas como «imagen» o cadenas saturadas de palabras clave engañan activamente a quien escucha.

La regla es simple pero depende del contexto. Las imágenes informativas necesitan una descripción concisa de su significado, no de su apariencia. Las imágenes decorativas que no aportan nada deben llevar un alt="" vacío para que los lectores de pantalla las omitan. Las imágenes funcionales — un icono que actúa como botón — deben describir la acción, no la imagen. Los elementos visuales complejos, como los gráficos, necesitan un alt breve más un equivalente de texto más largo cerca.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Las herramientas automáticas detectan al instante la ausencia de texto alternativo. No pueden decirte si el texto es correcto: eso requiere que una persona lea la página en su contexto.

Contraste de color insuficiente

A quién afecta: personas con baja visión, daltonismo o pérdida de visión relacionada con la edad; cualquiera que use una pantalla bajo la luz intensa del sol.

Criterio WCAG: 1.4.3 Contraste (mínimo), Nivel AA; además de 1.4.11 Contraste no textual para componentes de la interfaz.

WCAG 2.2 exige una relación de contraste de al menos 4,5:1 para el texto normal y 3:1 para el texto grande (aproximadamente 18 pt, o 14 pt en negrita). Los componentes de la interfaz y los gráficos significativos — bordes de campos de entrada, indicadores de foco, iconos que transmiten estado — deben alcanzar 3:1 respecto a su entorno. Los fallos de contraste están entre los problemas más comunes encontrados en toda auditoría a gran escala, y casi siempre se introducen en la fase de diseño.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Prueba toda la paleta, no solo el cuerpo del texto: el texto de marcador de posición, los estados deshabilitados que aún deben poder leerse, los mensajes de error y el texto colocado sobre fotografías son infractores frecuentes. Nunca dependas únicamente del color para transmitir significado (1.4.1): un borde rojo en un campo no válido debe ir acompañado de texto o de un icono.

Medios y movimiento que se reproducen automáticamente

A quién afecta: personas con trastornos vestibulares, discapacidades de atención o cognitivas, usuarios de lectores de pantalla cuya salida de audio queda ahogada, y cualquiera en un espacio compartido y silencioso.

Criterios WCAG: 1.4.2 Control de audio (Nivel A), 2.2.2 Pausar, detener, ocultar (Nivel A), 2.3.1 Tres destellos (Nivel A) y 2.3.3 Animación a partir de interacciones (Nivel AAA).

El audio o el vídeo que se reproduce automáticamente durante más de tres segundos debe ofrecer una forma evidente de pausarlo o silenciarlo. El contenido en movimiento, parpadeante o que se actualiza solo y dura más de cinco segundos — carruseles, banners animados, marquesinas — necesita un control de pausa accesible. El contenido que destella más de tres veces por segundo puede provocar convulsiones y debe evitarse por completo. Respeta la preferencia prefers-reduced-motion del usuario para atenuar la animación no esencial.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Operable: cosas que las personas no pueden usar

Inaccesibilidad por teclado y trampas de teclado

A quién afecta: personas con discapacidades motoras que no pueden usar un ratón, usuarios de lectores de pantalla (que navegan con el teclado) y personas que usan conmutadores o control por voz.

Criterios WCAG: 2.1.1 Teclado (Nivel A) y 2.1.2 Sin trampas de teclado (Nivel A).

Cada interacción — enlaces, botones, campos de formulario, menús, ventanas modales, selectores de fecha, arrastrar y soltar — debe ser totalmente operable solo con el teclado. La variante más dañina es la trampa de teclado: el foco entra en un componente (a menudo una ventana modal o un widget incrustado) y no puede salir, dejando al usuario atrapado en la página. Los widgets personalizados son los culpables habituales, porque los elementos nativos como <button> y <a> son operables con el teclado de forma predeterminada, mientras que las imitaciones basadas en <div> no lo son.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Recorre tus recorridos clave usando solo Tab, Mayús+Tab, las teclas de flecha, Intro, Espacio y Escape. Confirma que el foco siempre pueda avanzar y salir de cada componente, que Escape cierre las superposiciones y que nada requiera un puntero. Nuestro servicio de evaluación con lector de pantalla prueba exactamente estos flujos tal como los experimentan los usuarios reales de tecnología de asistencia.

Indicadores de foco ausentes o invisibles y orden de foco ilógico

A quién afecta: usuarios de teclado con visión, usuarios con baja visión y cualquiera que haya perdido la noción de dónde se encuentra en la página.

Criterios WCAG: 2.4.7 Foco visible (Nivel A) y 2.4.3 Orden del foco (Nivel A); 2.4.11 Foco no oscurecido (Nivel AA) en WCAG 2.2.

Un error «de limpieza» habitual es eliminar el anillo de foco predeterminado del navegador con outline: none y no reemplazarlo nunca. Los usuarios de teclado se quedan sin saber qué elemento está activo. Igual de dañino es un orden de foco que no sigue el orden de lectura visual y lógico, normalmente causado por valores de tabindex positivos o por un orden del DOM que difiere de la disposición renderizada.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 añade el 2.4.11: cuando un elemento recibe el foco, no debe quedar completamente oculto detrás de encabezados fijos, banners de cookies o widgets de chat. Abre una ventana modal, recórrela con el tabulador y confirma que el elemento enfocado nunca queda enterrado.

Enlaces y botones poco descriptivos

A quién afecta: usuarios de lectores de pantalla que abren una lista de todos los enlaces para escanear una página, y personas con discapacidades cognitivas.

Criterios WCAG: 2.4.4 Propósito del enlace (en contexto), Nivel A; 2.5.3 Etiqueta en el nombre, Nivel A.

Los usuarios de lectores de pantalla suelen navegar saltando entre enlaces fuera de contexto. Una página llena de enlaces «haz clic aquí», «leer más» y «saber más» se vuelve incomprensible cuando se lee como una lista. El texto del enlace debe describir su destino por sí solo. Lo mismo se aplica a los botones que solo tienen un icono, que necesitan un nombre accesible.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Navegación sobrecargada y sin forma de omitirla

A quién afecta: usuarios de lectores de pantalla, usuarios de teclado y personas con discapacidades cognitivas.

Criterio WCAG: 2.4.1 Evitar bloques (Nivel A).

Un mega-menú con decenas de enlaces obliga a los usuarios de lectores de pantalla y de teclado a recorrer toda la lista en cada página antes de llegar al contenido. Un enlace «Saltar al contenido principal» como primer elemento enfocable les permite saltar directamente por encima de los bloques repetidos. Agrupa los elementos relacionados, mantén los menús ligeros y asegúrate de que el enlace de salto se vuelva visible al recibir el foco.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Comprensible: contenido que confunde

Campos de formulario sin etiqueta o mal asociados

A quién afecta: usuarios de lectores de pantalla, personas con discapacidades cognitivas y usuarios de control por voz que se dirigen a los campos por su nombre.

Criterios WCAG: 1.3.1 Información y relaciones, 3.3.2 Etiquetas o instrucciones y 4.1.2 Nombre, función, valor (todos Nivel A).

Las entradas sin un <label> asociado de forma programática se anuncian como «editar texto, vacío»: el usuario no tiene ni idea de qué escribir. El texto de marcador de posición no es un sustituto: desaparece al introducir datos y suele fallar el contraste. Los campos obligatorios, las reglas de formato y los errores de validación también deben transmitirse en texto, no solo por color o posición.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Vincula los mensajes de error con su campo mediante aria-describedby, marca los campos no válidos con aria-invalid y asegúrate de que al enviar un formulario incompleto el foco se mueva al primer error.

Idioma de la página ausente

A quién afecta: usuarios de lectores de pantalla: el idioma incorrecto hace que el sintetizador pronuncie todo mal.

Criterios WCAG: 3.1.1 Idioma de la página (Nivel A) y 3.1.2 Idioma de las partes (Nivel AA).

Un solo atributo ausente arruina la pronunciación de toda una página. Declara el idioma principal en el elemento raíz y marca los pasajes en línea en otro idioma con su propio lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Jerarquía de encabezados incorrecta y puntos de referencia ausentes

A quién afecta: usuarios de lectores de pantalla que navegan por encabezados y regiones, y cualquiera que dependa de la estructura del documento.

Criterio WCAG: 1.3.1 Información y relaciones (Nivel A).

Los encabezados son el esquema de la página. Los usuarios de lectores de pantalla saltan de encabezado en encabezado para encontrar contenido rápidamente; cuando se omiten niveles, se usan solo para el tamaño de la fuente o están ausentes, esa navegación se derrumba. Cada página debe tener un único <h1> y una secuencia lógica e ininterrumpida de <h2>, <h3>, etc. Igual de importantes son las regiones de referencia — <header>, <nav>, <main>, <footer> —, que permiten a los usuarios saltar entre las áreas principales. Una página construida íntegramente con elementos <div> no ofrece ese mapa.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robusto: código que la tecnología de asistencia no puede interpretar

Widgets personalizados inaccesibles y uso indebido de ARIA

A quién afecta: sobre todo a usuarios de lectores de pantalla, y a cualquier tecnología de asistencia que dependa de un árbol de accesibilidad correcto.

Criterio WCAG: 4.1.2 Nombre, función, valor (Nivel A).

Los menús desplegables, pestañas, acordeones, cuadros combinados, ventanas modales y descripciones emergentes personalizados construidos con <div> y <span> no tienen función, estado ni comportamiento de teclado inherentes. Los desarrolladores recurren a ARIA para parchear esto, pero ARIA solo describe: no añade comportamiento, y un ARIA incorrecto es peor que ninguno. La primera regla de ARIA es preferir un elemento HTML nativo siempre que exista uno. Cuando debas construir un widget personalizado, implementa la interacción de teclado completa que especifican los patrones de autoría de ARIA y mantén aria-expanded, aria-selected y estados similares sincronizados con la realidad.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Estos son precisamente los problemas que los escáneres automáticos pasan por alto con más frecuencia. Un escáner ve un atributo aria-expanded y lo da por válido; solo una persona (o alguien que prueba con un lector de pantalla) puede confirmar que el valor realmente cambia cuando el menú se abre. Consulta nuestra guía de pruebas con lector de pantalla para saber cómo verificar el comportamiento de los widgets de principio a fin.

Una nota sobre los widgets de superposición

Es tentador instalar un «widget de accesibilidad» o superposición de una sola línea que promete cumplimiento instantáneo. Estas herramientas no corrigen los problemas anteriores: el texto alternativo sigue ausente en el código fuente, el contraste sigue fallando, el widget personalizado sigue sin funcionar. Las superposiciones no pueden remediar el código que causa las barreras, con frecuencia interfieren con la propia tecnología de asistencia de los usuarios y han aparecido en un número creciente de demandas por accesibilidad. La verdadera accesibilidad digital proviene de corregir el HTML, el CSS y el comportamiento subyacentes, no de enmascararlos.

Evita que estos problemas vuelvan a aparecer

Corregir una lista de errores una vez es necesario pero no suficiente; los mismos problemas reaparecen con la siguiente versión a menos que cambies cómo entregas. La solución duradera es integrar la accesibilidad en el flujo de trabajo:

Detecta pronto el 30–40 % automatizable integrando los escaneos en tu pipeline. La integración de accesibilidad en CI/CD hace que la compilación falle cuando se introduce una regresión, antes de que llegue a producción.
Cubre el resto con personas. Programa auditorías manuales de accesibilidad y auditorías realizadas por personas con discapacidad, que detectan barreras que ninguna herramienta puede encontrar.
Da a los equipos los instrumentos adecuados. El kit de herramientas de accesibilidad de QualiBooth y Agora ayudan a diseñadores y desarrolladores a probar mientras trabajan.
Conviértelo en un proceso, no en un proyecto. La consultoría de accesibilidad y la mejora del proceso de accesibilidad continuas arraigan los hábitos para que la calidad se mantenga con el tiempo.

Para una hoja de ruta de corrección paso a paso, empieza con nuestra guía sobre cómo hacer que tu sitio web cumpla con WCAG.

Por dónde empezar hoy

Con más de 1.300 millones de personas en el mundo que viven con algún tipo de discapacidad, el argumento empresarial a favor de la accesibilidad es claro, y desde junio de 2025, también lo es el argumento legal en virtud de la European Accessibility Act. Los problemas de este catálogo son los primeros que se examinan en cualquier queja o auditoría.

La forma más rápida de ver dónde estás es realizar un escaneo de URL gratuito: sin configuración, sin compromiso. Cuando estés listo para ir más allá de lo que la automatización puede alcanzar, solicita una demo y te mostraremos cómo un programa combinado de automatización y revisión manual cierra la brecha restante.