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

Esta lección reúne el curso en un caso realista, resuelto paso a paso, seguido de ejercicios de autoevaluación y una lista de comprobación para tus proyectos. Los nombres son ficticios; los problemas son los que aparecen una y otra vez en apps reales.

Caso práctico: la app municipal de incidencias

Un ayuntamiento de tamaño medio publica «Mi Barrio», una app nativa (SwiftUI en iOS y Jetpack Compose en Android) para comunicar incidencias en la vía pública: una farola fundida, un bache, un contenedor desbordado. El flujo tiene cuatro pantallas: categoría (cuadrícula de iconos), ubicación (mapa con un punto que se arrastra), detalles (foto, descripción y datos de contacto) y confirmación. Al ser una app de una administración pública, está sujeta al RD 1112/2018 (PDF, se abre en una ventana nueva) y debe cumplir la EN 301 549 v3.2.1 (PDF, se abre en una ventana nueva), cuyo capítulo 11 recoge los criterios WCAG 2.1 de nivel A y AA aplicados al software; el equipo trabaja ya con WCAG 2.2, que los incluye y añade otros como 2.5.7, 2.5.8 y 3.3.8. Un vecino que usa TalkBack informa por el mecanismo de comunicación de que «no hay forma de enviar una incidencia».

Paso 1: recorrer la tarea con tecnologías de apoyo

Antes de mirar el código, el equipo recorre el flujo completo con TalkBack y VoiceOver, con el texto al máximo y con un teclado Bluetooth, y anota lo que oye y lo que no puede hacer. Resultado:

Paso 2: priorizar

Primero lo que bloquea la tarea: la ubicación por arrastre y la confirmación inaccesible impiden enviar la incidencia, y los iconos sin nombre impiden siquiera empezar. Después lo que la dificulta: etiquetas, errores, texto grande y orientación. Es la misma lógica de impacto por frecuencia que viste en el nivel 4.

Paso 3: corregir

1. Categorías: cada celda pasa a ser un Button con Label("Alumbrado público", systemImage: …) en iOS y, en Android, un elemento selectable con Text real bajo el icono decorativo (contentDescription = null). El texto visible es ya el nombre accesible y Voice Control puede decirlo.
2. Ubicación: se añaden un campo «Escribe una dirección» con sugerencias, un botón «Usar mi ubicación» y los botones de zoom. El mapa queda como apoyo visual; la dirección elegida se muestra en texto y se anuncia. Se revisa que Tab salga del mapa.
3. Detalles: etiquetas visibles con OutlinedTextField(label = …) y texto encima del campo en iOS; textContentType(.telephoneNumber) y contentType = ContentType.PhoneNumber; errores en texto con semantics { error(…) } y anuncio del número de errores; la foto tiene un botón «Añadir foto (opcional)» con nombre y estado.
4. Texto grande: la pantalla se envuelve en un contenedor desplazable que respeta los insets del teclado; la etiqueta de la foto admite varias líneas.
5. Confirmación: la capa propia se sustituye por una pantalla nueva con título «Incidencia enviada», que recibe el foco y anuncia «Incidencia 2026-0412 registrada. Recibirás un aviso cuando se resuelva».
6. Global: se elimina el bloqueo de orientación y cada destino declara navigationTitle o paneTitle.

Paso 4: proteger y verificar

Se crea un componente CampoFormulario que exige etiqueta y tipo de contenido, se añaden pruebas de semántica para las celdas de categoría y una auditoría automática en las pruebas de UI de ambas plataformas. Finalmente, se repite el recorrido del paso 1 con TalkBack, VoiceOver, texto al máximo, teclado y Switch Access, y se contacta con el vecino que avisó para que lo compruebe. La declaración de accesibilidad de la app se actualiza con el resultado.

Ejercicios de autoevaluación

1. En iOS, una pantalla de ajustes muestra una lista de interruptores propios: un texto y una cápsula que cambia de gris a verde al tocarla. VoiceOver lee solo el texto. ¿Qué harías?

2. Una app de banca pide el código de verificación en seis campos de una cifra y no permite pegar. ¿Qué criterios están en riesgo y cuál es la solución?

3. Al cerrar una hoja inferior de filtros en Compose, TalkBack vuelve al principio de la pantalla. ¿Cómo lo corriges?

4. Las pruebas de UI de iOS localizan el botón de búsqueda con app.buttons["search_btn"], y ese texto es su accessibilityLabel. ¿Qué problema hay y qué cambiarías?

5. El gráfico de consumo de una app de una comercializadora eléctrica es una imagen sin descripción. Propón la solución mínima y la recomendable.

Lista de comprobación

• Cada control tiene nombre, rol, estado y valor en la API de la plataforma.
• Los botones de icono tienen nombre, y el nombre contiene el texto visible.
• Lo decorativo está oculto y las celdas compuestas son un solo elemento.
• Cada pantalla tiene un título anunciado y encabezados por secciones.
• El orden de recorrido sigue la lógica de la tarea.
• Los diálogos reciben el foco, ocultan el fondo y lo devuelven al cerrar.
• Todo gesto, arrastre o movimiento tiene alternativa de un toque.
• Los objetivos táctiles miden al menos 44 pt o 48 dp.
• El texto escala al máximo sin truncarse y la app gira libremente.
• Los campos tienen etiqueta visible y propósito de entrada declarado.
• Los errores se muestran en texto y se anuncian.
• El inicio de sesión admite gestores de contraseñas, pegado y biometría con alternativa.
• Mapas, gráficos y carruseles tienen alternativa accesible.
• Funciona con VoiceOver, TalkBack, Switch Access y teclado externo.
• Lint, pruebas de semántica y auditoría automática están en la integración continua.

Para seguir aprendiendo

• WCAG2ICT: guía del W3C para aplicar WCAG 2 a las TIC no web
• W3C WAI: accesibilidad móvil
• Android Developers: hacer apps más accesibles
• Apple: accesibilidad en sus dispositivos
• ETSI: EN 301 549 v3.2.1