PAUTAS PARA EL DISEÑO DE ENTORNOS EDUCATIVOS ACCESIBLES PARA PERSONAS CON DISCAPACIDAD VISUAL

1. INTRODUCCIÓN

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.

3. TIPOS DE APLICACIONES INFORMÁTICAS ACCESIBLES

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.
4. DEFINICIONES Y ACRÓNIMOS

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.

JAWS: Revisor de pantalla desarrollado por Freedom Scientific. Actualmente es el más usado de los que existen en el mercado. (http://www.freedomscientific.com/)

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.

5. PAUTAS DE ACCESIBILIDAD PARA APLICACIONES DIRIGIDAS

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. Pautas generales de manejo 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. Gráficos, enlaces gráficos y botones.

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. Formularios

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.

6.6. Tablas

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.

7. CRITERIOS PEDAGÓGICOS EN EL DESARROLLO DE APLICACIONES EDUCATIVAS PARA DISCAPACITADOS VISUALES.

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.

ONCE-CIDAT

GUÍA PARA EL ESTUDIO DE ACCESIBILIDAD DE SITIOS WEB

En la actualidad, los contenidos de los sitios Web no siempre son accesibles a personas con algún tipo de discapacidad (visual, auditiva, física o neurológico-cognitiva, tecnológica, etc.).

Algunos de los problemas habituales de accesibilidad a los sitios Web incluyen:

- imágenes sin texto alternativo
- enlaces sin un texto significativo
- ausencia de asociación de etiquetas a los controles correspondientes en los formularios
- tablas de datos sin información de cabeceras de fila y/o columna
- uso incorrecto de los elementos estructurales en las páginas
Bajo esta problemática, el Consorcio World Wide Web (W3C) , y más concretamente su grupo de trabajo permanente Grupo de Trabajo de las Pautas de Accesibilidad al Contenido en la Web (Web Accessibility initiative) , ha realizado estudios sobre la accesibilidad de la Web.
Como resultado de los trabajos desarrollados en el seno de WAI, se publicó el 5 de mayo de 1999 la especificación Pautas de Accesibilidad al Contenido en la Web 1.0 y en la actualidad se está trabajando en una nueva versión, Pautas de Accesibilidad al Contenido en la Web 2.0.
En España, en octubre de 2002 entró en vigor la Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSICE) que incluye el siguiente párrafo en sus disposiciones adicionales:
Las Administraciones Públicas adoptarán las medidas necesarias para que la información disponible en sus respectivas páginas de Internet pueda ser accesible a personas con discapacidad y de edad avanzada de acuerdo con los criterios de accesibilidad al contenido generalmente reconocidos antes del 31 de diciembre de 2005. Asimismo, podrán exigir que las páginas de Internet cuyo diseño o mantenimiento financien apliquen los criterios de accesibilidad antes mencionados.
Desde CIDAT, se recomienda el cumplimiento de la especificación Web Content Accessibility Guidelines 1.0 , en la cual se explica cómo hacer accesibles los contenidos de la Web a personas con discapacidad. La especificación contiene catorce pautas que son los principios generales para el diseño accesible, teniendo cada pauta asociados uno o más puntos de verificación que describen cómo aplicar esa pauta.
También se encuentran publicadas las Técnicas para las Pautas de Accesibilidad al Contenido en la Web 1.0 , donde se puede encontrar el procedimiento para el cumplimiento de los puntos de verificación mediante explicaciones y ejemplos.
GUÍA BREVE PARA CREAR SITIOS WEBS ACCESIBLES
Original en inglés: Quick Tips to Make Accessible Web ( Puntos básicos de las pautas WAI )

- Imágenes y animaciones: Use el atributo alt para describir la función de cada elemento visual.
- Mapas de imagen: Use el elemento map y texto para las zonas activas.
- Multimedia: Proporcione subtítulos y transcripción del sonido, y descripción del vídeo.
- Enlaces de hipertexto: Use texto que tenga sentido leído fuera de contexto. Por ejemplo, evite "pincha aquí".
- Organización de las páginas: Use encabezados, listas y estructura consistente. Use CSS para la maquetación donde sea posible.
- Figuras y diagramas: Descríbalos brevemente en la pagina o use el atributo longdesc.
- Scripts, applets y plug-ins: Ofrezca contenido alternativo si las funciones nuevas no son accesibles.
- Marcos: Use el elemento noframes y títulos con sentido.
- Tablas: Facilite la lectura línea a línea. Resuma.
- Revise su trabajo: Verifique. Use las herramientas y puntos de comprobación descritas en las pautas.
Otras recomendaciones
De forma complementaria, y como ayuda en el estudio del cumplimiento de algunos puntos de verificación de WCAG 1.0, se recomiendan las siguientes acciones:
- Utilización de herramientas de validación de accesibilidad: Como ayuda en el estudio de la accesibilidad de las páginas de un sitio web se pueden utilizar herramientas de validación automática de accesibilidad que permiten ver de forma rápida si existen errores muy graves. Sin embargo, se debe tener en cuenta que ninguna herramienta automática puede revisar determinadas cuestiones como si un texto es suficientemente significativo. Estos validadores permiten incluir en las páginas un icono indicando el nivel de adecuación a las Pautas de Accesibilidad. Algunos de los validadores disponibles son los siguientes:
- TAW (Test de Accesibilidad Web): herramienta de validación de accesibilidad en español. Dispone de soporte web y también presenta una versión descargable gratuita que permite el análisis de páginas web no publicadas.
- WebXACT: herramienta en línea que permite configurar en qué directrices de accesibilidad se desea basar el análisis y en el caso de Web Content Accessibility Guidelines 1.0 el nivel de adecuación que se desea analizar. Además analiza aspectos relacionados con el código.
- Cynthia Says: herramienta en línea que permite configurar en qué directrices de accesibilidad se desea basar el análisis y en el caso de Web Content Accessibility Guidelines 1.0 el nivel de adecuación que se desea analizar.
- Bobby: herramienta en línea que permite configurar en qué directrices de accesibilidad se desea basar el análisis (limita el estudio a una página por minuto).
- Validación de la sintaxis de las páginas y las hojas de estilo a través de los validadores del W3C, Servicio W3C de validación de marcado y Servicio W3C de validación CSS.
- Visualización de las páginas en un emulador o navegador sólo-texto.
- Diferentes tipos de visualización de las páginas:
- sin ratón
- sonidos y gráficos cargados
- gráficos no cargados
- sonidos no cargados
- scripts, hojas de estilo, y applets no cargados
- Visualización de las páginas en varios navegadores:
Navegador Opera para Windows
- Revisión de las páginas con un lector de pantalla:
- JAWS for Windows (Freedom Scientific)
- JAWS (versiones demo en español)
Direcciones útiles
- Consorcio World Wide Web (W3C), Oficina española. La Fundación CTIC (Centro Tecnológico de la Información y la Comunicación ) alberga la Oficina Española del W3C establecida en el año 2003.
- Documentos para el diseño accesible de contenidos en la Web. Traducciones de los documentos redactados y editados por la Iniciativa por la Accesibilidad de la Web (WAI) del W3C, alojados en Discapnet, proyecto financiado por Fundación ONCE y los fondos FEDER de la UE. La traducción y adaptación de los textos fue hecha por Carlos Egea García, Alicia Sarabia Sánchez y Alan Chuter.
- Área de recursos de accesibilidad de FUNDOSA TELESERVICIOS. Fundosa Teleservicios proporciona recursos para todas las partes involucradas en la accesibilidad de las tecnologías de la información y la comunicación, desde los propios usuarios, los diseñadores y desarrolladores, hasta los directivos.
- Diputación de Barcelona, Libro de estilo para la accesibilidad de los contenidos web. Resultado del trabajo conjunto entre la Diputación de Barcelona, usuarios, profesionales y técnicos del sector.
- W3 Schools: Recursos ofrecidos por W3C totalmente gratis, destacan tutoriales, guías y ejemplos sobre HTML, CSS, JavaScript, PHP, ASP, SQL, DTD, SOAP, etc. además de una descripción detallada de los objetivos y actividades de W3C.
- SIDAR: Fundación y Seminario. Sitio en el que se puede encontrar información sobre las actividades de la Fundación SIDAR y especialmente todo lo que atañe al Seminario SIDAR: Información y Recursos para el desarrollo y diseño accesible para la Sociedad de la Información, actividades como cursos, campañas, etc.
Iniciativas europeas
- eEurope niciativa de la Comisión Europea para lograr una Sociedad de la Información para Todos.
- EDeAN, European Design for All e-Accessibility Network Establecido en julio 2002, conforme a uno de los objetivos específicos del Plan de Acción eEurope 2002.
- Euroaccessibility. Un primer paso hacia una metodología armonizada para la evaluación de la accesibilidad de los sitios Web.