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

Esta lección aplica el curso completo a un encargo realista. Primero verás un caso resuelto paso a paso: la evaluación de la app de cita previa de un ayuntamiento, publicada en iOS y Android. Después tendrás cinco ejercicios con su solución, una lista de comprobación para tu próxima evaluación de app y recursos oficiales para seguir aprendiendo.

Caso práctico: la app de cita previa de Villaserena

El Ayuntamiento de Villaserena (municipio ficticio), obligado por el RD 1112/2018 (PDF, se abre en una ventana nueva), encarga la evaluación de su app «Villaserena Cita» antes de renovar la declaración de accesibilidad. La app permite pedir cita en las oficinas municipales, consultar y cancelar citas y ver un mapa de oficinas. Según el contacto técnico, la versión iOS está hecha en SwiftUI y la versión Android en Flutter.

Paso 1: plan, inventario y muestra

Fijas la referencia: EN 301 549 v3.2.1 (PDF, se abre en una ventana nueva), capítulo 11 y cláusulas aplicables de los capítulos 7 y 12, con WCAG 2.2 AA como bloque adicional acordado. Alcance: versión 3.1 (compilación 412), las dos últimas versiones mayores de cada sistema, un iPhone y un Android de Google como dispositivos principales y un Samsung de gama media como segundo dispositivo. La exploración da 22 pantallas. Muestra estructurada: 10 pantallas (inicio, acceso con código por SMS, ajustes, accesibilidad, selección de trámite, calendario, selección de hora, confirmación, «Mis citas» y mapa de oficinas con su lista), más 1 aleatoria sorteada sobre el resto (aviso de mantenimiento). Flujos críticos: pedir cita y cancelar cita. Pides una compilación Android de depuración con el depurador de semántica de Flutter disponible.

Paso 2: pasada automática

La auditoría del Accessibility Inspector y Accessibility Scanner devuelven dos tipos de aviso: siete iconos de 40 × 40 (dp en Android, pt en iOS) y el texto gris «Plazas libres» con un contraste de 3,1:1. Los iconos superan los 24 × 24 de 2.5.8, así que los registras como recomendación de plataforma. El contraste es un fallo de 11.1.4.3. Ninguna herramienta avisa de nada en el calendario.

Paso 3: protocolo manual y criterios móviles

• H-01 · Calendario (solo Android). TalkBack anuncia cada día solo con su número («14»), sin mes, sin rol de botón y sin indicar si quedan citas. El depurador de semántica muestra nodos con esa única etiqueta y el equipo confirma que cada día es un GestureDetector sin Semantics. En iOS, el calendario usa el selector de fecha del sistema y funciona. Impide pedir cita: crítico, 11.4.1.2 y 11.5.2.5.
• H-02 · Toda la app. No rota a horizontal en ninguna plataforma y no hay razón esencial: media, 11.1.3.4.
• H-03 · Barra de pestañas (iOS). Al 200 %, las etiquetas se cortan con puntos suspensivos y no hay visor de contenido grande: media, 11.1.4.4.
• H-04 · Confirmación (iOS). El aviso propio «Cita reservada» aparece y desaparece sin que VoiceOver lo anuncie: alta, 11.4.1.3.
• H-05 · Mis citas (ambas). Cancelar solo es posible deslizando la fila; los lectores ofrecen una acción, pero no hay alternativa para quien usa la app sin lector: alta, 11.2.5.1.
• H-06 · Acceso (ambas). El campo del código no se propone automáticamente desde el SMS y no admite pegar: 11.1.3.5 (alta) y, en el bloque WCAG 2.2, 3.3.8.
• Mapa. La lista de oficinas con dirección y horario es accesible, así que el mapa puede figurar como excluido en la declaración.

Paso 4: atribución y recomendaciones

H-01 se reproduce en el Samsung y en las dos versiones de Android: es un fallo de la app. Como el equipo Android trabaja en Flutter, la recomendación va en Dart:

// Incorrecto: zona táctil sin semántica
GestureDetector(onTap: () => elegir(dia), child: Text('${dia.day}'))

// Correcto: botón con fecha completa y estado
Semantics(
  button: true,
  label: '${formatoLargo(dia)}, ${libre ? "con citas libres" : "sin citas"}',
  selected: dia == seleccionado,
  child: GestureDetector(onTap: () => elegir(dia), child: Text('${dia.day}')),
)

Para H-04, la recomendación en iOS es enviar un anuncio de accesibilidad al mostrar el aviso; para H-05, un botón «Cancelar cita» en el detalle; para H-06, textContentType = .oneTimeCode en iOS y la marca de autocompletado equivalente en Android, sin bloquear el pegado.

Paso 5: informe y declaración

Resumen ejecutivo: no conforme en Android (flujo «pedir cita» no completable con TalkBack) y parcialmente conforme en iOS. La declaración, enlazada desde las dos tiendas, el menú «Accesibilidad» de la app y la web municipal, lista cada incumplimiento con su requisito y fecha prevista de corrección, el mapa como contenido excluido con su alternativa, el método (evaluación externa) y el canal de comunicación.

Ejercicios

1. Una app tiene 30 pantallas en el inventario y tu muestra estructurada reúne 15. ¿Cuántas pantallas aleatorias añades y cómo las eliges?

Ver solución

En torno al 10 % de la estructurada: 2 pantallas. Numeras las 15 que no están en la muestra, las sorteas con un generador de números aleatorios y documentas el método en el plan.

2. Accessibility Scanner avisa de que un botón de icono mide 40 × 40 dp. ¿Cómo lo registras?

Ver solución

Como recomendación de plataforma (Material propone 48 × 48 dp). Cumple 2.5.8 Tamaño del objetivo (mínimo), cuyo umbral es 24 × 24, y no es un incumplimiento de la EN 301 549 v3.2.1.

3. Una app bancaria muestra «Servicio de accesibilidad detectado» y cierra la sesión cuando TalkBack está activo. ¿Qué requisito incumple y qué recomiendas?

Ver solución

11.6.2, porque interfiere con las funciones de accesibilidad de la plataforma; severidad crítica. Recomiendas proteger las vistas sensibles con accessibilityDataSensitive en lugar de bloquear todos los servicios.

4. Una app hecha con Capacitor pasa Accessibility Scanner sin avisos. ¿Puedes concluir que el contenido es accesible?

Ver solución

No. El contenido es web dentro de una WebView: debes inspeccionarlo en remoto (chrome://inspect o Safari), evaluarlo con los criterios WCAG de contenido web y hacer las pruebas manuales con lector de pantalla. El contenedor nativo se evalúa con el capítulo 11.

5. Una fila se borra deslizando y VoiceOver ofrece la acción «Eliminar» en el rotor. ¿Cumple 2.5.1 Gestos del puntero?

Ver solución

No. La acción del lector solo ayuda a quien lo usa; una persona que maneja la app con un dedo o un puntero sin lector necesita una alternativa de un solo puntero sin trayectoria, como un botón o el menú que aparece al mantener pulsado.

Lista de comprobación final

• Plan validado: referencia, alcance, muestra y matriz de cobertura.
• Versión y compilación anotadas en cada evidencia.
• Tecnología de cada capa identificada.
• Lista de requisitos del capítulo 11 sin los criterios vacíos.
• Pasada automática hecha y avisos clasificados.
• Lector de pantalla en toda la muestra, en las dos plataformas.
• Texto al 200 % y al máximo, rotación y modo oscuro revisados.
• Gestos inventariados y alternativas comprobadas.
• Flujos críticos completados con cada tecnología de apoyo.
• Acceso, avisos y contenido de terceros evaluados.
• Hallazgos críticos y altos reproducidos en otro dispositivo.
• WCAG 2.2 presentado en un bloque aparte.
• Recomendaciones en el lenguaje del equipo.
• Declaración enlazada desde tiendas, app y web.

Para seguir aprendiendo

• WCAG2ICT: aplicación de WCAG 2.2 a las TIC no web (W3C)
• WCAG-EM: metodología de evaluación de conformidad (W3C)
• EN 301 549 v3.2.1 (ETSI, PDF)
• Real Decreto 1112/2018, texto consolidado (BOE)
• Probar la accesibilidad de una app Android (Android Developers)