Mis notas sobre las jornadas de accesibilidad (28/02/2004 00:53)

Estas son las anotaciones que he tomado durante las pasadas Jornadas de formación e intercambio de mejores prácticas en accesibilidad Web. Algunas cuestiones pueden parecer evidentes o demasiado básicas, pero he creído importante volver a recordarlas.

"Con la comprensión se llega antes a la aceptación."

9 de febrero de 2004

Rampas de aceras
La accesibilidad se puede comparar a las rampas de las aceras. Las personas que no tienen discapacidades no las necesitan, pero si existen todos se benefician, ya sea yendo en bici, en patines, llevando una maleta o en silla de ruedas.
Los tres niveles de accesibilidad se podrían incluir en esta comparación: una rampa con baches sería equivalente a un nivel A de accesibilidad, una rampa lisa sería equivalente a un nivel AA, y una rampa mecanizada, que ofrece todas las facilidades a un usuario con discapacidades físicas equivaldría a un nivel AAA en una web que facilitara al máximo la navegación a través de la misma a un usuario con cualquier tipo de discapacidad.

Mesa redonda
Se realizó una mesa redonda de usuarios reales con discapacidades, que navegaron con sus ordenadores y sistemas de interfaz adaptados a sus discapacidades. En ese momento uno ve los problemas que presenta la navegación y comprensión de sitios que se han desarrollado sin seguir las pautas de accesibilidad.
Estos usuarios emplean lectores de voz, líneas de braille, navegación por voz... En una de las demostraciones, el usuario dividía con un software la pantalla del ordenador, formando una cuadrícula, e iba navegando a través de la misma y moviendo el cursor con la voz mediante coordenadas. Me vino a la mente la escena de Blade Runner, cuando el protagonista analiza la fotografía dando instrucciones de voz a su ordenador.

WCAG 2.0
Actualmente se está elaborando la siguiente versión de las WCAG, las Web Content Accessibility Guidelines. Las empresas NO deben plantearse dejar pasar la oportunidad de aplicar la versión 1.0 y esperar a que salga la versión 2.0 para cumplirla, puesto que no habrá grandes cambios.

Se trataron otros temas, como armonización de normativas de accesibilidad y qué se está haciendo en otros países de Europa o asociados.

10 de febrero de 2004
Este día los contenidos fueron menos teóricos y más prácticos.

Imágenes
ALT: El texto alternativo debe tener en cuenta el contexto, el significado de una imagen puede variar mucho según el contexto en que sea empleada.
LONGDESC: se utiliza para proveer información adicional sobre una imagen. Es un enlace a otra página HTML.
Las herramientas de validación no pueden analizar si los textos alternativos son correctos, solo pueden comprobar si hay o no.

Formularios
Es conveniente introducir las instrucciones sobre qué campos son obligatorios y cómo introducir la información antes de las cajas de texto y opciones correspondientes, puesto que los lectores de texto siguen el orden del código de la página. De esta manera, un usuario que use un navegador de voz sabrá esta información antes de rellenar el campo correspondiente.
Cada campo de un formulario debe tener asociado un texto, empleado la etiqueta label para el texto e identicando en elemento de formulario con su ID.

Tablas
Las tablas pueden emplearse para maquetar una página, no hay ningún problema siempre que al linearizarse (es decir, al ser interpretadas con un navegador solo texto como Lynx) el contenido de la página siga teniendo sentido y siga siendo comprensible.
En el caso de tablas de datos, deben identificarse los encabezados empleando TH en vez de TD, o usar opciones más avanzadas como COLGROUP, como puede verse en este ejemplo
Que se puedan usar tablas no significa que ésta sea la mejor opción para maquetar una página ni que se puedan tener 200 tablas anidadas.

Hojas de estilo
Se presentó el sitio CSS Zen Garden, que permite aplicar diferentes hojas de estilos al mismo contenido. Yo no lo había visto hasta ahora :o

Versiones de solo texto
En algunos sitios se ha optado por desarrollar dos versiones de los mismos contenidos, una versión no accesible y otra versión accesible. No se recomienda seguir este sistema por varios motivos:

  • En el mundo real, los sitios de solo texto tienden a no estar actualizados con respecto a las versiones no accesibles.
  • Se genera un ghetto para personas con discapacidades, cuando lo que se busca es su integración e independencia.
  • Es una excusa por parte de los diseñadores para no hacer un sitio accesible y "soltarse la melena".
  • No sirven para personas con discapacidades temporales, y entre esos usuarios están los que usan un agente de usuario diferente al habitual (un PDA o un móvil en vez de su ordenador habitual) o un usuario cuando ha perdido sus gafas.

Usar encabezamientos H1, H2...
Los lectores de texto siguen este esquema al leer la página y facilita la comprensión a un usuario con discapacidades. Un lector puede ir saltando de H1 en H1 siguendo las instrucciones del usuario, o de H2 en H2, lo que le permite posicionarse rápidamente en cualquier sitio de la página web.

Web apps, Scripting
Debe emplease la etiqueta NOSCRIPT para proporcionar la funcionalidad o contenido que no está disponible si el agente de usuario no tiene Javascript. No tiene sentido para un usuario con discapacidades presentarte el texto "Su navegador no admite Javascript", seguramente ya lo sabe y ese mensaje no le aporta nada.

Validación de formularios
Si la validación de un formulario se realiza mediante Javascript en el cliente, se debe programar la misma validación en el servidor, puesto que el navegador del usuario puede no tener JS. Si el lenguaje de scripting es el mismo en el servidor y el cliente (en el caso de JS y JSP), tal vez se podría compartir el mismo código.
Si los lenguajes son diferentes pienso que lo mejor es validarlo todo en el servidor en vez de estar programando dos validaciones redundantes. La validación en el servidor debe realizarse en algún momento del proceso, aunque realizar parte de la misma en el cliente puede agilizar el proceso.

Cuando hay errores al rellenar un formulario, se deben evitar los mensajes del estilo "los errores están en rojo" e indicar textualmente (además de destacar visualmente el error si se considera oportuno) en qué campo se ha cometido el error y cómo corregirlo. Si se producen errores de servidor, sus mensajes de error también deben ser accesibles.

En algunos sitios, en el proceso de alta, se presenta un gráfico con un código para evitar el registro automático y también se ofrece el texto de forma sonora para usuarios con discapacidades, pero esta solución sigue siendo problemática, puesto que es difícil recordar el código, especialmente si el navegador por voz está leyendo en ese momento contenidos de la página.

Cambios de estado
Si se emplean eventos de Javascript, se debe tener en cuenta que el usuario puede estar navegando a través del teclado o el ratón. Por este motivo, si se emplean onMouseOut o onMouseOver, se deben añadir los correspondientes eventos onBlur o onFocus. En los menús desplegables, se debe evitar el evento onChange, cambiándolo por onSubmit. Esto permite al usuario verificar los contenidos que ha introducido en el formulario antes de enviarlo.
La mejor opción para realizar cambio de color, formato o fondo en un texto al pasar el ratón por encima es usar CSS en lugar de Javascript. Los efectos de roll-over deben evitarse en opciones de navegación y para mostrar información.

Tamaño del texto
Que se pueda cambiar el tamaño del texto de un sitio web (al emplear medidas relativas en vez de absolutas en la hoja de estilos) no implica que se pueda diseñar con tamaños de fuente pequeños. No todo el mundo sabe o puede cambiar el tamaño del texto en su navegador, por lo que el tamaño por defecto del sitio web debe ser razonable.

Applets y plugins
Si se usan applets u otros plugins, su programación debe incluir las opciones de accesiblidad que están dentro de cada lenguaje (Flash o Java). ¿Flash accesible? :D Según Macromedia lo es, pero creo que muchos usuarios con discapacidades no compartirían esta opinión. Al finalizar las jornadas, le pregunté a una usuaria que estuvo en la mesa redonda si había encontrado algún sitio con un Flash accesible, y su respuesta fue NO. Esto me hace pensar entre lo separados que están en ocasiones la accesibilidad teórica (la de las pautas y validadores) y la accesibilidad real de los usuarios con discapacidades.

Redacción de informes sobre evaluación
Si hay que redactar algún informa sobre el análisis de la accesibilidad de un sitio web, conviene ser alentadores, animar a realizar las mejoras necesarias, proporcionando información para resolver los problemas detectados. Se trata de motivar para realizar los cambios para que el sitio sea accesible.

Herramientas de evaluación
Las herramientas no pueden hacerlo todo, necesitan participación humana. La validación de accesibilidad de un sitio web puede compararse a un corrector ortográfico, puesto que se producen falsos negativos y falsos positivos, además es conveniente ir comprobando la accesibilidad de un sitio desde las primeras fases de desarrollo y no esperar a tener, siguiendo la comparación, redactado todo el libro para corregir todos los errores de accesibilidad.

El autor y las herramientas de autor son los primeros en generar errores de accesibilidad.
Las plantillas se emplean para repetir la presentación de contenidos, por lo que se pueden repetir errores de accesibilidad si no se detectan a tiempo. En sitios muy extensos a la hora de evaluar, las plantillas serían los primeros archivos a analizar.

Si se soportan varios idiomas hay que prestar atención porque puede haber páginas correctas en un idioma e incorrecta en otros idiomas.

Todos los enlaces

Validadores

Sebastian Villalba | 28/02/2004 00:53 | TrackBack
Comentarios

Exporta a PDF y me haces feliz :D

manu | 28/02/2004 04:13

He llegado a estas notas desde simplelogica.net
Me han gustado mucho porque creo que son un buen resumen de las Jornadas.
Tan solo un par de apuntes sobre un par de cosas que quizás no fueron lo suficientemente bien explicadas allí y por eso te han lleva a error:
[cita]
Versiones de Solo texto.
En algunos sitios se ha optado por desarrollar dos versiones de los mismos contenidos, una versión no accesible y otra versión accesible.
[fin cita]


Con esa redacción se da a entender que una "versión sólo texto" es sinónimo de "versión accesible" y eso no es así. Una versión sólo texto puede ser más o menos accesible e incluso absolutamente inaccesible para una persona ciega.

Las directrices lo que piden es crear una "versión accesible" que contenga el mismo contenido que la no accesible de forma alternativa. Es decir, una versión que aplique las directrices de accesibilidad y, por tanto, debe contener imágenes y gráficos. Precisamente, se entiende por plenamente accesible una página que contiene ilustraciones del contenido textual. Uno de los puntos de nivel 3 pide precisamente eso.

Applets y plugins:

Nadie dice que Flash sea accesible. Lo que se dijo, y tú lo has recogido más o menos bien, es que deben aplicarse las opciones de accesibilidad que aporta el editor de Flash. Estas opciones no son ni mucho menos lo ideal, no contemplan todos los casos y situaciones de los usuarios, pero son un avance que permiten la navegación y uso de un objeto flash a algunos usuarios.
En este momento Flash ofrece para la accesibilidad sólo dos cosas: textos alternativos y descripción de imágenes que pueden leer unicamente los lectores de pantalla que corren baja Windows e Internet Explorer: JAWS y WindowsEyes. Y por otra parte, la posibilidad de indicar atajos de teclado y definir el orden de tabulación de los elementos.

¡Enhorabuena por el artículo, creo que es un buen resumen de lo expuesto y, por tanto, un buen resumen de las directrices de accesibilidad más básicas!

Salu2.

Emmanuelle Gutiérrez y Restrepo | 28/02/2004 16:10

Manu, el único PDF que puedo generar es el de la página web, suelo editar los post en txt, nada de formatos y negritas en Word ;)

Emmanuell, muchas gracias por tus comentarios. Por cierto, uno de los sitios que he desarrollado consiguió una Mención SIDAR 2003 :)

Sebastian Villalba | 01/03/2004 01:22

¡Excelente! Un artículo y un resumen muy interesante. Yo hace unas semanas tuve que enfrentarme a un problema de accesibilidad (lo relato en mi weblog) y todo lo que dices es cien por cien útil.

Felicidades.

Juanjo Navarro | 02/03/2004 18:30
Envía tu comentario












Recordar información


No se permite HTML, los enlaces se generan automáticamente.
Por culpa de los casposos señores del spam es posible que tu mensaje tarde unas horas en aparecer.