En este artículo nos enfrentamos al tema de la accesibilidad y la tecnología adaptativa desde un punto de vista educativo. Daremos un repaso al estado actual de las soluciones y normas relacionadas con la atención a la diversidad que tiene origen en discapacidades perceptivas o cognitivas y trataremos de demostrar que el software libre está llegando a la madurez en este campo también. Por Juan Rafael Fernández García.
Historial de versiones | ||
---|---|---|
Revisión 0.3 | 2006-12-01 | jrf |
HTML 4.01 Transitional clean. | ||
Revisión 0.2 | 2006-09-03 | jrf |
Correcciones estéticas; versiones. | ||
Revisión 0.1 | 2005-10-01 | jrf |
Primera versión CC 2.0 del artículo de Linux Magazine. |
Nota legal. Este documento, el primero de una serie de dos artículos dedicados al estado de la accesibilidad en GNU Linux, fue publicado por primera vez en el número 6 de la revista Linux Magazine, de junio de 2005 (pero escrito en abril del mismo año). La versión pdf del artículo puede descargarse en el enlace http://www.linux-magazine.es/issue/06/.
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/a11y_1/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 primera parte
I. Idades varias
II. Tamaños y colores
III. Síntesis del habla
IV. El teclado
V. El ratón
VI. Reconocimiento del habla
VII. Y en el próximo número...
Imágenes
Notas
Balance de la situación actual
(Segunda parte del artículo)
Un artículo sobre accesibilidad no está tan lejos de un artículo sobre localización como podría pensarse[1]: ambas tecnologías están destinadas a solventar los problemas que presenta la diversidad de nuestros alumnos, sea lingüística y cultural, sea perceptiva o intelectiva; y para ambos tendremos que bucear en la configuración no estándar de los dispositivos de interrelación con el ordenador. Siento que el artículo que ahora me propongo escribir es urgente porque es un campo bastante desconocido en castellano y poco tratado en inglés. La última versión del Linux Accessibility HOWTO (hay traducción: Accesibilidad-Cómo[2]) es de 2002, y que yo sepa no existe un repaso de las nuevas iniciativas y desarrollos desde un punto de vista educativo. Y sin embargo el asunto está de plena actualidad: las administraciones públicas están llegando a acuerdos con instituciones como la ONCE para trabajar en la adaptación del software educativo[3] a las necesidades de los alumnos discapacitados. ¿Qué hay hoy día? No soy especialista en el campo pero espero abrir un camino que otros recorran.
Cuando el dios Theuth le presentó al rey de todo Egipto Thamus su invención de las letras con las palabras «Este conocimiento, oh rey, hará más sabios a los egipcios y más memoriosos, pues se ha inventado como un fármaco de la memoria y de la sabiduría»[4] estaba presentando la tecnología como una ayuda, como prótesis de los seres humanos. ¿Qué son una estaca, un abrigo, un coche, sino extensiones que nos hacen más fuertes, más adaptables a nuevos medios y más rápidos que los seres de la naturaleza? Hace tiempo que pienso que lo mejor de los libros es que nos permiten escuchar a los mejores de todos los tiempos, consiguen que Aristóteles me hable y puedo utilizar libros para aprender a leerle en el griego en el que daba sus conferencias (y desde el artículo anterior puedo escribirlo en mi portátil). Hoy día un ordenador es una máquina que nos completa, que hace de memoria y nos ahorra cálculos, que nos permite comunicarnos con personas que no están físicamente presentes y obtener información instantáneamente. Todos los humanos necesitamos ayudas.
Los teóricos se llenan la boca de las palabras usabilidad y accesibilidad. Hasta tenemos una nueva abreviatura para geeks, a11y. Pensemos la relación entre ambos conceptos y su importancia. Según la wikipedia «la usabilidad es la medida de la facilidad de uso de un producto o servicio, típicamente una aplicación software o un aparato. Generalmente se define en términos de las necesidades de los usuarios de dicho producto o servicios (...) Así pues, la usabilidad se encarga de todo lo que influya en el éxito y la satisfacción del usuario.» En cambio la accesibilidad indica «la facilidad con la que algo puede ser usado, visitado o accedido en general por todas las personas, especialmente por aquellas que poseen algún tipo de discapacidad. Para promover la accesibilidad se hace uso de ciertas facilidades que ayudan a salvar los obstáculos o barreras de accesibilidad del entorno, consiguiendo que estas personas realicen la misma acción que pudiera llevar a cabo una persona sin ningún tipo de discapacidad. Estas facilidades son llamadas ayudas técnicas.» Basta leer las dos definiciones para darse cuenta de que los dos conceptos comparten el 99% de su genoma: se basan en la facilidad de uso y se distinguen por los destinatarios. La usabilidad tiene destinatarios específicos, un target, luego es un concepto con un origen posiblemente comercial; por el contrario la accesibilidad generaliza. Y tiene su apoyo en obligaciones impuestas por las legislaciones nacionales. Quizás debamos insistir en esta distinción: la primera tiene que ver con la eficacia; la segunda con los derechos de todos al acceso a las nuevas tecnologías. Y del mismo modo que no podíamos aceptar una informática para occidentales que se defiendan en inglés, no podemos aceptar páginas o herramientas que excluyan a los que son diferentes.
Los entornos integrados de escritorio (Gnome, KDE) han especificado normas que deben cumplir las aplicaciones creadas con sus herramientas de desarrollo[5]. Estas guías pretenden definir un concepto bastante borroso, el de la intuitividad. Había un chiste de firma de correo electrónico que decía que la única interfaz intuitiva es el pezón; yo diría que llamamos intuitivo a a aquello a lo que nos hemos acostumbrado, como a que haya una opción «Guardar» bajo la entrada de menú «Archivo». Estas guías inciden en la integración y coherencia de la interfaz de usuario, y en el énfasis en la usabilidad y la accesibilidad.
Este artículo ha sido escrito dos veces, y espero tener que volver a redactarlo con las aportaciones y críticas que genere. Comencé con el enfoque que me parecía evidente, los discapacidades, hasta que me di cuenta de que herramientas de generación del sonido hablado las podemos necesitar todos, o que la informática debe responder a la cuestión del tamaño de los tipos de letra en terminales de cualquier tamaño, o prever salidas alternativas a la visual. En el momento actual está ordenado por tecnologías, por supuesto pensando siempre en su función auxiliar.
Empecemos por lo evidente, con perdón. Aquí y en el extranjero las adaptaciones más desarrolladas están dirigidas a las personas con discapacidades visuales. Siguen distintas estrategias, dependiendo del tipo de discapacidad. Pero es importante que estén integradas en la interfaz de usuario y no depender de aplicaciones individuales: la solución no está en poder utilizar unas pocas aplicaciones adaptadas, sino en que todo el entorno esté modificado en función de las necesidades del usuario.
Los nuevos entornos integrados son configurables desde el arranque: en la figura 1 vemos la ventana de configuración de las tecnologías de asistencia en Gnome. Para empezar los escritorios permiten configurar el tamaño de letra y ventanas y el número y contraste de colores simultáneos mediante lo que llaman temas; se han creado temas especiales de alto contraste, y las personas con problemas de daltonismo o disfunciones neurológicas de cualquier tipo pueden configurar el comportamiento cromático de todo el entorno. En la figura 2 hemos seleccionado un tema de alto contraste, y además hemos reducido la resolución de pantalla para que todo aparezca de mayor tamaño.
Es tradicional también el uso de lupas y ampliadores de zonas de pantalla, desde el clásico xmag hasta los integrados magnifier o kmag. La imagen 3 nos muestra en acción lo que los traductores de Gnome llaman el magnificador de pantalla.
Una última adaptación tiene que ver con los llamados timbres o pitidos (beep) visuales: el sistema no puede esperar que los usuarios oigan basándose en alarmas sonoras; el funcionamiento de un programa en su interacción con el usuario tiene que ofrecer una vía alternativa de información, en este caso visual (parpadeos, ventanas emergentes), para comunicar avisos o solicitar decisiones.
Es fácil no caer en la cuenta: pensamos en accesibilidad y pensamos en la ceguera; y sin embargo alguien que no ve no necesita una interfaz gráfica de usuario. Los invidentes se bastan con una terminal, incluso una consola. Un ciego no necesita ventanas. Y todos sabemos que Linux y los sistemas operativos Posix son el paraíso de los amantes de la línea de órdenes: con la línea de órdenes se navega por internet, se chatea, se escucha música, se programa, se imprime, se investigan los problemas leyendo los registros, se solucionan.
¿Cómo lee una pantalla un ciego? Pidiéndole al ordenador que lea para él. Es decir, con un programa de síntesis de voz.
Aunque existen sintetizadores hardware que funcionan con GNU Linux (puede consultarse la lista en el Accesibilidad-Cómo o en la ayuda de emacspeak: DoubleTalk PC, DoubleTalk LT, LiteTalk, Braille `n Speak, Type `n Speak, Braille Lite, Apollo 2 from Dolphin, or Accent SA) e IBM creó una versión de ViaVoice para GNU Linux, la síntesis de voz por software se llama festival, obra del Centre for Speech Technology Research de la Universidad de Edimburgo (por completar la exploración diremos que flite ---festival light--- es su versión ligera, y hay otro motor, FreeTTS, que funciona en java). Los programas de síntesis del habla necesitan bibliotecas de voces, que en nuestro caso están proporcionadas por FestVox (algunas de estas voces son no-libres en sentido Debian) o Mbrola.
Festival puede utilizarse como un programa de línea de órdenes; podemos utilizar la siguiente línea para escuchar este mismo artículo
festival --language spanish --tts accesibilidad.txt
Mi experiencia es que la calidad de la salida dependerá de la calidad de la voz. La voz en castellano (festvox-ellpc11k) suena bastante metálica y artificial, es la voz de una máquina, pero totalmente inteligible; las voces en inglés están bastante más avanzadas.
Pero hablábamos de integración plena: veíamos en la figura 1 que era posible configurar nuestro ordenador para que desde el primer momento el sistema nos diera una respuesta auditiva; esto se logra instalando festival como un servicio y activando el lector de pantalla de gnopernicus (Gnome), kmouth o KTTS, KDE Text-to-Speech System (KDE).
Insisto: ¿para qué quiere un ciego ventanas? Los sistemas anteriores son útiles para paliar discapacidades visuales no severas, pero ahora necesitamos soluciones alternativas. Necesitamos lectores de pantalla. La primera opción la proporciona como siempre emacs (¿saben el chiste? Emacs es un gran sistema operativo, lástima que no tenga un buen procesador de textos) con speech-dispatcher y Emacspeak. El Accesibilidad-Cómo nos relaciona otros cuantos lectores, con salidas a hardware o por software. Entre ellos speakup necesita que se parchee el núcleo (en Debian disponemos de los parches para los núcleos 2.4.x); he encontrado referencias a que Janina Sajka, directora de investigación y desarrollo de tecnología en la Fundación Americana para Ciegos (http://www.afb.org) y ciega ella misma, lo utiliza. screader está disponible en Debian y tiene salida para festival.
Ya sabemos mucho sobre la configuración a bajo nivel del teclado porque hemos trabajado en la instalación de distintos mapas de teclado. Ahora vamos a intentar dar respuesta a aquellos alumnos que tienen problemas motóricos a la hora de pulsar de forma coordinada las teclas y no pueden utilizar un ratón.
En primer lugar creo que todo el mundo sabe ya que nuestra configuración de teclado qwerty está diseñada expresamente para dificultar el tecleado. Tiene su origen en la necesidad de ralentizar las pulsaciones porque la mecánica de las máquinas de escribir iniciales no podían seguir el ritmo de un mecanógrafo experto: se dispersaron las teclas correspondientes a los caracteres y combinaciones más frecuentes, de manera que los dedos tuvieran que recorrer el máximo espacio y tardaran el máximo de tiempo. Esta disposición era provisional y hoy día absurda; fue corregida en los teclados Dvorak, y sólo una inercia incomprensible —y muy humana— nos hace resistirnos a aprender ¡y a enseñar! una solución tecnológica que es manifiestamente mejor. ¿Pero no es eso lo que le pasa a GNU Linux?
Es posible manejar un entorno de ventanas sin el uso del ratón. De hecho si lo que utilizamos con más frecuencia es un editor de textos y quizás un navegador nuestro trabajo será más rápido sin el ratón, porque no deberemos levantar los dedos de las teclas para ir a coger el apuntador. Centrándonos en Gnome, hay una serie de combinaciones de teclas predefinidas para las tareas más frecuentes (se les llama «atajos» y suelen aparecer como recordatorio en los menúes), y es posible configurar estas combinaciones para evitar interferencias entre programas y adaptarlas a nuestro gusto o nuestras posibilidades. Quizás la combinación más importante que debamos aprender es Alt-F1, que nos despliega el menú de aplicaciones. Alt-Tab recorre cíclicamente las aplicaciones abiertas, Alt-F4 cierra la aplicación que tenga el foco... El inconveniente evidente es que deberemos recordarlas.
Pero las personas que no pueden manejar un ratón probablemente necesiten ayuda en su manejo del teclado. La extensión AccessX del protocolo X cubre este campo[6]. En primer lugar es posible definir «teclas lentas» (figura 4), procedimiento por el que sólo se recoge una pulsación de tecla si se mantiene pulsada durante un tiempo definido; las teclas lentas responde al problema de filtrar las pulsaciones involuntarias de personas con problemas de coordinación en sus movimientos. De forma relacionada, existen las «teclas de rebote», filtro por el que se puede definir el tiempo a partir del cual se rechaza una pulsación mantenida o repetida y se devuelve una señal anunciándolo. Las «teclas de conmutación» devuelven una señal (normalmente un beep auditivo) cuando se pulsa una tecla de conmutación (mayúsculas...). Por último explicaremos el concepto de «teclas persistentes» (sticky keys, «pegajosas» ha traducido el equipo de KDE; figura 5): permiten sustituir las combinaciones simultáneas de teclas por pulsaciones consecutivas.
¿Es posible emular el ratón con un teclado? Sí, activando las «teclas del ratón». Con ellas activadas es posible utilizar el teclado numérico para dirigir los movimientos del puntero.
No he encontrado documentación específica actualizada sobre el uso de teclados especializados, adaptaciones para una sola mano, etc., salvo las capacidades de configuración del protocolo XKB.
Hemos hablado del manejo de la interfaz con la única ayuda del teclado; puede darse el caso contrario: el usuario sólo puede utilizar un apuntador de algún tipo, y no puede acceder al teclado. Recordaremos que para el sistema operativo los ratones son dispositivos que envían señales que se traducen a posiciones en la pantalla y a pulsaciones; cualquier dispositivo del que se conozca la señal, sea ratón, joystick, mando a distancia o switch puede hacer el papel de apuntador. Y las versiones modernas de las X Windows permiten el uso simultáneo de dos apuntadores, se forma encadenada (uno es dominante) o independiente entre ellos. Cualquier switch de los que se utilizan en educación especial es factible de ser utilizado también en GNU Linux: sólo depende de que se comunique con el sistema operativo mediante estándares conocidos o se hagan públicas sus especificaciones.
KMouseTool es una aplicación de KDE que realiza los click por el usuario. Está pensado para personas que sufren dolor al pulsar el ratón (cada vez son más frecuentes tendinitis, síndrome del túnel carpal...). Actúa cuando el puntero se detiene brevemente (el tiempo es configurable) disparando un click. En el modo de arrastre deja pulsado el apuntador y espera antes de liberarlo; si durante esta pausa movemos el ratón espera a que terminemos antes de dejar de pulsar.
Para sustituir al teclado se dispone de los llamados «teclados de pantalla» o «teclados virtuales». El más elemental es el que recoge la imagen 6: xvkbd muestra un mapa del teclado en pantalla y permite la pulsación sobre una tecla que se envía al programa que tenga el foco.
Más desarrollado y complejo de uso es gok, el «Gnome On-screen Keyboard» (figura 7). No se limita a mostrar una copia virtual de teclados reales; puede crear teclados que, de forma dinámica, en función del contexto, incluyan teclas para lanzar aplicaciones, u opciones de la interfaz de usuario de la aplicación que tenga el foco. Esta función proporciona un acceso eficiente a los elementos de la interfaz y elimina la necesidad de utilizar el teclado y sus atajos.
En otro orden de cosas, una alternativa a la entrada por teclado de textos es el uso de sistemas de entrada predictiva. Dasher (figura 8) está diseñado para situaciones donde la entrada por teclado es impráctica (PDAs, móviles) o imposible (movimiento del puntero con la cabeza o los ojos). Es un programa internacionalizado, se puede trabajar en español, y en las pruebas lo he encontrado algo inestable.
Según la definición de Romañach Cabrero en el documento de la ONCE citado en la bibliografía, la tecnología de reconocimiento de voz «consiste en registrar la voz del usuario y, a partir del análisis de la forma y del mensaje de la voz, realizar tareas predeterminadas. Su uso más habitual es la conversión del mensaje hablado a texto escrito (dictado automático de documentos) y el manejo de un ordenador». Sobre esta última función, el manejo del ordenador, se ha trabajado en Linux.
El «Accesibilidad-Cómo» habla de FreeSpeech (http://freespeech.sourceforge.net), del proyecto OpenMind. He explorado las páginas del proyecto y no encuentro ficheros posteriores a 2002, y aunque la lista de correo sigue viva (con dos mensajes en lo que va de año) deduzco que es un proyecto no muy activo. Espero que alguien desmienta esta afirmación. CVoiceControl (http://www.kiecza.net/daniel/linux/) es un proyecto de Daniel Kiecza abandonado en 2002. Ambas aplicaciones tenían un aspecto alentador. Otras soluciones (por ejemplo Xvoice) dependen de la presencia en el sistema del motor no-libre de IBM ViaVoice Dictation for Linux.
Cambiando de aires, Robert Tucker, en correo a la lista <linuxfortranlators@yahoogroups.coms> de 6 de marzo de 2005, nos pone al día del estado de la tecnología del reconocimiento del habla en GNU Linux. Informa de que «en la actualidad los dos proyectos más avanzados de reconocimiento del habla en Linux son Sphinx y Perlbox».
Sphinx ( http://cmusphinx.sourceforge.net/html/cmusphinx.php) no es una aplicación destinada a usuarios finales, sino un conjunto de bibliotecas. Han sido desarrolladas y utilizadas por compañías telefónicas (incluida Telefónica I+D) para sus servicios de contestador automático y atención automatizada al cliente. Mantiene tres versiones simultáneas: Sphinx-2 es la versión más rápida y ligera; Sphinx-3 es más avanzada y precisa, mientras que finalmente Sphinx-4 está escrita en java. Sphinx-2 es la única de las tres versiones que funciona en tiempo real.
Perlbox Voice (figura 9) es una aplicación perl-Tk que utiliza festival para generar habla y Sphinx-2 para convertir órdenes habladas de un diccionario a órdenes que la máquina entiende (abrir una ventana, lanzar navegador...). En el foro del sitio web de la aplicación se ha discutido la adaptación a idiomas diferentes del inglés; no me consta que se haya terminado.
No conozco ninguna aplicación libre que permita el dictado de texto sin restricciones. Y sin embargo tengo la impresión de que la tecnología, Sphinx, está ahí, que sólo falta un proyecto que ate los cabos sueltos y se los ponga al alcance del usuario final.
Hasta ahora sólo hemos tocado la superficie de la accesibilidad en GNU Linux[7]. Debemos examinar los sistemas alternativos de comunicación entre la máquina y el ordenador (morse, braille), la disponibilidad o no de aplicaciones destinadas a los alumnos con deficiencias cognitivas, la accesibilidad en la web, un cambio de enfoque para examinar todas estas herramientas y especificaciones desde el punto de vista pedagógico, el necesario balance final... ¿Nos vemos en el próximo número?
[1] Este arranque no se comprende sin saber que los artículos sobre accesibilidad siguen a otra serie de dos artículos sobre internacionalización y multilingualización del software.
[2] Los Cómo del LDP, Libre Documentation Project están disponibles en el paquete doc-linux-html; existe traducción en el sitio de la sede española del LDP (http://es.tldp.org) y paquete Debian doc-linux-es.
[3] Ejemplo en Andalucía:
http://www.andaluciajunta.es/SP/AJ/CDA/ModulosComunes/MaquetasDePaginas/AJ-vMaqCanalNot-01/0,20446,214288_214445_70680,00.html.
Lo que habría es que comprobar es el seguimiento del proyecto;
existe el antecedente de 11Linux (ftp://ftp.once.es/pub/accessibility/Linux/OnceLinux/),
abandonado (¿terminado?) desde el año 2000.
[4] Platón, Fedro, 274a ss.
[5] Véanse las GNOME Human Interface Guidelines 2.0, disponibles en el paquete doc-gnome-hig.
[6] http://accessibility.freestandards.org/modules.php?name=Content&pa=showpage&pid=34 nos recuerda que gran parte de estas soluciones ya estaban prefijadas en las especificaciones del protocolo XKB. El grupo de trabajo se plantea como objetivo «identificar y adoptar un subconjunto de la especificación XKB que permita proporcionar las propiedades y comportamientos estándar del teclado que necesitan las personas con problemas de movilidad».
[7] Para leer más:
(a) Linux Accessibility Resource Site, LARS
(http://lars.atrc.utoronto.ca/)
(b) Josephine Ciuca, «Speak to me, Linux», en http://applications.linux.com/applications/05/01/18/2148234.shtml, 19 de enero de 2005
(d) Noticia «Software libre y personas disminuidas», de amphora, en Libertonia (http://libertonia.escomposlinux.org/story/2003/6/13/1729/26171), junio de 2003
(e) Hilo abierto por Javier Sánchez, cicero, en Barrapunto en julio de 2004 (http://barrapunto.com/article.pl?sid=04/07/18/0919243&mode=thread).