Eyes-free y Android 4, una buena combinación

La aparición de Android 4, por parte de Google ha traído mejoras en la accesibilidad para los dispositivos Android. Muchas de estas mejoras vienen orientadas para dar solución a las necesidades de las personas con discapacidad visual. Muchas de estas mejoras se originan en el proyecto Eyes-free encargados del primer lector de pantallas para Android, más conocido como Talkback.

Eyes-free Talkback, el lector de pantallas de este proyecto, nos permite utilizar una de las nuevas mejoras de la capa de accesibilidad de Android 4. Una persona ciega puede arrastrar el dedo por la pantalla táctil de su dispositivo para explorar los controles que allí aparecen.

Talkback suele venir instalado en la mayoría de distribuciones Android que existen en el mercado ya que los principales fabricantes incluyen en sus teléfonos el paquete básico de accesibilidad para Android 4.

Aunque Talkback nos permita arrastrar el dedo para explorar la pantalla realizar ciertas operaciones básicas se vuelve una actividad compleja para el usuario ciego. Una de esas operaciones es la de introducir texto a través del teclado virtual en pantalla. Por esa razón los miembros del proyecto Eyes-free han desarrollado su propio teclado virtual conocido en el market de Android, la tienda de aplicaciones para esta plataforma, como Eyes-free keyboard.

Eyes-free keyboard ofrece, entre otras cosas, un teclado virtual en pantalla compatible con Talkback. Además permite un modo de navegación parecido al que se usa en VoiceOver para iOS, el lector de pantallas para iPhone e iPad, consistente en movimientos de arrastre corto (flicks) en vertical y horizontal para mover el foco de Talkback y explorar de forma más ordenada la pantalla.

Mejoras sustanciales pero trabajo por hacer

Las mejoras en la capa de accesibilidad para esta versión de Android son notables pero aún faltan características básicas para garantizar una accesibilidad suficiente para esta plataforma. Por ejemplo, para que los controles del interfaz de una aplicación sean reconocidos por la capa de accesibilidad y sus productos de apoyo es necesario que el desarrollador incluya una línea de código por cada control en su proyecto. Esto ha mejorado notablemente ya que sólo es necesario una línea de código por cada control pero el usuario con discapacidad sigue dependiendo de la generosidad y la concienciación de los desarrolladores para que incluyan esas pocas líneas de código.

Otro problema importante es la ejecución errática de los diferentes servicios del proyecto Eyes-free en según qué modelos. Se sabe que el Samsung Galaxy nexus funciona correctamente con el software vinculado al proyecto Eyes-free pero otros dispositivos de este y otros fabricantes no funcionan de la forma esperada. Errores en el reconocimiento de flicks, arrastres y otros gestos son comunes en otros dispositivos; problemas en la síntesis a la hora de pausar la verbalización o retomar la misma y problemas con las teclas de navegación Android (Back, Home, search, etc) en los dispositivos sin teclas físicas son problemas presentes en varios dispositivos que utilizan esta versión de Android.

Pero los problemas más preocupantes son: un usuario con discapacidad visual no tiene un método seguro para activar y desactivar el lector de pantallas o el magnificador ya que el control de gestos incluido por eyes-free no funciona del todo bien y la potencial pérdida de información de un usuario con discapacidad visual a la hora de explorar un interfaz. El usuario está obligado a arrastrar el dedo por toda la pantalla sin garantía de que todo lo que encuentre sea reconocible por el lector de pantallas. El sistema de navegación por gestos ofrecido por Eyes-free keyboard no funciona del todo bien y, en algunas aplicaciones, salta controles y etiquetas de contenido. Un resumen de este problema se puede resumir en la siguiente frase: Una plataforma que obliga a un usuario ciego a arrastrar el dedo por la pantalla durante más de 20 segundos para encontrar el botón aceptar es un sistema que necesita muchas mejoras.

Eyes-free incluye un pequeño tutorial básico de uso pero se limita a las funciones básicas de Talkback. Además aún no se ha incluido soporte para castellano.

Con todo esto podemos decir que Android 4 puede ser utilizado por personas con discapacidad visual con mucha experiencia en el manejo de dispositivos móviles y sus productos de apoyo y para aquellos usuarios con discapacidad con mucha paciencia. Esperemos que estos productos de apoyo y la capa de accesibilidad de Android sigan mejorando para garantizar una experiencia de usuario completamente satisfactoria para los usuarios con y sin discapacidad.

Google y su concepto de accesibilidad

This article has been translated to english.
You can read this article in english. Thans to No eyes needed blog.

En el día de ayer Google presentó varias novedades al mundo. Muchos medios se hicieron eco de su servicio de difusión musical y multimedia en la nube, la nueva versión de su sistema operativo Android, su navegador Gogle Chrome y más novedades pero pocos medios prestaron atención a las novedades en accesibilidad.

Una oportunidad perdida para Android

Entre las muchas novedades presentadas estaba Android Honeycomb 3.1. La nueva versión del sistema operativo de Google para smartphones y tablets. En esta versión Google ha decidido unificar el interfaz tanto para teléfonos como otros dispositivos. Algo que puede ser interesante y, con la ocasión de haber publicado unas nuevas herramientas y librerías para el diseño de interfaces, se podría haber incluido una capa de accesibilidad más completa y que resultase transparente para los desarrolladores de aplicaciones Android. Pues Google decepcionó al no incluir mejoras en accesibilidad en estas nuevas herramientas y librerías. Los atributos y elementos de accesibilidad en los interfaces de Android siguen siendo optativos y confusos para el desarrollador.

El proyecto Eyes-free, el cual recoge varias aplicaciones orientadas a la accesibilidad de Android entre las que destaca Talkback, no mostró demasiadas novedades. Destacaron una nueva característica para ampliar el tamaño de letra de la pantalla a través de un gesto. Si eso es una característica innovadora para Google me temo que falta muchísimo tiempo para que las personas ciegas y con baja visión puedan disfrutar de una accesibilidad completa y satisfactoria en Android.

La accesibilidad es un parche para Google

Ayer Google presentó también las novedades de su navegador web, más conocido como Google chrome. Se anunció a bombo y platillo que incorporaba mejoras en accesibilidad para que fuese compatible con lectores de pantallas de Windows, como Jaws y NVDA, y con VoiceOver para MacOS. Muchos nos decidimos a probar todas estas supuestas novedades y, tras varios intercambios de opiniones entre los que probamos todos coincidimos que o bien Google se adelantó en su anuncio y no indicó que las novedades serían desarrolladas para la próxima versión o bien que Google nos gastó una broma. Es cierto que hay mejoras en la compatibilidad de Google chrome y lectores de pantallas pero, en ningún caso, todas esas mejoras permiten una navegación normal y suficiente para una persona con discapacidad visual usando su lector de pantallas habitual y Google chrome como navegador.

Problemas con la identificación y uso de controles de formulario, falta de refresco en contenidos dinámicos o imposibilidad de acceder a contenidos habituales en una web usando cualquiera de los 3 lectores de pantallas mencionados. Ese fué el resultado tras probar las supuestas novedades de Google chrome con NVDA, Jaws 12 y VoiceOver. Todos los lectores de pantalla probados estaban actualizados a la última versión disponible.

¿Un lector de pantallas o un parche?

Otra de las novedades en accesibilidad de Google es la creación de un supuesto lector de pantallas para Google chromeOS, el sistema operativo de Google cuyo corazón es el navegador Google chrome. Lo de utilizar las palabras: supuesto lector de pantallas se justifica en que el lector de pantallas, bautizado como ChromeVox, en realidad es una extensión del navegador web. No se ha incorporado una capa de accesibilidad nativa para el sistema operativo, en su lugar se ha creado un miniprograma que se ejecuta sobre el navegador web, esto es una extensión, y que accede a algunos contenidos y funcionalidades del sistema operativo.

Google presentó como un logro importante el poder tener un feedback con síntesis de voz cuando escribimos una dirección web en el navegador, podemos leer el cuerpo de un correo electrónico o podemos navegar por la lista de resultados del buscador de Google usando los cursores. Todas las pruebas presentadas con ChromeVox se realizaron usando las páginas de los servicios de Google.

ChromeVox tiene muchas similitudes con VoiceOver para MacOS, la combinación de teclas para usar las funciones del lector de pantallas se compone de la tecla Shift junto a la tecla search y utiliza muchos sonidos para transmitir información al usuario.

El usar una extensión de un navegador web en lugar de utilizar un programa nativo o servicio del sistema operativo garantiza que el acceso a los contenidos del sistema operativo y de aplicaciones de terceros no será completo y tampoco será estable. Imaginemos el recorrido que debe realizar el supuesto lector de pantallas para acceder a un contenido:

ChromeVox se ejecuta sobre Google chrome que se ejecuta sobre la capa de ejecución del sistema operativo que, a su vez, está por encima del kernel del sistema operativo. Recordemos que el sistema operativo carece de capa de accesibilidad por lo que el lector de pantallas tendrá que utilizar todos los recursos necesarios para detectar, interpretar e interactuar con los controles y contenidos que encuentre. Teniendo en cuenta que cada vez que subimos desde el kernel hacia arriba en esa línea que hemos trazado en nuestra imaginación se consumen más recursos y el número de procesos en ejecución aumenta podemos imaginar que una persona ciega necesitará un equipo con mucha más memoria y más potencia de procesador. La razón de que un ciego no pueda comprar un equipo informático de bajo consumo es que Google no ha hecho bien sus tareas. Además, la inestabilidad del programa aumenta cuanto más arriba esté en esa linea imaginaria ya que si, por cualquier razón, cualquier proceso que se sitúe bajo nuestro programa se ralentiza o se cuelga, todo lo que haya por encima del proceso ralentizado o colgado también se ralentizará y colgará.

La broma de Google

Google ya nos tiene acostumbrado a los usuarios con discapacidad al hábito de ofrecer algo con unos requisitos mínimos de accesibilidad y 3 productos más totalmente inaccesibles. Ejemplos habituales son Googlemaps, Googledoc, Google calendar. También podemos comprender qué entiende Google por accesibilidad al ofrecer, en lugar de una interfaz accesible para su servicio GMail, realizar una versión limitada, fea e insuficiente para aquellos usuarios que no puedan acceder al interfaz oficial.

Google ha demostrado que la accesibilidad parece no ser un tema importante en su agenda de desarrollo. Ofrece soluciones mediocres e insuficientes para sus usuarios con discapacidad. Deja en manos de los desarrolladores el proporcionar un mínimo de accesibilidad en sus productos en lugar de garantizar la accesibilidad de una aplicación que utilice un interfaz con controles estandard. Parece que Google no entiende bien que la accesibilidad, además de un criterio de calidad, es un derecho de las personas.