Lección 10 de 10 · Caso práctico · 25 min · Revisado el 26/10/2026
Caso práctico, ejercicios y lista de comprobación
Esta lección aplica el curso a un proyecto realista: un caso resuelto por fases, cinco ejercicios con solución, una lista de comprobación y recursos.
Caso práctico: la nueva venta de billetes de Autocares Ribera
Autocares Ribera (empresa ficticia, 180 personas en plantilla) opera líneas interurbanas de autobús y vende billetes en su web y en su app. Como servicio de transporte de viajeros dirigido a consumidores, su web, su app y sus billetes electrónicos entran en el ámbito de la Ley 11/2023 (PDF, se abre en una ventana nueva), aplicable desde el 28 de junio de 2025, y la empresa no puede acogerse a la exención de las microempresas. Quiere relanzar la compra de billetes en doce meses con la accesibilidad integrada en todo el proyecto.
Paso 1: descubrir y medir
Ficha de contexto: Ley 11/2023; WCAG 2.2 AA y EN 301 549 (PDF, se abre en una ventana nueva) (capítulo 11 para la app); matriz con NVDA, VoiceOver, TalkBack y zoom al 200 % y 400 %; terceros críticos: pago, mapa de paradas y cookies. La línea base sobre la web actual (muestra de 14 pantallas más el proceso de compra completo) da 57 hallazgos: 38 proceden de siete componentes de plantilla, 9 de contenido, 6 de terceros y 4 del flujo. Hay dos bloqueantes: el selector de asientos no funciona con teclado y el pago exige resolver un CAPTCHA visual sin alternativa.
Paso 2: decidir el camino
El frontal es antiguo y el rediseño está aprobado: se reconstruye. Pero faltan doce meses, así que en la web actual se atacan los bloqueantes en dos semanas: el CAPTCHA se sustituye por un método antiabuso sin desafío y se añade un botón «Asignar asiento automáticamente», operable con teclado, como alternativa provisional. El resto se registra como deuda.
Paso 3: requisitos, diseño y design system
El documento de requisitos incluye la cláusula de accesibilidad y los criterios de salida. La historia «Elegir asiento» lleva criterios observables: cada asiento se alcanza y se selecciona con teclado; el lector de pantalla anuncia número, posición (ventanilla o pasillo) y estado (libre, ocupado, seleccionado); el estado no depende solo del color; y la asignación automática sigue disponible. Antes de estimar, una spike de tres días prototipa el mapa con el patrón de cuadrícula de la APG (se abre en una ventana nueva). Los colores de los estados se definen como tokens con contraste de al menos 3:1 (1.4.11 Contraste no textual) y se acompañan de icono y texto.
Paso 4: construir y verificar
La plantilla de pull request incluye el bloque de accesibilidad. Playwright con axe-core analiza el proceso de compra en cada pull request después de abrir el mapa de asientos, provocar un error en los datos del viajero y llegar al pago; pa11y-ci rastrea cada noche 60 URL del entorno de pruebas. QA recorre la compra completa con los tres lectores de pantalla en cada versión candidata.
Paso 5: la puerta de salida
La evaluación previa al lanzamiento encuentra un defecto grave fuera de los flujos críticos: en «Mis viajes», el filtro por fechas no anuncia cuántos resultados quedan al aplicarse (4.1.3 Mensajes de estado). Se aprueba una excepción de 30 días con alternativa (la lista completa, ordenada por fecha), registrada como deuda. La información de accesibilidad del servicio se publica en las condiciones generales, en HTML accesible, y atención al cliente recibe su guion.
Paso 6: operar y aprender
En la tercera semana, una persona ciega escribe al canal de accesibilidad: el billete electrónico se descarga como un PDF que su lector de pantalla no puede leer. Triaje: grave (puede viajar mostrando el código, pero no comprobar fecha, hora ni asiento). Respuesta en 24 horas con los datos en el cuerpo del correo; corrección en tres semanas: el billete pasa a ser una página HTML accesible con el código y un PDF etiquetado. En la retrospectiva, la pregunta «¿en qué fase debió evitarse?» tiene una respuesta clara: en la definición, porque el billete electrónico, expresamente incluido en el ámbito de la ley, no figuraba en el inventario del proyecto.
Ejercicios de autoevaluación
Ejercicio 1
Reescribe este criterio de aceptación para que sea verificable: «El buscador de horarios será accesible».
Ver solución
Por ejemplo: (1) los campos de origen, destino y fecha tienen etiqueta visible asociada al campo; (2) las sugerencias del campo de origen se recorren con las flechas y el lector de pantalla anuncia cuántas hay y cuál está seleccionada; (3) al buscar, se anuncia el número de resultados sin mover el foco (4.1.3 Mensajes de estado); (4) la tabla de horarios tiene encabezados de columna y se lee correctamente con NVDA y VoiceOver; (5) todo funciona al 400 % de zoom sin desplazamiento horizontal, salvo el que necesite la propia tabla de horarios (1.4.10 Reajuste de los elementos).
Ejercicio 2
En una revisión de código encuentras este asiento del mapa. ¿Qué problemas tiene y cómo lo corregirías?
<div class="asiento libre" onclick="elegir(12)">12</div>Ver solución
No es operable con teclado (2.1.1 Teclado), no expone rol ni estado (4.1.2 Nombre, función, valor), «12» no informa de la posición y «libre» solo se transmite con color (1.4.1 Uso del color). Una corrección sencilla:
<button type="button" class="asiento" aria-pressed="false">
Asiento 12, ventanilla, libre
</button>Los asientos ocupados se marcan como no disponibles y el estado también se muestra con icono o texto. En mapas grandes, el patrón de cuadrícula de la APG evita cientos de pulsaciones de Tab.
Ejercicio 3
Tras una actualización del proveedor de pagos, el foco deja de verse en el formulario de la tarjeta. Nadie del equipo ha tocado código. ¿Qué mecanismo debió detectarlo y qué haces ahora?
Ver solución
Debió detectarlo la vigilancia de terceros (prueba manual rápida tras cada actualización anunciada) y, en parte, las pruebas sintéticas del flujo de compra en producción, aunque un foco invisible suele escapar a axe y requiere comprobación manual. Ahora: registrar la incidencia (2.4.7 Foco visible) como grave en un flujo crítico; ofrecer alternativa inmediata (compra por teléfono o en taquilla con el mismo precio); exigir al proveedor una corrección con fecha; y añadir al contrato una cláusula de aviso y prueba previa de las actualizaciones.
Ejercicio 4
El día antes del lanzamiento quedan abiertos tres defectos: (a) en Safari, el botón «Continuar» de los datos del viajero no se alcanza con teclado; (b) en las preguntas frecuentes, los encabezados saltan de nivel; (c) en el área de cliente, la factura se descarga como PDF sin etiquetar. ¿Se lanza?
Ver solución
No, mientras siga abierto (a): es un bloqueante en un flujo crítico y no admite excepción, así que se corrige antes de salir o se aplaza el lanzamiento. (b) es moderado: se registra como deuda. (c) es grave fuera del flujo crítico: puede salir con una excepción documentada, con la factura en formato accesible a petición como alternativa, responsable, fecha límite y aprobación de alguien ajeno al equipo.
Ejercicio 5
El equipo va a migrar 3.000 páginas de información de líneas a un nuevo gestor de contenidos. ¿Qué comprobaciones automatizarías antes y después?
Ver solución
Número de imágenes sin alt; estructura de encabezados por página; tablas de horarios sin th; vídeos sin pista de subtítulos; documentos enlazados sin versión accesible; fragmentos con atributo lang. Primero con una muestra y después en la migración completa; si alguna cifra empeora, se detiene y se revisa el mapa de campos.
Lista de comprobación final
- Ficha de contexto con marco legal, personas usuarias, plataformas y terceros.
- Matriz de tecnologías de apoyo acordada al inicio.
- Responsable principal asignado a cada grupo de criterios.
- Puertas de calidad definidas entre fases, con criterio y evidencia.
- Criterios de aceptación observables en cada historia.
- Diseños anotados con todos sus estados y revisados.
- Componentes del design system con patrón APG y pruebas.
- Bloque de accesibilidad en la plantilla de pull request.
- axe-core en los flujos críticos y rastreo nocturno con umbral.
- Registro de deuda con impacto, alcance y alternativa.
- Criterios de salida y procedimiento de excepciones aprobados.
- Declaración, información de accesibilidad o informe actualizados al lanzar.
- Soporte con guion de alternativas y escalado.
- Línea base y comparación antes y después en rediseños y migraciones.
Para seguir aprendiendo
- Accessibility Roles and Responsibilities Mapping (ARRM), W3C: reparto de responsabilidades por rol y criterio.
- WCAG-EM, metodología de evaluación del W3C: para la línea base y la evaluación previa al lanzamiento.
- ARIA Authoring Practices Guide (APG): patrones de componentes y su interacción con teclado.
- ATAG 2.0: pautas para evaluar herramientas de autor y gestores de contenidos.
- Directiva (UE) 2019/882, Acta Europea de Accesibilidad: servicios cubiertos e información que deben ofrecer.
Comprueba lo que has aprendido
Esta lección se puede leer libremente. Para hacer su test de 3 preguntas, los ejercicios prácticos con páginas reales, guardar tu avance y optar al examen y al certificado, matricúlate en el curso.
Matricularme · nivel 7 (179 €)