PAUTAS PARA EL DISEÑO DE ENTORNOS EDUCATIVOS ACCESIBLES PARA PERSONAS CON DISCAPACIDAD VISUAL Enero 2005
ÍNDICE
1. INTRODUCCIÓN............................................................................ 2
2. OBJETIVOS DEL DOCUMENTO.................................................. 3
3. TIPOS DE APLICACIONES INFORMÁTICAS ACCESIBLES.. 4
4. DEFINICIONES Y ACRÓNIMOS................................................... 5
5. PAUTAS DE ACCESIBILIDAD PARA APLICACIONES DIRIGIDAS 6
6. PAUTAS DE ACCESIBILIDAD PARA APLICACIONES NO DIRIGIDAS 8
7. CRITERIOS PEDAGÓGICOS EN EL DESARROLLO DE APLICACIONES EDUCATIVAS PARA USUARIOS CIEGOS Y DEFICIENTES VISUALES. 13
APÉNDICE A: Orden de tabulación lógico...................................... 15
APÉNDICE B: Ejemplos de colores para textos............................. 16
ANEXO 1: Aplicaciones y dispositivos tiflotécnicos....................... 16
ANEXO 2: Notas para adaptaciones en relieve............................... 21
ANEXO 3: Aspectos perceptivos del niño ciego y deficiente visual. 25
El presente documento pretende ofrecer a todos aquellos profesionales que intervienen en el desarrollo de entornos educativos una serie de pautas que, tenidas en cuenta desde la fase de especificación y diseño de los contenidos, permiten que estos entornos sean manejables por alumnos con ceguera o con algún tipo de discapacidad visual. Es necesario reseñar, que si bien muchas de estas pautas son aplicables a usuarios con cualquier tipo de discapacidad, el documento está enfocado a usuarios con discapacidad visual. Junto con una guía práctica acerca del diseño de la propia aplicación informática, se incluyen criterios pedagógicos sobre la estructuración y forma de presentación más adecuada de los contenidos, basados en la experiencia docente con alumnos con discapacidad visual. Con este documento no se pretende promover el diseño de entornos educativos especiales, sino que los que se desarrollen puedan ser manejados por alumnos con discapacidad visual con garantías de un aprovechamiento análogo al del resto de los estudiantes, permitiendo un uso indistinto, autónomo o en conjunto. Las pautas se clasificarán teniendo en cuenta los elementos más frecuentes en las actuales aplicaciones educativas, tanto en aspectos de programación como de contenido o métodos de aprendizaje. Como se reiterará a lo largo de todo el documento, dos son los objetivos básicos en el orden de la programación informática: 1. Garantizar el manejo de todas las funcionalidades de la aplicación mediante el uso del teclado, sin necesidad de emplear el ratón, debiendo coexistir ambas modalidades. 2. Facilitar que toda la información significativa que aparezca en la pantalla del monitor y sus cambios sean conocidas, de alguna forma, por el estudiante con ceguera o con algún tipo de discapacidad visual. 2. OBJETIVOS DEL DOCUMENTO Este documento pretende servir de guía de referencia para todos aquellos profesionales que intervienen en el desarrollo de entornos educativos y ayudarles a conseguir que estos sean accesibles para alumnos con discapacidad visual. Es necesario reseñar que, si bien las pautas que se exponen en este documento pueden ser de gran utilidad, cada entorno educativo que se desarrolle necesitará un estudio particularizado de la accesibilidad, debido a la diversidad de contenidos con los que nos podemos encontrar en el campo de la enseñanza. Se pretende abarcar todos los ámbitos que intervienen en el desarrollo, desde el diseño y programación de la propia aplicación informática, hasta la definición de contenidos educativos, pasando por el diseño gráfico del interface, y la conexión con dispositivos tiflotécnicos y herramientas de uso exclusivo por personas con discapacidad visual. Debido al amplio abanico de profesionales a los que va dirigido (programadores, diseñadores gráficos, profesores, pedagogos, etc.), y los cambios constantes que se producen en los distintos campos del conocimiento a los que afecta, este documento debe ser dinámico, y por ello será objeto de revisiones periódicas con el fin de añadir nuevas ideas, o eliminar conceptos que se vayan quedando obsoletos. El segundo objetivo que se pretende es justificar la necesidad de seguir todas las pautas. Para ello, se han añadido una serie de anexos y apéndices específicos, con información útil que puede ayudar a los profesionales que no hayan tenido contacto con la enseñanza de alumnos con discapacidad visual. Desde la perspectiva del manejo de aplicaciones informáticas por parte de personas con discapacidad visual, existen dos procedimientos principales para lograr que estas sean accesibles: - Una aplicación estándar, que siguiendo una serie de pautas de diseño básicas, pueda ser manejada con la ayuda de un revisor de pantalla. - Una aplicación que sea accesible por sí misma, sin la ayuda de ninguna herramienta. Este tipo de aplicaciones se denominan dirigidas. En este documento se tratarán las pautas de diseño, tanto para un tipo de aplicaciones como otro, aunque diferenciándolos, ya que en el caso de las aplicaciones dirigidas, estos criterios varían ligeramente. El objetivo que se persigue teniendo en cuenta los dos tipos de aplicaciones accesibles, es abarcar todo el abanico de la educación, desde educación infantil al resto de etapas. En principio, el criterio de decisión sobre qué tipo de aplicación a desarrollar, se basa en dos factores: ü La edad y etapa de los alumnos a los que va dirigida. Para alumnos de educación infantil y primer ciclo de educación primaria es aconsejable desarrollar aplicaciones dirigidas, ya que a estas edades los alumnos con discapacidad visual, todavía no tienen las habilidades y estrategias necesarias para manejar los llamados revisores de pantalla. ü La complejidad técnica de la aplicación a desarrollar, que normalmente suele aumentar al hacerla dirigida, aunque no necesariamente. Por último es necesario reseñar que sea cual sea el tipo de aplicación que se desarrolle, si esta necesita un proceso de instalación, éste deberá ser totalmente accesible para usuarios con discapacidad visual. Así mismo, la documentación que esté relacionada de forma directa o indirecta con las aplicaciones debe estar en un formato que sea accesible. Braille: Código de lecto-escritura basado en combinaciones de seis puntos dispuestos en una matriz de dos columnas y tres filas. Dicho código se percibe mediante el tacto. Horno Fúser: Dispositivo dotado de una fuente de calor que permite generar el relieve de las líneas impresas en el papel microcápsula. Revisor de pantalla: Programa que envía la información que ofrece el ordenador a una línea braille, a una síntesis de voz, o a ambas. A su vez, también permite manejar el ordenador mediante una serie de comandos y combinaciones de teclas. Magnificador: Software específico para deficientes visuales que permite la ampliación de tamaño de los elementos que aparecen en la pantalla de un ordenador. Impresora braille: Periférico de salida que permite la impresión de la información en código braille. Pantalla táctil: Pantalla de ordenador, que permite el manejo del mismo mediante la interactuación del usuario por pulsaciones sobre la propia pantalla. Papel microcápsula: Tipo de papel especial que al recibir una fuente de calor eleva las líneas impresas en él, de forma que se pueden detectar mediante el tacto. Tableta digitalizadora: Periférico que permite el manejo de un ordenador desde un tablero sensible a las pulsaciones y movimientos de un lápiz especial, sobre dicho tablero. Tiflotecnología: Nombre que recibe la tecnología aplicada a la deficiencia visual, entendiendo dentro de tiflotecnología, el conjunto de conocimientos, de técnicas y recursos de que se valen las personas con discapacidad visual para poder utilizar la tecnología estándar. Esto permite la adaptación y accesibilidad de las tecnologías de la información y comunicación para su utilización y aprovechamiento. Tramas: Diferentes tipos de relleno que permiten diferenciar mediante el tacto las distintas zonas de un dibujo. WAI: Web Accessibility Initiative (http://www.w3.org/WAI/). Conjunto de grupos de trabajo del W3C especializados en diversas materias relacionadas con la accesibilidad a la Web. En este epígrafe se hará referencia a las pautas de diseño de una aplicación que sea dirigida, es decir la propia aplicación guiará al usuario mediante mensajes sonoros o de otro tipo, de forma que un usuario ciego o deficiente visual pueda utilizarla sin la ayuda de un revisor de pantalla. Las pautas de accesibilidad para este tipo de aplicaciones no varían excesivamente de las aplicaciones no dirigidas, en cuanto a los elementos que pueden formar parte de una aplicación. Por tanto, en este apartado sólo haremos hincapié en aquellos aspectos de accesibilidad que las diferencian, pero contando que en entornos educativos este tipo de aplicaciones se desarrollarán para usuarios de corta edad, hay que observar una serie de pautas o recomendaciones, que se exponen a continuación: 5.1. El acceso a la aplicación debe ser inmediato o con el menor recorrido posible desde el arranque, y la salida de la misma, sencilla, aunque haya de ser verificada. 5.2. La aplicación debe poder manejarse completamente con el teclado. Ello no implica la anulación del ratón, antes bien, deben coexistir ambas modalidades. 5.3. El número de teclas a utilizar debe ser el menor posible, y de fácil localización; por ejemplo las teclas de cursor, el bloque numérico, la barra espaciadora, Escape y Enter. 5.4. Todas las pantallas o apartados deben tener un título identificativo, y este deberá verbalizarse mediante un mensaje sonoro al iniciarse esa pantalla. 5.5. Es conveniente incluir un menú principal que aparezca en todas las secciones, y desde el cual se pueda acceder a cualquier apartado de la aplicación. 5.6. La aplicación debe disponer de una opción que permita al usuario con discapacidad, seleccionar las opciones de visualización de textos, opciones de colores de la aplicación y opciones de impresión, en tinta o en braille, o si se van a imprimir pantallas que posteriormente se adaptarán con un horno Fúser. 5.7. Cualquier cambio que se produzca en la pantalla, automáticamente o por acción del usuario, debe ser informado mediante un sonido o verbalmente. 5.8. Cada botón o enlace debe tener un mensaje sonoro identificativo asociado, el cual se reproduce cuando el elemento recibe el foco. 5.9. Todos los textos, así como la información relevante que aparece en pantalla, deben tener un mensaje sonoro asociado y permitir al usuario repetir este mensaje con el contenido del texto tantas veces como quiera. 5.10. Las imágenes y fotografías deben tener un fichero de audio que describa su contenido. 5.11. Los vídeos deben tener un fichero de sonido asociado, que describa lo que está ocurriendo en la secuencia. 5.12. Los aspectos visuales de todos los elementos, textos, gráficos, deben seguir las mismas pautas de diseño que en aplicaciones no dirigidas. 5.13. La aplicación debe permitir al usuario elegir la configuración de colores de la aplicación (fondos, textos, etc) o, en su defecto, que la aplicación utilice la que el usuario está empleando en el sistema operativo. En cualquier caso debe mantener un alto nivel de contraste. (ver Apéndice B). 5.14. La finalización de una acción debe ser informarda al usuario mediante un sonido, sea cual sea el resultado. 5.15. Sean cuales sean las teclas que se definan para la navegación por los elementos de cada pantalla, esta debe seguir un orden lógico (ver Apéndice A). 5.16. La navegación con teclado por los elementos de cada pantalla debe ser circular. Es decir después de llegar al último elemento debe pasarse al primero. 5.17. La navegación con teclado por los menús también debe ser circular. 5.18. Los elementos comunes a todas las pantallas deben tener la misma localización en cada una de ellas. 5.19. La estructura de la información debe ser la misma en todas las pantallas y/o secciones de la aplicación. 6. PAUTAS DE ACCESIBILIDAD PARA APLICACIONES NO DIRIGIDAS En este epígrafe se hará referencia a las pautas a seguir para conseguir la accesibilidad de aplicaciones que se van a manejar con la ayuda de un revisor de pantalla. Es necesario recalcar que estas pautas no se enumeran en orden de importancia o prioridad, sino que la accesibilidad se conseguirá en mayor medida cuanto más pautas se tengan en cuenta a la hora de hacer las especificaciones y diseño de la aplicación. 6.1.1. El manejo de todas las funcionalidades de la aplicación debe poder realizarse mediante el uso del teclado, sin necesidad de manejo de ratón; debiendo, no obstante, coexistir ambas modalidades. 6.1.2. Debe permitir al usuario la posibilidad de ejecutar la aplicación a pantalla completa y ampliar campos de la misma. 6.1.3. Debe utilizar la misma estructura visual de la información en todas las pantallas o páginas de la aplicación. 6.1.4. Debe facilitar al usuario, en todo momento, el acceso rápido a cualquier apartado de la aplicación, mediante un menú general presente en todas las secciones, o un mapa con accesos directos a los diferentes apartados. 6.1.5. En la medida de lo posible se recomienda usar controles estándar del sistema operativo para el que se desarrolle la aplicación. 6.1.6. En aplicaciones complejas se debe permitir que el usuario acceda a las acciones más críticas o habituales mediante el uso de las teclas rápidas del revisor de pantalla. 6.1.7. Es aconsejable realizar el diseño visual de la aplicación para que sea visualizado correctamente con una configuración de pantalla de 800x600 píxeles, ya que es la más comúnmente utilizada por las personas con discapacidad visual. 6.1.8. Debe permitir al usuario elegir la configuración de colores de la aplicación, fondos, textos, etc. o, en su defecto, que la aplicación utilice la que el usuario esté usando en el sistema operativo. 6.1.9. La aplicación debe disponer de una opción que permita seleccionar las opciones de visualización de textos, opciones de colores de la aplicación y opciones de impresión, en tinta o en braille, o si se van a imprimir pantallas que posteriormente se adaptarán con un horno Fúser. 6.1.10. Definir un orden lógico y coherente de tabulación entre los diferentes objetos de cada pantalla de la aplicación (ver Apéndice A), ya que JAWS permite el cambio del elemento que recibe las acciones en ese momento, es decir el que tiene el foco, mediante el uso del tabulador. 6.1.11. No sobrecargar las pantallas de la aplicación con excesivos enlaces a otras secciones (salvo en el caso de índices). Se recomienda que no haya más de cinco o seis en cada pantalla. 6.1.12. Eliminar enlaces redundantes dentro de la misma página o pantalla. 6.2.1. Todos los enlaces gráficos deben tener un texto alternativo descriptivo de la acción que realizan. 6.2.2. Deben tener un tamaño grande para ser fácilmente identificables en la pantalla. 6.2.3. Es aconsejable que los enlaces aumenten su tamaño y/o cambien de color al recibir el foco. 6.2.4. Los botones o enlaces que realizan la misma acción deben ser iguales en todas las pantallas o páginas de la aplicación, por ejemplo: volver, ir a la página principal, imprimir, etc. 6.2.5. La forma de los botones y enlaces gráficos debe ser sencilla, preferiblemente formas geométricas básicas. 6.2.6. Deben tener destacados los contornos de los diferentes elementos. 6.2.7. El color del botón o enlace gráfico debe contrastar con el color de fondo de la pantalla en la que se encuentra. 6.2.8. Si el botón contiene una imagen representativa de la acción que desempeña, esta debe contrastar con el color de fondo del botón. 6.3. Textos 6.3.1. No sobreimprimir textos sobre imágenes, antes bien, debe presentarse sobre fondos lisos de un único color. 6.3.2. Permitir el empleo de magnificadores de pantalla o, en su defecto, utilizar tamaños de letra grandes (mínimo: 14) y colores adecuados (ver Apéndice B). 6.3.3. Los textos deben ser “editables”, para permitir su lectura por frases cortas, por palabras e incluso por caracteres. 6.3.4. Para textos extensos, es preferible la presentación en única columna, recurriendo a la lectura mediante desplazamiento vertical. 6.3.5. Las fórmulas matemáticas, de física o química y las frases musicales precisan de una edición especial por “Línea braille”, con un editor adecuado. De no ser posible, deben ser considerados como elemento gráfico (ver 6.2). 6.3.6. Aquellos elementos y aspectos gráficos con fines de estructuración y resaltado de textos (recuadros, fondos, cambios de color o tipográficos, etc.) no tienen por qué reflejarse en la edición por línea braille o describirse vía audio, salvo que se les confiera un carácter fundamental; en cuyo caso, es preferible la ilustración sonora a la mera descripción. 6.4.1. Se deben utilizar controles estándar del sistema operativo. 6.4.2. Se debe asociar a cada elemento del formulario su etiqueta correspondiente. 6.4.3. Se debe separar un elemento del formulario de la etiqueta de otro. 6.4.4. Las listas desplegables deben tener un botón asociado para ejecutar la acción asociada a la opción seleccionada en la lista. 6.4.5. Evitar, en la medida de lo posible, las listas de selección múltiple. 6.4.6. Es conveniente encerrar el formulario dentro de un cuadro de un color que contraste con el de fondo de la pantalla, para facilitar su localización. 6.5. Vídeos 6.5.1. Los vídeos deben tener un tamaño de visualización grande. 6.5.2. Deben tener una locución sonora (verbalización o etiqueta sonora) que describa, en sincronía con la imagen, la representación o variaciones que se van produciendo en el vídeo. 6.5.3. El vídeo debe tener un botón asociado para comenzar su visualización, y no comenzar automáticamente. 6.5.4. Deben tener la posibilidad de interrumpir momentáneamente la proyección/verbalización. 6.5.5. Deben tener la posibilidad de ralentizar la proyección/verbalización. 6.5.6. Deben tener la posibilidad de repetir la proyección/verbalización. Estas pautas están basadas en las pautas del WAI para diseño de tablas accesibles en HTML. 6.6.1. No utilizar tablas si no es estrictamente necesario para estructurar la información de forma que sea más comprensible. 6.6.2. Distinguir entre las celdas de los encabezados y las de datos propiamente dichos. En este apartado se ofrecen una serie de pautas a tener en cuenta en el diseño de aplicaciones educativas, con el fin de facilitar su empleo desde el punto de vista pedagógico y de contenido. Es decir, con la pretensión de asegurar su valor didáctico. 7.1. Las aplicaciones desarrolladas para educación infantil y primeros ciclos de educación primaria, deben ser dirigidas. 7.2. Todos los ejercicios y juegos desarrollados deben poder manejarse por igual con el ratón o con el teclado. 7.3. El repertorio de teclas para usar las aplicaciones de educación infantil debe ser lo más reducido posible. 7.4. Deben existir mensajes sonoros para animar al niño, e incitarle a resolver el ejercicio, en el caso de que pase un tiempo excesivo sin que la aplicación reciba respuesta por parte del alumno. El periodo de tiempo dependerá tanto de la edad de los alumnos a los que va dirigido el programa, como del tipo de tarea, objetivo didáctico, etc. Cuando la aplicación está cargando o realizando alguna función interna, deberá dar un mensaje de información de espera, por ejemplo, "espere por favor" "el juego se está cargando”. 7.5. Se consideran imprescindibles los “fondos sonoros”, que informen al alumno de que el programa está activo o espera una respuesta que, como se ha indicado, se reclamará periódicamente. 7.6. La aplicación debe explicar claramente al alumno lo que se pretende que haga en cada momento. 7.7. Deben existir sonidos asociados al éxito y fracaso a la hora de resolver un ejercicio o un juego, cada vez que estos se produzcan, evitando el paso inmediato de una respuesta a la pregunta siguiente. 7.8. El alumno debe estar informado en todo momento sobre los aciertos y fallos que ha cometido. 7.9. Deben evitarse los juegos de relacionar colores o formas, ya que un niño ciego no puede identificarlos. En vez de esto se pueden utilizar sonidos o imágenes representativas de los colores y formas. En caso de considerarse imprescindibles, debe disponerse de la oportuna versión háptica de pantallas para su empleo sobre “tablero de conceptos”, “pantalla digital” o “tableta digitalizadora”. 7.10. Los juegos cuyo objetivo es identificar y/o conocer letras o números deben tener salida/entrada a la linea braille, con el fin de que el niño que utilice este código lecto-escritor conozca los caracteres en el alfabeto adecuado.
APÉNDICE A: Orden de tabulación lógico. En este apéndice se pretende dar una idea sobre cual puede ser el orden adecuado de navegación entre los elementos de una página, bien usando el tabulador, o cualesquiera otras teclas para realizarla. Al entrar en la página, debemos acceder primero a los elementos propios de la misma, es decir, a la información que aporta esa página, en primer lugar al título, luego al texto y gráficos que la componen, con su correspondiente descripción y, por último, a los enlaces y botones propios de la página. Seguidamente, al seguir navegando, accederemos a los enlaces generales de toda la aplicación. Estos estarán presentes en todas las pantallas. La navegación debe ser circular, es decir, después de visitar el último elemento de la página debemos volver al primero. Dentro de los elementos propios de cada pantalla, aunque la forma estándar de explorar una página es de izquierda a derecha y de arriba abajo, creemos conveniente que los elementos que sean similares, o las acciones que realizan sean parecidas, deban visitarse uno tras otro, independientemente de su situación geográfica en la pantalla.
APÉNDICE B: Ejemplos de colores para textos A continuación se muestran una serie de combinaciones de colores de texto y fondo que presentan un alto contraste lo que facilita su lectura por parte de una persona con deficiencia visual. Debemos puntualizar que esto sólo es una muestra de todas las combinaciones que se pueden utilizar, y que no todas ellas son adecuadas para todos los tipos de deficiencia visual que nos podemos encontrar. Por último, es necesario recordar que el tamaño y el tipo de letra también intervienen en la lectura del texto y, por tanto, se recomienda que se utilicen tamaños grandes de letras fácilmente legibles. Ejemplos: | 
