Aplicaciones Web compatibles para invidentes

bigstock-blind-businessman-working-at-h-42100729

WAI-ARIA: Desarrollo de aplicaciones web compatibles para personas invidentes o con problemas visuales

“Creo que no nos quedamos ciegos, creo que estamos ciegos, ciegos que ven, ciegos que, viendo, no ven.”

- José Saramago.

Fue a principios del 2008 cuando en un proyecto un cliente nos pidió que el sitio web incluyera soporte para invidentes. En ese entonces estaba desarrollando un CMS para noticias. Estábamos en el último mes del desarrollo cuando nos encontramos con la sorpresa de que teníamos que soportar un estándar del que ninguno de mis compañeros o yo, para este caso, habíamos escuchado y mucho menos usado. Después de invertir algunos minutos en Google supe que este era un estándar usado por programas y dispositivos auxiliares para leer el contenido de las páginas web.

Honestamente ¿Alguna vez te has preguntado cómo es que las personas invidentes interactúan con computadoras o dispositivos móviles en general?

Al menos yo hasta ese momento no me había hecho esa pregunta, un mes pasó y la implementación del estándar en el sistema CMS fue muy sencillo, se trataba básicamente de agregar un par de propiedades en el código HTML y listo. La parte más complicada hasta ese momento había sido instalar y aprender a usar el software lector de pantalla, así que me sentía confiado de que implementar este estándar no representaría un reto la segunda vez que una petición similar se presentara en un futuro.

Fue a mediados de 2012 cuando nuestro Manager en California nos dijo que debido a acuerdos legales con una importante compañía que usaba el cliente de correo que habíamos desarrollado (Con más de 25,000 usuarios alrededor del mundo) tendríamos que implementar algo de lo que él nunca había escuchado: WAI-ARIA. Como yo ya tenía experiencia usando el estándar me asignaron para trazar el plan para implementarlo en la aplicación web. Esta vez no fue nada sencillo.

Como implementar WAP-ARIA en tu aplicación Web

La primera vez no fue en una aplicación RIA sino en un sitio de noticias, ahora el reto era hacer accesible toda la aplicación. Esto tiene dos retos principales:

  • El primero tiene que ver con la accesibilidad desde el teclado, cada botón, diálogo, nodo en el árbol y componente en la aplicación debe ser accesible usando únicamente el teclado, el uso del ratón no es una opción.
  • El segundo reto fue no modificar la funcionalidad existente o agregar elementos extra, ya que los cambios deberían ser transparentes para los usuarios existentes, (olvidé mencionar que para ese momento la aplicación era usada por más de 1 millón de usuarios en todo el mundo).

Landmarks – Como navegar por las secciones de la aplicación

Sin el uso de un ratón, navegar en una aplicación web no es algo sencillo, aún con el uso del tabulador es una tarea compleja. El estándar define marcadores que nos permiten navegar entre secciones de la aplicación y estas secciones las definimos nosotros usando  las propiedades ARIA.

A continuación presento un ejemplo:

http://jsfiddle.net/ernestohs/UJQM4/embedded/result,html,css/

Como podemos observar solo es necesario agregar una propiedad extra a la etiqueta HTML

Landmarks

Ahora cuando el lector de pantalla nos lea nuestra página, éste nos informara que existen Landmarks y cuántos son, y el usuario podrá ir directamente a estas secciones sin tener que pasar por todos los contenedores.

Diálogos, Botones y más

Yo no soy fanático de ningún framework para el desarrollo de aplicaciones RIA, pero existen dos que de verdad pueden considerarse que cumplen con ARIA, estos son jQuery UI y SenchaJS, sin embargo el que los componentes cumplan con ARIA no significa que los plugins o controles de terceros cumplan con el estándar y éste fue un problema que tuvimos que afrontar con jQuery. En muchos casos tuvimos que implementar funcionalidad extra dentro de estos plugins ya que los controles no incluían ninguna propiedad ARIA.

¿Pero qué tengo que hacer para que mis controles cumplan con el estándar WAI-ARIA? En el ejemplo que veremos a continuación tenemos un escenario común en el desarrollo web, tenemos una entrada de datos que cambia dependiendo de la entrada de datos. El cambio del texto es visual pero el lector de pantalla no se entera de que hubo un cambio por que el texto ya fue leído al usuario. Nosotros le notificamos al lector que la sección puede cambiar, de esta forma el lector está atento a los cambios del contenido dentro de esa etiqueta HTML.

Ejemplo: http://jsfiddle.net/ernestohs/aH6ts/embedded/result,js,html,css/

Los roles y propiedades ARIA se deben aplicar solo a los elementos no naturales, es decir a aquellos controles que creamos. Los botones y controles HTML no requieren roles ARIA, aúnque pueden requerir algunas propiedades extra para indicar cómo es que estos deben ser leídos al usuario.  A continuación veremos un ejemplo de botones artificiales para un pequeño editor de texto:

Ejemplo: http://jsfiddle.net/ernestohs/6FtJW/embedded/result,js,html,css/

Aquí es donde empieza la parte más interesante, ya que el botón puede tener un contenido (Símbolo de suma, resta o las letras i y B) y sin embargo para los usuarios invidentes estos botones se leerán como: Reducir fuente, Aumentar fuente, Itálica y Negritas.

Pero ahí no terminan los cambios de igual forma podemos indicar que el botón se encuentra presionado y de esta forma el usuario puede saber que la fuente está en Itálica. El lector de pantalla dirá algo como “Botón Itálica Presionado”, es por medio de estos indicadores que podemos “describir” al usuario la aplicación y este pueda darse cuenta del estado de los controles y que es lo que sucede dentro de la aplicación. Este tema nos daría mucho de qué hablar, al final del artículo anexo una serie de videos y documentos que me han sido muy útiles para poder entender e implementar este estándar.

Lectores de Pantalla – Cómo probar que mi aplicación funciona correctamente

Ahora nuestra página es accesible por medio del lector de pantalla, al igual que con los navegadores, existen una variedad de programas y estos no siempre interpretan los estándares de la misma forma. Al igual que con los navegadores existen unos mejores que otros.

Continuando con el paralelismo entre los lectores de pantalla y los navegadores podríamos decir que JAWS sería como el Internet Explorer de los lectores de pantalla, NVDA como el Firefox y bueno Chrome tiene una Extensión para eso llamada ChromeVox, hago esta comparativa porque en mi experiencia el lector que más canas verdes me ha sacado es el JAWS. Este programa es de paga y el cliente compró licencias para mí y para el equipo de QA, para que pudiéramos probar los cambios y la verdad que no fue una tarea sencilla. Primero te tienes que familiarizar con los accesos de teclado que son muchos y lo segundo es que tienes que desarrollar mucha paciencia porque el software va a leer todo: el arranque del sistema, las notificaciones, los títulos y no solo tu página. Así que si alguien te habla en Skype mientras estas probando vas a terminar maldiciendo.

Muchas veces para probar la accesibilidad teníamos que apagar el monitor y escuchar al lector de pantalla, durante este tiempo cometí el grave error de usar las bocinas de la computadora. El uso de audífonos ayudo a que mis compañeros no tuvieran que escuchar cientos de veces “La aplicación está cargando espere un momento”, “Esta cuenta tiene 350,000 correos electrónicos”, etc.  Uno de mis más grandes dolores de cabeza fue la navegación entre los elementos por medio del teclado y esto se debe a que JAWS cambia el comportamiento de los eventos de teclado que son enviados al sistema operativo.

Fue después de que tuve que trabajar con este tipo de estándares que terminé por apreciar más la capacidad que tenemos para ver, lo complicado que sería para mí o para cualquier persona el adaptarse al uso de este tipo de tecnologías. Nadie está exento de la posibilidad de quedar ciego o padecer deficiencias visuales. Aún cuando existen estándares y solo algunos productos los utilizan, queda la mayor parte de las páginas que son desarrolladas en todo el mundo que no pueden leerse con este tipo de herramientas.

Mientras estuve trabajando con estas herramientas descubrí que Facebook y las aplicaciones de Yahoo! sí cumplen con estos estándares pero el resto de aplicaciones son inutilizable. Es el momento para que este estándar sea adoptado como parte del desarrollo de cualquier aplicación. Al menos esa es mi opinión.

Nota: Los ejemplos están disponibles en la página del Illinois Center for Information Technology and Web Accessibility en este artículo los puse dentro de contenedores de JsFiddle para que el lector pudiera interactuar con el código dentro del mismo artículo.

Links adicionales:

http://www.youtube.com/watch?v=lMrkCoqgoxw

http://www.youtube.com/watch?v=K4xuitAzIEk

Accesibilidad en dispositivos móviles

http://www.youtube.com/watch?v=3DeprwFkl3U

ARIA

http://www.w3.org/WAI/aria/faq#start

Landmarks

http://www.html5accessibility.com/tests/landmarks.html

Ejemplos del uso apropiado de ARIA

http://test.cita.illinois.edu/aria/

 

Autor: Ernesto Herrera.