Llega el juez de la Orca

Cerramos la serie presentando la gran novedad en lectores de pantalla, Orca y nos atrevemos a llegar a conclusiones. Por Juan Rafael Fernández García.

Historial de versiones
Revisión 0.1	2007-10-20	jrf
Primera versión CC 2.0 del artículo de Linux Magazine.

Está usted leyendo Llega el juez de la Orca, cuarto de una serie de cuatro artículos sobre la síntesis de voz y la accesibilidad en 2007 publicado por primera vez en el número 27 de la revista Linux Magazine, de mayo de 2007 (pero escrito en febrero de 2007). La versión pdf del artículo puede descargarse en el enlace http://www.linux-magazine.es/issue/27/.

La versión «canónica» del artículo, la única mantenida por el autor, se encuentra en http://people.ofset.org/jrfernandez/edu/n-c/orca_4/index.html. Está publicada por contrato con la editorial bajo licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.0 (-sa-by-nc 2.0).

Índice de la cuarta parte
I. El lector de pantalla Orca
II. Conclusiones no concluyentes
III. Y en el próximo número...

Cuadro 1: Para saber más
Imágenes
Notas

Lectores de pantalla para consola (Primera parte de la serie)
Presente imperfecto, futuro brillante (Segunda parte de la serie)
Síntesis de voz en Gnome (Tercera entrega de la serie)

Esta es la cuarta y última entrega de la serie sobre síntesis de voz en GNU Linux. En las anteriores hemos realizado un recurrido más o menos exhaustivo sobre las soluciones disponibles, pero como de costumbre hemos dejado para el final la propuesta aparentemente preferible. Ya veremos si esta apariencia se sostiene.

I. El lector de pantalla Orca

Orca[1] (en Debian el paquete el paquete se llama gnome-orca para evitar un conflicto de nombres) es la gran novedad de los últimos tiempos en el área de la accesibilidad. Se trata de un lector de pantalla que utiliza gnome-speech para la síntesis de voz y al igual que su antecesora gnopernicus integra todas las ayudas tiflotecnológicas (braille, magnificador, teclado en pantalla). El desarrollo de Orca ha sido liderado por Willie Walker, de Sun Microsystems, Inc., una prueba más del interés de las grandes empresas del software por la accesibilidad (y junto con LSR del apoyo de IBM y Sun al software libre. De nobles es ser agradecidos).

En la tercera entrega habíamos aceptado como un acto de fe la superioridad de orca sobre gnopernicus y como evidente y perentoria su sustitución. Pero somos unos descreídos, ¿verdad? ¿Por qué es mejor orca? Eso mismo se preguntó a la lista gnome-accessibility el 7 de julio de 2006[2]. Intentemos resumir las respuestas: Orca es mejor porque es programable mediante guiones; los guiones permiten controlar cómo habla y actúa en diferentes entornos, especialmente cuando la aplicación que se desea leer no se comporta correctamente desde el punto de vista de la accesibilidad. Orca es mejor porque trabaja en otro plano: para entendernos porque se sitúa mejor entre los objetos de la interfaz de usuario (botones, menúes...) y las interacciones del usuario. También es superior el modo «revisión plana», porque proporciona una imagen bastante buena de la estructura de la pantalla y permite navegar por las barras de herramientas y menúes. Aceptemos que es mejor, entre otras cosas porque gnopernicus no va a evolucionar; probémosla y si no nos convence, nos queda la opción LSR. ¿Cómo funciona orca?

Hemos examinado Orca en tres máquinas distintas, una Edubuntu Edgy, una Debian Etch actualizada (desde Experimental, lamentablemente, ya vimos en la tercera parte que las aplicaciones de accesibilidad más interesantes se habían quedado fuera de la inminente Debian Estable) con los paquetes python-pyorbit_2.14.1-2 (la versión congelada en Etch es la 2.0.1-5 y aunque no figure en las dependencias es imprescindible la actualización) y gnome-orca_2.17.4-1 y una tercera máquina, un portátil con Debian Etch, en la que hemos compilado las últimas versiones disponibles en el repositorio de Gnome de gnome-speech, pyorbit y orca (tenga en cuenta el lector de este artículo que el presente del acto de escritura corresponde a mediados de febrero de 2007 y que ojalá no tenga que entrar en estas profundidades cuando deba hacer frente a las necesidades que resuelve orca).

En las tres máquinas apreciamos distintos niveles de integración del nuevo entorno. En la Edubuntu, es lógico, se lanza desde el punto central de configuración de las preferencias de tecnologías de asistencia, sustituyendo definitivamente a gnopernicus (figura 1). Es importante destacar también que la versión de gnome-speech incluida en esta distribución sólo contiene el controlador para festival. En la Debian mixta creada a mano la entrada «Preferencias» -- «Accesibilidad» -- «Soporte para tecnologías de asistencia» sigue llevando a la configuración de gnopernicus, normal. Tampoco aparece en «Aplicaciones» -- «Accesibilidad» ni en parte alguna del menú de Gnome. Para llegar a la configuración de orca hay que abrir una terminal y lanzar directamente

La figura 2 nos muestra que el controlador festival puede utilizar las voces mbrola adaptadas que habíamos añadido en la primera parte de nuestro estudio.

Exploremos Orca en la versión más actual. La figura 3 nos muestra cómo reclama el papel de lector de pantalla y magnificador en paralelo a gnopernicus (inmediatemente después procedimos a desinstalar este para evitar conflictos). Si pulsamos en «preferencias» tras ejecutarlo (o siempre que lancemos la aplicación con el parámetro -- setup) nos aparecerán las opciones de configuración. Son importantes para nuestro estudio las pestañas que tienen que ver con la síntesis de voz y los atajos de teclado.

En las preferencias relacionadas con el sistema de voz (figura 4) nos aparece de forma predeterminada como sintetizador de voz el controlador de Gnome para festival, y si vamos a trabajar en alguno de los idiomas para los que existen voces para festival no deberemos modificarlo. Pero ahora al fin tenemos otras opciones, del mismo modo que anteriormente podíamos cambiar de motor de síntesis con test-speech: podemos alternar entre los controladores de festival, eSpeak o speech-dispatcher (figura 5), y las voces que hemos configurado para cada uno de ellos. Es el momento adecuado de recordarlo: todas las novedades que estamos documentando son experimentales, y por tanto inestables. Es justo anunciarlo y reiterar que las cosas pueden fallar en el momento más inesperado; no sería la primera vez que fallaran en mitad de una presentación pública (a un servidor le ocurrió ayer mismo). Quien experimenta se arriesga; quien busque estabilidad que use una versión estable.

La pestaña de la figura 6, «Atajos de teclado», nos sirve para configurar las combinaciones de teclas que nos permitirán controlar orca y también como recordatorio de los atajos definidos. Un consejo: antes de jugar con orca debemos aprender las combinaciones que nos permitan realizar las tareas más importantes. Primeramente activar y desactivar la síntesis (en el portátil con Bloq. May. + s); escuchar continuamente este tipo de voces puede con la paciencia de cualquiera, pensemos que normalmente los discapacitados visuales utilizan la síntesis de voz junto a un dispositivo braille, para confirmar y aclarar el contenido de la pantalla. Lo segundo que tenemos que aprender de memoria es a hacer reaparecer la ventana de configuración (Bloq. May. + barra espaciadora).

Nos dicen que lo interesante de Orca son los guiones. ¿Qué guiones? En la carpeta /usr/local/lib/python2.4/site-packages/orca/scripts/ (recordemos que hemos hecho una instalación local) tenemos la lista: guiones para metacity, nautilus, evolution, acroread, mozilla, staroffice, gaim, lifearea... un listado no tan incompleto como podríamos pensar para una tecnología tan novedosa.

Y sin embargo todavía no nos hemos puesto manos a la obra. Para usar Orca disponemos de la estupenda ayuda en castellano que nos proporcionan las páginas del wiki de Tiflolinux[3]. Vamos a experimentar lo que puede parecer uno de los casos más complicados: la lectura de un fichero pdf. Seguimos las instrucciones del documento, instalamos los plugins de acroread (usando los paquetes Debian de Marillat; evince etc. no valen), habilitamos la accesibilidad (figura 7) y reactivamos la voz (Bloq. May. + s) ¡Funciona! (para ser sinceros funciona en la mayoría de las ocasiones pero también se encuentran algunas pegas, falla con los acentos en algunos documentos y también con un documento a tres columnas, será cuestión de investigar las causas).

Bien, pero este artículo trata de la síntesis multilingüe, ¿cómo se cambia de idioma? Llamando a la ventana de configuración de preferencias y cambiando de motor y/o persona (es decir, de voz). Con las precauciones de quien está tratando de desarrollos experimentales, y con las diferencias de calidad que dependen de las distintas voces disponibles, si todo funciona podemos cambiar de una voz con acento más o menos marcadamente norteamericano a una voz neutra española.

II. Conclusiones no concluyentes

Bien, empecemos insistiendo en que lo visto es experimental, sujeto a errores y cambios importantes, pero también esperanzador. Nunca hemos estado tan cerca de una interfaz auditiva accesible, y nunca de que la síntesis de varios idiomas esté al alcance de todos.

El lector de pantalla (con permiso de LSR) para Gnome es Orca. Orca permitirá la utilización por parte de las personas con discapacidad visual de las mismas herramientas (OpenOffice, firefox/iceweasel...) que el resto de los usuarios. El «para Gnome» es la pega: es necesario desligar la tecnología utilizada en Orca de las dependencias de Gnome para que pueda utilizarse en cualquier otro entorno, KDE o XFCE. Se está trabajando en este sentido, esperamos que el lector tenga en la memoria la «carta de la accesibilidad» del Free Standards Group (documentada en la segunda parte de la serie).

Es necesario dar respuesta a la segunda exigencia que nos planteábamos al comienzo y aplazábamos hasta conocer las opciones disponibles: una instalación y un inicio del sistema accesibles. No es aceptable hacer esperar a que el sistema operativo esté plenamente cargado y se inicien las X para que la síntesis se active: ¿qué ocurre si algo falla en el proceso? ¿cómo puede alguien desprovisto de visión tener acceso a los mensajes de error del núcleo?

Después de las últimas discusiones en la lista de accesibilidad en Debian[4] podemos tener claro que es muy difícil que SpeakUp, la candidata a solución integrada en el núcleo, pase un un plazo corto de tiempo a incorporarse a los núcleos generalistas. Problemas de actitud de los desarrolladores y errores técnicos en el enfoque de los dispositivos serie que hacen inseguro e inestable el núcleo la descartan. Además hemos aprendido en ese hilo que las máquinas de síntesis por hardware son restos del pasado próximos a su desaparición y que por tanto el uso que nos quedaba de SpeakUp tenía que esperar a la carga de los controladores por software (recordemos que necesitábamos la presencia de speech-dispatcher y speechd-up). Pero si descartamos una solución de síntesis integrada en el núcleo sólo nos quedan las disponibles en el espacio de usuario, que no nos sirven para ser testigos auditivos del inicio del núcleo.

El caso del instalador es diferente: puede cargarse un motor ligero (eSpeaker directamente o speech-dispatcher con algún motor) que actúa durante el proceso de instalación, y después dar paso a motores de más calidad.

Pero es más, para salvaguardar la autonomía de los usuarios la exigencia de accesibilidad debe estar presente desde el mismo gestor de arranque, sea grub o uno alternativo y de hecho lo está en las distribuciones más actuales. Un sistema de señales auditivas informativas (agudo = éxito; grave = error) y una tecla de función debe permitir activar los servicios de accesibilidad e incluso optar por un núcleo especializado.

Nos queda una pregunta, ¿tiene sentido el mantenimiento de soluciones para consola? En principio mientras haya desarrolladores dispuestos a trabajar en ellas no hay problema, y es verdad que en la mayor parte de las ocasiones en la consola el trabajo será más ágil y se podrán realizar la mayoría de las tareas. Pero mi impresión es que la velocidad de la evolución de la informática y de los servicios y entornos que se están creando en la red por una parte, y la exigencia de igualdad de oportunidad de acceso por otra exigen más bien el logro de condiciones de accesibilidad plena para todas las herramientas generalistas; nunca un pequeño equipo de desarrolladores podrá seguir el paso de proyectos gigantes como un navegador web de última generación.

La síntesis de voz no es una necesidad exclusivamente tiflotecnológica. Tiene aplicaciones en la enseñanza de idiomas, pero tampoco se limita a esta; en un mundo plural son pensables abundantes usos nuevos: es cada vez más normal y deseable en trabajo en varios idiomas, un usuario puede preferir escuchar las páginas web por las que navega a leerlas o puede utilizar un reproductor de sonido portátil para escuchar una novela en formato pdf. La interfaz visual de usuario fue un gran invento de los años 60, lo que no tiene sentido es que no hayamos sido capaces de desarrollar otras interfaces. Es más, el trabajo que se está realizando consiste en verbalizar la interfaz visual (botones, menúes), y se podría ir más allá, hacia una abstracción mayor: documento, abrir, mensaje de correo, redactar...

Lo hemos consultado[5]: no se ha pensado aún un sistema automatizado para que el sistema pase de la síntesis en un idioma a la de otro e implicará la introducción de tecnologías de marcado de idiomas que no están generalizadas. Ahora mismo no tenemos más que los cambios manuales que hemos practicado antes, más o menos sencillos dependiendo de si el cambio de lengua implica un cambio de motor de síntesis o no.

Finalmente, nos queda pendiente también la solución a las colisiones de los sistemas de audio y de síntesis. Pero es el momento de cerrar la serie. Una serie inconclusa porque la solución definitiva, válida para todas nuestras exigencias, todavía no existe. Y sin embargo estamos cada vez más cerca.

III. Y en el próximo número...

Cerrar un ciclo de artículos tiene algo de abandono y derrota. ¡Qué mal resumimos tal punto en la primera entrega, los problemas de speakUp por ejemplo! ¡cómo vamos a cerrar la serie sin hablar del documento de «Requisitos de accesibilidad de los sistemas de audio» de Hynek Hanke, donde enumera las condiciones que los servidores de audio deben de cumplir para ser compatibles con las exigencias de la accesibilidad[6]! Por no hablar del pasado: tienen razón los amigos que opinaban que las entregas sobre los usos de moodle hubieran requerido alguna otra adicional y más carne en un armazón demasiado esquemático. Pero todo termina, los plazos deciden por nosotros. Quizás no sea tan malo.

Y quedan tantos temas fascinantes, las bitácoras educativas desde el punto de vista de un escéptico 2.0. Y eXe-learning, y el entorno de participación social Elgg, los portfolios electrónicos... cuando empezamos a escribir estos artículos sabíamos que en el campo del software educativo estaba todo por hacer.