Construir sitios web accesibles

La accesibilidad web no es opcional: es un requisito fundamental para crear experiencias digitales inclusivas. Más de mil millones de personas en todo el mundo viven con algún tipo de discapacidad, y el diseño accesible beneficia a todos, no solo a quienes tienen una discapacidad permanente.

Los subtítulos ayudan a quien ve un video en el tren. Un buen contraste ayuda a quien lee el teléfono bajo el sol. El soporte de teclado ayuda tanto al usuario avanzado como a la persona que este mes lleva la muñeca enyesada.

Esta guía cubre el estándar, los patrones que resuelven la mayoría de los problemas reales y una rutina de testing que encaja en el desarrollo habitual.

Entendiendo las WCAG

Las Pautas de Accesibilidad para el Contenido Web (WCAG) proporcionan un marco para que el contenido web sea perceptible, operable, comprensible y robusto. Estos cuatro principios, a menudo abreviados como POUR por sus siglas en inglés, sirven de base para todos los estándares de accesibilidad.

Entre los criterios de éxito clave se encuentran proporcionar alternativas textuales para el contenido no textual, garantizar relaciones de contraste de color suficientes, hacer que toda la funcionalidad esté disponible desde el teclado y ofrecer varias formas de navegar por el contenido.

Niveles y versiones

Cada criterio de éxito tiene asignado un nivel: A, AA o AAA. El nivel AA es el objetivo práctico para la mayoría de las organizaciones y el nivel al que remiten la mayoría de los requisitos de contratación y políticas de accesibilidad. El nivel AAA no es alcanzable para todo el contenido, así que trátelo como una meta ambiciosa para páginas concretas.

WCAG 2.2 se convirtió en Recomendación del W3C en octubre de 2023. Amplía la versión 2.1 en lugar de reemplazarla, por lo que el trabajo realizado con la versión anterior sigue siendo válido. Un criterio, 4.1.1 Procesamiento, se eliminó por obsoleto. Si está empezando un proyecto nuevo, apunte a WCAG 2.2 AA.

Qué añadió WCAG 2.2

Vale la pena conocer los nuevos criterios por su nombre, porque detectan problemas que las listas de verificación más antiguas pasan por alto:

• 2.4.11 Foco no oculto (mínimo), AA: un elemento con el foco no debe quedar completamente oculto por contenido creado por el autor, como un encabezado fijo o un banner de cookies.
• 2.5.7 Movimientos de arrastre, AA: cualquier acción que se realice arrastrando, como reordenar una lista o mover un control deslizante, necesita una alternativa con un solo puntero.
• 2.5.8 Tamaño del objetivo (mínimo), AA: los objetivos del puntero deben medir al menos 24 por 24 píxeles CSS o tener suficiente espacio a su alrededor, con algunas excepciones enumeradas.
• 3.2.6 Ayuda consistente, A: los mecanismos de ayuda que se repiten en varias páginas aparecen en el mismo orden relativo.
• 3.3.7 Entrada redundante, A: no obligue a las personas a volver a introducir información que ya proporcionaron en el mismo proceso.
• 3.3.8 Autenticación accesible (mínimo), AA: iniciar sesión no debe depender de una prueba de función cognitiva, como recordar o transcribir un código, salvo que exista una alternativa o asistencia (por ejemplo, permitir pegar y usar gestores de contraseñas).

Los otros tres criterios nuevos (2.4.12, 2.4.13 y 3.3.9) son de nivel AAA.

Patrones de accesibilidad comunes

Empiece con HTML semántico. Usar la jerarquía de encabezados correcta, los elementos de landmark y las etiquetas de formulario cubre una parte importante de los requisitos de accesibilidad. Los atributos ARIA deben complementar la semántica nativa de HTML, no reemplazarla.

Prefiera los elementos nativos

Un elemento button recibe el foco, se activa con Enter y Espacio, expone el rol de botón y participa en los formularios. Un div con un manejador de clic no hace nada de eso hasta que usted lo reconstruye a mano, y la mayoría de las versiones hechas a mano omiten algo.

<!-- Evitar: necesita role, tabindex y manejadores de teclado para acercarse a la paridad -->
<div class="btn" onclick="save()">Save</div>

<!-- Preferir: teclado, foco y semántica incluidos -->
<button type="button" onclick="save()">Save</button>

Lo mismo se aplica a los enlaces (a con href para la navegación, button para las acciones), a details y summary para el contenido desplegable y a dialog para los modales. Cuando ningún elemento nativo encaje, siga la WAI-ARIA Authoring Practices Guide en lugar de inventar un modelo de teclado propio.

Landmarks y encabezados

Los usuarios de lectores de pantalla suelen navegar por landmarks y encabezados en lugar de leer de arriba abajo. Dé a cada página un único main, envuelva la navegación del sitio en nav y use header y footer para los banners a nivel de página. Si tiene más de un nav, asigne a cada uno un aria-label para poder distinguirlos.

Los encabezados deben describir la estructura del contenido, no su tamaño visual. No salte de h2 a h4 porque el estilo más pequeño se veía mejor; cambie el estilo en su lugar.

Formularios

Cada campo necesita una etiqueta asociada mediante código. El texto de placeholder no es una etiqueta: desaparece al escribir y a menudo no cumple el contraste. Agrupe los controles relacionados con fieldset y legend, y vincule las indicaciones y los errores a sus campos:

<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email"
       aria-describedby="email-hint email-error" aria-invalid="true">
<p id="email-hint">We will only use this to send your receipt.</p>
<p id="email-error">Enter an email address in the format name@example.com.</p>

Los mensajes de error deben indicar qué salió mal y cómo corregirlo. Al enviar el formulario, mueva el foco a un resumen de errores o al primer campo no válido para que los usuarios de teclado y de lectores de pantalla no tengan que adivinar. El atributo autocomplete también importa: cumple el criterio 1.3.5 Identificar el propósito de la entrada y reduce la escritura para todos.

Gestión del foco

La gestión del foco es fundamental en las aplicaciones de una sola página. Cuando el contenido cambia dinámicamente, asegúrese de que el foco se mueva de forma predecible para que los usuarios de lectores de pantalla entiendan qué ha cambiado. Use regiones aria-live para anunciar las actualizaciones dinámicas.

Unas pocas reglas cubren la mayoría de los casos:

• Tras un cambio de ruta en el cliente, mueva el foco al encabezado principal o a la región principal de la nueva página, y actualice el título del documento.
• Cuando se abra un modal, mueva el foco a su interior y manténgalo ahí; cuando se cierre, devuelva el foco al control que lo abrió. El elemento nativo dialog abierto con showModal() resuelve buena parte de esto por usted.
• Nunca elimine el indicador de foco sin reemplazarlo. Use :focus-visible para mostrar un anillo claro a los usuarios de teclado sin mostrarlo en cada clic del ratón.
• Las regiones live deben existir en el DOM antes de que cambie su contenido, o muchos lectores de pantalla no anunciarán la actualización. Use aria-live="polite" para los mensajes de estado y reserve assertive para los realmente urgentes.

Color y contraste

El texto normal necesita una relación de contraste de al menos 4.5:1 con su fondo, y el texto grande (aproximadamente 18 pt, o 14 pt en negrita) necesita 3:1 (1.4.3). Los componentes de la interfaz de usuario y los gráficos con significado, como los bordes de los campos, los anillos de foco y las líneas de los gráficos, necesitan 3:1 frente a los colores adyacentes (1.4.11). Compruebe tanto el tema claro como el oscuro; una paleta que aprueba en uno a menudo falla en el otro.

El color nunca debe ser la única forma de transmitir información (1.4.1). Un borde rojo en un campo no válido debe ir acompañado de un icono o de texto; una serie de un gráfico debe poder distinguirse por su etiqueta, patrón o posición, además de por su tono.

Movimiento y zoom

Respete la preferencia de movimiento del usuario. Los efectos parallax grandes y las animaciones que se reproducen automáticamente pueden causar un malestar real a las personas con trastornos vestibulares.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

El contenido también debe reorganizarse sin desplazamiento horizontal a un ancho de 320 píxeles CSS (1.4.10), que es lo que ocupa una ventana de 1280 píxeles con un zoom del 400 %. Use unidades relativas para la tipografía, evite alturas fijas en los contenedores de texto y nunca desactive el zoom con pellizco en la etiqueta meta viewport.

Cómo probar su trabajo

Las herramientas automatizadas como axe-core y Lighthouse detectan solo una parte de los problemas de accesibilidad. Son excelentes en comprobaciones objetivas como etiquetas ausentes, ARIA no válido y fallos de contraste, pero no pueden decirle si el texto alternativo tiene sentido, si el orden del foco es lógico o si una interacción es comprensible. Las pruebas manuales con navegación por teclado y lectores de pantalla (VoiceOver, NVDA, JAWS) son esenciales para detectar el resto. Incluya a personas con discapacidad en su investigación de usuarios para obtener la retroalimentación más precisa.

Una rutina que encaja en el desarrollo

1. Linting y pruebas unitarias. Ejecute un linter de accesibilidad para su framework y añada comprobaciones automáticas con axe a las pruebas de componentes y end-to-end para que las regresiones hagan fallar la compilación.
2. Pasada con teclado. Desconecte el ratón. Recorra la página con Tab: ¿puede llegar a cada control y operarlo, el indicador de foco está siempre visible y el orden es lógico?
3. Zoom y reflujo. Aplique un zoom del 200 % y del 400 %. Nada debería superponerse, truncarse ni requerir desplazamiento en dos dimensiones.
4. Comprobación puntual con lector de pantalla. Elija el flujo crítico (registro, checkout, el panel principal) y complételo con un lector de pantalla. Preste atención a botones sin etiqueta, errores que no se anuncian y un orden de lectura confuso.
5. Comprobación de preferencias. Active el movimiento reducido, los colores forzados (Alto contraste de Windows) y el modo oscuro, y confirme que no desaparece nada importante.

Cómo hacer que perdure

La accesibilidad suele fallar por deriva: una funcionalidad añadida meses después rompe silenciosamente una trampa de foco. Algunos hábitos lo evitan:

• Incluya criterios de aceptación de accesibilidad en los tickets, no en un backlog de auditoría aparte.
• Integre los patrones en componentes compartidos para que los equipos de producto obtengan el comportamiento correcto por defecto.
• Publique una declaración de accesibilidad que indique con qué estándar cumple, qué problemas conocidos persisten y cómo pueden las personas reportar incidencias.

Construir sitios web accesibles es un compromiso continuo, pero las herramientas y los patrones disponibles hoy lo hacen alcanzable para cualquier equipo de desarrollo. Empiece con HTML semántico, pruebe con el teclado cada vez que publique y trate cada error de accesibilidad con la misma seriedad que cualquier otro defecto que deje fuera a los usuarios.