Accesibilidad (a11y)

Por qué es importante la accesibilidad

La accesibilidad consiste en desarrollar para personas que utilizan tecnologías de asistencia, navegan mediante el teclado, necesitan un mayor contraste o prefieren el movimiento reducido. Aproximadamente una de cada seis personas vive con alguna discapacidad, y casi todo el mundo se beneficia de la accesibilidad en algún momento: un brazo roto, una pantalla demasiado brillante o un tren ruidoso.

Además, es un requisito cada vez más común. La legislación y las normas de contratación en muchos países hacen referencia a las WCAG, por lo que la accesibilidad es una base profesional y no un simple complemento. Lo alentador es que la mayor parte se logra haciendo bien los conceptos básicos.

WCAG y POUR

Las Web Content Accessibility Guidelines definen el estándar. Sus cuatro principios son:

• Perceptible — el contenido puede ser percibido; por ejemplo, mediante alternativas textuales para imágenes y un contraste suficiente.
• Operable — todo funciona mediante el teclado y no requiere un puntero de precisión.
• Comprensible — el contenido y el comportamiento son predecibles y claros.
• Robusto — funciona con los agentes de usuario y las tecnologías asistivas actuales y futuras.

Cada principio tiene criterios de éxito comprobables en los niveles A, AA y AAA. La mayoría de los equipos apuntan al nivel AA.

El HTML semántico es la base

La mayor parte de la accesibilidad proviene del uso de los elementos correctos. Los elementos nativos ya incluyen roles, estados y comportamiento de teclado.

<!-- semantics.html -->
<header>
  <nav aria-label="Main">
    <a href="/">Home</a>
  </nav>
</header>
<main>
  <h1>Dashboard</h1>
  <button type="button" aria-expanded="false">Filters</button>
</main>

Un <button> es enfocable, responde a Enter y Espacio, y se anuncia como un botón. Un <div onclick> no cumple ninguna de estas condiciones. Es por esto que la guía de HTML semántico va antes que esta: la semántica es la mejora de accesibilidad más sencilla y eficiente que existe.

Soporte de teclado

Cada elemento interactivo debe ser accesible y operable únicamente con el teclado.

• Utiliza controles nativos, que son enfocables por defecto.
• Mantén un orden de tabulación lógico; este debe seguir el orden visual.
• Proporciona un skip link para que los usuarios puedan omitir la navegación repetitiva.
• Nunca atrapes el foco dentro de un componente sin una vía de escape.
• Muestra un indicador de foco claro y nunca elimines los outlines sin un reemplazo visible.

<!-- skip.html -->
<a href="#main" class="skip-link">Skip to content</a>
<main id="main" tabindex="-1">...</main>

Gestión del foco

El foco es el cursor del usuario que utiliza el teclado. Gestiónalo de manera deliberada:

• Cuando se abra un diálogo, mueve el foco hacia su interior y mantenlo atrapado allí.
• Cuando se cierre, devuelve el foco al elemento que lo abrió.
• En las navegaciones del lado del cliente, mueve el foco hacia el nuevo contenido.
• Tras errores de validación, pon el foco en el primer campo inválido.

Los diálogos modernos pueden utilizar el elemento <dialog> con showModal(), que gestiona gran parte de esto por ti.

Alternativas de texto

Las imágenes necesitan alternativas de texto que transmitan su propósito según el contexto.

• Las imágenes informativas llevan una descripción de lo que transmiten.
• Las imágenes decorativas llevan alt="" para que sean omitidas.
• Las imágenes funcionales, como un icono dentro de un enlace, describen la acción.
• Las imágenes complejas requieren una descripción más detallada en las cercanías.

El mismo principio se aplica a los medios: proporciona subtítulos para los videos, transcripciones para el audio y etiquetas para cada control de formulario.

ARIA, usado con cuidado

ARIA añade semántica que HTML no puede expresar, pero es fácil utilizarlo incorrectamente. La primera regla de ARIA es: no uses ARIA si ya existe un elemento nativo que cumpla la función. Un <div role="button"> es peor que un <button> en casi todos los sentidos.

Cuando realmente lo necesites:

• aria-label nombra un elemento que no tiene texto visible.
• aria-labelledby hace referencia a un texto visible que nombra al elemento.
• aria-describedby vincula un control con una pista o un mensaje de error.
• aria-expanded, aria-controls y aria-live describen el estado y las actualizaciones dinámicas.

Prueba ARIA con un lector de pantalla real; un ARIA incorrecto suele ser peor que no tener ninguno.

Color y contraste

El texto debe tener suficiente contraste respecto a su fondo:

• 4.5:1 para texto normal, 3:1 para texto grande en nivel AA.
• 3:1 para iconos, bordes e indicadores de foco.
• Nunca utilices el color como único medio para transmitir significado; añade texto, iconos o patrones.

Verifica el contraste con una herramienta y prueba tu diseño en escala de grises para detectar comunicaciones basadas únicamente en el color.

Movimiento y preferencias

Respeta las preferencias del usuario.

/* motion.css */
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Los efectos de parallax pronunciados y las animaciones de scroll son los culpables más comunes. Evita también la reproducción automática de medios con sonido y proporciona controles para cualquier elemento que tenga movimiento.

Pruebas

Las herramientas automatizadas detectan quizás un tercio de los problemas. Combínalas con pruebas manuales:

1. Ejecuta axe o Lighthouse para detectar violaciones comunes.
2. Navega utilizando únicamente el teclado, verificando el foco y el orden.
3. Aumenta el zoom al 200% y comprueba que nada se rompa o se superponga.
4. Prueba un lector de pantalla: VoiceOver, NVDA o Narrator.
5. Verifica el contraste y que no se utilice el color como único medio para transmitir significado.
6. Prueba los formularios con errores y contenido dinámico.

La guía de Testing Library muestra cómo las consultas accesibles integran la accesibilidad como parte de tu suite de pruebas.

Mejores prácticas

• Comienza con HTML semántico antes de añadir ARIA.
• Haz que todo sea operable mediante el teclado y con un foco visible.
• Proporciona alternativas de texto para todo el contenido multimedia significativo.
• Cumple con el contraste AA y nunca dependas únicamente del color.
• Gestiona el foco en diálogos, navegación y errores.
• Respeta la reducción de movimiento y evita la reproducción automática de multimedia.
• Realiza pruebas con herramientas automatizadas y tecnología asistiva real.

Errores comunes

• Usar divs como botones y enlaces.
• Eliminar los contornos de enfoque (focus outlines) por estética.
• Texto alternativo (alt text) ausente o poco útil.
• Implementar ARIA incorrectamente y romper la semántica nativa.
• Texto con bajo contraste y estados basados únicamente en el color.
• Ignorar a los usuarios de teclado en widgets personalizados.

Próximos pasos

La accesibilidad es una práctica, no una lista de verificación. Refuerza tus conocimientos con Semantic HTML, haz que tus formularios sean utilizables con Forms & Validation e intégralo en tus pruebas con Testing Library. Después, elige una página, navega por ella usando únicamente el teclado y corrige lo que encuentres.