Aprender en el flujo de trabajo: laboratorios, revisiones y microformación

Lo que se aprende en un taller se pierde en pocas semanas si no se practica en el trabajo diario. La formación más eficaz en accesibilidad no ocurre solo en el aula: ocurre en la revisión de un pull request, en el mensaje de un linter, en un laboratorio con barreras preparadas o en una jornada en la que un equipo dedica la tarde a corregir. En esta lección verás cómo convertir el propio flujo de trabajo en un entorno de aprendizaje. La integración técnica de las pruebas en el ciclo de vida (axe-core, Playwright, criterios de aceptación) la tienes en el curso N7-C2; aquí la miramos con ojos de formador: cómo hacer que cada uno de esos puntos enseñe.

Laboratorios con barreras sembradas

Un laboratorio es un entorno de práctica (una página, una pequeña aplicación o una copia de un proceso real) en el que se han introducido a propósito barreras conocidas. El alumnado las busca, las diagnostica, nombra el criterio y las corrige; la persona formadora tiene el mapa de soluciones. Funciona porque reproduce el trabajo real en un entorno seguro, sin miedo a romper producción.

Cómo construirlo

• Parte de componentes propios: el laboratorio más útil es una copia del proceso de alta, del buscador de oficinas o del formulario de cita previa de la organización, no una web genérica.
• Siembra entre 10 y 15 barreras de tipos variados: algunas que detecta una herramienta automática y otras que solo se encuentran con teclado o lector de pantalla.
• Gradúa la dificultad: nivel 1 (alt ausente, contraste), nivel 2 (etiquetas, nombres de botones, orden del foco), nivel 3 (gestión del foco en un diálogo, mensajes de estado, componentes ARIA).
• Documenta la solución de cada barrera: criterio WCAG, impacto en personas usuarias, corrección y cómo comprobarla.
• Versiona el laboratorio para poder reutilizarlo y actualizarlo cuando cambie el design system.

<!-- Fragmento de laboratorio: cuatro barreras sembradas -->
<img src="tarifas-2026.png">
<input type="text" placeholder="Buscar oficina">
<a href="/condiciones">Pulse aquí</a>
<span class="icono-cerrar" onclick="cerrar()"></span>

<!-- Mapa de soluciones (solo para la persona formadora) -->
<!-- 1.1.1: tabla de tarifas como tabla HTML, no como imagen -->
<label for="buscar">Buscar oficina</label>
<input id="buscar" type="search" autocomplete="off">
<a href="/condiciones">Condiciones de la Cuenta Nómina</a>
<button type="button" aria-label="Cerrar aviso">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

Las cuatro barreras cubren 1.1.1 Contenido no textual (la imagen con datos), 3.3.2 Etiquetas o instrucciones y 1.3.1 Información y relaciones (el placeholder no es una etiqueta), 2.4.4 Propósito de los enlaces (en contexto) y 2.1.1 Teclado con 4.1.2 Nombre, función, valor (el icono que solo responde al ratón y no tiene nombre). Solo la imagen sin alt la marcará con seguridad cualquier herramienta automática; el campo con solo placeholder lo señalan unas herramientas y otras no (axe-core, por ejemplo, acepta el placeholder como nombre accesible), y las otras dos barreras obligan a probar.

Si quieres un recurso público para empezar, la Before and After Demonstration (BAD) del W3C ofrece un sitio de ejemplo en versión inaccesible y corregida, con las barreras documentadas.

La revisión como formación

Cada revisión de código o de diseño es una microsesión de formación individual. La diferencia entre un comentario que enseña y uno que solo bloquea es enorme:

Un comentario que enseña tiene cuatro partes: qué falla y qué criterio incumple, a quién afecta y cómo, propuesta de corrección y enlace a la guía interna. Al principio cuesta más escribirlo; a los pocos meses el equipo deja de cometer ese error y ya no hace falta. Para apoyarlo:

• Una plantilla de pull request con tres o cuatro preguntas de accesibilidad («¿lo has probado con teclado?», «¿los controles nuevos tienen nombre accesible?»).
• Revisión por pares en pareja mixta (una persona con más experiencia en accesibilidad y otra con menos) durante los primeros meses tras la formación.
• En diseño, revisiones de anotaciones (orden del foco, nombres, encabezados) antes de pasar a desarrollo, con el mismo formato de comentario.

Herramientas que enseñan

Linters, comprobadores y herramientas de prueba son también material formativo, porque hablan con la persona justo cuando comete el error:

• Linters de código: eslint-plugin-jsx-a11y avisa en el editor con reglas como jsx-a11y/alt-text, jsx-a11y/label-has-associated-control o jsx-a11y/click-events-have-key-events. Activa pocas reglas al principio y explícalas en la formación, para que el aviso se entienda.
• Resultados de axe-core: cada incidencia trae una descripción y un enlace de ayuda; en los informes de las pruebas automáticas añade un enlace a la entrada correspondiente de vuestra guía interna, en español y con ejemplos propios.
• Comprobadores ofimáticos: el comprobador de accesibilidad de Word o PowerPoint explica cada problema y cómo resolverlo; enseñar a usarlo en cada publicación forma al personal de contenidos de forma continua.

Microformación justo a tiempo

La microformación son piezas de 3 a 5 minutos que se consumen justo cuando se necesitan: antes de publicar el primer PDF, al usar por primera vez el componente de pestañas, al preparar la primera publicación con vídeo. Funcionan si están enlazadas desde el lugar donde surge la necesidad (la guía de componentes, el gestor de contenidos, la plantilla de pull request) y si cada una resuelve una sola tarea. Formatos que funcionan: un vídeo corto con subtítulos y la locución describiendo lo que se hace, una ficha de una página, un ejemplo de código copiable. Las horas de consulta de la oficina (ver la lección de comunidad interna) completan la microformación para las dudas que no caben en una ficha.

Jornadas de corrección intensiva

Una jornada de corrección (en inglés bug bash) reúne a un equipo durante media jornada o una jornada para buscar y corregir barreras en su producto, con apoyo de la oficina y, si es posible, de personas usuarias que validan las correcciones. Es formación aplicada con resultado visible el mismo día. Para que funcione:

• Alcance acotado: un proceso concreto (contratar, pedir cita, pagar), no «toda la web».
• Equipos mixtos de diseño, desarrollo y contenidos, con el protocolo de prueba y la plantilla de registro de la lección de dinámicas.
• Clasificación por severidad (bloqueante, grave, moderada, leve) antes de corregir, para empezar por lo que impide completar la tarea.
• Reconocimiento por impacto validado, no por número de incidencias: si se premia la cantidad, aparecen duplicados y barreras triviales.
• Cierre con lo aprendido: qué patrones se repitieron y qué entrada de la guía o qué módulo hay que reforzar.

Resumen

• Los laboratorios con 10-15 barreras sembradas, basados en componentes propios y con mapa de soluciones, permiten practicar diagnóstico y corrección sin riesgo.
• Un comentario de revisión que enseña dice qué falla y qué criterio incumple, a quién afecta, cómo corregirlo y dónde ampliar.
• Linters, resultados de axe y comprobadores ofimáticos enseñan en el momento del error si se introducen por tandas y enlazan a la guía interna.
• La microformación justo a tiempo y las jornadas de corrección con alcance acotado y reconocimiento por impacto mantienen la práctica entre sesiones.