Cómo corregir las 6 fallas de WCAG más comunes en cualquier sitio web

Abre cualquiera de los principales un millón de sitios web ahora mismo y hay una probabilidad de 96 sobre 100 de que encuentres una infracción de las WCAG que un escáner automatizado puede detectar en segundos. En un millón de páginas de inicio, se detectaron 56,114,377 errores de accesibilidad distintos — un promedio de 56.1 errores por página. Lo que hace que esto sea especialmente llamativo es que el 96% de todos los errores detectados se concentran en solo seis categorías, y esos seis tipos de error más comunes se han mantenido iguales durante los últimos siete años. Eso significa que corregir un puñado de problemas bien entendidos mejoraría drásticamente la accesibilidad en toda la web — y empieza por tu sitio.

Por qué los mismos seis fallos siguen apareciendo

Puede que te preguntes cómo, en una era de herramientas de desarrollo sofisticadas y un creciente escrutinio legal, los mismos errores persisten a gran escala año tras año. La respuesta es sistémica. Esta densidad de errores refleja lo profundamente que la inaccesibilidad se ha incorporado a las prácticas de desarrollo web. Los problemas de las plantillas se multiplican en cada página. Los fallos de los componentes se repiten en todo el sitio. Sin una atención deliberada a la accesibilidad, los flujos de trabajo de desarrollo estándar producen resultados sistemáticamente inaccesibles.

También existe una falsa sensación de progreso impulsada por la automatización. Las pruebas automatizadas solo detectan entre el 30–40% de los posibles fallos de las WCAG. Los sitios que aprueban las pruebas automatizadas pueden seguir teniendo problemas significativos de navegación por teclado, lectores de pantalla o accesibilidad cognitiva. Esto significa que incluso el pequeño porcentaje de sitios que parecen conformes sobre el papel probablemente se quedan cortos en la práctica.

Las implicaciones legales son reales y van en aumento. Según Seyfarth Shaw, se presentaron 8,800 demandas federales bajo el Título III de la ADA en 2024, con aproximadamente 2,452 dirigidas específicamente a la accesibilidad web. Los sitios de comercio electrónico enfrentan un riesgo desproporcionado — el 77% de las demandas por accesibilidad web se dirigen al comercio minorista en línea. El cumplimiento ya no es algo “agradable de tener”. Es un asunto de continuidad del negocio.

¿La cara alentadora de la moneda? Esta concentración tiene implicaciones prácticas. Las organizaciones pueden abordar la mayoría de sus problemas de accesibilidad centrándose en un puñado de tipos de problemas. El cumplimiento integral de las WCAG requiere atención a los 78 criterios, pero las mejoras de mayor impacto provienen de corregir estos fallos comunes. Así que trabajemos cada uno de ellos, con soluciones prácticas que puedes implementar hoy.

Fallo n.º 1 — Texto con bajo contraste (WCAG 1.4.3)

El texto con bajo contraste — texto que no tiene suficiente diferenciación de color respecto a su fondo — aparece en el 83.6% de las páginas de inicio estudiadas. Este es el fallo de WCAG más común, y afecta a más de cuatro de cada cinco sitios web. La WCAG 1.4.3 (Contraste mínimo) es brutalmente directa: el texto normal debe alcanzar una relación de contraste de al menos 4.5:1 con respecto a su fondo, y el texto grande (18pt o 14pt en negrita) debe llegar al menos a 3:1.

Los fallos de contraste suelen derivarse de decisiones de diseño que priorizan la estética sobre la legibilidad. El texto gris claro sobre fondos blancos parece sofisticado para diseñadores con visión perfecta. Para personas con baja visión, personas mayores o cualquiera que lea en una pantalla con reflejos, es ilegible. Las etiquetas secundarias, los placeholders de formularios, el texto del pie de página y los estados deshabilitados de los botones son los culpables habituales — se estilizan para que se vean sutiles y terminan siendo invisibles para una parte significativa de tu audiencia.

La solución casi siempre es un ajuste de CSS. Pasa tus pares de colores por un comprobador de contraste como la herramienta de contraste de WebAIM o el panel de accesibilidad de las DevTools del navegador, y luego ajusta el valor del primer plano o del fondo hasta que apruebe. Aquí tienes un patrón común que falla y cómo corregirlo:

/* Falla — relación aproximadamente 2.3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Pasa — relación aproximadamente 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

Para el texto de placeholder, recuerda que las WCAG lo tratan como texto real — no como una pista decorativa — así que también debe cumplir el umbral de 4.5:1. Evita depender únicamente del placeholder para transmitir instrucciones; acompáñalo siempre de un elemento <label> visible. Si usas imágenes de texto, no puedes corregir el contraste con CSS — necesitas regenerar esas imágenes, lo que es otra razón más para preferir texto HTML en vivo frente a texto incrustado en gráficos.

Fallo n.º 2 — Falta de texto alternativo en imágenes (WCAG 1.1.1)

Las imágenes sin texto alternativo aparecen en el 58.2% de las páginas de inicio. Cuando las imágenes carecen de texto alternativo, las personas usuarias de lectores de pantalla se encuentran con silencio o nombres de archivo sin sentido donde debería haber contenido significativo. Este problema no es nuevo. El texto alternativo ha sido un requisito fundamental de accesibilidad desde las WCAG 1.0 en 1999. Veinticinco años después, la mayoría de los sitios web siguen sin implementarlo de forma consistente.

La razón por la que persiste es una brecha en el flujo de trabajo, no una brecha de conocimiento. Esta tasa de fallos apunta a brechas sistemáticas en los flujos de trabajo de contenido. Quienes escriben y editan a menudo no saben que se necesita texto alternativo. Los sistemas de gestión de contenido no siempre lo solicitan. El control de calidad no detecta su ausencia. La solución, por tanto, tiene dos capas: una técnica y otra de proceso.

En el plano técnico, cada imagen significativa necesita un atributo alt que transmita la misma información que transmite la imagen. Las imágenes decorativas — adornos puramente visuales que no aportan información — deben recibir un alt="" vacío para que los lectores de pantalla las omitan por completo. Acertar con esta distinción es tan importante como añadir el atributo en sí. Un gran porcentaje de imágenes tienen texto alternativo ausente o inexacto. Algunas imágenes significativas no tienen ninguna descripción, mientras que las imágenes decorativas a menudo se tratan como contenido significativo. Ambos problemas rompen la conformidad con las WCAG para el contenido perceptible.

<!-- Imagen significativa: describe lo que transmite -->
<img src='team-photo.jpg' alt='El equipo de ingeniería de Accsible en su offsite de 2024 en Lisboa' />

<!-- Imagen decorativa: alt vacío, no se necesita role -->
<img src='wave-divider.svg' alt='' />

<!-- Imagen enlazada: describe el destino, no la imagen -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='Ver planes de precios' />
</a>

En el plano de proceso, actualiza las plantillas de tu CMS para que el campo alt sea obligatorio para las imágenes de contenido, y forma a cualquier persona que suba recursos. Herramientas automatizadas como Accsible pueden detectar imágenes con texto alternativo ausente o vacío en todo el sitio, proporcionando a tu equipo una lista auditable para trabajar de forma sistemática.

Fallo n.º 3 — Falta de etiquetas en campos de formulario (WCAG 1.3.1, 3.3.2)

El 48.6% de los sitios web tienen campos de formulario sin etiquetas. Este fallo es particularmente dañino porque los formularios son donde las personas usuarias realmente hacen cosas — registrarse, pagar, contactar, enviar solicitudes de soporte. Muchos formularios carecen de etiquetas accesibles, dependen solo de placeholders, no exponen instrucciones y mensajes de error, o no admiten el uso exclusivo del teclado. Dado que los formularios son esenciales para la mayoría de las experiencias digitales, estos fallos crean barreras de usabilidad graves.

El error más común es usar el texto del placeholder como sustituto de un <label>. Los placeholders desaparecen en cuanto la persona empieza a escribir, dejando a cualquiera con problemas de memoria a corto plazo — o simplemente a alguien que se distrae a mitad del formulario — sin idea de para qué sirve el campo. Los lectores de pantalla varían en cómo manejan los placeholders, y ninguno de los enfoques es tan fiable como una asociación correcta con una etiqueta.

El patrón correcto es usar un elemento <label> vinculado a su campo mediante atributos for e id coincidentes. Si por razones de diseño no es posible una etiqueta visible, usa aria-label o aria-labelledby — pero no recurras a ARIA cuando podrías usar simplemente un <label>.

<!-- Correcto: asociación explícita de etiqueta -->
<label for='email'>Dirección de correo electrónico</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Incorrecto: solo placeholder -->
<input type='email' placeholder='Dirección de correo electrónico' />

<!-- Aceptable cuando la etiqueta debe estar visualmente oculta -->
<label for='search' class='visually-hidden'>Buscar en el sitio</label>
<input type='search' id='search' name='q' />

Los mensajes de error también deben estar asociados de forma programática. Cuando un formulario se valida y encuentra un error, el mensaje debe vincularse al campo usando aria-describedby, e idealmente el foco debería moverse al primer campo no válido. Los errores de validación de formularios deben ser eficientes, intuitivos y accesibles — el error debe identificarse claramente, debe proporcionarse acceso rápido al elemento problemático y la persona usuaria debe poder corregir fácilmente el error y volver a enviar el formulario.

Fallo n.º 4 — Enlaces y botones vacíos (WCAG 2.4.4, 4.1.2)

El 44.6% de los sitios web tienen hipervínculos vacíos. Se encontraron botones vacíos en casi el 30% de las páginas, y esta cifra aumentó respecto al año anterior. Eso significa que las personas ciegas o con baja visión no entenderán el propósito de botones como enviar, restablecer, filtrar o buscar. Juntos, los enlaces y botones vacíos representan una de las experiencias más frustrantes para quienes usan lectores de pantalla — encontrarse con elementos interactivos sin nombre es como presionar una manija de puerta sin etiqueta y sin idea de adónde conduce.

Los enlaces vacíos se producen con mayor frecuencia cuando un icono o imagen es el único hijo de una etiqueta <a>, y no se proporciona ningún texto alternativo. Los botones vacíos aparecen cuando los botones solo con iconos — menús hamburguesa, iconos de cierre, botones para compartir en redes sociales — carecen de cualquier nombre accesible. Ambos son sencillos de corregir.

<!-- Enlace vacío — falla -->
<a href='/dashboard'><svg>...</svg></a>

<!-- Corregido con aria-label -->
<a href='/dashboard' aria-label='Ir al panel'><svg aria-hidden='true'>...</svg></a>

<!-- Botón vacío — falla -->
<button><svg>...</svg></button>

<!-- Corregido con texto visualmente oculto -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Cerrar menú</span>
</button>

Fíjate en el aria-hidden='true' en el SVG de cada ejemplo corregido. Cuando proporcionas una alternativa textual mediante aria-label o texto visualmente oculto, quieres suprimir el SVG del árbol de accesibilidad — de lo contrario, los lectores de pantalla pueden anunciar tanto la etiqueta como el título o la descripción propios del SVG, creando un doble anuncio confuso. El texto de enlace ambiguo — frases como “haz clic aquí”, “leer más” o “más información” — es un fallo relacionado. Otros problemas de hipervínculos, como el texto de enlace ambiguo, se encontraron en casi el 14% de las páginas de inicio, un aumento respecto al año anterior. Los hipervínculos con texto adecuado son importantes para que las personas usuarias sepan adónde las llevará un enlace. El nombre accesible de cada enlace debe tener sentido fuera de contexto porque quienes usan lectores de pantalla suelen navegar mostrando una lista de todos los enlaces de una página.

Fallo n.º 5 — Falta de idioma del documento (WCAG 3.1.1)

Este puede parecer menor en comparación con el contraste o el texto alternativo, pero alrededor del 16% de las páginas carecen de un idioma de documento establecido — y el impacto en las personas usuarias de lectores de pantalla es inmediato y chocante. Si la persona usuaria del lector de pantalla tiene instalado el paquete de idioma específico, el contenido se leerá correctamente. De lo contrario, sonará como un mal acento y puede que no sea comprensible.

La solución es un solo atributo HTML — literalmente una línea de código — y no hay excusa para omitirlo. Añade el atributo lang a tu elemento <html> con la etiqueta de idioma BCP 47 adecuada. Si secciones de tu página están en un idioma diferente al del conjunto de la página, añade también un atributo lang a esos elementos específicos.

<!-- Falta: sin atributo lang -->
<html>

<!-- Correcto: página en inglés -->
<html lang='en'>

<!-- Correcto: página en francés -->
<html lang='fr'>

<!-- Cambio de idioma en línea dentro de una página -->
<p>La expresión francesa <span lang='fr'>joie de vivre</span> significa un disfrute alegre de la vida.</p>

Si usas un CMS o un generador de sitios estáticos, el atributo lang debería establecerse en tu plantilla base. Revisa tu plantilla una vez, corrígela una vez, y cada página de tu sitio quedará corregida de inmediato. Este es quizá el arreglo con mayor retorno de esfuerzo de toda esta lista — un solo cambio en la plantilla elimina el problema en todo tu dominio.

Fallo n.º 6 — Navegación por teclado y gestión del foco inaccesibles (WCAG 2.1.1, 2.4.7)

La accesibilidad por teclado es donde la brecha entre las pruebas automatizadas y la usabilidad en el mundo real es más amplia. Las herramientas automatizadas pueden detectar algunos fallos de teclado — como elementos interactivos construidos con etiquetas no semánticas — pero no pueden simular el orden de tabulación, el atrapamiento del foco o la experiencia de navegar por un menú desplegable solo con las teclas de flecha. Los sitios con frecuencia eliminan los indicadores de foco predeterminados sin proporcionar alternativas, lo que hace que la navegación por teclado sea casi imposible. Esto afecta no solo a personas con discapacidades motoras, sino a cualquiera que prefiera la navegación por teclado, a personas usuarias avanzadas y a quienes usan dispositivos de conmutación.

Los fallos de teclado más comunes son: componentes interactivos personalizados construidos con etiquetas <div> o <span> que nunca reciben el foco; reglas CSS que eliminan el anillo de foco predeterminado del navegador con outline: none o outline: 0 sin reemplazarlo por algo igualmente visible; cuadros de diálogo modales que no atrapan el foco (de modo que las personas que usan teclado pueden tabular detrás de la superposición); y carruseles o acordeones que no se pueden operar sin ratón.

<!-- Botón personalizado inaccesible por teclado — falla -->
<div class='btn' onclick='doSomething()'>Enviar</div>

<!-- Correcto: usa un botón real -->
<button type='button' onclick='doSomething()'>Enviar</button>

<!-- Eliminar estilos de foco — incumple la WCAG 2.4.7 -->
* {
  outline: none; /* nunca hagas esto de forma global */
}

<!-- Mejor: estiliza el foco de forma visible manteniendo la estética -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

La pseudoclase :focus-visible es tu mejor aliada aquí. Muestra los estilos de foco cuando la persona navega con el teclado, pero los suprime para los clics de ratón — ofreciéndote una estética limpia sin sacrificar la accesibilidad. Para modales y paneles laterales, usa una utilidad de atrapamiento de foco que limite la navegación con tabulador al interior del cuadro de diálogo mientras esté abierto, y devuelva el foco al elemento que lo activó cuando se cierre. Las ventanas emergentes a menudo aparecen sin una gestión adecuada del foco, sin etiquetas o sin soporte para la navegación por teclado. Esto provoca interrupciones significativas, especialmente en flujos críticos como registros, inicios de sesión y procesos de pago.

Más allá de los componentes individuales, plantéate añadir un enlace para saltar la navegación — un enlace visualmente oculto que se vuelve visible al recibir el foco y permite a las personas que usan teclado saltar la navegación repetitiva e ir directamente al contenido principal. Los enlaces para saltar la navegación que permiten a las personas usuarias omitir la navegación repetitiva faltan en la mayoría de los sitios. Son tres líneas de HTML y un pequeño fragmento de CSS, y marcan una diferencia profunda para cualquiera que navegue por una página rica en contenido usando el teclado.

<!-- Coloca esto como el primer elemento dentro de <body> -->
<a href='#main-content' class='skip-link'>Saltar al contenido principal</a>

<!-- Luego en tu CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

Una nota sobre ARIA: úsala con cuidado

Muchos equipos recurren a los atributos ARIA (Accessible Rich Internet Applications) como una solución rápida para las brechas de accesibilidad. Los datos sugieren que esto fracasa más a menudo de lo que ayuda. Aproximadamente el 79% de las páginas de inicio evaluadas usaban ARIA, un aumento respecto al año anterior. Las páginas de inicio con ARIA tenían más del doble de errores que las páginas sin ARIA. ARIA en sí no es el problema — normalmente lo es el uso indebido o incorrecto de ARIA. Muchas personas desarrolladoras bien intencionadas creen que están haciendo el contenido más accesible al añadir ARIA, cuando en realidad a menudo lo hacen menos accesible.

El principio rector es simple: usa primero HTML semántico. Un <button> es mejor que un <div role='button'>. Un <nav> es mejor que un <div role='navigation'>. Los elementos HTML nativos vienen con comportamiento de teclado integrado, gestión del foco y roles ARIA implícitos que el marcado personalizado te obliga a replicar manualmente — y es en esa replicación manual donde se cuelan los errores. Reserva ARIA para los casos en los que HTML realmente no pueda expresar la semántica que necesitas, como regiones en vivo, widgets compuestos complejos o cambios de estado dinámicos.

Integrar la accesibilidad en tu flujo de trabajo

Corregir las infracciones existentes es necesario, pero evitar que aparezcan nuevas es lo que diferencia a los programas de accesibilidad maduros de las carreras puntuales por el cumplimiento. La accesibilidad no es una solución de una sola vez. Cada actualización de contenido, cambio de diseño o despliegue de código puede introducir nuevos problemas. Las seis categorías de fallos tratadas en esta guía tienden a ser problemas a nivel de plantilla — corrige la cabecera, el pie de página y los componentes compartidos y eliminarás el problema en cientos de páginas simultáneamente.

Integra el escaneo automatizado en tu pipeline de CI/CD para que las infracciones se detecten antes de llegar a producción. Herramientas como axe-core pueden integrarse en pruebas unitarias y suites de pruebas de extremo a extremo. Combina eso con recorridos periódicos manuales con teclado y pruebas con lectores de pantalla — VoiceOver en macOS e iOS, NVDA en Windows — porque las pruebas automatizadas pueden detectar errores de accesibilidad comunes, pero las pruebas manuales ayudan a cubrir las lagunas. Para equipos que necesitan una incorporación más rápida, un widget de overlay de accesibilidad como Accsible puede detectar y remediar una clase significativa de problemas en la capa de renderizado mientras se planifican y despliegan correcciones a más largo plazo a nivel de código.

Por último, aborda el punto de mayor apalancamiento en tu base de código: tus plantillas. La mayoría de los sitios web usan plantillas — una cabecera, un pie de página, una navegación y un diseño de página que se repiten en cada página. Los problemas en estas plantillas se multiplican en todo tu sitio. Corrígelas primero para lograr el máximo impacto. Una sola plantilla base corregida puede convertir 10,000 fallos de WCAG en cero con un solo despliegue.

Conclusiones clave

• Seis tipos de problemas dominan el panorama. El texto con bajo contraste, la falta de texto alternativo, los campos de formulario sin etiqueta, los enlaces y botones vacíos, la falta de idioma del documento y la navegación por teclado rota representan la abrumadora mayoría de los fallos de las WCAG. Corregir estas seis categorías ofrece resultados desproporcionados en relación con el esfuerzo.
• La mayoría de las correcciones son cambios de CSS o de una sola línea de HTML. Añadir lang='en' a tu etiqueta <html>, reemplazar outline: none por estilos :focus-visible y asociar etiquetas con campos son horas de trabajo, no meses — y aun así eliminan fallos que afectan a cada persona con discapacidad que visita tu sitio.
• Las plantillas son el lugar de corrección con mayor apalancamiento. Los errores de accesibilidad en componentes compartidos y plantillas de página se replican en todo tu sitio. Audita primero tu cabecera, pie de página, navegación y formularios — corregirlos ahí es corregirlos en todas partes.
• ARIA es una herramienta de último recurso, no una primera respuesta. Los sitios que dependen en gran medida de ARIA sin una base sólida de HTML semántico tienden a tener significativamente más errores de accesibilidad, no menos. Prefiere los elementos HTML nativos siempre que sea posible.
• El escaneo automatizado detecta menos de la mitad de los problemas reales. Complementa tus herramientas con recorridos manuales con teclado y pruebas con lectores de pantalla para encontrar los fallos que ningún escáner mostrará, incluidos los atrapamientos de foco, los problemas de orden lógico de tabulación y el contenido dinámico que no anuncia los cambios.