Caso práctico, ejercicios y lista de comprobación

Esta lección reúne todo el curso en un caso resuelto paso a paso, cinco ejercicios con su solución y una lista de comprobación que podrás usar la próxima vez que una organización te pida «formar a la plantilla en accesibilidad».

Caso práctico: un banco que tiene seis meses para formar a sus equipos

El Banco Almadraba (ficticio) tiene 900 empleados, 120 de ellos en equipos digitales: 40 en desarrollo web, 15 en desarrollo móvil, 12 en diseño, 20 en contenidos y marketing, 10 en QA, 8 en producto y 15 en otras funciones técnicas. Además, 6 personas en compras y unas 300 en oficinas y atención telefónica. Su banca en línea y su app están sujetas a la Ley 11/2023 (PDF, se abre en una ventana nueva) desde el 28 de junio de 2025. Una auditoría externa ha detectado 140 incidencias, 18 de ellas bloqueantes en el alta de clientes y en las transferencias. Nadie ha recibido formación en accesibilidad. La dirección pide un plan para los próximos seis meses.

Paso 1. Diagnóstico inicial

En lugar de una encuesta de opinión, se usa una prueba práctica breve por perfil: los desarrolladores corrigen tres componentes del laboratorio; los diseñadores revisan dos pantallas; contenidos revisa una página y un PDF. Resultado: solo 6 de 40 desarrolladores corrigen el botón de icono; ningún diseñador comprueba el contraste del foco; el equipo de contenidos no conoce el etiquetado de PDF. Esto confirma las carencias que explicaban las incidencias de la auditoría.

Paso 2. Matriz e itinerarios con prioridad

Se prioriza a los equipos del alta de clientes y de transferencias, que concentran los bloqueantes.

Paso 3. Sensibilización de lanzamiento

Primera sesión con dirección: una persona ciega usuaria de lector de pantalla, colaboradora remunerada de una asociación, intenta hacer una transferencia en la app. Se atasca en el teclado de firma, cuyos dígitos no tienen nombre accesible. El mensaje se adapta a la audiencia: obligación exigible, clientes que no completan la operación y llamadas a la oficina que se podrían evitar. Ante la objeción «ya tenemos un widget de accesibilidad», se recorre la misma pantalla con el widget activado y la barrera sigue ahí.

Paso 4. Diseño de los módulos

Cada módulo se diseña con objetivos comprobables y evaluación primero. Ejemplo para desarrollo: «Dado el componente de selección de cuenta, la persona lo corrige para que sea operable con teclado y anuncie nombre, función y estado (2.1.1 y 4.1.2), y lo comprueba con NVDA y TalkBack». La evaluación es exactamente esa entrega, revisada con rúbrica. Se pilota con 8 personas, entre ellas un champion y un escéptico declarado.

Paso 5. Facilitación y formación de formadores

Como hay equipos en tres ciudades, la mitad de las sesiones son en remoto: sonido del sistema compartido, Visor de voz de NVDA visible, subtítulos automáticos y subtitulado profesional cuando se inscribe una persona sorda. Se forma a 8 champions en las cinco fases (dominio, facilitación, observación, coimpartición, autonomía) y cada módulo tiene su kit del formador.

Paso 6. Aprendizaje en el flujo

Se crea un laboratorio con 12 barreras sembradas sobre una copia del alta de clientes. Se añade una plantilla de pull request con cuatro preguntas de accesibilidad y se activan cinco reglas de eslint-plugin-jsx-a11y, una tanda por módulo impartido. A los cuatro meses se celebra una jornada de corrección del proceso de transferencias, con reconocimiento por impacto validado.

Paso 7. Materiales, evaluación y comunidad

Antes de lanzar el curso en línea para oficinas, se verifica el LMS con teclado y lector de pantalla y se amplía el tiempo de los test. La evaluación sigue los cuatro niveles: encuesta de reacción, entregas con rúbrica, revisión de pull requests reales a los dos meses y, como resultado, incidencias bloqueantes en los dos procesos críticos. La red de champions tiene 4 horas al mes reconocidas por sus responsables y una reunión mensual.

Resultado a seis meses (ilustrativo)

Los 18 bloqueantes iniciales quedan en 3; el porcentaje de componentes nuevos que pasan la revisión de accesibilidad a la primera sube de forma sostenida, y la oficina recibe cada vez más consultas antes de desarrollar que después. La dirección aprueba mantener el plan como formación de incorporación y reciclaje anual.

Ejercicios de autoevaluación

1. Un objetivo de un curso dice: «Conocer las WCAG 2.2 y su importancia». Reescríbelo para el perfil de contenidos.

2. Vas a hacer una demostración con lector de pantalla por videoconferencia a 30 personas. Enumera cuatro preparativos imprescindibles.

3. En una sesión, un jefe de proyecto dice: «Esto no nos afecta; nuestros clientes no tienen discapacidad». ¿Cómo respondes?

4. Un revisor escribe en un pull request: «Esto no es accesible». Reescribe el comentario para un botón de icono de búsqueda sin nombre.

5. Se organiza una jornada de corrección y se propone premiar al equipo que registre más incidencias. ¿Qué cambiarías?

Lista de comprobación

• Perfiles, número de personas y competencias observables definidos en una matriz.
• Diagnóstico inicial con prueba práctica, no solo con encuesta.
• Itinerarios priorizados por impacto en los productos críticos.
• Objetivos con verbo observable, condición y criterio en cada módulo.
• Evaluación diseñada antes que el contenido y módulo pilotado.
• Sensibilización con personas usuarias remuneradas y foco en las barreras.
• Mensajes adaptados a cada audiencia y respuestas preparadas a las objeciones.
• Demostraciones ensayadas, a velocidad reducida, con texto y foco visibles.
• Sesiones en remoto con sonido compartido, subtítulos y ajustes preguntados en la inscripción.
• Laboratorio con barreras sembradas y mapa de soluciones.
• Plantilla de pull request y comentarios de revisión que enseñan.
• Materiales y LMS verificados con teclado y lector de pantalla.
• Evaluación en cuatro niveles con indicadores ligados al producto.
• Champions con tiempo reconocido, kit del formador y relevo previsto.

Para seguir aprendiendo

• W3C WAI: Curricula on Web Accessibility, currículo modular con objetivos y evaluación.
• W3C WAI: How to Make Your Presentations Accessible to All, para sesiones y eventos.
• W3C WAI: Involving Users in Web Accessibility, sobre la participación de personas usuarias.
• W3C WAI: Before and After Demonstration (BAD), sitio de ejemplo para laboratorios.
• W3C WAI: Web Accessibility Perspectives, vídeos breves para sesiones de sensibilización.