Mobile accessibility para Android, una solución sencilla

Android, el sistema operativo para dispositivos móviles de Google posee importantes carencias en accesibilidad. La gente de Talkback, el lector de pantallas oficial de Android, parece que no escucha demasiado a los usuarios y tampoco transmite las peticiones de desarrolladores y usuarios con discapacidad a Google. Todo esto ha provocado que grupos de desarrolladores y algunas empresas expertas en productos de apoyo se aventuren a desarrollar sus propios productos de apoyo para este sistema operativo.

Codefactory, la empresa creadora de magnificadores y lectores de pantalla para symbian y Windows mobile, ha decidido debutar en Android creando un producto de apoyo para usuarios con discapacidad visual.

Mobile accessibility

Mobile accessibility for Android es una solución de accesibilidad para usuarios con discapacidad visual que da acceso a las funciones más importantes del teléfono. Navegar por la Web, leer y escribir correos electrónicos, consultar datos del GPS son actividades que podrán realizarse con Mobile accessibility junto a las ya clásicas de gestionar llamadas, escribir y leer mensajes SMS, calendario y agenda de contactos. También permite configurar algunas cosas del terminal, como el tono de llamada, cuentas de correo, etc.

Mobile accessibility muestra toda la información en una interfaz muy simple, en blanco y negro, de forma que en todo momento se vea qué se está haciendo. Esto se debe a que Mobile accessibility no es un lector de pantallas que de acceso a todo el sistema. Mobile accessibility es un entorno cerrado accesible para personas con discapacidad visual.

Acceso limitado al sistema

Mobile accessibility incluye un lector de pantallas rudimentario que permite navegar por las opciones del launcher, el escritorio estandar de Android, y las opciones de configuración del sistema. Este lector de pantallas rudimentario da un acceso muy limitado al sistema, al igual que hace Spiel o talkBack, otros lectores de pantalla para Android. Esto se debe a que dentro del entorno cerrado de Mobile accessibility for Android no se tiene acceso a todas las opciones de configuración y manipulación del teléfono. Por ejemplo, una limitación muy grande es que, debido a las limitaciones de permisos de Android, no se puede apagar el teléfono desde el propio Mobile accessibility, hay que salir de él y usar el lector de pantallas rudimentario para apagar el teléfono o ponerlo en silencio. Android no sólo tiene carencias en accesibilidad, sino que impide crear aplicaciones accesibles que den solución a las carencias de accesibilidad a través de interfaces alternativos.

Manejo de Mobile accessibility

Mobile accessibility reconoce gestos sobre la pantalla dentro de su interfaz cerrada accesible. Esto permite a cualquier ciego con cualquier teléfono que use Android 2.X o superior el acceso a las funciones ya mencionadas. Los gestos, muy sencillos son similares a los conocidos flicks de VoiceOver para iOS de Apple. El teclado virtual sobre la pantalla táctil se usa de forma similar a como se hace en touchPad para Android o el método de VoiceOver para iOS.

El reconocimiento de gestos no funciona cuando salimos del entorno cerrado accesible de Mobile accessibility for android, por esta razón, se recomienda adquirir un teléfono que posea un trackBall, cursor o sistema de cursores en 5 direcciones. De esta forma nos podremos mover con el lector de pantallas rudimentario y acceder a las opciones de apagado y configuración del teléfono.

Esperemos que en futuras versiones de Mobile accessibility y Android mejoren estos aspectos.

Usuario ideal de Mobile accessibility

Al igual que pasó con la versión para Symbian de Mobile accessibility, allá por el año 2003, el usuario que aprovechará más este producto es aquel que quiera utilizar un teléfono de última generación sin complicarse demasiado. Por ejemplo, los teléfonos con Android de bajo coste que llegarán desde China podrían ser utilizados con este software de accesibilidad para personas con discapacidad visual. De esta forma una persona ciega podría acceder a la información de su teléfono, navegar por la Web y gestionar su correo electrónico con un teléfono barato.

Mobile accessibility puede encontrarse en el Market de Android, la tienda de aplicaciones on-line de google.

Lectores de pantalla

Un lector o revisor de pantallas es una herramienta de asistencia para discapacitados visuales grabes o totales cuya principal función es transmitir al usuario la información que se visualiza por pantalla.

Dentro de los interfaces de texto (como serían la consola de Windows, MSDOS o el Bash de Linux) las funciones del lector de pantalla son simples. Sólo tiene que poder leer cada una de las diversas líneas de texto que aparecen en la consola y transmitirlas al usuario. Otras funciones asociadas para este tipo de lectores son las posibilidades de revisar línea a línea la pantalla, verbalizar los cambios sufridos en la pantalla o crear cuadros de detección para prestar mayor atención a zonas específicas de la pantalla.

El tener un interfaz visual basado en texto y con una estructura de distribución de la información simple, como es el caso de las consolas de texto, simplifica mucho la tarea del lector de pantallas. El problema aparece cuando el interfaz consiste en elementos visuales como iconos, cuadros de texto, ventanas, barras de desplazamiento y demás controles visuales utilizados por la mayoría de interfaces gráficos de usuario comunes en Windows, GNome, KDE y MacOS X.
En este caso el lector de pantallas tiene que realizar una interpretación previa de lo que existe y se ve en la pantalla para transmitirlo al usuario.

Esta interpretación del contenido visual se hace siguiendo un protocolo y conjunto de reglas denominado off screen model.

Dependiendo del tipo de Off screen model el lector de pantallas permitirá una exploración focal (siguiendo al foco del tabulador), exploración línea a línea (como el cursor de JAWS o un lector de pantallas para consola), exploración posicional (como hace voiceOver), o exploración gerarquica utilizando el árbol de objetos (como hace NVDA y tiflowin).
También influirá a la hora de transmitir cierta información como la fuente y color del texto de un control visual, el tamaño del control, el estado del control (activo, visible, oculto, etc) o las caracteristicas de accesibilidad o información alternativa del control (tooltips, globos de texto, etiquetas descriptivas, etc).

Hay que prestar atención en la diferencia que hay entre «lo que existe en la pantalla» y «lo que se ve en la pantalla» ya que el uso de ventanas solapables en los interfaces gráficos puede provocar que el usuario sin discapacidad visual no vea lo que hay detrás de una ventana aunque siga existiendo en el interfaz. El lector de pantallas debe detectar si el control o elemento del interfaz está visible para notificarle el estado al usuario ciego. El lector de pantallas puede controlar la información visual consultando al sistema operativo sobre el árbol de objetos visuales o parasitando el controlador de video, siendo la primera opción la menos intrusiva ya que no se requiere de la instalación de ningún driver o parche de control de video.
El árbol de objetos visuales es una representación abstracta de lo que hay en un interfaz gráfico de usuario. Es utilizado por el sistema operativo para estructurar los diversos elementos de un interfaz gráfico y actualizar el estado y gestionar los eventos. En el árbol de objetos podemos tener la rama inicial en el escritorio y de ella nacen varias ramas hijas representando a las ventanas de las aplicaciones abiertas que tengamos en ese momento, de una de esas ramas pueden colgar subramas para representar subventanas, botones, barras de menú, etc presentando una vista gerarquizada de los elementos del interfaz.

El lector de pantallas también debe estar pendiente del dispositivo de entrada, sea este un teclado, una pantalla táctil o una botonera. El usuario ciego deberá utilizar el dispositivo de entrada para explorar el interfaz gráfico e interactuar con él. Por esta razón el lector de pantallas deberá modificar el comportamiento del dispositivo de entrada para incluir ciertas combinaciones de teclas, gestos o movimientos determinados para realizar las funciones de exploración en el interfaz(leer una ventana o cuadro de texto, moverse al elemento anterior o siguiente del interfaz, activar un elemento del interfaz, etc).

El lector de pantallas debe transmitir el resultado de la interpretación del interfaz al usuario con discapacidad visual utiizando un canal accesible para él, como puede ser voz sintética, eventos de sonido o salida por un dispositivo de lectura braille.

En resumen, un lector de pantallas se compone de los siguientes elementos:

  • Módulo de control del interfaz gráfico
  • Módulo de control del dispositivo de entrada
  • Módulo de salida de información
  • Off screen model

Dentro del catálogo de operaciones que un usuario puede pedir a un lector de pantallas están: Leer caracter, palabra, línea anterior, actual o siguiente; consultar tipo, tamaño y color de fuente, leer título y última línea de la ventana, repetir lo último verbalizado, etc.

Algunos ejemplos de lectores de pantalla son: NVDA, Window eyes, JAWS, Dolphin HAL, Thunder, voiceOver, Orca, Mobile speak, Talks, out spoken, virgo, tiflowin, lector98, habla, parla, etc.

La accesibilidad en crisis para los desarrolladores ciegos

En todas partes se habla de la accesibilidad en general, en otras partes, además, se habla de la accesibilidad a la Web. En muy pocas partes se habla de los problemas que encontramos los desarrolladores ciegos para poder diseñar y desarrollar software.

En la red se está moviendo una corriente de curiosidad sobre si una persona con ceguera puede desarrollar software. La respuesta, hablando desde mi experiencia personal como desarrollador en varios lenguajes y plataformas, es que si pero no gracias a esas grandes empresas y organizaciones que se mueven en pro de la accesibilidad. Esa accesibilidad que atrae a la gente y los medios de comunicación es para una mayoría de personas con discapacidad, con perfiles de discapacidad mayoritarios. Digo esto porque conozco la postura de grandes empresas como Sun microsystems, recientemente adquirida por Oracle, que no duda en adherirse a proyectos europeos en pro de la Accesibilidad pero ante una pregunta de un servidor sobre si sus herramientas de desarrollo serán accesibles también le contestaron que hay muy pocos desarolladores ciegos en el mundo como para tomarse el trabajo. Otra gran empresa de desarrollo de software y sistemas operativos, hablamos de Microsoft, que tiene uno de los departamentos de accesibilidad con más personal del mundo; parece que se asegura que cada nueva versión de sus diversos productos software guarden una compatibilidad hacia atrás en su interfaz para mantener la poca accesibilidad que tengan sus productos. Esto es así excepto para sus herramientas de desarrollo, donde a cada nueva versión un desarrollador ciego encontrará más y más problemas. Apple, empresa que se enorgullece de sacar todos sus productos accesibles desde la caja y con un departamento de accesibilidad bastante funcional, ante la petición de hacer más accesible su herramienta de diseño de interfaces comenta que mejor esforzarse en hacer accesible la versión que saldrá para la nueva generación de su suite de desarrollo software, suite que va con retraso y mientras un servidor diseña los interfaces de sus aplicaciones para MacOS X, iPhone e iPad utilizando matemáticas, mucha imaginación y mucha cantidad de código fuente en sus programas.

Las propias empresas de desarrollo de software para personas con discapacidad, como pueden ser Freedom scientific (creadores de Jaws), GWMicro (Window eyes) o Dolphin software (creadores de Hal) no se interesan en proporcionar soporte, scripts y mapas de ventana para sus lectores de pantalla.

Editoriales que publican sus libros o sólo en papel o en formato electrónico donde el código fuente se imprime en una imagen, o redactan las explicaciones haciendo referencia a imágenes y resultados visuales por pantalla.

Con todo esto se podría aventurar uno a decir que no se puede programar si un desarrollador no puede ver la pantalla. Incluso hay un movimiento por crear un lenguaje de programación para ciegos ya que con los actuales parece que no puede trabajar un desarrollador ciego.

La realidad es que los lenguajes de programación son, la gran mayoría, completamente accesibles. Lo inaccesible son los entornos de desarrollo o herramientas de desarrollo. ¿Para qué quiero aprender un lenguaje de programación discriminatorio que no va a utilizar ninguna empresa de desarrollo de software? Nadie me contrataría si sólo domino un lenguaje de programación para ciegos. Un desarrollador debe conocer varios lenguajes de programación y dominar el manejo de los entornos de desarrollo para dichos lenguajes. Si un entorno de desarrollo es inaccesible, como puede ser el nuevo Visual studio 2010, un desarrollador ciego puede optar por utilizar un procesador de textos común y corriente, y normalmente muy accesible, y utilizar el compilador y depurador en línea desde la consola de comandos. El problema de esta solución es que hace que el desarrollador ciego sea menos productivo que un desarrollador que utilice Visual Studio 2010 y en la actualidad las empresas valoran más la productividad del desarrollador que su situación o la calidad de su código.

En esta situación de posible baja productividad nos encontramos muchos desarrolladores ciegos obligados por cada nueva versión que sale de un entorno de desarrollo por parte de estas empresas con gran responsabilidad social. Estas empresas que condenan a muchos profesionales del desarrollo software que poseen una discapacidad visual a buscar sus propias soluciones porque ni las empresas que desarrollan sus productos de apoyo les apoyan.

La conclusión es que la respuesta inicial se convierte en: hay desarrolladores ciegos pero están en peligro de extinción gracias a los mismos que alzan el estandarte de la accesibilidad para todos.