En dicho artículo se explica cómo obtener gracias un móvil información desde la Web sobre el estado de los autobuses tanto en Madrid como en Barcelona:

Así que después de este rollo que os he soltado, y en vista de que creo que la solución del móvil y las Webs es el menos malo de todos, voy a pasar a explicar, para los autobuses de Madrid y de Barcelona, cómo podemos ver desde la Web y desde el móvil el tiempo de espera de nuestro autobús, que nos servirá, al menos, para estar atentos y no dejarle pasar de largo cuando aparezca.

Esto es genérico para todos los móviles con navegación Web y con un lector de pantallas. Creo que para los orgullosos propietarios de un Iphone (la envidia es muy mala, señores), hay una aplicación que ya incluye esta funcionalidad, pero como yo tengo Symbian y el lector de pantallas TALKS, os voy a contar cómo lo hago para obtener tan preciada información.

Autobuses de Madrid

1. Lo primero que debemos hacer, es entrar desde el móvil a la Web de transportes de la Comunidad de Madrid: http://www.emtmadrid.es.
2. Aquí, buscamos un encabezado de nivel 3, que reza: Tiempo de espera. Con talks, podemos ir saltando entre encabezados con el número 4.
3. Bajamos hasta un cuadro combinado con las líneas, lo activamos, y seleccionamos la línea que queramos consultar.
4. Aceptamos la opción elegida, y bajamos hasta encontrar el botón de Aceptar.
5. La página se recargará, y ahora ya podremos elegir la parada a consultar. Si en este momento guardamos la página en favoritos, podremos reabrirla desde allí, y nos podremos saltar el paso de elegir la línea.
6. Aquí, volvemos a buscar un encabezado: “Tiempo que falta para que venga mi autobús”, y bajo él, veremos que tenemos las paradas de ambos sentidos. Elegimos el cuadro y la parada que nos interese (aparece el número de la parada y el lugar en el que se encuentra, y tras esto, pulsamos Aceptar.
7. Cuando la página se recargue, volvemos a pulsar el atajo de teclado para llegar al primer encabezado (Tiempo que falta para que venga mi autobús), pulsamos el atajo de teclado para ir al botón de Aceptar (en talks es el número 5), y bajo el botón, nos aparecerá el tiempo de espera: “EMT Informa: Autobús en entorno de parada. El siguiente llegara en 10 minutos.”.
8. Si queremos actualizar el asunto, subimos con las flechas hasta el botón de aceptar, y lo volvemos a pulsar (ya aparecen seleccionadas de antes la línea y la parada). Tras la recarga, volvemos a ir al encabezado y luego al botón, y volveremos a tener la información actualizada en pantalla.

Autobuses de Barcelona

En Barcelona, lo tenemos aún más sencillo.

Con sólo entrar a la Web: http://www.tmb.cat/ibus.html, escribir el número de la línea y de la parada y pulsando en Aceptar, nos aparecerá una página con dicha información. Pero lo mejor, es que una vez estemos en esa página, además de tener un botoncito para actualizar la información, podemos guardar la página en favoritos, y abrirla directamente sin necesidad de estar consultando cuadros combinados de paradas ni nada parecido. Y para más comodidad, la página no tiene ninguna información superflua, sólo la línea seleccionada y la parada (incluso si queremos todas las paradas de una línea, podemos dejar el cuadro de parada en blanco), y los tiempos de espera para la selección. Ni imágenes, ni enlaces, ni nada de nada.

Es ingenioso el sistema por mando de Málaga aunque casi siempre el planteamiento más sencillo será la solución al problema más difícil.

Entre ellas, destacan:

• The Myth of the Typical Screen Reader User. Mediante datos obtenidos de diferentes encuestas podemos comprobar el uso de las herramientas de ayuda así como el perfil del usuario que las utiliza.
• Accessibility of Rich Internet Applications. La tecnología nos permite realizar aplicaciones que permiten una mejor experiencia de uso al usuario pero en demasiadas ocasiones este uso de la tecnología provoca barreras de accesibilidad a la información. En esta presentación nos indican los pasos a seguir para que la tecnología y el acceso a la información vayan de la mano.

Fuente: CSUN 2010 Presentations

Pero las encuestas nos dicen lo contrario, que existe una mayoría muy amplia de usuarios que utilizan herramientas de ayuda y que ejecutan JavaScript así que aparte debemos comprobar que nuestra funcionalidad es igualmente accesible con dicha tecnología.

Roger Johansson habla brevemente sobre ello y expone como ejemplos el uso, en ocasiones abuso, de los efectos ligthbox (las ampliaciones que nos aparecen en grande oscureciendo el resto de la pantalla), calendarios, controles de formulario personalizados, etc…. todos ellos funcionales sin tecnología JavaScript pero con carencias de acceso por teclado o mediante un lector de pantalla ejecutando código JavaScript.

Fuente: Unobtrusive JavaScript is not necessarily accessible JavaScript

En el blog de The Paciello Group hablan de ello y ponen dos ejemplos con el editor de entradas de WordPress:

Editor de entradas de WordPress en modo normal

Editor de entradas de WordPress en alto contraste

Parece ser que algunos modos de alto contraste pueden llegar a ocultar las imágenes utilizadas como fondo.

En el artículo proponen alguna solución mediante hojas de estilo para usar alguna alternativa.

Otra opción siempre puede ser evaluar si merece la pena o no que usemos la imagen como fondo. Obviamente esto dependerá mucho de la página en cuestión ya que hay veces que el uso de fondos está muy claro mientras que en otras ocasiones se puede optar de este modo por simple optimización de recursos y/o por facilitar un efecto de cambio al pasar el usuario por encima de un enlace por ejemplo.

Fuente: High Contrast Proof CSS Sprites

Dichos consejos tienen la finalidad de ayudar a la compresión de la presentación que hagamos y faciliten la asimilación de los mensajes que queramos transmitir.

El documento se titula Pautas de accesibilidad en presentaciones PowerPoint y se encuentra en formato .doc de Office.

A continuación lo reproducimos:

Las presentaciones en “PowerPoint” son aconsejables en todas las charlas, presentaciones o conferencias, sea cual sea su duración, ya que facilitan la comprensión a todas aquellas personas con alguna dificultad para la comprensión oral. Deben ser una guía y no una transcripción de lo que presentamos.

Es cierto que no todas las presentaciones son efectivas. Existen algunas pautas de estilo que pueden ayudar a que realmente faciliten la comprensión.

Se ha de mantener:

Una zona del 10% alrededor del borde en la que no habrá información de ningún tipo. Esto evitará que haya datos fuera de una pantalla mal apostada.

Regla del 6:

• No más de 6 palabras por línea.
• No más de 6 líneas de texto.
• No más de 6 elementos en un gráfico.
• Con ello facilitamos la lectura, evitamos la dispersión de la atención y focalizamos las ideas principales.

Hacer el texto fácil de leer:

• Usar letra arial o helvética (de “palo seco”).
• El tamaño de letra debe acercarse a 28.
• No poner más de 30 caracteres por línea (un texto apretado es más difícil de leer).
• Use un interlineado de 1,5. Si es menor es difícil de leer. Si es mayor parecerá que no hay relación entre los textos
• Los títulos no deberían ser más largos de 5 palabras. Se deben evitar títulos como: “Dispositivos no ópticos y sus accesorios para la magnificación en personas con baja visión”.

Los gráficos:

• Sencillos y con datos claros. Muchos datos en un gráfico impiden su lectura.
• Se deben utilizar sólo cuando facilitan la comprensión.
• Evita más de un gráfico por diapositiva.

Los colores :

• No más de 3 colores por diapositiva.
• Usar los colores de forma consistente a lo largo de la presentación facilita la percepción de coherencia.
• Es mejor un fondo oscuro y texto claro que un fondo claro y texto oscuro.
• El color rojo provoca mucha saturación. Debe emplearse escasamente.

Las transiciones:

• De las opciones que oferta el Power-point, las transiciones denominadas “desvanecimiento, disolver y aparecer” son las que mejor mantienen la atención.
• Evita los ruidos (clicks, disparos, etc.) salvo en puntos muy concretos que faciliten centrar la atención.
• Las transiciones largas, como las apariciones letra a letra o cambios con giros y vueltas, fatigan y descentran.

Objetos

Recuerde que si incluye vídeos con sonido debe subtitularlos.

Fuente: Presentaciones en “PowerPoint” accesibles

Desde WebAIM han realizado un estudio de Accesibilidad Web de Google Wave y el resultado es totalmente inaccesible. Algunas de las conclusiones obtenidas han sido:

• falta de textos alternativos en imágenes.
• uso de fondos de imágenes para mostrar contenido.
• No hay semántica en la información del documento. Falta de encabezados, listas, etc.,
• Ausencia de etiquetas asociadas a controles de formularios.
• Dificultad de navegación mediante teclado.
• Dificultad de navegación mediante tabulaciones.
• Dificultad de compresión de la herramienta cuando se aumenta el tamaño del texto.

En los comentarios del estudio surge el debate. ¿Google puede hacerlo accesible? ¿Por qué se hace después? Pasó lo mismo con Google Chrome. Salió público pero las consideraciones relacionadas con la Accesibilidad se hicieron posteriormente. Siendo un poco drásticos, ¿se hace un edificio y después se le añaden los accesos o se hace a la vez que se construye?

En el estudio preguntan: ¿la accesibilidad condiciona la innovación? y también acaban afirmando que Google Wave puede convertirse en no sólo en una herramienta fantástica, si no también en una gran herramienta accesible.

Fuente: Google Wave Preview Accessibility Review

Los sitios Web suelen tener una actualización periódica de contenidos. Estos pueden desarrollarse directamente sobre las páginas realizadas o mediante algún tipo de herramienta de gestión de contenidos (conocidos también como CMS) que facilite dicha tarea.

¿Herramienta de gestión de contenidos?

¿Cuál es la mejor para un proyecto que tenga requerimientos de accesibilidad?. La respuesta: aquella que permita un absoluto control sobre las páginas desde el punto de vista del código utilizado. Afortunadamente la cosa ha mejorado con los años y prácticamente casi todas nos permiten un trabajo adecuado salvo algunas excepciones.

El Instituto Nacional de Tecnologías de la Comunicación (INTECO) proporciona un manual titulado: Guía CMS accesible en donde nos indica unas pautas a seguir que debería tener toda herramienta de gestión de contenidos. Nosotros por ejemplo utilizamos eZ Publish.

Utilizar una determinada herramienta no es sinónimo de éxito. En la jornada Sobrevivir a WCAG 2.0: Guía de utilización y aplicación se pusieron dos ejemplos de sitios desarrollados (el Ayuntamiento de Santander y la página del Gobierno de Aragón) con la misma herramienta pero con un tratamiento muy distinto.

¿Cómo es posible que la misma herramienta utilizada en dos portales distintos sea capaz de devolver un código fuente tan diferente? En el caso del Ayuntamiento de Santander nos encontramos con un código aparentemente correcto. En el Gobierno de Aragón nos encontramos con algo incorrecto y que denota una falta de control sobre lo realizado en la página.

Formación tras el proyecto

La experiencia demuestra que, una vez realizado el sitio, si el equipo encargado de su mantenimiento no recibe unas sesiones formativas, el trabajo puede echarse a perder en un periodo muy corto de tiempo. Estas sesiones formativas pueden estar orientadas a:

• Conocer la herramienta de gestión de contenidos en caso que exista.
• Aprender qué es la Accesibilidad Web y por qué mi sitio tiene que ser accesible.
• Factores a la hora de gestionar contenido que pueden afectar a la Accesibilidad Web de un sitio.
• Conocer las pautas de Accesibilidad Web.
• Conocimientos básicos del lenguaje utilizado para la creación y gestión de contenidos en Internet.
• Etc.

Es normal encontrarse cierto rechazo por parte de las personas que reciban la formación: “A mí enséñame a usar el editor de la herramienta que no tengo por qué saber código. Eso para los de informática”.

Será entonces cuando lleguen las preguntas de rigor: ¿vas a manejar la información de la página? ¿vas a ocuparte de redactar los contenidos? ¿vas a revisarlos antes de publicarlos? Si la respuestas son afirmativas significa que vas a gestionar el lenguaje que se utiliza para representar la información en Internet.

Para manejar la herramienta, hay que tener al menos un conocimiento básico de gestión párrafos, creación y manejo de listas, representación de tablas de datos, uso de encabezados, etc.,

La herramienta puede facilitarnos la tarea pero es labor nuestra una revisión de lo realizado para comprobar que es correcto.

¿Revisiones periódicas?

Establecer un calendario de revisión en nuestra página nos puede ayudar a solucionar problemas diarios. Otra opción es un sistema de control de cambios para llevar una especie de “diario de actualizaciones”.

¿Por qué establecer un registro de actualización? Porque uno de los requisitos para obtener el certificado de AENOR de Accesibilidad Web es la realización de un plan de gestión de la accesibilidad del sitio (un libro de instrucciones hablando claro).

Si no realizamos ninguna de estas tareas, nos podemos llevar una sorpresa cuando al cabo de dos, tres meses, un año o más queramos hacer una revisión de nuestra página y empecemos a descubrir errores de accesibilidad más o menos graves.

¿Y los documentos PDF (Portable Document Format) tengo que hacerlos accesibles?

La respuesta es sí. Ahora bien, siempre podrá haber excepciones como documentos que por algún requerimiento legal no puedan ser reproducidos o aquellos que se usen para apoyar un resumen de algún texto en pantalla o que su finalidad sea exclusivamente un medio en papel.

¿Pero cómo se hacen accesibles estos documentos?

El Instituto Nacional de Tecnologías de la Comunicación tiene un par de manuales bastantes útiles sobre la creación y edición de documentos PDFs para hacerlos accesibles.

También podemos encontrar en Internet buenos recursos como PDF accesibles y PDF accesibles (2): metodología, ambos de Olga Carreras. Como bien dice, Hasta que uno no se pelea con unos cuantos PDF no sabe lo complejo que puede llegar a ser hacer un PDF accesible.

¿Y tengo que hacer accesibles TODOS los documentos PDF que tenía en mi sitio?

Lo ideal sería que sí pero puede volverse una tarea compleja dependiendo del volumen de pdf que podamos llegar a tener. Obviamente, todo documento nuevo que salga publicado debería ser ya accesible. Para aquellos más antiguos podemos disponer de un contacto mediante el cual los usuarios puedan solicitar alguno en concreto.

Por ejemplo, los documentos algo más antiguos publicados por el Boletín Oficial Español (BOE) en formato PDF tal vez no sean accesibles. Siempre nos quedará su versión en web para su consulta.

Un método, un plan…

Tener planificado como se van a tratar las peticiones de actualización de contenido en un sitio nos facilitará la tarea a la hora de evitar posibles problemas. Si existe un departamento reducido de personas que centraliza toda la publicación, dicho departamento deberá revisar los contenidos y peticiones que se reciben (tanto imágenes como gráficos) para su publicación.

Si alguno de estos contenidos proporcionados no es válido debería ser devuelto a su origen para su corrección.

Si por el contrario son varios departamentos los que se dedican a la creación y publicación de contenidos en el sitio, todos ellos deberían haber recibido formación sobre el manejo de la herramienta de gestión así como nociones sobre Accesibilidad Web y sus implicaciones en el contenido.

¿Y cuáles son los problemas más comunes relacionados con el contenido?

• Incorrecto formateo del contenido. No podemos copiar directamente desde un fichero de Microsoft Word por ejemplo y pegarlo directamente en la herramienta. Este proceso tal vez nos genere fallos a la hora de interpretar el contenido.
• Uso incorrecto de párrafos, listas de elementos, anidamientos de listas de listas de elementos, tablas, .etc. Respecto a las tablas es interesante echar un vistazo al manual del INTECO Comprobación de la Accesibilidad: Tablas (formato PDF)
• Elementos gráficos. Revisar el tema de los contrastes utilizados en imágenes, posibles animaciones de las mismas, etc. Otro documento muy útil del INTECO Comprobación de la Accesibilidad: Imágenes (formato PDF)
• Videos. Podía incluirse este punto dentro del anterior pero mejor tratarlo como uno aparte. Debido al auge de los contenidos multimedia gracias en parte a sitios como Youtube debemos recordar que si queremos que nuestra página siga siendo accesible, deberemos proporcionar subtítulos a los videos que publiquemos o algún tipo de transcripción del mismo que permita su compresión en caso de no poder reproducirse. Si podemos ofrecer las dos soluciones mejor que mejor. Es interesante echar un vistazo a estos manuales: Guía Breve de Subtitulado y Sincronización de Vídeos con SMIL y Comprobación de la Accesibilidad: Multimedia (documento PDF)

En resumen

Conocer y comprender la Accesibilidad Web así como tener una metodología a la hora de gestionar los contenidos de una página sumados a una formación de la herramienta, en caso que exista, así como del lenguaje de creación de contenidos en Internet nos permitirá mantener nuestro sitio accesible.

Como somos humanos, es posible que se nos escape algún error pero ser conscientes de ellos, no ocultarlos ni taparlos. En caso que algo no pueda hacerse correctamente explicar por qué y establecer una alternativa. Por ejemplo, una dirección física donde acudir a recoger algún tipo de documento o similar podría ser válido. Tal vez no es la mejor opción por molestias al usuario pero es una alternativa al fin y al cabo.

Y sobre todo, concienciación. No podemos pedir que se haga un sitio accesible y luego olvidarse que lo es y seguir como si nada.

Espero que esta entrada pueda servirte de punto de partida para mantener tu sitio web accesible.

1. Accesibilidad significa tener dos versiones de un sitio web: No gustan las puertas traseras y si se opta por esta solución también descubriremos que duplicamos el trabajo de mantenimiento.
2. La accesibilidad web es asunto de diseñadores y programadores: y también de toda la gente involucrada en el día a día de un sitio Web. En especial de la gente encargada de la gestión de los contenidos.
3. Las páginas web accesibles son feas y aburridas: no tiene por qué ser así. Cuando vayamos profundizando en los conocimientos sobre accesibilidad Web veremos de lo que seremos capaces de hacer.
4. Los usuarios deben visualizar el sitio tal y como lo diseñó su autor: las necesidades de los usuarios son muy diversas y el sitio debe poder ajustarse a dichas necesidades.
5. La accesibilidad web es sólo para ciegos: parece mentira pero es habitual encontrarse con esta excusa.
6. La accesibilidad web significa no usar Flash: dependerá de cómo se haga dicho Flash y si se dispone de alguna alternativa. Se podría añadir otro mito parecido que podría ser La accesibilidad web significa no usar javaScript.
7. Las herramientas automáticas determinan el nivel de accesibilidad: la herramienta ayuda pero el nivel lo acaba determinando una persona que haya hecho una revisión de la página.
8. Las versiones de sólo texto son suficientes para garantizar la accesibilidad: eso sí que es feo y aburrido.
9. Para qué hacer un sitio accesible si las personas con discapacidad no son mi target: por desgracia, es habitual que estas palabras cambien únicamente cuando alguien de la competencia haga su página accesible.

Fuente: 10 Mitos y Falacias sobre Accesibilidad Web

Recordemos que las Pautas de Accesibilidad al Contenido Web 1.0 (WCAG 1.0) tienen unos 10 años y han estado vigentes todo este tiempo sin cambiarse ni flexibilizarse. La versión 2.0 de dichas pautas se aprobaron en diciembre de 2008 pero actualmente la legislación española hace referencia a la UNE 139803:2004 que a su vez sigue las WCAG 1.0 así que debemos seguir ciñéndonos de momento a esta primera versión.

Echemos un vistazo al siguiente punto de verificación para cumplir el nivel máximo (AAA):

Hasta que las aplicaciones de usuario manejen correctamente los controles vacíos, incluya caracteres por defecto en los cuadros de edición y áreas de texto.

Pautas de Accesibilidad al Contenido en la Web 1.0. Punto 5.2

Es decir, si tenemos un formulario de registro que se piden una serie de campos en todos los controles deberemos indicar un texto por defecto. Podría resultar visualmente un poco raro y tal vez se pida que se cambie pero… es uno de los puntos a tratar para lograr el nivel AAA.

Otro punto:

Especifique la expansión de cada abreviatura o acrónimo cuando aparezcan por primera vez en el documento.

Pautas de Accesibilidad al Contenido en la Web 1.0. Punto 4.2

Desde el punto de vista de gestión de contenidos es un reto. La herramienta que usemos tendrá que estar preparada para ello y las personas encargadas de su gestión deberán conocer cómo y por qué deben hacerlo.

Probablemente este requerimiento caiga en saco roto cuando se manejen volúmenes de información grandes.

Veamos este otro punto:

Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los mapas de imagen de cliente), los controles de formulario y los grupos de controles de formulario.

Pautas de Accesibilidad al Contenido en la Web 1.0. Punto 9.5

Es decir, proporciona atajos de teclado para aquellas funcionalidades más importantes. Es algo que realmente no cuesta hacer aunque nos pidan un nivel mínimo de Accesibilidad (A).

Veamos ahora por ejemplo un punto necesario para cumplir la triple A (AAA) según las WCAG 2.0:

Se proporciona una interpretación a lengua de signos para todo contenido de audio pregrabado del contenido multimedia sincronizado.

Pauta 1.2. Pautas de Accesibilidad de Contenido Web 2.0 [Traducción]

Si proporcionamos algún tipo de audio previamente grabado en nuestra página web, deberemos dotarle de un video en lengua de signos con el contenido del mismo. Tiene sentido el hacerlo pero no siempre se querrá hacer por algún tema de disponibilidad de recursos o de presupuesto.

Tras la asistencia a Sobrevivir a WCAG 2.0: Guía de utilización y aplicación, un vistazo a estas pautas en su versión máxima nos muestra la exigencia a la hora de abordar algunos problemas algunos de los cuales tecnológicamente no estén aún disponibles.

¿A qué viene todo esto? Antes de abordar un nivel máximo de accesibilidad por el hecho de destacar entre el resto, tratemos primero de concienciar a todo el equipo implicado, tanto en el desarrollo como en el cliente mismo, seamos conscientes de lo que queremos hacer y siempre procuremos que una tercera parte revise nuestro trabajo para comprobar que lo hemos hecho correctamente o si por el contrario deberemos subsanar algo.

En resumen, un nivel doble A (AA) bien trabajado por todas las partes implicadas y revisada (certificada) por un tercero es un motivo para estar orgulloso del trabajo hecho y poder hablar de él así como promocionarlo.

Ahora bien, si se insiste con el nivel máximo (AAA), no hay problema, lo hacemos.