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

Es el momento de aplicar lo aprendido. En esta lección vas a analizar un proceso real de compra a través de los ojos, los oídos y las manos de cinco personas distintas, a relacionar cada barrera con su criterio y a decidir qué corregir primero. Después tienes ejercicios de autoevaluación con su solución y una lista de comprobación para tus propios proyectos.

Caso práctico: comprar un billete en Autocares del Levante

Autocares del Levante (empresa ficticia) vende billetes de autobús de largo recorrido en su web y en su app. Como servicio de transporte de viajeros de largo recorrido, sus canales digitales están dentro del ámbito de la Ley 11/2023 (PDF, se abre en una ventana nueva) (en el transporte urbano, suburbano y regional el alcance de la ley es mucho menor). La dirección quiere saber si «una persona con discapacidad puede comprar un billete». Tu tarea es responder con algo más útil que un sí o un no.

Paso 1. Definir la tarea y las personas

La tarea es comprar un billete de ida de Murcia a Madrid y llevarlo en el móvil. Para recorrerla eliges cinco personas con necesidades distintas, basadas en perfiles reales:

• Lucía, 34 años, ciega: VoiceOver en el iPhone y NVDA en el portátil.
• Antonio, 71 años, degeneración macular e hipoacusia: zoom al 200 % y texto grande en el móvil; audífonos.
• Raúl, 45 años, tetraplejia: control por voz en el ordenador.
• Marta, 28 años, sorda signante; el castellano escrito es su segunda lengua.
• Sara, 19 años, TDAH y dislexia: lee despacio y se distrae con facilidad.

Paso 2. Recorrer el proceso con cada persona

Recorres los siete pasos de la compra, incluida la ayuda, con las herramientas de cada perfil (teclado, NVDA, VoiceOver, zoom al 400 %, texto grande, control por voz y vídeo sin sonido) y anotas cada barrera:

Paso	Barrera detectada	A quién afecta	Criterio
Origen y destino	Las sugerencias del campo de búsqueda no se pueden elegir con teclado ni se anuncian	Lucía, Raúl	2.1.1, 4.1.2
Horarios	Tabla de horarios que obliga a desplazarse en horizontal con zoom; plazas libres solo en verde	Antonio; personas con daltonismo	1.4.10, 1.4.1
Asiento	Asientos de 18 píxeles que solo muestran un número; el lector dice «botón»	Lucía, Raúl, Antonio	4.1.2, 2.5.8
Datos del viajero	Errores del formulario solo en la parte superior y marcados en rojo	Antonio, Sara	3.3.1, 1.4.1
Pago	Temporizador de 10 minutos sin aviso; para identificarse y pagar hay que transcribir un CAPTCHA de letras distorsionadas sin alternativa	Sara, Raúl, Antonio, Lucía	2.2.1, 3.3.8, 1.1.1
Billete	Billete en un PDF sin etiquetar: el lector lo lee desordenado	Lucía	1.3.1
Ayuda	Vídeo «Cómo viajar» sin subtítulos; incidencias solo por teléfono	Marta, Antonio	1.2.2; canal alternativo

Paso 3. Separar lo que bloquea de lo que molesta

No todas las barreras pesan igual. Lo que impide terminar la tarea va primero: el autocompletado inaccesible (Lucía y Raúl no pueden ni empezar), los asientos sin nombre ni tamaño suficiente, el temporizador sin aviso y el CAPTCHA. El desplazamiento horizontal de los horarios y el color de las plazas son serios, pero Antonio consigue avanzar con esfuerzo. El vídeo sin subtítulos no impide comprar, aunque deja a Marta sin información sobre el viaje, y el teléfono como único canal le impide resolver cualquier incidencia.

Paso 4. Proponer soluciones

• Autocompletado con un patrón accesible: navegable con flechas y con las sugerencias anunciadas al lector.
• Asientos como botones de al menos 24 por 24 píxeles, con nombre completo («Asiento 12, ventanilla, libre») y estado legible sin color.
• Aviso antes de que caduque el tiempo, con opción de ampliarlo con un solo gesto, y datos conservados.
• Eliminar el CAPTCHA de transcripción o sustituirlo por un método sin prueba cognitiva.
• Errores junto a cada campo, con texto e icono, y foco movido al resumen de errores.
• Tabla de horarios que se reorganiza en tarjetas en pantallas estrechas, plazas con texto («3 libres»), vídeo subtitulado y canal de chat o formulario para incidencias.

Paso 5. Responder a la dirección

Tu respuesta no es «no es accesible», sino: «Hoy, una persona ciega o que usa control por voz no puede comprar un billete sin ayuda, y una persona mayor con baja visión o con dificultades de atención puede quedarse fuera por el temporizador. Corrigiendo cuatro componentes (buscador, mapa de asientos, temporizador y CAPTCHA) se desbloquea la compra para los cinco perfiles analizados; el resto de mejoras puede planificarse en una segunda fase». Una respuesta así se entiende, se prioriza y se puede presupuestar.

Ejercicios de autoevaluación

1. En la app de Autocares del Levante, el carrusel de destinos solo avanza deslizando el dedo. Lucía, con VoiceOver, no consigue pasar de la primera tarjeta. ¿Por qué ocurre y cómo se soluciona?

Ver solución

Con VoiceOver activado, el deslizamiento a un lado lo usa el lector para pasar al elemento siguiente, así que nunca llega al carrusel. Hay que añadir botones visibles «Anterior» y «Siguiente» con nombre accesible (o mostrar los destinos en una lista). Además, así se cumple 2.5.1 Gestos del puntero.

2. Reescribe con lenguaje respetuoso esta frase de una nota de prensa: «Gracias al nuevo servicio, los discapacitados y los invidentes que sufren problemas para comprar podrán hacerlo como las personas normales».

Ver solución

Una versión posible: «Con el nuevo servicio, las personas con discapacidad, incluidas las personas ciegas, podrán comprar sus billetes de forma autónoma, como el resto de la clientela». Se sustituyen «discapacitados», «invidentes», «sufren» y «normales», y el foco pasa de la persona a la autonomía.

3. La portada de un gimnasio muestra un vídeo de fondo que se reproduce solo, en bucle, con cortes rápidos y luces estroboscópicas. Indica dos criterios WCAG que pueden estar en juego y qué preferencia del sistema debería respetar.

Ver solución

2.3.1 Umbral de tres destellos o menos (si destella más de tres veces por segundo por encima de los umbrales, no puede publicarse) y 2.2.2 Poner en pausa, detener, ocultar (movimiento automático de más de cinco segundos sin control para detenerlo). Debería respetar la preferencia de reducir el movimiento (prefers-reduced-motion), mostrando una imagen fija.

4. El servicio de atención de una compañía eléctrica funciona solo con un asistente telefónico que pide «diga su número de cliente». ¿Qué necesidades funcionales de la EN 301 549 (PDF, se abre en una ventana nueva) quedan sin atender?

Ver solución

Al menos 4.2.6 Uso con capacidad vocal nula o limitada (personas con disartria, laringectomía o que no se comunican oralmente) y 4.2.4 Uso sin audición (personas sordas). También puede afectar a 4.2.10, por el tiempo de respuesta. La solución es un canal escrito equivalente: chat, formulario o correo.

5. Tienes 30 minutos para hacer una primera revisión del formulario de reserva de un hotel pensando en varios perfiles. ¿Qué cinco pruebas harías?

Ver solución

Una selección razonable: recorrerlo solo con el teclado (foco visible y sin trampas); escucharlo con NVDA o VoiceOver (nombres de campos y botones); ampliar al 400 % (reflow y mensajes de error cerca del campo); activar el texto grande en el móvil (textos que se cortan); y cronometrar el proceso buscando temporizadores, CAPTCHA y datos repetidos.

Lista de comprobación

• Defino la tarea completa antes de revisar páginas sueltas.
• Elijo varias personas con necesidades distintas, incluidas combinadas.
• Recorro el proceso solo con el teclado.
• Lo escucho con un lector de pantalla en el ordenador y en el móvil.
• Amplío al 400 % y activo el texto grande del móvil.
• Pruebo los botones principales con control por voz.
• Reviso los vídeos sin sonido y los avisos sin audio.
• Busco destellos, movimiento automático y animaciones al desplazarme.
• Compruebo que ningún gesto o movimiento del móvil carece de alternativa.
• Busco temporizadores, CAPTCHA y datos que se piden dos veces.
• Verifico que hay un canal de contacto que no depende de la voz.
• Reviso el lenguaje sobre discapacidad en textos y avisos.
• Priorizo lo que bloquea la tarea sobre lo que solo molesta.

Para seguir aprendiendo

• How People with Disabilities Use the Web (W3C WAI): perfiles, herramientas, estrategias e historias de personas usuarias.
• Web Content Accessibility Guidelines (WCAG) 2.2 (W3C): el texto oficial de los criterios citados en el curso.
• EN 301 549 v3.2.1 (ETSI): la norma europea, con las necesidades funcionales del apartado 4.2.
• Accesibilidad de Apple: descripción de VoiceOver, Zoom, Control por voz y Control por botón.
• Accesibilidad en Android (Android Developers): cómo funcionan TalkBack y el resto de servicios de accesibilidad en las apps.