5 comprobaciones de accesibilidad que debes hacer antes de publicar

Antes de publicar, ejecuta estas cinco comprobaciones en este orden: recorre toda la interfaz con el teclado mediante la tecla Tab, realiza un análisis automatizado, verifica el HTML semántico y las etiquetas, comprueba el contraste de color y prueba con un zoom del 200 %.

Cualquiera que haya publicado un modal que atrapaba silenciosamente a los usuarios de teclado, y que semanas después se enteró por un informe de error, entiende por qué existe una lista como esta. Es el tipo de problema que nadie detecta con el ratón en la mano.

En conjunto, estas comprobaciones toman unos pocos minutos y detectan los fallos de accesibilidad más comunes. No hace falta experiencia previa, ni herramientas costosas, ni semanas de estudio. Esta es una lista de verificación de accesibilidad previa a la publicación que puedes ejecutar en cada pull request, diseñada para ser rápida y honesta sobre sus propias limitaciones. No hará que tu aplicación cumpla plenamente con WCAG 2.2 (el estándar actual, publicado como Recomendación del W3C en octubre de 2023 y adoptado como ISO/IEC 40500:2025), pero elimina los fallos que más perjudican a los usuarios reales. Hacer un poco es significativamente mejor que no hacer nada.

1. Recorre toda la interfaz con el teclado

La prueba real más rápida es gratuita y toma menos de un minuto: deja el ratón a un lado, recorre la página con la tecla Tab y confirma que puedes ver el foco, llegar a todos los elementos interactivos y salir de cada modal sin quedar atrapado. Fíjate en cuatro cosas: un indicador de foco visible en cada elemento, un orden de tabulación lógico, que cada botón, enlace y campo sea accesible, y que no haya trampas de foco en menús desplegables o diálogos.

Dos errores causan la mayoría de los fallos de teclado. El primero: controles personalizados que ocultaron el contorno nativo para aplicarles otro estilo. Si hiciste eso, vuelve a añadir un estilo :focus (o :focus-visible) visible:

.custom-checkbox input:focus-visible + .box {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

El segundo: un <div> clicable. Sustitúyelo por un <button>, que recibe el foco por defecto e incluye activación con Enter/Espacio y un rol de botón sin coste alguno. Un <div> no tiene nada de eso:

// Not reachable by keyboard
<div onClick={handleClick}>Save</div>
// Focusable and operable by default
<button onClick={handleClick}>Save</button>

Tu recorrido manual con Tab prueba el camino ideal que diseñaste. La reproducción de sesiones reales revela los fallos de teclado y de foco que solo aparecen en producción: un usuario que entra con Tab en un modal y no puede salir, o un foco que desaparece hacia el inicio del documento después de cerrar un diálogo, dejando perdido al usuario de teclado. La reproducción de sesiones te muestra dónde el comportamiento real del foco difiere de lo que tu análisis aprobó.

2. Ejecuta un análisis automatizado (Lighthouse + axe DevTools)

Un escáner encontrará entre un tercio y un 40 % de los problemas de accesibilidad de una página, así que una puntuación verde significa que has resuelto lo fácil (texto alternativo ausente, campos sin etiqueta, contraste bajo, un atributo lang faltante) y nada más. Ese rango es lo que suelen reportar los proveedores de pruebas, y es un piso más que un techo: el estudio de Deque de 2021 sostiene que si se cuenta el volumen de problemas encontrados, en lugar de la proporción de criterios de conformidad cubiertos, la cobertura automatizada se acerca al 57 %. En cualquier caso, los problemas detectados son los más económicos de corregir.

Ejecuta el análisis desde el panel Lighthouse en Chrome DevTools: abre DevTools, selecciona el panel Lighthouse, marca Accessibility y genera el informe. Una ejecución limitada a accesibilidad termina rápido. La auditoría de accesibilidad de Lighthouse se basa en el conjunto de reglas de código abierto axe-core de Deque, pero solo ejecuta parte de ese conjunto, así que añade la extensión axe DevTools, que ejecuta las reglas completas y se centra exclusivamente en accesibilidad. Corrige primero los problemas Critical y Serious.

3. Verifica el HTML semántico y las etiquetas

Los lectores de pantalla transmiten la estructura a través de la semántica, así que usa el elemento que corresponda a la tarea: <button> para acciones, <a href> para navegación, <ul>/<li> para listas, <nav> y <main> para regiones (landmarks), y encabezados en orden (h1 → h2 → h3, sin saltarse niveles). Cuando todo es un <div>, un lector de pantalla anuncia «grupo, grupo, grupo» y la página pierde su forma.

Cada campo necesita una <label> asociada; los botones con solo un icono necesitan un aria-label para que no se anuncien simplemente como «botón»:

<label htmlFor="email">Email</label>
<input id="email" type="email" />

<button aria-label="Copy to clipboard" onClick={copy}>
  <ClipboardIcon />
</button>

Un modo de fallo habitual en producción: una biblioteca de componentes de terceros con muy buen acabado entrega marcado inaccesible, como un acordeón o un combobox cuyo <input> no tiene <label>, así que el lector de pantalla no anuncia nada. Un componente bonito no es garantía de nada. Inspecciona el DOM que renderiza la biblioteca y verifica que las etiquetas están realmente ahí.

4. Comprueba el contraste de color y no dependas solo del color

Para el nivel AA, el texto necesita una relación de contraste de al menos 4.5:1 para texto normal y 3:1 para texto grande (18pt/24px, o 14pt/18.66px en negrita), según el Criterio de Conformidad 1.4.3 de las WCAG. Trata ambos números como mínimos estrictos. No se redondea nada hacia arriba, así que un valor medido de 4.499:1 no cumple. Los componentes de interfaz y los iconos con significado se rigen por un criterio distinto y más bajo, de 3:1 respecto a los colores adyacentes (SC 1.4.11 Contraste no textual), lo que significa que un color de texto que cumple no garantiza que tus botones y bordes de formulario también lo hagan.

Lighthouse señala muchos fallos de contraste de texto; el WebAIM Contrast Checker confirma las relaciones exactas. En concreto: #999999 sobre blanco da 2.85:1 y no cumple; #595959 sobre blanco da 7:1 y cumple.

El contraste no es toda la historia. Nunca señales un error únicamente con color. Un borde rojo es invisible para muchos usuarios con daltonismo, así que combínalo con un icono y texto para que el significado se conserve sin depender del color. Añade un mensaje «⚠ El correo electrónico es obligatorio» junto al campo, no solo un contorno rojo.

5. Amplía al 200 % y respeta la reducción de movimiento

Con un zoom del navegador al 200 %, nada debería solaparse, recortarse ni forzar el desplazamiento horizontal. Mantén pulsado Ctrl/Cmd y pulsa + hasta llegar al 200 %, y luego navega por la interfaz: los contenedores de ancho fijo y los tamaños basados en píxeles son los culpables habituales. Definir tamaños en rem y añadir overflow-wrap mantiene los diseños fluidos:

.container { max-width: 60rem; padding: 1rem; }
p { overflow-wrap: break-word; }

Después respeta prefers-reduced-motion: envuelve las animaciones no esenciales en una media query para que los usuarios que han pedido a su sistema operativo reducir el movimiento no se vean afectados. Este ajuste te pide eliminar el movimiento decorativo, no despojar a la interfaz de toda animación, así que deja funcionando todo lo que transmita significado (un indicador de carga, una barra de progreso).

@media (prefers-reduced-motion: reduce) {
  /* Target the decorative motion, not every animation on the page.
     Loading spinners and other essential feedback should keep moving. */
  .parallax,
  .carousel-autoplay,
  .hero-animation {
    animation: none;
    transition: none;
  }
}

Extra, 60 segundos: activa un lector de pantalla y escucha. En macOS, pulsa Cmd + F5 para VoiceOver; en Windows, instala el gratuito NVDA. Recorre la página con Tab y confirma que los encabezados, las etiquetas y los campos se anuncian con un significado real.

Publica y luego profundiza

Estas cinco comprobaciones son un piso, no un techo. Dejan fuera los patrones ARIA complejos, la gestión del foco en aplicaciones de página única y las tablas de datos accesibles, todo ello trabajo real para otro día. Elige tu próxima funcionalidad, ejecuta las cinco antes de abrir el PR y corrige los problemas Critical que encuentres. Cuando quieras ir más allá, WCAG 2.2, WebAIM y la documentación de accesibilidad de MDN son las fuentes principales que merecen tu tiempo. La accesibilidad es una dirección en la que avanzas, y publicar con estas cinco comprobaciones te acerca a ella hoy mismo.

Preguntas frecuentes

¿Qué relación de contraste necesito para la accesibilidad?

Para el nivel AA de las WCAG 2.2, el texto normal necesita una relación de contraste de al menos 4.5:1 respecto a su fondo, y el texto grande (18pt/24px, o 14pt/18.66px en negrita) necesita al menos 3:1, según el Criterio de Conformidad 1.4.3. Los componentes de interfaz y los iconos con significado se rigen por un criterio distinto, el 1.4.11, que exige 3:1 respecto a los colores adyacentes. Ninguno de los dos valores admite redondeo hacia arriba, así que un valor medido de 4.499:1 no cumple.

¿Las herramientas automatizadas de accesibilidad detectan todo?

No. Lighthouse y axe detectan entre un tercio y un 40 por ciento de los problemas de accesibilidad, principalmente los más sencillos, como texto alternativo ausente, campos sin etiqueta, contraste bajo y un atributo lang faltante. No pueden juzgar si el texto alternativo es significativo, si el orden de tabulación es lógico, ni si el foco se gestiona tras una interacción. Una puntuación verde en Lighthouse resuelve las correcciones económicas, no la página completa, así que acompaña cada análisis con pruebas de teclado y de lector de pantalla.

¿Cuál es la diferencia entre Lighthouse y axe DevTools?

La auditoría de accesibilidad de Lighthouse se basa en el conjunto de reglas axe-core de Deque, aunque solo ejecuta una parte, junto con auditorías de rendimiento, SEO y buenas prácticas, todo desde el panel Lighthouse de Chrome DevTools. La extensión de navegador axe DevTools ejecuta el conjunto completo de reglas de axe-core y se centra exclusivamente en accesibilidad. Usa Lighthouse para una revisión rápida y luego axe DevTools para una cobertura más profunda, centrada solo en accesibilidad.

¿Qué versión de las WCAG debo seguir en 2026?

Sigue las WCAG 2.2, el estándar actual. Se convirtió en Recomendación del W3C en octubre de 2023, se actualizó en diciembre de 2024 y ahora también es la norma ISO/IEC 40500:2025, idéntica a la versión de octubre de 2023. Las WCAG 3.0 existen únicamente como un Borrador de Trabajo que el W3C revisa periódicamente, con una Candidate Recommendation prevista para finales de 2027 y una Recomendación final que no se espera antes de 2028. Las WCAG 3.0 no rigen nada a día de hoy.