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.

Convivencia de MacOS X y Windows dentro del hardware de Apple

Muchos usuarios que quieren dar el salto al sistema operativo de Apple tienen miedo del periodo de adaptación. Aunque MacOS X sea muy intuitivo es cierto que requiere de un periodo de adaptación, sobre todo si el usuario tiene que acostumbrarse a un nuevo producto de apoyo. Una de las posibles soluciones, para hacer que la experiencia del switcher (denominación que se da a la persona que cambia a otro sistema operativo) no sea tan traumática es utilizar 2 sistemas operativos en la misma máquina.

Boot camp

MacOS X, en sus últimas versiones, incluye una utilidad para estos usuarios que vienen de Windows pero quieren saltar a MacOS X manteniendo el uso de Windows. Esta utilidad se llama Boot camp y permite, desde MacOS X, crear una partición en el disco duro y comenzar el proceso de instalación de windows. Todo el proceso de creación y gestión de Boot camp es accesible pero cuando comience el proceso de instalación de Windows, al reiniciar la máquina, sólo dispondremos de la accesibilidad que proporcione Windows en su proceso de instalación, lo que es muy poca o nula accesibilidad.

Al utilizar Boot camp, en Windows, deberemos instalar una serie de drivers y aplicaciones que nos permitirá aprovechar más el hardware de Apple sobre Windows. Además, nos permitirá seleccionar con qué partición arrancaremos la próxima vez que encendamos el equipo. Con esta característica un usuario ciego puede decidir si arrancar Windows o MacOS X sin necesidad de acceder a Grub, Lilo o cualquier otro gestor de arranque.

Virtualización

Con la solución de Boot camp deberemos reiniciar el equipo cada vez que queramos cambiar de sistema operativo. Esta solución puede ser apropiada para aquellos usuarios que pasen largas sesiones en un sólo sistema operativo. Para los usuarios que trabajen en MacOS X y quieran, muy puntualmente, acceder a Windows para utilizar una aplicación concreta la mejor solución pasa por virtualizar.

La virtualización de un sistema operativo consiste en utilizar una aplicación de virtualización (cliente) que permita ejecutar otro sistema operativo como si fuese un programa.

Para MacOS X hay varias soluciones de virtualización: VMWare, Parallels, VirtualBox, etc. Cada una tiene sus ventajas y defectos.

La principal diferencia entre ejecutar un sistema operativo de forma nativa, como se haría con Boot camp en el caso de Windows, es que todos los recursos de hardware están disponibles para el sistema operativo. En el caso de una ejecución virtualizada, si ejecutasemos un Windows virtualizado, sólo podríamos acceder a los recursos que el cliente de virtualización nos permita. Esto se debe, principalmente, a que los recursos de la máquina deben repartirse entre los dos sistemas operativos que se están ejecutando: el sistema operativo base o anfitrión, que ejecuta el cliente de virtualización, y el sistema operativo virtualizado.

Algunas ventajas de la virtualización es la posibilidad de almacenar instalaciones completas de un sistema operativo en discos externos. De esta forma, si nuestro Windows comienza a ir más lento o se detectan problemas de ejecución que nos hacen pensar en que tenemos que reinstalar, podemos ir a la carpeta donde nuestro cliente de virtualización guarda sus máquinas virtuales (que es como se conoce a una instalación de un sistema operativo virtualizado) y sustituir el Windows corrupto por nuestra copia de seguridad. Todo el proceso de reinstalación de Windows, más de 45 minutos, se reducen a un par de minutos. Incluso algunos clientes de virtualización permiten copiar o descargar instalaciones ya creadas.

Problemas de accesibilidad y virtualización

La ejecución virtualizada de un sistema operativo puede crear conflictos con algunos productos de apoyo. Por ejemplo, se conoce el problema que existe con VMWare, uno de los clientes de virtualización más utilizados, y la tecla de bloqueo de mayusculas, utilizada por varios lectores de pantalla como tecla de función. Además, el teclado de MacOS X no posee la tecla Insert, tecla también utilizada por varios productos de apoyo. La solución pasa por remapear la función de una de las teclas duplicadas del teclado (comando, mayúsculas, etc) y asignarle a dicha tecla la función de tecla Insert.

Un problema que afecta tanto a sistemas operativos virtualizados como nativos es la poca tolerancia del driver de vídeo de Jaws a drivers gráficos un tanto especiales. En el caso de una instalación nativa, una vez hayamos instalado los drivers de Boot camp, no encontraremos problemas. En el caso de una instalación de windows virtualizada, deberemos evitar el modificar el tamaño de la ventana del cliente de virtualización. Se recomienda utilizar Windows virtualizado a pantalla completa. Además, deberemos instalar los drivers para Windows del software de virtualización que estemos utilizando.

Conclusiones

Con estas posibilidades de ejecutar Windows y MacOS X el camino del switcher se hace más cómodo. Sólo debemos decidir si queremos 2 instalaciones nativas, para largos periodos de uso de una de ellas; o instalación nativa de MacOS X y virtualizada de Windows, por lo que Windows irá un poco más lento pero podremos saltar de un sistema operativo a otro de forma muy rápida.

Magnificadores de pantalla

Algunos usuarios poseen una discapacidad que, aunque pudiendo apreciar visualmente el mundo que les rodea, no pueden utilizar un ordenador debido a que la resolución o el tamaño o los colores empleados en la pantalla no pueden ser percibidos de forma clara, impidiendo la lectura del contenido de la pantalla al usuario. Este tipo de usuario necesita algo que realice la función de lupa o filtro de color para la pantalla, esta es la función de los magnificadores de pantalla.
Un magnificador de pantalla es, básicamente, un software que simula el efecto de una lupa sobre la pantalla del ordenador. Esta magnificación de la imagen de la pantalla se puede realizar en diferentes grados de aumento (zoom) y de diversas formas de visualización (a pantalla completa o mostrando la ampliación en un area determinada de la pantalla). Dependiendo de las necesidades del usuario, estos parámetros cambiarán.
Los aumentos realizables por un magnificador de pantalla dependen del algoritmo que emplee para realizar la ampliación (con efectos de antialiasing, proyecciones vectoriales o redimensionado matricial), y el método de tratamiento de la información de video (utilizando la propia VRAM y el hardware de video instalado en el equipo o delegandolo todo al procesador y el sistema operativo). Dependiendo de todos estos factores, un magnificador de pantalla puede realizar una ampliación de entre 1,5 aumentos y 700 aumentos.
A parte de la función de aumentar la imagen de la pantalla, algunos magnificadores de pantalla permiten aplicar un filtro de color a la imagen ampliada para que el usuario pueda personalizar el contraste de color y los tonos empleados en la imagen ampliada.
El foco de ampliación es un area móvil de la pantalla que, a semejanza del puntero del ratón, señaliza donde se encuentra el foco o zona de la pantalla que debe ser ampliada. Este foco puede ser modificado mediante el uso del ratón (siguiendo el foco de ampliación al puntero del ratón) mediante el uso de teclas de función o por eventos del sistema (ventanas o areas de pantalla que actualizan su información). El problema de estos movimientos de foco es transmitir al usuario, en todo momento, donde se encuentra ya que si el foco es modificado de repente, puede provocar una confusión del usuario. Por ejemplo: imaginemos que el usuario se encuentra leyendo un documento en su procesador de textos y el foco de ampliación está sobre la mitad de la pantalla. De repente, llega un correo electrónico y se muestra un pequeño icóno indicando de la presencia de nuevo correo. El magnificador de pantalla puede llevar el foco de ampliación directamente al icono de notificación de correo nuevo, si nuestro usuario no está atento puede leer algo como ‘En un lugar de la Mancha de cuyo correo electrónico nuevo…’.
Para solventar estos problemas y aumentar la funcionalidad de los magnificadores de pantalla se han hecho uso de tecnologías de síntesis de voz para notificar al usuario, mediante voz, la información acerca de lo que está leyendo o si el magnificador o el sistema ha realizado alguna operación.
Algunos sistemas operativos llevan incluidos un magnificador de pantalla rudimentario por lo que se opta por instalar software más funcional cuyas prestaciones son cada vez más cercanas a las que brinda un lector de pantallas al incluir síntesis de voz, posicionamiento subjetivo, navegación utilizando MSAA o AT-SPI u otras características de accesibilidad de los sistemas operativos.
Los problemas de accesibilidad que encuentran los usuarios de magnificadores de pantalla, a parte de encontrar imágenes sin un contraste suficiente para poder apreciar los detalles de una imagen o el uso de colores no soportados nativamente por el sistema, están los diseños de tamaños enormes que provocan la aparición de barras de desplazamiento horizontal o la existencia de contenido visual dinámico ((animaciones, videos, etc) que provocan que el magnificador intente focalizar todo lo que se mueva o que el propio usuario no pueda determinar qué ocurre en la animación o el video al, únicamente, poder visualizar una zona muy limitada de la imágen. Es como si intentasemos ver una película en el cine utilizando unas gafas cuya superficie de visualización fuera un pequeño círculo de 3cm de radio. Para ver la pantalla tendríamos que girar continuamente la cabeza para ver toda la pantalla y, aún así, no podríamos ver toda la pantalla en un mismo instante.

Algunos ejemplos de magnificadores de pantalla son: Gnome-Mag, Zoomtext, Once Mega 98, Magic, Supernova, Lunar.

Excepciones de pronunciación para VoiceOver en MacOS X

Los usuarios de lectores de pantalla encuentran un serio problema a la hora de comprender ciertos mensajes que transmite su dispositivo al usuario a través de una síntesis de voz. Estos problemas se suelen originar por una incorrecta pronunciación por parte de la síntesis de voz de algunos términos o palabras en otros idiomas, siglas o términos científicos.

Algunos motores de síntesis de voz, como Infovox ivox para MacOS X, incorporan un mecanismo de personalización de pronunciación que permite modificar algunas palabras a la hora de ser pronunciadas. El problema aparece cuando el propio motor de voz posee ciertos términos predefinidos a la hora de ser pronunciados. Un ejemplo puede ser dl ( decílitro). La herramienta de diccionario, que es como se conoce a este tipo de aplicaciones que permiten modificar el comportamiento de una síntesis de voz a la hora de pronunciar algunas palabras, aunque admita el nuevo término, no cambiará la pronunciación ya que las pronunciaciones predefinidas poseen más prioridad que las pronunciaciones definidas por el usuario.

La solución pasa por utilizar la herramienta de diccionario del propio lector de pantallas. En el caso de Infovox iVox, al tratarse de MacOS X, es VoiceOver.

Realizaremos un breve ejercicio de modificar la pronunciación de dl (decílitro) por dl (de ele).

Abriremos la ventana de configuración de VoiceOver pulsando VO+F8. Las teclas VO corresponden a pulsar Control+ALT, por lo que la pulsación anterior sería Control+ALT+F8. Se abrirá la ventana de configuración de voiceOver.

En la categoría llamada Texto hablado encontraremos la pestaña Pronunciación.

Aquí encontraremos una tabla con las modificaciones de pronunciación definidas por el usuario. En la parte baja de la ventana encontraremos el botón agregar para añadir una nueva modificación de pronunciación.

Al pulsar el botón agregar VoiceOver nos llevará a un cuadro de texto vacío donde deberemos meter el término original, en nuestro caso las letras d (de) y l (ele). Tras introducirlas debemos pulsar la tecla tabular, VoiceOver nos llevará a un nuevo campo de texto vacío donde deberemos introducir cómo queremos que se pronuncie el nuevo término. En nuestro caso recomiendo escribir de,ele.

Si seguimos pulsando la tecla tabular pasaremos a un botón de menú para especificar si queremos que el cambio de pronunciación afecte a todo el sistema o a una aplicación en concreto. Esto es util, por ejemplo, para modificar la pronunciación de emoticonos en nuestra aplicación de chat habitual.

Si pulsamos una vez más la tecla tabular nos lleva a una casilla de verificación que nos permite indicar si queremos que se distinga entre mayúsculas o no a la hora de pronunciar. Esto significa que no será lo mismo ms que Ms, o mS o MS (cambiando algunas letras por mayúsculas en cada caso).

Una vez creado nuestra nueva regla de pronunciación podemos cerrar la ventana de configuración de VoiceOver o buscar el botón agregar para añadir otra nueva regla de pronunciación.

Android 2.3, una decepcionante novedad en accesibilidad

A principios de este mes de Diciembre Google publicó la última versión de su sistema operativo para dispositivos móviles, más conocido como Android.

Esta nueva versión, la 2.3, cuyo nombre en clave es galleta de jengibre, prometía incluir sustanciosas mejoras en accesibilidad para aquellos usuarios con discapacidad visual.

Tras la publicación de la noticia por parte de Google, muchos de los que estamos interesados en Android y su accesibilidad consultamos la lista de novedades y mejoras de esta nueva versión. el resultado fue del todo decepcionante. Ni una sola mención a cualquier mejora o característica de accesibilidad.

En la lista de correo del grupo de usuarios del proyecto Eyes-free, donde se localiza TalkBack el lector de pantallas oficial para Android, muchos usuarios publicaron mensajes transmitiendo sus quejas y decepción ante esta aparente ignorancia de Google por las necesidades de los usuarios de Android con discapacidad visual. Hasta la fecha ningún miembro del equipo de desarrollo de Eyes-free ha dado una respuesta a las decenas de preguntas hechas por los usuarios de Talkback en la lista.

Android puede ser una buena alternativa ante el inminente monopolio que se puede crear en un futuro temprano sobre plataformas accesibles para dispositivos móviles. Symbian está muriendo lentamente, Apple, con iOS, parece ganar cada día más terreno entre los usuarios con discapacidad, alternativas como Samsung Bada o Meego siguen sin una base de accesibilidad y, el gran contrincante de Apple en sistemas operativos para dispositivos móviles, nos referimos a Google, parece que no entiende que las leyes, cada vez más, obligarán a la adquisición de dispositivos accesibles por parte de las administraciones de países y grandes corporaciones.

Un servidor no entiende, actualmente, esta posición de Google de ignorar la necesidad de una solución accesible para Android. No se sabe, a ciencia cierta, si es incapacidad del proyecto Eyes-free por aportar una solución concreta y eficiente de accesibilidad para los usuarios con discapacidad visual. El equipo de desarrolladores ha hecho un buen trabajo con Talkback pero no es un producto terminado. No permite utilizar cualquier dispositivo con Android por parte de una persona ciega, no es compatible con las aplicaciones primarias de Android, como pueden ser el navegador Web o el cliente de correo electrónico. Hay programas alternativos en el Market de Android, la tienda on-line de aplicaciones para Android, pero esto imposibilita el hecho de identificar un teléfono con Android como un dispositivo accesible desde la caja.

Parece que el culpable de este desinterés por la accesibilidad se origina en Google al ver sus más recientes lanzamientos.

Google books, para iOS, es una aplicación para iPhone e iPad que permite acceder, comprar y leer libros en la tienda de libros de Google. La aplicación resulta accesible a la hora de manipular los libros, el acceso a la tienda y falla rotundamente en accesibilidad en su principal función: no permite leer los libros con lectores de pantalla. Un usuario ciego de iPhone o iPad podrá comprar libros electrónicos, ordenarlos en su librería, borrarlos o consultar el catálogo de obras disponibles pero no podrá leer ningún libro que haya adquirido.

Google Chrome OS, el sistema operativo de Google para equipos de sobremesa, ha aparecido sin ninguna característica de accesibilidad. Por no tener, no tiene ni teclas pegajosas, campana de sistema o un tema de alto contraste por defecto.

Esperemos que Google rectifique en su postura y comprenda que la accesibilidad y el diseño para todos son sellos de calidad en los proyectos de hardware y software.

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.