Todo tipo de información sobre accesibilidad en la Web: errores de accesibilidad, ejemplos de páginas inaccesibles, noticias, software, hardware, ayudas técnicas, tecnologías de apoyo, consejos, pautas y guías de accesibilidad, WAI, WCAG, Norma UNE 139803:2004, legislación, etc.
El objetivo este volumen es mostrar a las Administraciones Públicas que la inversión en tecnologías accesibles no es una inversión a fondo perdido, sino que permite recuperar el capital invertido y, además, obtener importantes beneficios gracias al ahorro de costes que se produce con la implantación de este tipo de tecnologías.
Se han analizado los principales sectores productivos que gestionan las instituciones públicas, tanto ámbitos verticales o sectores específicos: Sanidad, Educación y Empleo; como ámbitos horizontales o sectores transversales, es el caso de la Administración Electrónica o las Ciudades Inteligentes (Smart Cities). Este análisis se complementa con diversos casos específicos, en los que se detalla cuantitativamente cómo la implantación de las tecnologías accesibles impacta de forma positiva en los procesos de gestión y cómo se reducen significativamente los costes que actualmente están soportando las instituciones públicas.
Además el informe incorpora un análisis socio-económico del impacto de las compras TIC potencialmente accesibles en la economía nacional, y un análisis estratégico DAFO, previo a las conclusiones finales del volumen.
Cuando avisé de la presentación de este informe, ya dije que tenía mucho interés en consultarlo "porque una cosa es decir que la accesibilidad no cuesta mucho y otra es decir que incluso permite el ahorro". El misterio está resuelto: en el informe se mezclan diferentes contextos de uso de nuevas tecnologías en diferentes contextos (medicina, educación, empleo) que en algunos casos sí que se pueden considerar "tecnologías accesibles", pero que en otros muchos casos son simplemente nuevas tecnologías de uso general. Incluso aparecen las famosas "ciudades inteligentes" que tan de moda están últimamente.
En fin, el típico informe que se podría haber resumido en 10 páginas.
Hace unas semanas publiqué una entrada sobre cómo desactivar el diseño web adaptable, ya que puede causar problemas de uso entre algunos usuarios. Por tanto, puede suponer un problema de accesibilidad.
En Responsive Web Design and Accessibility, varios expertos discuten sobre cómo encajan el diseño web adaptable y la accesibilidad. Algunas de las frases que se destacan en esta discusión:
Both responsive Web design and accessibility are ways of making a site flexible.
Responsive Web design and accessibility are very complementary, but … doing responsive design does notmean that you automatically have an accessible site or application and vice versa.
Responsive design and accessibility are orthogonal. You can have accessible sites that aren’t responsive. You can have responsive sites that aren’t accessible.
As responsible Web designers, we should be building Web sites in such a way that people using accessibility technologies are able to have a coherent user experience.
Creating Web sites that work with different devices is … a good start for accessibility.
Both responsive Web design and accessibility rely on coding a site to standards. “This includes separating the content from the display rules.
Por si no lo sabes, ChromeVox es un complemento del navegador Google Chrome que integra un lector de pantallas en el propio navegador.
Google ha creado un API para ChromeVox, de forma que desde una página web se puede proporcionar información adicional a ChromeVox para que éste interprete y lea las páginas web tal como el creador de la página web quiera. Esto ofrece un abanico nuevo de posibilidades, pero también abre la puerta a muchos abusos que pueden producir una fragmentación de la accesibilidad.
Lo más interesante que se muestra en el vídeo es la utilización de esta API para la interpretación de contenido matemático en formato MathML. ¡Todo un avance muy interesante!
En YouTube Flash player with captions, presentan un reproductor de vídeo accesible, basado en Flash, que proporciona controles accesibles para personas que utilizan un lector de pantalla o que manejan el ordenador con el teclado.
La educación es sin duda uno de los temas candentes de la actualidad, en los medios se refleja el continuo debate sobre la formación libre y para todos. No obstante, desde CENTAC creemos que en ese "para todos" es imprescindible incluir a las personas con discapacidad, y las TIC son una oportunidad para lograrlo.
Además, en las conclusiones de varios de nuestros talleres hemos recogido que la educación es un vehículo fundamental para la normalización de la discapacidad, sin embargo la realidad indica que todavía queda mucho camino por recorrer. Las TIC están transformando el mundo educativo porque ofrecen enormes posibilidades para encontrar nuevos canales, nuevas formas de enseñar y nuevas formas de aprender. Pero, ¿que ocurre si no son accesibles? ¿Ayudan o suponen un freno?
Estas son algunas de las posibles preguntas sobre las que hablaremos en nuestro próximo taller del 13 de junio, donde expertos que están en el día a día trabajando con alumnos con discapacidad nos hablarán de las posibilidades y realidades que hoy en día están ofreciendo las TIC en la educación y cómo las están incorporando en sus métodos de enseñanza, también hablaremos sobre cómo están haciendo que los contenidos sean accesibles para sus alumnos con discapacidad.
En el artículo Ten Common Accessibility Problems, su autor recopila los diez problemas más comunes en base a su experiencia como revisor de la accesibilidad de numerosos sitios web. En esta lista, el orden de los problemas no es significativo:
No incluir el texto alternativo para las imágenes.
Uso de CAPTCHA.
No proporcionar alternativas adecuadas para contenido inaccesible.
No usar los encabezados de HTML de forma apropiada.
No asociar de forma explícita los controles de un formulario con sus etiquetas.
No garantizar la suficiente diferencia de contraste entre el color del texto y el color de fondo.
No identificar las tablas de datos con summary o caption.
No etiquetar las tablas de datos correctamente.
No garantizar que las páginas se pueden usar sin el ratón.
Uso del evento onchange en los menús de tipo select.
En el vídeo mostraba un problema que no es realmente un problema de accesibilidad, afecta a todos los usuarios: las provincias de Álava y León aparecían repetidas. Pero problemas como el de los nombres de las estaciones se pueden ver potenciados de forma negativa en el caso de las personas con discapacidad.
Por ejemplo, en la lista de provincias aparecían repetidas las provincias de Álava y León, y las estaciones de ambas provincias se repartían entre las dos repeticiones. Una persona que ve tiene más fácil darse cuenta de que esas provincias aparecen repetidas que una persona ciega que usa un lector de pantallas.
Desde aquí, le doy las gracias a Adif por resolver este problema, que no sé si lo han hecho a raíz de mi vídeo, pero resuelto está.
En la siguiente imagen vemos que la provincia de Álava ya no aparece repetida, además, también han corregido el nombre de Vizcaya:
En la siguiente imagen vemos que la provincia de León tampoco aparece repetida:
Ahora ya sólo falta que Renfe resuelva el lío que tiene con el nombre de las estaciones.
El Centro de Referencia Estatal de Autonomía Personal y Ayudas Técnicas, CEAPAT, centro
perteneciente al IMSERSO, celebra su semana de puertas abiertas del 10 al 14 de junio, donde usuarios,
técnicos y empresas comparten experiencias sobre nuevas tecnologías y accesibilidad.
Entre otras actividades, se han organizado unas jornadas técnicas que se retransmiten en directo vía streaming por la empresa EDSOL PRODUCCIONES, especializada en la retransmisión de eventos en directo a través de Internet.
Según la nota de prensa del evento:
La retransmisión de las jornadas incluye el subtitulado e la interpretación en lengua de signos en
directo que pueden activarse o desactivarse a voluntad del usuario. Además de incluirse incrustados en
el vídeo, los subtítulos están disponibles en modo texto. Esto permite su seguimiento por línea Braille
para personas ciegas y sordociegas. Otra ventaja de este tipo de subtitulado es que al finalizar el evento
se dispone de todo el texto para su consulta y edición por parte de periodistas y bloggers.
Las jornadas se pueden seguir a través de cualquiera de estos dos enlaces:
After further looking into this, we've decided to support the longdesc attribute in Firefox.
While we've considered longdesc in the past, the landscape has changed and there are reasons to support it now. For one, the W3C validator now supports it, making it more likely to be supported across browsers. Authors who want to make pages accessible may not be able to rely on longdesc on any browser, but there isn't presently another standardized option available. And, importantly, it can be implemented without disrupting the user experience of users who don't require it. Underscoring all of this is that the Mozilla project is a community, and our actions must reflect the needs and wants of the community.
There is a chicken and egg issue here, as Alastair notes in comment 20. Supporting longdesc means that the door to wider adoption is open, and perhaps authors will surprise us with innovative uses of this attribute once they feel freer to do so. And, perhaps in time better solutions to some of the problems longdesc tackles will emerge. While we'll always be open to browser improvements, particularly in the accessibility space, we shouldn't ignore a ready solution because it's not perfect.
Y justo hace unos días, el 6 de junio, se publicó una nueva versión de HTML5 Image Description Extension. Poco a poco se acerca más al "last call" para por fin llegar al nivel de "recommendation".
Hay campos en el formulario de selección de trenes que no tienen una etiqueta que los identifique.
Atributo title en enlaces redundante porque repite la misma información que contiene el enlace.
El formulario de selección de trenes no tiene un botón de envío, es un enlace.
No se indica el formato para introducir la fecha de salida y de regreso.
La lista de estaciones no es accesible para los usuarios ciegos.
Ausencia de encabezados en algunas zonas importantes.
No se avisa de que ciertos enlaces se abren en una ventana nueva (en realidad, no se debería abrir ninguno en una ventana nueva).
Y en la segunda página, la que sale una vez se han completado el formulario de compra:
Errores de validación del código HTML, como una tabla con dos títulos, que pueden repercutir en la accesibilidad.
Los encabezados son un verdadero desastre.
Los botones para pasar al día anterior o al día siguiente no son botones, son enlaces.
El formulario para acceder como un usuario registrado no tiene un botón de envío, es un enlace.
El botón para continuar con la compra no es un botón, es un enlace.
Y la transcripción del audio:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y en este vídeo vamos a ver algunos problemas graves de accesibilidad que presenta el nuevo sitio web de Renfe.
Este vídeo consta de varias partes y ha sido realizado con la colaboración de Ramón Corominas y Jesús Álvarez del Amo, que realizaron una presentación sobre los problemas de la web de Renfe en el marco de las reuniones de “Madrid Accesibilidad TICs”.
En el vídeo anterior, vimos que en los últimos meses ha habido varias quejas de usuarios respecto a los problemas de usabilidad y de accesibilidad de la nueva web de Renfe. En este vídeo vamos a ver los principales problemas de accesibilidad.
En concreto, vamos a ver los problemas que presentan dos páginas, la página principal y la página que aparece al introducir los datos de un viaje y pulsar en el botón comprar.
Voy a empezar con la validación del código HTML de la página principal, ya que las dos versiones de las Pautas de Accesibilidad al Contenido en la Web del W3C lo exigen.
Los resultados que se obtienen con el validador oficial del W3C son desastrosos, 75 errores y 7 advertencias.
Vamos a ver los primeros errores simplemente para tener una idea de su naturaleza.
La página tiene definido el DOCTYPE XHTML 1.0 Strict, lo cual está muy bien.
El primer error es que la página contiene el atributo “onLoad” con la “l” en mayúsculas. En XHTML los atributos se tienen que escribir todos en minúsculas.
A continuación, hay errores en el primer formulario, porque está escrito directamente dentro de la etiqueta form, y eso no es posible. Los campos de un formulario deben de escribirse dentro de un elemento de bloque, como un párrafo p o un contenedor div.
Este formulario tiene campos de tipo input que no han sido cerrados. Sin embargo, es gracioso ver que otras etiquetas de tipo input sí que han sido cerradas correctamente. ¿A qué se debe este error? ¿A un olvido? ¿A las prisas? ¿A una falta de control de calidad?
Y bueno, así hasta llegar a los 75 errores.
La herramienta de evaluación de la accesibilidad WAVE detecta 5 errores y 22 advertencias.
Los cinco errores son campos del formulario que no tienen asociados una etiqueta label que los identifique.
En realidad, como podemos ver, sí que existen las etiquetas label para esos campos, pero la asociación está mal hecha, porque el valor del atributo “for” no se corresponde con el atributo “id” o el campo no tiene atributo “id”.
Por cierto, en este fragmento de código sorprende encontrarse dos etiquetas input escritas en mayúsculas. Eso es otro error de validación.
En 10 ocasiones, el atributo “title” usado en enlaces es redundante, porque repite el mismo texto que contiene el enlace. Eso es totalmente inútil, no sirve para nada, pero puede ocasionar problemas.
WAVE señala como una advertencia, como un posible error el uso de “accesskey”, los atajos de teclado, nueve veces. Aunque en principio es una característica destinada a mejorar la accesibilidad, normalmente se desaconseja su uso, ya que estos atajos de teclado pueden interferir con los atajos de teclado que tenga definido el usuario. Por lo tanto, es mejor no usarlo en un sitio web destinado a todo el público.
La herramienta de evaluación TAW detecta 13 errores automáticos de prioridad 2.
Los errores detectados son básicamente los mismos que hemos visto antes: los campos de los formularios están mal etiquetados.
La herramienta de evaluación eXaminator proporciona una nota de 6,5 sobre 10. En la página web de Renfe hay 6 pruebas que se valoran como “mal”.
eXaminator detecta un error importante: hay un formulario sin un botón de envío.
Efectivamente, el formulario principal, el de compra de billetes, el que seguramente más le interesa a los usuarios, y más le tiene que interesar a Renfe porque es su fuente de ingresos, no tiene botón de envío.
Estos dos botones que vemos aquí, “Todas las estaciones” y “Comprar”, no son realmente botones, visualmente parecen botones, pero son enlaces que realizan la función de botones.
Aunque no es una barrera de accesibilidad grave, sí que puede causar confusión entre algunos usuarios.
Además, eXaminator también detecta que hay un valor del atributo id repetido en la página.
Este error está otra vez relacionado con los campos de los formularios.
En definitiva, que la página web contiene numerosos errores. Alguien puede decir que no son errores importantes, pero aunque fuese verdad, que no lo es, son un claro síntoma del poco cuidado que tiene la gente que desarrolla el sitio web de Renfe.
Antes de continuar, hay que recordar que las herramientas automáticas de evaluación de la accesibilidad no son capaces de detectar todos los problemas. En realidad, los problemas más graves que presenta la página web de Renfe, que los vamos a ver a continuación, no son detectados por las herramientas que acabamos de ver.
Como ya podemos intuir por los resultados de las herramientas automáticas de evaluación de la accesibilidad, los problemas más graves están en el formulario de compra.
En este formulario, el origen y el destino de un viaje sí que están correctamente identificados por una etiqueta label.
Pero la fecha de salida y la fecha de regreso no están correctamente relacionadas con sus correspondientes etiquetas.
Por cierto, en este fragmento de código, ¿qué hace un div dentro de un párrafo? Eso es otro error de validación.
Sin la correcta identificación de los campos, un usuario ciego que utiliza un lector de pantallas, no sabe qué tiene que introducir en estos dos campos.
Además, ¿qué formato de fecha se debe emplear? Este ya no es sólo un problema de accesibilidad, sino que es un problema de usabilidad porque afecta a todos los usuarios.
Y ya que estamos, otro problema de usabilidad. Si aquí se habla de “Ida y vuelta”, ¿por qué no emplea la misma denominación aquí? ¿Por qué se emplea “Salida” y “Regreso”?
En realidad, podemos ver que en esta versión del sitio web de Renfe de abril de 2010, se empleaban los términos “Ida” y “Vuelta” para la fecha de ida y la fecha de vuelta.
Pero el problema más grave es la lista de búsqueda de estaciones para el origen y el destino.
La lista desplegable que aparece se puede emplear con el teclado sin problemas, pero no es accesible para los usuarios ciegos que utilizan un lector de pantallas, pero este problema se explicará en un siguiente vídeo.
Un aspecto positivo que tiene la página principal de Renfe es el empleo correcto de los encabezados. Sin embargo, vamos a ver que no ocurre lo mismo en todas las páginas.
Estos son todos los encabezados que hay en la página principal de Renfe.
Se podría haber hecho un poco mejor, ya que hay una zona muy importante que no tiene encabezados, el apartado de redes sociales.
Justo en el apartado de redes sociales encontramos un problema importante: no avisa de que los enlaces se abren en una ventana nueva.
En realidad, abrir un enlace en una ventana nueva es una mala opción para todos los usuarios, el usuario tiene que tener la libertad de tomar la decisión de abrir un enlace en una ventana nueva, no se debe decidir por el usuario.
Y otra pregunta, ¿por qué dos listas? Se podría haber hecho con una sola lista y habría sido más significativo.
Pero curiosamente, esta barra de navegación, cuyos enlaces también se abren en una ventana nueva, como podemos ver en este fragmento de código, sí que tienen un aviso, en concreto “Se abre en ventana nueva”, que añade un pequeño icono con ese texto alternativo a los enlaces anteriores que tienen un id con el valor “opc” más un número.
¿Y el “BonoAVE”, por qué no tiene la imagen y el aviso? Muy sencillo, porque se les olvidó poner atributo id en el enlace de “BonoAVE”.
Bien, ahora vamos a ver la segunda página, la página que aparece al introducir los datos de un viaje y pulsar en el botón comprar.
En esta página el usuario tiene que elegir el tren que desea utilizar entre todos los que ha encontrado Renfe que cumplen sus criterios de búsqueda.
En esta página hay un error tremendo.
Mientras que en la página anterior, la página principal, los encabezados estaban correctamente etiquetados, en esta página los encabezados son un desastre y no sirven para nada.
¿Dónde está el problema? El problema está en que no se han cerrado correctamente los encabezados.
Por ejemplo, aquí tenemos el primer encabezado h1 que sí que está cerrado correctamente.
Pero el segundo encabezado h1 no se cierra correctamente, e incluye todo lo que viene a continuación.
Este encabezado se abre en la línea 511, y se cierra posteriormente en la línea 597.
Pero como podemos ver aquí, esto no sólo ocurre con este encabezado, ocurre lo mismo con los siguientes encabezados de la página.
Otro problema importante se encuentra en este panel para cambiar el día del viaje.
En primer lugar, hay un problema de usabilidad importante. El color gris se suele emplear para indicar que un elemento de interacción como un botón, no es utilizable, sin embargo, en esta página, estos dos botones que aparecen en gris sí que se pueden utilizar.
Pero el problema de accesibilidad lo detectamos al ver el código fuente. Otra vez, lo que aparentemente son botones, en realidad no son botones.
Son enlaces a los que se les ha asignado una acción con el evento “onclick”.
Si algo parece un botón y actúa como un botón, ¿por qué no está etiquetado como un botón?
Pero además, el texto de estos enlaces no es significativo, no identifica correctamente la función del enlace, del botón. ¿”Día antes” y “Después”, de qué?
Algunos usuarios, por ejemplo los usuarios ciegos que utilizan un lector de pantallas, navegan por las páginas web a través de una lista que contiene todos los enlaces de la página.
En la página de Renfe, a los usuarios ciegos les aparece repetido el enlace “Día Antes” y “Después”, pero no saben si se refiere al viaje de ida o de vuelta.
Por cierto, en la página principal se usan los términos “Salida” y “Regreso”, ¿por qué se emplean ahora los términos “Ida” y “Vuelta”? ¿No crea un poco de confusión?
Y ya para finalizar, dos botones más que no son realmente botones.
Por un lado, el botón “Entrar”, del formulario para acceder como un usuario registrado no es realmente un botón, es, otra vez, un enlace que hace creer que es un botón.
Por otro lado, al final de la página aparece el botón “Continuar”, que tampoco es realmente un botón, sino que es un enlace con una acción asociada.
Y además, qué codigo HTML más raro: un h3, que tiene dentro un div, que a su vez tiene un enlace a, que a su vez tiene otro div.
En resumen, sin duda alguna, de la nueva página web de Renfe se puede decir que se puede hacer mal, pero peor que esto, imposible.
Y con esto finaliza este videotutorial que ha mostrado algunos de los problemas de accesibilidad que presenta el sitio web de Renfe.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
