Evaluación de Accesibilidad de Radar COVID (I)

En esta ocasión os traigo la evaluación de accesibilidad de la aplicación móvil Radar Covid que hace unas pocas semanas lanzó el Ministerio de Sanidad con el propósito de mejorar el rastreo de personas con Covid y sus contactos estrechos. Podéis acceder directamente a las Conclusiones sobre la Accesibilidad de Radar COVID.

La aplicación móvil Radar COVID está disponible tanto en iOS como en Android y podéis descargarla desde las stores correspondientes:

Si queréis saber qué es un contacto estrecho, podéis consultar cómo lo ha definido el Ministerio de Sanidad a continuación.


Evaluación de Accesibilidad de Radar COVID

A continuación podéis encontrar una tabla con los 50 criterios AA de WCAG 2.1 junto con el resultado de su evaluación tanto para la versión iOS como para la versión Android así como explicaciones para entenderla.


La primera vez que lanzamos la aplicación Radar COVID se nos muestra una pantalla de bienvenida en la que se nos invita a seleccionar el idioma que queremos que tenga la interfaz, dándonos como opciones “Castellano” (por defecto), “Catalán” e “Inglés”.

En este primer punto se aprecian ya las primeras diferencias entre la versión iOS y Android, ya que mientras que en la versión Android el control destinado a elegir el idioma es detectado por las tecnologías de apoyo como un control de selección, en iOS es detectado como un botón estándar. No obstante, eligiendo “Castellano” y siendo ésta la opción por defecto, el botón descrito como “Continuar” del final de la pantalla se encuentra habilitado para poder ejecutarlo.

Cuando ejecutamos este botón “Continuar” de la pantalla de bienvenida, accedemos a una segunda pantalla en la que debemos aceptar la política de privacidad, aspecto, el de la privacidad, especialmente importante en una app de estas características.

Sin embargo, en este punto aparece la barrera de accesibilidad más grave, por resultar crítica y bloqueante para un amplio abanico de personas con discapacidad; y es que el control de selección (cuadro en el que debemos activar un check) para indicar que aceptamos la política de privacidad de Radar COVID no puede ser accedido por las tecnologías de apoyo de los dispositivos iOS, lo que implica que el botón “Continuar” de esta segunda pantalla no se habilite para poder ejecutarlo y acabando en este paso la posibilidad de que un gran número de personas puedan utilizar la aplicación RADAR Covid de manera autónoma, teniendo que recurrir a una persona sin discapacidad para realizar este paso tan sencillo.

En la versión Android, por su parte, las tecnologías de apoyo sí pueden acceder al control para aceptar la política de privacidad y ejecutar por tanto el botón “Continuar”.

Superando este paso en ambas versiones, accedemos a una pantalla con un menú inferior con tres pestañas del que cabe destacar:

  • Cada pestaña está representada por un icono gráfico carente de descripción textual: las personas ciegas no saben para qué sirve cada pestaña.
  • El contraste entre el color de los iconos y del fondo no cumple el ratio mínimo de contraste: personas con baja visión no pueden distinguir qué es cada pestaña; tampoco una persona que esté usando la aplicación con el sol de espaldas.
  • En la versión Android, además, los controles no están identificados semánticamente como pestañas ni como ningún control activable: las personas ciegas no lo distinguen de texto plano o información decorativa.

La pestaña más relevante es “Inicio” que está representada por el icono de una casita y que es la que está activa por defecto. en esta pestaña se nos muestra nuestro nivel de exposición al COVID, un control para desactivar el uso de RADAR COVID y un botón para notificar un diagnóstico positivo de COVID.

En esta ocasión los controles sí pueden ser accedidos y utilizados por las tecnologías de apoyo como lectores de pantalla, navegación por voz, control por botón, etc… sin embargo, destacan dos importantes barreras que afectan a personas con diferentes discapacidades visuales:

  • El contraste entre el color de primer plano de los controles y el fondo no cumple el ratio mínimo: personas con discapacidad visual no podrán distinguirlos, tampoco personas sin discapacidad visual pero que ejecuten la aplicación en un entorno con mucho brillo detrás de ellas.
  • El nivel de exposición utiliza el color para proporcionar información: personas con daltonismo tendrán que conformarse con el texto “Exposición baja” o “Exposición alta”.


Criterio WCAG 2.1 Nivel Cumplimiento iOS Cumplimiento Android
1.1.1 Contenido no textual A No cumple No cumple
1.2.1 Sólo audio y sólo video (Pregrabado) A No aplica
1.2.2 Subtítulos (Pregrabado) A No aplica No aplica
1.2.3 Audiodescripción o alternativa textual completa (Pregrabado) A No aplica No aplica
1.2.4 Subtítulos (Directo) AA No aplica No aplica
1.2.5 Audiodescripción (Pregrabado) AA No aplica No aplica
1.3.1 Información y relaciones A No cumple No cumple
1.3.2 Secuencia significativa A Cumple Cumple
1.3.3 Características sensoriales A No aplica No aplica
1.3.4 Orientación de la pantalla AA No cumple No cumple
1.3.5 Identificación del propósito del campo AA No aplica No aplica
1.4.1 Uso del color A No cumple No cumple
1.4.2 Control del audio A No aplica No aplica
1.4.3 Contraste (Mínimo) AA No cumple No cumple
1.4.4 Redimensión del texto AA Cumple Cumple
1.4.5 Imágenes de texto AA Cumple

Cumple

1.4.10  Reajuste de elementos AA No aplica No aplica
1.4.11 Contraste no textual AA No cumple

No cumple

1.4.12 Espaciado del texto AA No aplica No aplica
1.4.13 Contenido en hover o focus AA No aplica No aplica
2.1.1 Teclado A No cumple Cumple
2.1.2 Sin trampa de teclado A Cumple Cumple
2.1.4 Atajos de teclado A No aplica No aplica
2.2.1 Límite de tiempo ajustable A No aplica No aplica
2.2.2 Pausar, detener, ocultar A No aplica No aplica
2.3.1 Tres destellos o por debajo del umbral A Cumple Cumple
2.4.1 Saltar bloques A No aplica No aplica
2.4.2 Página titulada A No cumple No cumple
2.4.3 Orden de foco A Cumple Cumple
2.4.4 Propósito de enlace (En contexto) A No cumple No cumple
2.4.5 Diferentes caminos AA No aplica No aplica
2.4.6 Encabezados y etiquetas AA No cumple No cumple
2.4.7 Foco visible AA No aplica No aplica
2.5.1 Gestos del puntero A No aplica No aplica
2.5.2 Cancelación del puntero A No cumple Cumple
2.5.3 Etiqueta en el nombre A No cumple No cumple
2.5.4 Actuación por movimiento A No aplica No aplica
3.1.1 Idioma de la página A Cumple Cumple
3.1.2 Idioma de partes AA No aplica No aplica
3.2.1 Con foco A Cumple Cumple
3.2.2 Con entrada de datos A No cumple Cumple
3.2.3 Navegación consistente AA No aplica No aplica
3.2.4 Identificación consistente AA No aplica No aplica
3.3.1 Error de identificación A No aplica No aplica
3.3.2 Instrucciones o etiquetas A No aplica No aplica
3.3.3 Sugerencia tras error AA No aplica No aplica
3.3.4 Prevención del error (Legales, financieros, de datos) AA Cumple Cumple
4.1.1 Interpretación A No aplica No aplica
4.1.2 Nombre, rol, valor A No cumple No cumple
4.1.3 Mensajes de estado AA No cumple No cumple

Leyenda

  • Símbolo de check: Cumple
  • Aspa: No cumple
  • Guión: No aplica


La tabla anterior presenta tres niveles de cumplimiento: “Cumple”, “No cumple” y “No aplica”, en la que el único nivel que podría dar lugar a confusión es “No aplica”, ya que la metodología de evaluación WCAG-EM (Website Accessibility Conformance Evaluation Methodology)
permite evaluar como “Cumple” aquellos criterios en los que no exista contenido que pudiera presentar alguna barrera de accesibilidad. Es decir, el cumplimiento de un criterio se podría conseguir incluyendo contenido bien creado o directamente no incluyéndolo. en la evaluación de accesibilidad de Radar COVID he decidido marcar como “No cumple” aquellos criterios cuyo contenido no existe ya que a la hora de evaluar una aplicación móvil como esta que cuenta con muy poco contenido, marcarlos como “Cumple” distorsionaría demasiado el resultado final.


El nivel de gravedad de una barrera está directamente relacionado con su capacidad para resultar bloqueante, es decir, con su capacidad para que a una persona con una discapacidad o bajo unas determinadas circunstancias sobrevenidas le resulte imposible utilizar la aplicación.

Así, una imagen que podría considerarse decorativa que carezca de descripción textual o que no se haya ocultado a determinadas tecnologías de apoyo, haría incumplir el Criterio 1.1.1 Contenido no textual, pero no impediría a ninguna persona hacer uso de una aplicación. Sin embargo, si el incumplimiento de este mismo criterio afecta a un control ejecutable como un botón que exclusivamente está representado por una imagen sin descripción textual, la barrera adquiriría carácter grave y resultaría bloqueante para las personas ciegas. Lo mismo sucedería si el color de la imagen que representa al control ejecutable no presenta suficiente contraste impidiendo ser visto por una persona en condiciones de baja visión.

Atendiendo a lo anterior, la aplicación Radar COVID resulta inaccesible por la existencia de las siguientes barreras:

  • Control para aceptar la política de privacidad inaccesible en iOS: Criterios 2.1.1 Teclado y 4.1.2 Nombre, rol, valor.
  • Contraste insuficiente entre el color de primer plano y fondo: Criterio 1.4.3 Contraste mínimo.
  • Diseño exclusivamente en posición vertical: Criterio 1.3.4 Orientación de la pantalla.
  • Controles gráficos sin descripción textual: Criterios 1.1.1 Contenido no textual, 2.4.6 Encabezados y etiquetas, y 2.5.1 Etiqueta en el nombre.

Conclusiones sobre la Accesibilidad de Radar COVID

Podemos concluir con total seguridad que la aplicación Radar COVID no es accesible puesto que su evaluación da como resultado que no es conforme con las Pautas de Accesibilidad WCAG 2.1

La importancia de algunas de las barreras detectadas, además, hace que un gran número de personas no puedan utilizarla, no por difícil, sino por inaccesible:

  • Personas ciegas.
  • Personas con baja visión
  • Personas con movilidad reducida

Comparte esta entrada:

Deja un comentario