A medida que se acerca el siglo XXI, los mercados se van haciendo más exigentes y los productos dan cada vez más y mejores servicios. Se refuerza la corriente de diseño para todos, que implica contemplar los requisitos de todos los posibles usuarios desde las primeras fases de los diseños de productos, de manera que las personas mayores y las personas con discapacidad se convierten en una parte importante de los posibles clientes. Así, los teléfonos con teclas cada vez más grandes, los mandos a distancia con botones grandes y simplificados, los ascensores parlantes, etc. se están convirtiendo en productos cuyo consumo se ha disparado en los últimos años.
El mundo de la informática es también un mercado en el que las personas con discapacidad se están convirtiendo en clientes potenciales muy importantes, como demuestra el acuerdo realizado recientemente entre la ONCE y Microsoft para adaptar la siguiente versión de su sistema operativo Windows NT.
La personas con discapacidad ven así como poco a poco los ordenadores y sus programas se van haciendo accesibles y se convierten, además de su herramienta de trabajo, en un elemento fundamental en el proceso de su integración social.
La accesibilidad a las plataformas informáticas (ordenadores y sus programas) venía hasta ahora apoyada en el desarrollo de productos específicos, tanto a nivel de software como de hardware, de manera que cada tipo de discapacidad precisaba de accesorios peculiares o programas específicos, como los sintetizadores de voz para las personas con discapacidad visual o los emuladores de ratón para las personas con discapacidad física.
Sin embargo, la progresiva incorporación de nuevas tecnologías, como servicios multimedia o reconocimiento de voz permiten afrontar el siglo que viene con el convencimiento de que el diseño para todos permitirá que los futuros ordenadores y sus programas vengan preparados para que los manejen las personas con casi todo tipo de discapacidad sin necesidad de utilizar ningún tipo de accesorio.
La variedad de la problemática de acceso que se presenta en función de las diversas discapacidades, han hecho necesaria la recopilación de todos los problemas de accesibilidad en dos documentos, estructurados como dos normas de AENOR (Asociación Española de Normalización y Certificación), que contemplan todos los posibles problemas detectados para discapacidades visuales, auditivas, físicas y psíquicas, en lo referente al interfaz de usuario, tanto del soporte lógico (software), como del soporte físico (hardware), además de a la documentación asociada a estos productos.
Las personas ciegas tienen su principal barrera de acceso a la informática en la obtención de información que está presentada de forma visual. Muchos de los usuarios de informática que son ciegos utilizan "lectores de pantalla" para comunicarse con los ordenadores. Los "lectores de pantalla" facilitan una descripción hablada o en Braille de las ventanas, controles, menús, imágenes textos y otras informaciones que puedan aparecer en pantalla.
Las personas con problemas de visión, que no son ciegas, utilizan diferentes métodos para aumentar el tamaño, el contraste o las características generales de visibilidad, en función de sus necesidades visuales. Los elementos más utilizados son los monitores grandes, tamaños de letra grandes, alto contraste, y la ampliación (hardware o software) de zonas de la pantalla.
Las personas con dificultades auditivas que no alcanzan la sordera tienen problemas con los cambios y determinados rangos de frecuencia y para localizar y distinguir determinados sonidos. Normalmente utilizan la opción "ShowSounds" (mostrar sonidos) que ya proveen algunos sistemas operativos y que permiten tener una información visual relacionada con los sonidos que se generan en el uso del ordenador.
Además de tener problemas para detectar informaciones auditivas, los usuarios sordos no suelen ser capaces de hablar de manera que sea reconocida por los sistemas informáticos de reconocimiento de voz.
Las dificultades de las personas con problemas físicos suelen ser derivados de su falta de coordinación, su debilidad, la dificultad para alcanzar las cosas o la imposibilidad de mover alguna o algunas extremidades.
Este tipo de personas pueden o no utilizar dispositivos específicos de naturaleza tan variada que no se pueden describir todos en poco espacio. Algunos ejemplos son los dispositivos de seguimiento de ojos, los teclados en pantalla, los sistemas de reconocimiento de voz y los punteros alternativos (licornios, punteros de manos, etc.).
Todas estas dificultades y más que no han sido descritas han sido tenidas en cuenta en el desarrollo de las normas AENOR, aunque el enfoque haya sido más orientado a los elementos que componen el interfaz de usuario, que a los problemas característicos de cada discapacidad.
Además la norma afecta muy poco a las partes internas o capas inferiores del software, de manera que se limita a hacer una aproximación desde el punto de vista de la usabilidad de las plataformas, manteniéndose alejada de los detalles internos y de construcción de los elementos que conforman las plataformas informáticas.
A lo largo de más de 153 elementos normativos, se describen uno por uno los requisitos que deben cumplir tanto el hardware como el software para que no presenten ningún problema de accesibilidad. Para cada elemento normativo se especifica el tipo de discapacidad que se ve afectado y se da una breve explicación del concepto.
Un ejemplo de un elemento normativo es el siguiente:
Todos los iconos deben tener asociada una etiqueta de texto y se debe facilitar una opción que permita ver sólo esa etiqueta.
Grupo destinatario: LV, LC, LP, LSCNota - Los iconos no son siempre comprensibles para personas con limitaciones psíquicas. Además si sólo fueran gráficos resultarían inaccesibles a personas con discapacidad visual que utilicen lectores de pantalla.
Donde LV, LC, LP, LSC indica que este elemento afecta a personas con limitaciones visuales, personas ciegas, personas con limitaciones psíquicas y personas sordociegas.
La norma que afecta al hardware se llama "Informática para la salud. Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad de las plataformas informáticas. Soporte físico." y tiene como número de norma 139.801. En ella se contemplan los aspectos de accesibilidad de la unidad central, la pantalla, el teclado, el ratón y los periféricos.
La norma que afecta al software se denomina "Informática para la salud. Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad de las plataformas informáticas. Soporte lógico." y tiene como número de norma 139.802. En ella se describen los problemas de accesibilidad separando los que afectan al sistema operativo, a las aplicaciones y a Internet.
La longitud de los nombres de las normas viene derivada del propio proceso normativo que especifica AENOR. La realización de la norma se ha llevado a cabo dentro del grupo de trabajo 1 del AEN/CTN139/SC8 (Subcomité 8 - Sistemas y Dispositivos para los grupos de Tercera Edad y Discapacitados del Comité Técnico de Normalización 139 - Tecnologías de la Información y las Comunicaciones para la Salud de AENOR)
La norma ha sido elaborada por especialistas de la Universidad Politécnica de Madrid (Escuela Técnica Superior de Ingenieros de Telecomunicaciones, Facultad de Informática, Escuela Universitaria de Informática), FUNDESCO (Fundación para el Desarrollo de las comunicaciones de Telefónica), Hospital Nacional de Parapléjicos, CEAPAT (Centro Estatal de Ayudas Técnicas del IMSERSO) y COCEMFE (Confederación Estatal de Federaciones de Asociaciones de Minusválidos Físicos de España). Este grupo de personas tiene amplia experiencia en el campo de la tecnología y la discapacidad y ha recopilado información de los centros más avanzado del mundo en esta especialidad.
El carácter experimental de la norma garantiza su revisión dentro de tres años, de manera que se pueda adaptar al siempre cambiante mundo de la informática.
Existe en la actualidad una gran variedad de documentos técnicos que abordan la problemática del acceso a la informática por parte de personas con discapacidad y diferentes soluciones para la accesibilidad a plataformas informáticas. Sin embargo este tipo de documentos suelen permanecer ocultos en los propios entornos que los generan, suelen tener dificultades de difusión, sufren cambios con bastante frecuencia y resultan difíciles de conseguir.
Una norma es un documento público al que pueden acceder todas las personas interesadas, previo pago de un pequeño canon. El organismo normalizador pertinente, en este caso AENOR, es el garante de la disponibilidad del documento y su estabilidad, asegurando un proceso formal de cambio.
Poniendo las miras un poco más lejos, si algún día se consiguiera promulgar una ley que garantizara la accesibilidad a la informática a todos los ciudadanos, resultaría conveniente tener una normativa ya desarrollada, sobre la que se pudiera apoyar la ley.
Por lo tanto el objetivo de escribir la norma es doble, conseguir un documento formalmente estable y preparar el camino a una posible legislación futura.
A continuación se procede a hacer un examen detallado de los contenidos de la norma, siguiendo sus dos documentos.
Los problemas accesibilidad al hardware se centran sobre todo en las dificultades que se pueden tener a la hora de manejar los controles, interruptores y elementos de los diferentes componentes que constituyen una configuración habitual (unidad central, pantalla, teclado, ratón, impresora, etc.).
Muchos de estos problemas quedarían resueltos si todos estos elementos fueran controlables por programa, de manera que los componentes del soporte físico se pudieran encender, apagar y regular utilizando programas del propio entorno operativo. Los programas de control de los aparatos serían creados por el fabricante del equipo o podrían venir incorporados en el entorno operativo, en el caso de los modelos más habituales.
Sin embargo, para conseguir un enfoque realista no conviene pedir demasiadas cosas a la vez y resulta más operativo exigir de momento que todos los controles se pongan de manera que resulten accesibles (p. ej. en la parte frontal del elemento) e ir informando a los fabricantes de la necesidad de que desarrollen programas que sean capaces de configurar y regular completamente sus equipos en el futuro.
Es especialmente importante que los botones de encendido y apagado de los elementos que configuran el soporte físico de una plataforma informática estén situados en la parte frontal de dicho elemento. La colocación dichos controles afecta especialmente a las personas con discapacidad física, ya que muchas veces no pueden acceder a los laterales o la parte trasera de los elementos.
De igual manera, la consistencia de la colocación de dichos controles en los diferentes aparatos resulta de especial utilidad para personas con problemas de visión o con discapacidades psíquicas. Resulta mucho más fácil encontrar el botón de encendido de un aparato si se sabe que en todos ellos, dicho botón se encuentra siempre en la parte frontal derecha.
Por otro lado, los controles (botones, reguladores, interruptores, etc.) de los ordenadores, al igual que los de muchos de los aparatos modernos, distan mucho de tener la forma y tamaño ideal para ser manejados por personas con algún tipo de problemas, o sencillamente para ser utilizados por personas mayores. En la norma se exige a los controladores que tengan realimentación táctil, se recomienda además que tengan realimentación sonora, y por supuesto se les pide que sean grandes (2-5 mm de altura, 12-15 mm dimensiones superficiales y 18-20 mm de espaciado).
También se les exige a los botones que sean cóncavos y que sean no deslizantes, de manera que resulte más fácil atinar en ellos, sobre todo a personas con problemas de precisión en el control (paralíticos cerebrales, personas espásticas, etc.).
Otro aspecto a tener en cuenta son las etiquetas que identifican las funciones de los controles (p. ej. el 0 y el 1 de un control de encendido y apagado). Dichas etiquetas deben resultar fácilmente asociables a un concepto y deben resultar sencillas de leer. De esta manera se garantiza su correcto uso por parte de personas con limitaciones psíquicas o visuales. Para hacerlas visibles se deben utilizar colores de alto contraste y utilizar un tipo de letra "san serif" que sea de un tamaño grande (por ejemplo Arial superior a 16 puntos). Para las personas ciegas, todo esto puede resultar insuficiente, por lo que se aconseja facilitar alternativas Braille o táctiles.
Otro punto de fricción a la hora de utilizar el hardware son las unidades de soporte de almacenamiento removibles (disquetes, CD-ROM, etc.). Las personas con problemas de control y precisión en las manos y en los brazos tienen muchos problemas para poder introducir un disquete en las ranuras de las unidades actuales. Resulta mucho más sencillo dejar caer un CD-ROM en las típicas plataformas de entrada/salida deslizante, por lo que se recomienda a los fabricantes que adopten este tipo de mecanismos para todas las unidades de almacenamiento removibles. También resultan especialmente incómodas las palancas giratorias de algunas unidades de disquetes (sobre todo en las antiguas), por lo que se exige que todos los mecanismos tengan pulsadores de tipo botón y que éstos no requieran excesiva fuerza para manejarlos.
Existe además el problema de la colocación correcta de los dispositivos auxiliares de almacenamiento en sus respectivas unidades. Si una unidad permite que el usuario coloque de manera incorrecta, pongamos por ejemplo, un CD-ROM boca abajo, entonces deberá existir una manera de avisar al usuario de que ha insertado incorrectamente el CD-ROM.
Cómo se puede observar, las directrices principales orientan a los fabricantes para que hagan las cosas más fáciles de utilizar y requieran menos destreza por parte de los usuarios. En esa línea, se deben evitar las funciones que dependen de la combinación de maniobras con controles (por ejemplo pulsar un botón y a la vez girar otro una palanca). Si no es posible evitar este tipo de combinaciones, por lo menús se debe ofrecer una opción distinta para conseguir la misma funcionalidad. De esta manera se conseguirá que las personas con problemas en las manos o con un solo brazo puedan realizar este tipo de maniobras.
Los elementos periféricos que sirvan de vehículo de comunicación con el usuario (pantalla, teclado, impresora, etc.) deben ser independientes de la unidad central, de manera que resulten fácilmente intercambiables, con el fin de suplir o aumentar alguna capacidad comunicativa. Así se pueden poner con la misma unidad central pantallas grandes, teclados adaptados, dispositivos especiales y otros elementos que pueden servir para mejorar la interacción hombre-máquina.
Además, estos elementos independientes deben tener una base de asentamiento estable y antideslizante, de manera que resulte difícil tirarlos al suelo en un movimiento espástico. No obstante, su regulación de orientación y altura, debe ofrecer poca resistencia para facilitar su posicionamiento óptimo.
Las impresoras, escáners y demás elementos que utilicen papél deben tener bandejas de alimentación y almacenamiento de hojas que resulten fácilmente accesibles, para lo que no deben tener cubiertas que tapen las hojas y no resultar imprescindible extraer una bandeja para poder poner o quitar papel.
Las personas con problemas auditivos, tienen una dificultad especial para deducir el estado de su plataforma informática, ya que carecen de las informaciones sonoras que otras personas perciben normalmente. Por ejemplo, es corriente deducir si un equipo está encendido por el ruido que hace su disco duro, o por los sonidos que se emiten al arrancar el ordenador. Para evitar este tipo de diferencias, se exige que los fabricantes de ordenadores sean capaces de visualizar todos los tipos de informaciones auditivas que resultan relevantes. Estas informaciones deberán aparecer en pantalla de modo que avise al usuario de la aparición y desaparición de ruidos sin los que resulta difícil trabajar.
De la misma manera, los usuarios con problemas auditivos no son capaces de detectar los ruidos emitidos por el altavoz interno de la unidad central. Por eso se recomienda que dicho altavoz esté colocado en la parte frontal de manera que quede próximo al usuario. Además se recomienda que dicho altavoz disponga de sistemas regulables de volumen y frecuencia y de la posibilidad de conectar altavoces que recojan su sonido.
El problema de la accesibilidad del software resulta mucho más complejo por resultar sus componentes y sus fronteras mucho más difusas. En aras de una mayor claridad en el estudio se han considerado tres diferentes niveles o partes en el software. Por un lado el entorno operativo, denominación que engloba al sistemaoperativo, a su interfaz de usuario asociado y a algunas de las aplicaciones que suelen venir con él (administrador de archivos, programas de configuración, etc.). Por otro lado las aplicaciones, como podrían ser un tratamiento de textos, un programa de diseño, etc. Y por último se ha considerado la ventana en la que se mueve el mundo Internet, por resultar de unas características muy particulares, muchas de ellas todavía por definir.
Existen una serie de requisitos que afectan por igual a los tres niveles en que se ha dividido el soporte lógico, ya que afectan a la filosofía general de la comunicación entre el hombre y el ordenador. Se estudian primero estos aspectos, para luego analizar los específicos de cada nivel.
Los tres niveles utilizan un interfaz de usuario para informarle de lo que resulta necesario. Un interfaz de usuario debe ser conciso, coherente y consistente, para facilitar la vida al usuario. Así, los famosos mensajes de error del tipo "Error 108:345, overflow en la pila en posición 4012. Perderá todos los datos. Pulse cualquier tecla para continuar" resultan confusos para todos los usuarios, pero especialmente para aquellos usuarios con problemas psíquicos que pueden no comprender lo que significa y ponerse muy nerviosos pensando que es culpa suya. Lo mismo ocurre con muchas personas con dificultades auditivas, ya que no están acostumbrados al lenguaje escrito complejo. Por ello se recomienda el uso de mensajes cortos y sencillos del estilo "El sistema necesita reniciarse" y la utilización del mismo texto en el mensaje siempre que sea posible.
De igual manera resulta conveniente para todas las personas que el mismo tipo de mensaje salga siempre en la misma zona de la pantalla utilizando los mismos elementos compositivos (tipo de letra, colores, botones, etc.). De esta manera se puede identificar el mensaje por su aspecto, además de por su texto (especialmente útil para personas con discapacidad cognitiva) y resulta fácil de encontrar en la pantalla, ya que siempre está en la misma zona. Para ello, lo más fácil es utilizar cuando sea posible las convenciones del entorno operativo, que será garante de la consistencia en las posiciones y formas de los diferentes tipos de mensaje.
Otro aspecto a tener en cuenta de los mensajes del entorno operativo es su tiempo de permanencia en pantalla. Para las personas con algún tipo de discapacidad, los tiempos de reacción ante eventos del entorno operativo son muy superiores. Por ello resulta contraproducente poner mensajes en pantalla que desaparecen transcurrido un cierto tiempo. En la norma se exige que no sea así y que se espere siempre a la aceptación por parte del usuario antes de permitir la desaparición del mensaje de la pantalla. Si no fuese posible y el mensaje tuviera que desaparecer por sí solo transcurrido un tiempo, se pide que el tiempo de permanencia en pantalla sea configurable por el usuario. Este requisito, aunque válido para todos los mensajes, se hace especialmente necesario en mensajes críticos del sistema operativo.
La inmediatez de su aparición es también de su importancia y afecta especialmente a los mensajes de voz que se produzcan después de un evento, ya que debe haber una asociación temporal del concepto oído con lo que pase en la plataforma informática.
Los lectores de pantalla utilizados por los ciegos son capaces de distinguir los textos escritos con letras, pero son incapaces de leer los textos escritos usando primitivas gráficas. Por lo tanto, los textos que se escriban en pantalla no deben utilizar los servicios gráficos para poner las letras, sino que deben utilizar las funciones de escritura de texto facilitadas por el entorno operativo.
Del mismo modo, cualquier foto, vídeo, dibujo o gráfico queda fuera del alcance de los lectores de pantalla, por lo que cuando se utilicen gráficos en la pantalla, deberán ir acompañados por textos explicativos que permitan a las personas invidentes obtener información acerca del contenido de la imagen.
Las personas con problemas en la vista no siempre son capaces de ver lo que escriben a la hora de introducir datos en un ordenador. Esta introducción de datos se hace de manera similar en los interfaces modo texto que en los gráficos, si bien en los segundos ha sido necesario crear un concepto intermedio, llamado cuadro de edición. En cualquiera de los casos, el texto que se haya escrito debe ser recorrible con el cursor, de manera que un lector de pantalla pueda leerlo en voz alta. También el texto de la etiqueta asociada debe poder ser leído y debe resultar fácil poder leer ambos (etiqueta y contenido) de manera que su asociación quede patente.
Además, la etiqueta que va acompañando al espacio de introducción de datos debe ir alineada horizontalmente con la primera línea del campo de introducción de datos, de manera que ambos sean fácilmente asociables tanto para lectores de pantalla como para personas con problemas cognitivos.
Aunque se ha mencionado anteriormente que los elementos compositivos (tipo de letra, color, etc.) ayudan a localizar y comprender los mensajes, conviene tener en cuenta que estos elementos deben servir sólo de acompañamiento. En el caso del color, las personas daltónicas no son capaces de distinguir algunos colores, por lo tanto si una información se apoya sólo en los colores (p. ej. "Pulse en el botón rojo para terminar") muchas personas perderán la información y no sabrán cómo reaccionar. Por lo tanto los elementos compositivos sólo deben servir para acompañar o realzar la información, con lo que en realidad se estarán enviando partes redundantes de la misma información por diferentes canales, color y texto, color y forma, color texto y forma, etc.
Lo mismo ocurre con la utilización del sonido. Habitualmente se utiliza como indicador de fin de una tarea o como alerta de algún tipo de error. Las personas con problemas auditivos se pierden este tipo de información, por lo que debe ir acompañada de una señal visual que indique lo mismo. Como se puede observar, la redundancia de canal de comunicación resuelve muchos de los problemas de accesibilidad.
No sólo debe existir redundancia de canal de salida, sino que también debe haber el mismo tipo de redundancia en los canales de entrada. Así toda la entrada de datos (tanto control como entrada textual) debe ser posible realizarla sólo con pulsador, sólo con ratón, sólo con teclado y sólo con sistemas de reconocimiento de voz, además de poder combinar más de un canal para simplificar algunas tareas. Así el manejo del entorno operativo, las aplicaciones e Internet debe ser posible, por ejemplo, sólo con el teclado (sin necesidad de tener un ratón).
El teclado es el elemento de introducción y selección más extendido, por lo que todos los aspectos de accesibilidad de su manejo deben estar contemplados con sumo cuidado. Se debe evitar el uso de acciones simultáneas (mantener apretada una tecla mientras se pulsa otra) y si no se evitan, se debe proporcionar un método secuencial alternativo para lograr el mismo resultado.
El manejo por teclado debe incluir todo lo que afecta al control del interfaz de usuario. En especial debe permitir la activación y desactivación de menús y el desplazamiento pos sus opciones. El caso de los menús es bastante característico y, dado que suelen ser muy largos y llegar a ellos con las flechas de cursor puede resultar un proceso penoso, cuando sea posible, es conveniente poner alternativas de acceso con teclas de aceleración o atajos, ya que las personas con problemas de precisión o visión pueden necesitar varios intentos de recorrido del menú hasta acertar con la opción deseada, para después encontrarse posiblemente con otro submenú de iguales o mayores dimensiones.
Por idénticos motivos, el recorrido de los menús debe ser circular, es decir saltar de la primera opción a la última y viceversa cuando se recorra el menú con teclado. Este recorrido circular debe aplicarse también a las funciones de cambio de zona de una ventana, el recorrido por las opciones de un cuadro de diálogo, etc.
Cuando todo el manejo se realiza por teclado, puede haber tareas cuya secuencia de teclas asociada no resulte nada evidente. Por ello, todos los sistemas de ayuda deben facilitar cuál es la secuencia de teclas asociada a una acción de manera que resulte fácil encontrarla.
Los entornos operativos establecen los servicios de ayuda sobre el propio entorno que luego son utilizados por muchas aplicaciones para poner a disposición del usuario sus propias ayudas. Estos sistemas suelen tener formato textual, lo que resulta incomprensible a veces para personas con discapacidades auditivas o psíquicas. Por eso se debe incluir la posibilidad de incorporar la lengua de signos en los servicios de ayuda.
El entorno operativo es el centro de todas las piezas que componen una plataforma informática. Es el conjunto de tareas software que se encarga de comunicar la unidad central, los dispositivos de almacenamiento, los elementos de comunicación con el usuario (pantalla, teclado, etc.). Por lo tanto es el responsable fundamental de todos los elementos que conforman la comunicación básica del hombre con la máquina.
Tradicionalmente, el desarrollo de los entornos operativos se ha enfocado más a la complejidad de los procesos de la máquina que a la interacción con el usuario. Sin embargo, desde hace quince años, el desarrollo de denominado interfaz hombre-máquina ha cobrado una importancia fundamental, hasta tal punto que a cada sistema operativo se le asigna hoy en día un determinado interfaz, de manera prácticamente biunívoca.
Se pueden distinguir dos tipos de interfaces, los textuales y los gráficos. En los primeros, el usuario ve una pantalla en la que sólo se visualizan caracteres de entre un juego predeterminado y sólo se ve el resultado de una aplicación en un momento dado. El dispositivo de entrada de datos y de selección es principalmente el teclado y las ayudas del ratón son residuales y casi inexistentes. En los interfaces gráficos, los elementos de representación en pantalla ya no son los juegos de caracteres, sino los pixels o puntos de pantalla. De esta manera, las posibilidades de representación son infinitamente superiores y resulta factible ver el resultado de varias aplicaciones en diferentes zonas, denominadas ventanas. El concepto de ventana resulta fundamental en el desarrollo de los interfaces hombre-máquina y lleva asociado el uso del ratón para la selección de la ventana sobre la que se quiere actuar (y los elementos dentro de ella).
El paso del uso de los caracteres a los pixels ha resultado muy beneficioso para la mayoría de los usuarios, pero ha resultado extremadamente perjudicial para las personas ciegas. Con los interfaces gráficos, ya no hay una sola cosa que entender, puede haber un sinfín de aplicaciones abiertas simultáneamente en diferentes ventanas y cada ventana tiene la complejidad que antes tenía toda una pantalla.
Los exponentes más característicos del interfaz en modo texto son los sistemas operativos más longevos (VM, MVS, VMS, Unix, DOS, etc.) y los de los interfaces gráficos son los más modernos (Windows, MacOS, OS/2, etc.). Sin embargo, casi todos comparten hoy en día el uso combinado de los dos interfaces, utilizándose el modo de texto para las fases de configuración y puesta en marcha del sistema operativo y el modo gráfico para el funcionamiento habitual del sistema.
Los problemas de accesibilidad de los interfaces de modo texto se consideran sólo un subconjunto del que forman los problemas de accesibilidad de los interfaces gráficos. Esta consideración, aunque resulte una simplifcación, ayuda a hacer una mejor evaluación de todos los problemas de accesibilidad al entorno operativo.
Las personas que tienen más problemas con la accesibilidad al soporte lógico son las que sufren de ceguera o tienen problemas graves de vista. Todo lo que se ve en una pantalla, especialmente con los interfaces gráficos, está pensado y diseñado para ser visto. Por lo tanto, desde el principio la orientación se desvía del camino de la integración y accesibilidad. Para paliar esta desviación se utilizan hoy en día lo que se denomina modelos de pantalla, que consisten en mantener una representación exacta de lo que se representa en pantalla en forma de datos, de manera que sea posible, utilizando las herramientas adecuadas, realizar una descripción hablada de los contenidos de la pantalla.
Aunque éste es el problema fundamental para las personas con ceguera, existen otros muchos muy distintos en función de las diferentes discapacidades. En líneas generales, la norma que analizamos en este documento exige que el entorno operativo sea capaz de aceptar datos del usuario utilizando cualquiera de los dispositivos de entrada conocidos actualmente (teclado, ratón, pulsador) y recomienda que utilice también un sistema de reconocimiento de voz. De igual forma, la salida de datos se debe realizar, además de por el canal habitual (vídeo), por audio, de manera que los ciegos tengan acceso a la misma información, aunque sea distinto canal de comunicación.
Las diferentes posibilidades y combinaciones de posibilidades de canales y características de entrada y salida, al igual que las posibles prestaciones específicas para una discapacidad, deben tener carácter de activación opcional, de manera que la misma plataforma informática pueda ser utilizada indistintamente por un amplio abanico de usuarios con diferentes necesidades. Para evitar tiempos perdidos y ganar estabilidad, se exige que la activación o desactivación de prestaciones se lleve a cabo sin tener que reiniciar el sistema.
El entorno operativo contiene además una serie de servicios que son utilizados por las aplicaciones (servicios de gestión de archivos, memoria, dispositivos, etc.) Estos servicios deben estar diseñados de manera que sean capaces de garantizar que las aplicaciones construidas por encima suyo puedan ser accesibles. Se trata de proporcionar elementos de construcción intrínsecamente accesibles, que garanticen que el resultado puede ser accesible (aunque la accesibilidad final depende de cómo se usen los servicios). Así, el entorno operativo puede proporcionar un servicio que lea por tarjeta de síntesis de voz el último texto mostrado en pantalla. Por lo tanto todas las aplicaciones dispondrán de este servicio y serán accesibles si lo utilizan.
Para conseguir estos servicios accesibles y los modelos de pantalla, hay que pedirle al entorno operativo que al crear un elemento del interfaz de usuario, lo identifique (por ejemplo con una etiqueta de texto) y que permita acceder a las propiedades de ese elemento (ventana abierta o cerrada, de qué tamaño, con foco...), preferiblemente a través de servicios predeterminados.
Las personas con problemas de movilidad física, especialmente aquellas que presentan problemas en sus miembros superiores tienen muchas dificultades a la hora de introducir o extraer elementos de almacenamiento removibles (disquetes, CD-ROM, etc.). Aunque en el apartado del soporte físico ya se ha reflejado esta necesidad, conviene que el entorno operativo incorpore servicios de manejo automático de este tipo de unidades, especialmente en lo referente a su expulsión.
Algunos interfaces de usuario de entornos operativos incorporan el concepto de áreas de trabajo, que son diferentes zonas de trabajo en las que puede haber ventanas abiertas, aunque sólo se puede visualizar un área de trabajo en momento dado. El cambio de un área de trabajo a otra debe poder hacerse utilizando el teclado, además del ratón, manteniendo así el concepto anteriormente expuesto de redundancia de canal.
Para las personas con problemas de visión resulta incómodo y a veces imposible ver los iconos y otros objetos que se visualizan en un área de trabajo, por lo el propio entorno operativo debe permitir que se modifiquen sus tamaños y sus posiciones, bien independientemente o por grupos.
Los iconos deben además tener asociada una etiqueta, de manera que se permita ver sólo esa etiqueta, facilitando su identificación y su comprensión por parte de personas con disminuciones psíquicas.
La gestión de las ventanas (refresco, desplazamiento, cambio de tamaño, etc.) es un conjunto de tareas para el todos los programas utilizan primitivas del entorno operativo, más bien del gestor de ventanas, que es un componente del interfaz gráfico del usuario. Habitualmente todas las operaciones a realizar necesitan del uso del ratón. Para las personas con problemas de precisión, el uso del ratón resulta un inconveniente, por lo que la norma exige que todas estas operaciones se puedan realizar también con el teclado.
En el caso específico de las barras de herramientas, a las que habitualmente no se puede acceder por teclado ni habilitar su acceso, se exige que todas las operaciones realizables desde cualquier botón de la barra, sean accesibles también a través de opciones de menú.
Dado que hay personas con necesidades especiales que ponen sus herramientas en la pantalla (emuladores de teclado, editores predictivos, etc.) y éstas deben estar permanentemente visibles, se exige que todas las ventanas se puedan cambiar de tamaño y de posición en la pantalla. También se exige que sean maximizables y minimizables y que todas ellas se puedan cerrar, ya que pueden entrar en conflicto con las herramientas anteriormente mencionadas.
También se le pide al entorno operativo que facilite una manera de cambiar de una ventana a otra, para que las aplicaciones especiales puedan cooperar con las generales.
El controlador de teclado es el programa que se encarga de las comunicaciones entre el ordenador y el teclado y es un punto en el que se pueden incorporar muchas prestaciones que faciliten la accesibilidad. Las personas que más dificultades tienen para el uso del teclado son las que tienen problemas de precisión en el uso de sus brazos, dedos o manos, seguidas de las personas con discapacidades psíquicas y visuales, por lo que se deben contemplar las diferentes problemáticas.
Así, el controlador de teclado debe incorporar una opción que permita bloquear las teclas de control (Mayúsculas, Alt, Ctrl, Meta, etc.), de manera que las personas que sólo puedan utilizar una mano eviten las maniobras de pulsación simultánea.
También debe incorporar una opción que permita visualizar y escuchar el estado de las mentadas teclas de control y de las teclas de cambio de estado (Bloq Num, Bloq Mayús, etc.) para que las personas con problemas psíquicos puedan encontrar con más facilidad la razón de comportamientos inesperados en las pulsaciones del teclado. De igual modo, las personas con discapacidad visual necesitan saber, sin ver, el estado de dichas teclas.
Otras personas tienen problemas de control fino y mantienen pulsada una tecla demasiado tiempo, consiguiendo una repetición inesperada de la misma. Por ello se debe permitir configurar el tiempo repetición tras la pulsación de una tecla. En la misma línea muchas personas pulsan teclas equivocadas por falta de control, por lo que resulta conveniente poder configurar el tiempo que se debe pulsar una tecla antes de ser aceptada. Otro efecto frecuente es la repetida pulsación involuntaria de la misma tecla, por lo que también se tiene que poder configurar el número de pulsaciones de la misma tecla hasta su aceptación.
Algunas personas no teclean utilizando los dedo, sino que utilizan los nudillos o muñones, para todos ellos existen puntos del teclado en los que las manos chocan, haciendo imposible llevar a cabo ciertas combinaciones de teclas. Por ello se debe ofrecer la posibilidad de reconfigurar todas las teclas del teclado para permitir adaptarse a necesidades especiales. También las personas a las que le falta un brazo utilizan disposiciones especiales del teclado, que deben venir con el controlador del sistema operativo.
El controlador del ratón es un programa que habitualmente viene con el propio ratón pero, dado que todos los equipos se venden hoy en día llevan un ratón, resulta más lógico incorporar este controlador como una parte del entorno operativo.
En el caso del ratón, las personas que más dificultades tienen en su manejo son las personas con discapacidad visual que no pueden seguir los movimientos de su indicador en la pantalla, aunque presenta problemas también para las personas con problemas de precisión, movilidad o fuerza en los miembros superiores.
El controlador del ratón debe incorporar ciertas prestaciones que faciliten la accesibilidad, así debe permitir modificar la orientación en el movimiento, de manera que el apoyo de la mano y la situación de los botones sean las más convenientes. De igual forma debe permitir modificar la velocidad y aceleración del movimiento del puntero, separando las velocidades horizontal y vertical, de manera que las personas con problemas de precisión puedan controlar el ratón de manera razonable.
De manera similar al teclado, se debe poder programar el tiempo de aceptación del clic, el tiempo entre dos clics y se deben poder intercambiar las funciones de los botones derecho e izquierdo.
Además, para las personas con problemas de movilidad en los dedos, se debe permitir realizar el bloqueo de clic para el arrastre, disponiendo de un botón del ratón para esta función o, en su defecto, utilizando una temporización de uno de los botones o una tecla del teclado.
Para conseguir que un entorno sea completamente accesible, no basta con conocer todos los servicios y requisitos generales estipulados hasta ahora. Hace falta además que las aplicaciones usen esos servicios, se coordinen con ellos y cumplan los requisitos no asignables directamente a un servicio.
Es por tanto fundamental la concienciación de las personas encargadas del desarrollo de los programas en todos los aspectos relacionados con la accesibilidad.
Los elementos textuales y de identificación (nombre de la ventana, etiqueta del icono, etc.) deben ser susceptibles de emitirse por voz utilizando los servicios facilitados por el entorno operativo, de manera que las personas que no ven puedan identificar la aplicación y sus contenidos.
Para las personas con problemas de atención y concentración es necesario además utilizar mensajes cortos y sencillos y cumplir los requisitos estipulados en los requisitos generales tanto en lo que respecta a mensajes como al resto de los aspectos (redundancia de canal, gráficos, etc.)
Se debe prestar especial atención a que todas las funciones ofrecidas por la aplicación sean accesibles por teclado, requisito especialmente difícil para algunos tipos de aplicaciones (programas de dibujo, aplicaciones musicales, etc.) y que puede ser completado con el uso de emuladores de ratón.
A la hora de acceder con el teclado a los menús, se deben respetar las combinaciones habituales del entorno operativo. Así, si para acceder al elemento archivo se utiliza la tecla 'A' en el entorno operativo, el programa debe utilizar la misma tecla para la misma función. Lo mismo se debe hacer con los atajos de teclado que se ponen en varias de las opciones de un menú. Además, la aplicación se debe diseñar de manera que el número de pasos necesarios para acceder por teclado a cualquier opción sea el mínimo posible, haciendo especial hincapié en las opciones más frecuentemente utilizadas. De esta manera se conseguirá una mayor eficiencia para personas con todo tipo de discapacidad.
Por otro lado, se debe permitir la modificación del tamaño y lugar de los iconos y objetos generados por la propia aplicación, para hacerlos accesibles a personas con problemas de visión. De igual manera se les debe asignar una etiqueta que pueda ser leída por los lectores de pantalla.
Hay que tener en cuenta que, a pesar de los avances realizados, muchos problemas de accesibilidad se resuelven todavía con programas específicos, por lo que la norma exige a la aplicación que coopere con otras aplicaciones especiales de acceso (editores predictivos, emuladores de teclado, etc.) incluso en entornos que no sean de ventanas, de manera que a veces las aplicaciones especiales puedan incluso superponerse a las normales. Para ello se deben utilizar los mecanismos de coordinación proporcionados por el entorno operativo, evitando que las aplicaciones se bloqueen las unas a las otras.
Para evitar conflictos y problemas de accesibilidad, tanto a ciegos como a personas con discapacidad psíquica, si una aplicación utiliza ventanas, su gestión debe dejarse al entorno operativo, que será el encargado de facilitar los servicios de accesibilidad. Si se utilizan varias ventanas, se debe permitir el cambio de una a otra y se debe seguir siempre la misma secuencia de cambio.
Finalmente, y para evitar problemas de consistencia, de coordinación de aplicaciones y facilitar su uso a personas con problemas cognitivos, toda aplicación debe tener una opción de finalizar provista por ella misma.
La aparición de Internet y sus diferentes servicios ha constituido una auténtica revolución en el mundo de la informática. Quizá el cambio más espectacular lo ha aportado el World Wide Web, ya que constituye un tipo de aplicación inexistente hasta el momento que permite, entre otras muchas cosas, la ejecución remota de programas que utilicen una máquina virtual intermedia que es la que se encarga del uso de los servicios del entorno operativo en el que se está ejecutando.
El resto de los servicios, correo electrónico, tablones de anuncios, gopher, etc. resultan muy similares a cualquier otra aplicación, por lo que no incorporan características de accesibilidad distintas.
La tecnología web se apoya en varios protocolos (HTTP, HTML, etc.) susceptibles de ser modificados y ampliados para mejorar la accesibilidad y utiliza varios tipos de programas (navegadores, Conversores gráficos, reproductores de vídeo, etc.) que tienen problemas específicos para ciertas discapacidades. No obstante, en la norma se trata sólo de analizar el interfaz del usuario y sus problemas, dejando de lado todos los aspectos internos de Java, CGI y los protocolos anteriormente mencionados.
Podemos distinguir dos aspectos en la accesibilidad, los del programa utilizado para navegar y los de los contenidos de las páginas que se visualizan.
Los navegadores tienen que cumplir los requisitos de accesibilidad comunes al resto de los programas, tal como se ha descrito anteriormente. Pero además deben permitir el desplazamiento dentro de las páginas HTML utilizando sólo el ratón y sólo el teclado. Lo mismo debe ser válido para pasar de un enlace a otro y de un marco (frame) a otro.
La presentación en pantalla de documentos web (habitualmente escritos en HTML) presenta dificultades de accesibilidad, sobre todo a personas con discapacidad visual, por la amplia orientación multimedia que tienen.
Se le exige a todas las páginas web, incluidos HTML, CGIs, Java, etc. que cumplan todos los requisitos de accesibilidad aplicables a todas las aplicaciones. En el caso de utilizar formatos alternativos (PDF, MS-Word, etc.) se debe poner la misma información en HTML o en ASCII, de manera que resulte accesible.
Además, dado que el texto de los enlaces que aparezcan juntos pueden ser visto como un sólo enlace por los lectores de pantalla, la norma exige que se separen por barras verticales o algún otro carácter, que no forme parte del enlace.
Asimismo, si se ponen dos enlaces en la misma página cuyo texto es idéntico, resulta difícil distinguirlos entre sí si se sacan fuera de contexto, que es lo que hacen algunas herramientas de navegación para personas invidentes. Por lo que se pide que los enlaces de la misma página tengan textos distintos y autoexplicativos.
Para las personas con discapacidad psíquica resulta especialmente complicado comprender bien la información en el caso de llegada a una zona intermedia de una página web. Por lo que esos puntos de llegada deberán tener asociado un enlace que lleve al usuario a una parte significativa de la página.
El uso de textos que se mueven o parpadean es también perjudicial, ya que muchos lectores de pantalla no son capaces de detectarlos y por lo tanto los ignoran. Lo mismo ocurre con los textos verticales.
Por otro lado y siguiendo los criterios de consistencia en el desarrollo de interfaces se recomienda que los botones o enlaces que tengan la misma función aparezcan siempre en la misma posición de la página.
Las listas de elementos textuales suelen ser leídas de corrido por los lectores de pantalla, con el consiguiente problema de comprensión para el que no las ve. Por tanto se recomienda que las listas se hagan de tipo viñeta o numeradas, de manera que cada elemento se lea separado del otro por algún elemento.
Otro punto negro de la accesibilidad a las páginas web es el uso de tablas. Los lectores de pantalla que utilizan las personas con discapacidad visual suelen recorrer la pantalla primero en horizontal y luego en vertical. De esta manera si los datos de una celda de la tabla ocupan más de una línea, se lee la primera línea de cada celda y luego sus segundas líneas. Y aunque el lector de pantalla pueda leer cada celda correctamente, resulta muy difícil para una persona con discapacidad visual situarse dentro de una tabla. Por lo tanto se recomienda que no se usen.
En el caso de los formularios, que también resultan complejos de manejar para las personas ciegas, se pide que se faciliten formas alternativas de introducción de datos, como un número de teléfono o copias que se puedan rellenar fuera de línea para ser mandadas posteriormente por correo electrónico.
También añade complejidad a la navegación el uso de marcos (frames) por lo que se desaconseja su uso.
Por supuesto se exige también la utilización del concepto de redundancia de canal, de manera que la información gráfica se acompañe de texto, al igual que la información sonora y que los videos sean subtitulados, o dispongan de un enlace a una página la que se describa su argumento. En el caso de uso de mapas sensibles, se recomienda poner una lista con todos los enlaces a los que se puede acceder a través del mapa.
La documentación de todos los elementos de una plataforma informática, tanto hardware como software, se han entregado tradicionalmente en papel, con el inconveniente que eso supone para las personas con discapacidad visual. Esta tendencia tiende a corregirse, y cada vez se entrega más documentación en formato electrónico, con lo que se puede utilizar el ordenador y sus ayudas técnicas para leerlo. No obstante, en la norma se recoge la necesidad de la existencia de documentación en formato electrónico.
En el caso en el que sea imposible el requisito anterior, la encuadernación debe permitir abrir la documentación por cualquier página y no precisar sujeción para mantenerla abierta, el papel no debe ser deslizante y el color del papel y de la letra deben tener un alto contraste.
Igualmente debe mantenerse el criterio de redundancia de canal y no permitir que los gráficos no tengan textos explicativos ni que existan informaciones que se apoyen exclusivamente en el color.
La existencia de la norma no es ninguna garantía de que los fabricantes de hardware y software la vayan a seguir. Pero se intentarán tomar medidas auxiliares par la progresiva implantación de sus ideas en el mundo de la informática.
Los criterios de accesibilidad en ella recogidos son la primera recopilación formal que se hace en todo el mundo y puede servir para sentar las bases de un futuro más accesible, además de servir para una posible elevación de la norma a nivel europeo y mundial.
El dinamismo característico del mundo de la informática hace previsible que el documento sufra muchos cambios en los años venideros, lo que no es óbice para aceptar que las ideas que en él se recogen son los criterios que pueden, hoy por hoy, marcar la pauta de una mayor integración social de las personas con discapacidad.
La aperición de nuevos productos e ideas en el campo de la informática lleva asociado un contínuo seguimiento de las posibles barreras que conlleven y la consiguienmte inclusión en la norma de medidas para evitarlas.
Aplication Software Design Guidelines. Trace R&D
Center, Dpto. of Industrial Engineering (University of Wisconsin)
Compiled by Gregg C. Vanderheiden
Accesible Design of Consumer Products.
Industry-Consumer-Researcher Work Group
Compiled by Gregg C. Vanderheiden and Katherine R.
Vanderheiden
Considerations in the Design of Computers to Increase
Their Accessibility by Persons with Disabilities.
Industry/Government Computer Accessibility Task Force
Trace Center
PC 97 Design Guide, Designing Pcs and peripherals for the Microsoft Windows Systems. Microsoft Corporation
Design of HTML (Mosaic) Pages to Increase their
Accessibility to Users with Disabilities. Gregg C. Vanderheiden
Ph.D.
Trace R& D Center, University of Wisconsin - Madison
Designing the World Wide Web for People With Disabilities:
A User Centered Design Approach. Lils F. Laux, Peter R. Mc
Nally, Michael G. Paciell, Gregg C. Vanderheiden
ASSets '96, Vancouver, British Columbia, Canada -
Unified
Web Site Accessibility Guidelines. March 1997
Gregg C. Vanderheiden Ph.D., Wendy A. Chisholm, Neal Ew