Accesibilidad: empieza por una tarea

Una página accesible permite percibir la información, entenderla y actuar con distintas formas de interacción. Para una persona puede significar leer con ampliación; para otra, recorrer los controles con un pulsador o escuchar los encabezados. El trabajo consiste en resolver esas tareas completas, también cuando aparece un error.

Para quién: responsables de contenido, diseño y desarrollo. Usa esta guía para revisar una plantilla o un recorrido antes de publicar. Si buscas estados y componentes dinámicos, continúa después con WAI-ARIA.

Qué exige un estándar y qué debes decidir tú

Las WCAG son pautas de accesibilidad del contenido web. WCAG 2.2 organiza criterios verificables en niveles A, AA y AAA. Una referencia a AA incluye también los criterios A aplicables. El estándar establece resultados que debe alcanzar la interfaz; las técnicas y documentos explicativos ayudan a conseguirlos, pero no son una receta única ni sustituyen el texto normativo.

Separaremos tres cosas: requisito cuando identificamos un criterio; recomendación cuando proponemos una práctica útil; y decisión de diseño cuando escogemos una solución para un contexto. Un tamaño de letra agradable no demuestra conformidad y cumplir criterios no elimina la necesidad de investigar dificultades de uso.

Empieza por el documento: idioma, títulos y regiones

Declara el idioma principal, por ejemplo <html lang="es">, y marca los cambios de idioma que lo requieran. Escribe un título de página que identifique el contenido y su contexto. Los encabezados deben expresar la estructura: el título de la guía, sus apartados y los subapartados. Elegir un H4 porque se ve más pequeño mezcla semántica y presentación.

Para una página editorial, un H1 que identifica el recurso y H2/H3 subordinados ofrece una estructura fácil de mantener. Es una decisión práctica de esta publicación: no afirmamos que cualquier página con dos H1 incumpla automáticamente WCAG. Usa main para el contenido principal visible y nav para bloques de navegación relevantes; si hay varios, dales nombres que permitan distinguirlos.

<html lang="es">
  <head><title>Preparar una prueba de usabilidad | Mi publicación</title></head>
  <body>
    <a href="#contenido">Saltar al contenido</a>
    <header>
      <nav aria-label="Principal">
        <a href="/guias/">Guías</a>
      </nav>
    </header>
    <main id="contenido" tabindex="-1">
      <h1>Preparar una prueba de usabilidad</h1>
      <h2>Elegir una tarea</h2>
      <p>Define un resultado observable.</p>
    </main>
    <footer><a href="/contacto/">Contacto</a></footer>
  </body>
</html>

Ejemplo estructural, sin estilos: el enlace de salto debe quedar visible al recibir foco. Comprueba el destino y el orden real en el navegador; no basta con que el identificador exista. Las regiones permiten saltar entre áreas y los encabezados explorar el contenido dentro de ellas.

Enlaces, botones e imágenes con propósito

Un enlace con href lleva a un destino; un botón ejecuta una acción. Conserva esa diferencia aunque compartan aspecto. «Descargar guion de prueba» anticipa mejor el resultado que «Haz clic aquí». Si un icono acompaña texto suficiente, puede ser decorativo; si es el único contenido de un control, este necesita un nombre accesible que describa la acción.

Decide el texto alternativo según la función de la imagen en esa página. Una captura que muestra dónde se produce un error necesita explicar el hallazgo, no el nombre del archivo. Una imagen puramente decorativa puede llevar alt="". Un gráfico complejo necesita una explicación o tabla equivalente cercana; no comprimas todos sus datos en un alt interminable. Si la imagen es un enlace, su alternativa debe ayudar a reconocer el destino.

Prueba el teclado como un recorrido completo

1. Recarga la página y avanza con Tab, retrocede con Mayús+Tab y activa enlaces con Intro. Los botones nativos admiten Intro y Espacio.
2. Encuentra todas las acciones visibles: abrir el menú, buscar, desplegar ayuda, corregir un formulario y cerrar un diálogo.
3. Comprueba que el foco tiene un indicador visible y un orden comprensible, también tras aparecer o desaparecer contenido.
4. Sal de cada componente sin ratón. Una interacción que captura el teclado sin salida puede bloquear todo el recorrido.
5. Verifica que cabeceras, avisos o barras fijas no ocultan por completo el elemento enfocado; busca que tampoco lo tapen parcialmente como mejora adicional.

WCAG 2.1.1 exige funcionamiento mediante interfaz de teclado, con una excepción para funciones cuyo movimiento dependa de la trayectoria. WCAG 2.4.11, de nivel AA, se refiere a que el elemento con foco no quede completamente oculto por contenido creado por el autor. La visibilidad completa corresponde a un criterio más exigente. No confundas ese mínimo con una recomendación de dejar el foco parcialmente tapado.

Evita ordenar controles mediante valores positivos de tabindex. Corrige el orden del documento. Usa tabindex="-1" para un destino que deba recibir foco por código, sin convertir cada párrafo o encabezado en una parada de Tab. Para pestañas y diálogos, sigue el contrato de interacción del componente.

Contraste: mide combinaciones y estados

WCAG 1.4.3, nivel AA, pide una relación mínima de 4,5:1 para texto normal y 3:1 para texto grande. A estos efectos, grande significa al menos 18 puntos, o 14 puntos en negrita: aproximadamente 24 y 18,67 píxeles CSS. Hay excepciones, entre ellas logotipos y componentes inactivos. No redondees un resultado inferior para declararlo válido.

Comprueba el texto sobre su fondo real, incluidos enlaces, ayudas de formulario, estados al pasar el puntero y textos sobre imágenes. Los requisitos para información gráfica y partes necesarias de controles se tratan por separado en 1.4.11. Un borde decorativo tenue no equivale necesariamente a un control ilegible; importa qué información permite identificarlo. No uses solo rojo/verde para errores y aciertos: añade texto o una forma reconocible.

Ampliación, redistribución y espaciado

Son comprobaciones diferentes. El criterio 1.4.4 exige poder ampliar texto hasta el 200 %, con sus excepciones, sin perder contenido ni funcionalidad. El 1.4.10 trata la redistribución: para contenido que se desplaza verticalmente, verifica un ancho equivalente a 320 píxeles CSS. Una ventana de 1280 píxeles al 400 % puede servir para ese escenario, pero no sustituye todas las pruebas de ampliación.

A ese ancho, el artículo debería leerse en una columna sin desplazamiento horizontal de toda la página. Una tabla de datos que necesita dos dimensiones puede tener desplazamiento local; esa excepción no permite que el encabezado, los controles o todos los párrafos desborden. Las líneas largas de código merecen el mismo cuidado: desplazamiento local reconocible y utilizable con teclado, o ajuste de línea cuando preserve la comprensión.

WCAG 1.4.12 exige que no se pierda contenido o funcionalidad al aplicar determinados ajustes de texto: interlineado de 1,5 veces el tamaño de fuente; espacio posterior a párrafos de 2 veces; entre letras de 0,12 veces; y entre palabras de 0,16 veces. Son valores para probar tolerancia a la personalización, no una obligación de imponer ese aspecto inicial a todo el mundo.

• Usa unidades relativas para el texto y evita alturas fijas en cajas con contenido.
• Comprueba navegación, botones, tablas, notas y código después de ampliar, no solo el primer párrafo.
• Permite zoom del navegador y prueba también cambios de tamaño de texto.
• Revisa el contenido en vertical y horizontal; no impongas orientación salvo que sea esencial.
• En formularios, comprueba lo que queda visible cuando aparece el teclado virtual.

Movimiento, audio y vídeo

Respeta prefers-reduced-motion cuando haya desplazamientos animados, paralaje o transiciones que puedan provocar molestias. Reducir movimiento significa conservar información y funcionalidad con una presentación más estable. No basta con acelerarlo todo a una duración casi nula si una animación comunica un proceso o controla un estado.

En multimedia, planifica las alternativas antes de grabar. Los subtítulos incluyen habla e información sonora relevante; una transcripción facilita leer y localizar el contenido; la audiodescripción comunica información visual necesaria que no transmite la pista sonora. La alternativa exigible depende del tipo de medio, de si es grabado o en directo y del nivel evaluado. Una transcripción no sustituye siempre los subtítulos ni la audiodescripción.

Caso didáctico: un vídeo enseña a completar un campo y solo dice «pulsa aquí». Para quien no ve la pantalla, faltan el nombre del campo y la acción. Mejorar el guion original puede reducir la necesidad de añadir explicaciones después. Revisa también el propio reproductor: nombres, teclado, foco, volumen y activación de subtítulos.

Cómo organizar una comprobación útil

Elige una muestra que incluya familias de páginas y procesos completos: artículo, buscador sin resultados, formulario con errores, menú móvil y contenido incrustado. Registra URL, estado, pasos, resultado esperado, resultado observado y evidencia. Al corregir una plantilla, revisa también las páginas que la usan; al corregir un componente, repite sus estados, no solo su apariencia inicial.

Una puntuación de una herramienta describe su conjunto de comprobaciones y su configuración. No es un porcentaje de accesibilidad. Si no has probado un lector de pantalla, escribe «pendiente de comprobar con lector de pantalla» y no «compatible». Una declaración de conformidad requiere definir alcance, versión, nivel y demás condiciones; esta guía no certifica una web.

Fuentes y siguientes pasos

• W3C: WCAG 2.2 y requisitos de conformidad
• WAI: estructura de página
• WAI: alternativas para imágenes
• WAI: teclado
• WAI: foco no oculto
• WAI: contraste del texto
• WAI: ampliar texto
• WAI: redistribución
• WAI: espaciado de texto
• WAI: audio y vídeo accesibles
• WAI: evaluar accesibilidad
• Continuar con formularios