Autor: Ramón Voces Merayo (Universitat Autònoma de Barcelona)
Citación: Ramón Voces Merayo. Rich Internet Applications (RIA) y Accesibilidad Web [on line]. "Hipertext.net", núm. 9, 2011. http://www.upf.edu/hipertextnet/numero-9/ria-accesibilidad-web.html
Resumen: Se presenta en primer lugar una introducción sobre la creación y la ejecución de aplicaciones web accesibles para continuar analizando las problemáticas de accesibilidad de las Rich Internet Applications y las soluciones que ofrecen las WAI-ARIA.Palabras: Accesibilidad Web, Rich Internet Applications, RIA, WAI, WAI-ARIA
Sumario
1. Introducción
2. Construyendo una página web rica
2.1 Desarrollar RIA con estándares
3. Ejecutando una aplicación web accesible
4. Los problemas de accesibilidad de las RIA
5. Las soluciones para la accesibilidad de las RIA
5.1 Operabilidad y WAI-ARIA
5.2 La semántica de los elementos de interacción y WAI-ARIA
5.3 Regiones dinámicas (live-regions)
6. Mejorando la experiencia de usuario con WAI-ARIA
6.1 Semántica estructural
6.2 Formularios
6.3 Etiquetaje
7. Cuando las RIA no son HTML
8. Conclusiones
9. Bibliografía
Es fácil darse cuenta de que las páginas web que solemos utilizar hoy en día se parecen poco o muy poco a aquellas que se utilizaban en los inicios de Internet. Actualmente, muchas sedes web son capaces de sorprendernos por su diseño gráfico, por su diseño informacional, por los contenidos que se ofrecen o por otros muchos aspectos que hasta hace pocos años eran absolutamente impensables.
Seguramente, uno de los avances más sorprendentes está relacionado con el modelo de uso del usuario: en los inicios, el paradigma de interacción se caracterizaba por la escasez de elementos de interacción (principalmente enlaces y elementos de formularios) y donde la página se constituía como la unidad mínima de información, con lo que cualquier petición por parte del usuario implicaba una recarga completa de toda ella.
Actualmente, existen muchas tecnologías, propietarias y no propietarias, que son capaces de introducir en la web el paradigma de la aplicación de escritorio. Esto es, de crear aplicaciones web con dos características fundamentales:
FIGURA 1
Ejemplo de una interfaz RIA
No cabe duda que este tipo de aplicaciones, que normalmente reciben el nombre de Aplicaciones Ricas de Internet o Rich Internet Applications (RIA), pueden mejorar sustancialmente la experiencia de usuario en la web. Sin embargo, existen como mínimo dos aspectos que conviene tener en cuenta:
A pesar de que ambos aspectos son muy interesantes, este artículo se va a centrar en el segundo apartado: la accesibilidad web de las RIA.
Para entender las problemáticas de accesibilidad que presentan las RIA, es conveniente analizar previamente las tecnologías que se utilizan y la forma en la que se desarrollan.
En general, una página web rica puede crearse siguiendo dos modelos:
Inicialmente este artículo se va a centrar en el desarrollo mediante estándares para, en un apartado posterior, puntualizar las problemáticas específicas para las tecnologías incrustadas.
Desde el punto de vista del desarrollador, implementar una RIA mediante estándares no representa cambios muy importantes en lo que se refiere al proceso de desarrollo.
FIGURA 2
Capas de programación para una página web
Como se puede apreciar en la figura anterior, y de forma muy resumida, en cualquier página web (sea RIA o no) se pueden distinguir hasta 3 capas de desarrollo (Voces et al., 2009):
Para el desarrollador, la capa de comportamiento abre todo un mundo de posibilidades ya que permite, entre otras muchas cosas, crear módulos que simulen los elementos de interacción convencionales presentes en cualquier aplicación de escritorio (como menús, botones, árboles, etc.). Actualmente, existen multitud de bibliotecas gratuitas repletas de estos elementos de interacción (como qooxdoo, jQuery , o Dojo) capaces de mejorar la experiencia de usuario y de reducir el tiempo de desarrollo de la aplicación.
Es también en la capa de comportamiento donde se codifican las actualizaciones de información: mediante una combinación de tecnologías denominadas AJAX, es posible realizar peticiones de datos al servidor de forma asíncrona (es decir, sin recargar la página) y presentarlos de forma inmediata. De este modo, se consigue una experiencia de usuario similar a la producida por una aplicación de escritorio.
FIGURA 3
Flujo de datos en una petición de información mediante XMLHttpRequest
Fuente: http://java.sun.com/developer/technicalArticles/J2EE/AJAX/DesignStrategies/
Según las nuevas WCAG 2.0 (W3C, 2008), una aplicación será accesible cuando se cumplan los siguientes requisitos:
Ciertamente, todos los puntos descritos anteriormente dependen de la implementación de la aplicación. Sin embargo, si abrimos un poco el foco, es fácil darse cuenta que para que una aplicación web sea accesible necesita ejecutarse en un entorno también accesible. O dicho de otro modo, de nada sirve desarrollar una aplicación accesible si, por ejemplo, el usuario no es capaz de llegar e ejecutarla porque el sistema operativo no lo es.
FIGURA 4
Entorno de ejecución de una aplicación web
A vista de pájaro y para una aplicación web, un entorno accesible depende básicamente de 4 elementos fundamentales:
Todos estos elementos deben estar implementados de forma absolutamente cooperativa ya que un problema en cualquiera de ellos puede provocar directamente problemas de accesibilidad. Es evidente que no se trata de una labor sencilla, sobre todo, teniendo en cuenta que cada elemento se construye por desarrolladores diferentes que, a menudo, también tienen intereses diferentes (Henry, 2006).
Los problemas de accesibilidad más comunes asociados a las RIA se relacionan con la forma en la que se crean y usan sus elementos de interacción y con las zonas de actualizaciones dinámicas.
Básicamente, las RIA presentan 3 problemas de accesibilidad:
Por suerte, hay muchos desarrolladores trabajando para solucionar todos los problemas mencionados anteriormente que, de alguna forma, se coordinan mediante el Protocols and Formats Working Group (PFWG) del Web Accessibility Initiative (WAI). Su trabajo más representativo son un conjunto de directrices denominadas WAI-ARIA (Web Accessibility Initiative- Accesible Rich Internet Applications) (W3C, 2010) (W3C, 2011) que, a pesar de no ser aún una recomendación oficial del W3C (actualmente su estado es de Candidate Recommendation), están siendo asumidas por los desarrolladores más importantes, con productos tan representativos como Mozilla Firefox, Microsoft Internet Explorer, JAWS o NVDA.
EL objetivo de WAI-ARIA consiste en aportar soluciones a este nuevo paradigma de uso que suponen las RIA, ya sea redefiniendo el funcionamiento de atributos existentes de (X)HTML o bien definiendo otros nuevos.
A continuación se van a analizar cuáles son las propuestas que se especifican en WAI-ARIA para los problemas mencionados anteriormente.
Un punto clave en accesibilidad web es que todas las interfaces deben ser operativas desde el teclado. La razón fundamental de este requerimiento es que una buena parte de las personas con discapacidad acceden linealmente a la página. Por ejemplo, las personas con discapacidades motrices acceden elemento a elemento mediante la tecla de avance (normalmente la tecla TAB). Por lo tanto, es fácil entender que una interfaz que dependa exclusivamente del ratón es una interfaz que se puede considerar no accesible.
Para solucionar los problemas de operabilidad de las RIA, se requiere:
FIGURA 5
Deslizadores jQuery
Por ejemplo, una interfaz como se muestra en la figura anterior, debe ser capaz de permitir al usuario seleccionar cada uno de los deslizadores y, una vez seleccionados, poder incrementar o reducir su valor.
En lo que respecta a la selección de los elementos de interacción, según la especificación de (X)HTML, sólo pueden ser seleccionados una serie de marcas (<a>, <area>, <button>, <input>, <object>, <select> y <textarea>) y el orden de selección se establece en función de un atributo con valor numérico denominado tabindex, de forma que el primer elemento es el que tiene el valor positivo más pequeño.
Para conseguir que los nuevos elementos de interacción se puedan seleccionar, WAI-ARIA redefine el funcionamiento del atributo tabindex de forma que se pueda asignar a cualquier marca que genera un contenido visual y le proporciona la siguiente interpretación:
FIGURA 6
Ejemplo de la programación del orden de tabulación con TABINDEX
En lo que respecta a las teclas utilizadas para la interacción con los elementos seleccionados, WAI-ARIA proporciona una serie de recomendaciones para cada uno de los elementos de interacción más comunes que, en general, coinciden con las teclas que normalmente se utilizan en los entornos de escritorio. De esta manera, se pretende evitar que diferentes desarrolladores utilicen diferentes teclas para los mismos elementos de interacción. Por ejemplo, en el caso del deslizador se recomienda utilizar las fechas de cursor.
De poco sirve poder seleccionar un determinado elemento de interacción de las RIA si realmente no se proporciona información al usuario acerca de cuál es su función y la situación en la que se encuentra actualmente.
Para solucionar este problema WAI-ARIA se basa en el concepto de rol. Un rol no es más que una especie de etiqueta que permite al desarrollador especificar la función de un determinado elemento de interacción (es un deslizador, una caja de texto, un menú, etc.).
WAI-ARIA ha definido toda una serie de roles (uno para cada elemento de interacción) mediante una taxonomía modelada en RDF/OWL (Resource Description Framework/Web Ontology Language) y, a cada uno de ellos, le ha asociado los atributos que le son pertinentes y que serán los que, finalmente, definirán las propiedades y el estado del elemento de interacción.
Por ejemplo, un deslizador tendrá el rol slider, como propiedades aria-valuemax (su valor máximo) y aria-valuemin (su valor mínimo) y su estado se definirá por el atributo aria-valuenow (su valor actual).
FIGURA 7
La accesibilidad de los deslizadores con y sin WAI-ARIA
En la figura anterior se puede apreciar la información de accesibilidad de dos deslizadores (obtenido mediante la aplicación Inspect32) y el marcaje HTML utilizado. En el de la derecha, se le ha añadido marcaje WAI-ARIA y, como se puede apreciar, las tecnologías asistivas no tendrían ningún problema para reconocer el rol, el valor actual y el estado en el que se encuentra. En cambio, en el de la izquierda se ha eliminado el marcaje WAI-ARIA, y ya no es posible conocer ni el rol ni el valor actual.
Finalmente, también es interesante comentar que WAI-ARIA proporciona dos atributos que pueden incrementar todavía más la semántica de los elementos de interacción. El primero, aria-owns, está pensado para definir relaciones padre/hijo en elementos de interacción complejos (como un árbol o un menú). El segundo, aria-controls, está pensado para indicar en interfaces complejas que la acción sobre un elemento de interacción modifica (o controla) uno u otros elementos de la misma interfaz.
Una de las características fundamentales de las aplicaciones RIA es que son capaces de cambiar asíncrona y dinámicamente el contenido de alguna de las regiones de la página web.
FIGURA 8
Ejemplo de región dinámica
Obviamente, las tecnologías asistivas, en especial los lectores de pantalla, deben ser capaces de gestionar adecuadamente estos contenidos. Para que esto sea posible, es necesario que el desarrollador incluya la siguiente información:
FIGURA 9
Ejemplo de marcaje de región dinámica de un temporizador
El en ejemplo anterior, las marcas WAI-ARIA utilizadas informan a las tecnologías asistivas de que los cambios producidos deben ser anunciados cuanto antes (aria-live="assertive") y que es necesario transmitir de nuevo al usuario todos los datos de la región dinámica (aria-atomic="true").
Sin duda, es necesario que cualquier página web sea accesible. Pero, esto no es suficiente: además de accesible también debe ser usable. Desgraciadamente, existen páginas que desde el punto de vista técnico se pueden considerar como accesibles pero que, al final, resulta muy complicado para el usuario poder acceder a la información que presenta.
A pesar de que el primer objetivo de WAI-ARIA consiste en mejorar la accesibilidad de las RIA, también define una serie de mecanismos que pueden mejorar sustancialmente la usabilidad final de las páginas web, lo que podría considerarse como un elemento más de una estrategia de Mejora Progresiva (Progressive Enhancement). En concreto, son destacables los relativos a la semántica estructural, a los formularios y al etiquetaje.
Uno de los problemas más habituales de usabilidad con el que se encuentran las personas con discapacidad que acceden a la web de forma lineal es la dificultad con la que llegan al contenido principal. Como se sabe, uno de los objetivos de diseño más perseguidos en la elaboración de las sedes web es que sean coherentes. Esto implica mantener en la misma posición, tamaño y contenido, algunos de los bloques de su estructura como, por ejemplo, la cabecera o el sistema de navegación global. Desgraciadamente, este principio de coherencia obliga a estas personas discapacitadas a pasar por todas estas estructuras comunes antes de llegar al contenido principal, y esto, página tras página.
Hasta WAI-ARIA, algunos desarrolladores utilizaban diversas técnicas como, por ejemplo, poniendo un enlace hacia el contenido principal en el inicio de la página (Voces, 2010). En todo caso, atendiendo a la complejidad que ofrecen muchas interfaces actuales, son técnicas que se podrían considerar del todo rudimentarias.
Seguramente, el concepto más importante que introduce WAI-ARIA desde el punto de vista de semántica estructural es un rol específico denominado landmark. WAI-ARIA lo define como "un tipo de región a la cual el usuario podría querer acceder rápidamente" y define los siguientes tipos: application, banner, complementary, contentinfo, form, main, navigation y search.
De este modo, una página marcada con landmarks permite añadir toda la información semántica necesaria para que los agentes de usuario y las tecnologías asistivas puedan ofrecer al usuario una navegación por landmarks.
FIGURA 10
Ejemplo de landmarks en barra de accesibilidad de Firefox
Por otro lado, los landmarks no son los únicos elementos de semántica estructural: también se encuentran roles tan variados como barras de navegación (toolbar), cabeceras (heading) o publicación (article).
La accesibilidad de los formularios siempre ha sido un tema clave, ya que representan el único mecanismo que tiene un usuario para transferir información al servidor y, por lo tanto, realizar operaciones tan variadas como darse de alta de un servicio, comprar o enviar una sugerencia.
Uno de los aspectos habituales y a menudo más inaccesibles se produce en la forma de notificar al usuario cuáles son los campos cuyo contenido es obligatorio o erróneo. En muchas ocasiones, los desarrolladores optan por resolver ambos problemas cambiando la presentación de los campos (por ejemplo, modificando su color). Obviamente, estas prácticas no son accesibles.
FIGURA 11
Uso inaccesible del color para campos obligatorios en los formularios
Para solucionar estos problemas, WAI-ARIA introduce los atributos aria-required y aria-invalid para marcar los campos con contenidos obligatorios y erróneos respectivamente. De este modo, las tecnologías asistivas pueden ser capaces de informar adecuadamente al usuario.
A veces se hace necesario precisar con claridad el objetivo de un elemento de interacción. Por ejemplo, a la hora de crear un formulario se considera una buena práctica asociar a cada campo una etiqueta que clarifique qué información se debe introducir.
FIGURA 12
Cuadro combinado con etiqueta
Como se puede ver en la figura anterior, en (X)HTML se resuelve mediante la marca label. El problema de esta marca es que sólo está disponible para elementos de formulario.
Por ello, WAI-ARIA ha creado un atributo alternativo denominado aria-labelledby, aplicable a cualquier marca. Como se puede observar en la figura siguiente, el uso es muy parecido a label.
FIGURA 13
Uso de aria-labelledby
Una buena parte de las RIA se desarrollan con tecnologías alternativas a (X)HTML. De todas ellas, seguramente Microsoft Silverlight y, sobre todo, Adobe Flash son las más conocidas y utilizadas.
Ciertamente, los enfoques que utilizan son diferentes (Microsoft, n.d.) (Adobe, 2010): mientras Microsoft Silverlight se basa exclusivamente en la nueva capa de accesibilidad desarrollada por Microsoft denominada UI Automation, Adobe Flash es compatible con la capa de accesibilidad MSAA de Microsoft (la precursora de UI Automation), IAccessible2 de Linux Foundation y la capa de accesibilidad AX de OSX. En cualquier caso, es necesario reconocer que ambos fabricantes han hecho un esfuerzo importante en el desarrollo de la accesibilidad de sus productos y, desde el punto de vista técnico, se pueden considerar potencialmente accesibles.
Desgraciadamente, en la práctica, una buena parte de las aplicaciones creadas con estas tecnologías no son accesibles, en general, debido a una implementación deficiente.
Sin duda, resulta una situación difícil de justificar, sobre todo, cuando existe suficiente documentación en ambas tecnologías y, además, no supone un esfuerzo técnico importante.
Este artículo ha empezado analizando la forma en la que se desarrollan las RIA y el entorno en el que se ejecutan para continuar analizando sus problemas de accesibilidad y las soluciones.
Como se ha podido observar, en lo que se refiere a las RIA, se puede decir que con WAI-ARIA se pueden resolver los problemas más importantes de accesibilidad y que, además, cuenta con el respaldo de la gran mayoría de fabricantes involucrados en el desarrollo de sistemas operativos, navegadores y tecnologías asistivas.
Es cierto que todavía no es una recomendación oficial del W3C y, por lo tanto, puede ser susceptible de cambios. También es cierto que el ritmo al que evoluciona la tecnología (que a menudo entiende la accesibilidad web como una mejora y no como un requerimiento) y las presiones empresariales por utilizar lo más novedoso no lo ponen fácil a los desarrolladores.
Sin embargo, nada de lo anterior debe servir de excusa para no crear aplicaciones accesibles. Básicamente por 3 razones:
En consecuencia, cada organización es libre de elegir si desarrolla una aplicación convencional o una RIA. Pero, sea cual sea la elección, el resultado siempre debe ser accesible. Porque es posible y, además, es necesario.
ADOBE. (2010). Flash Player and Flex support for IAccessible2 and WAI-ARIA. [En línea] http://blogs.adobe.com/accessibility/2010/03/flash_player_and_flex_support.html [Consulta: 25/02/2011].
Carreras, Olga. (2011). Referencia sobre legislación española relacionada con la accesibilidad web. [En línea] http://olgacarreras.blogspot.com/2005/01/referencia-sobre-legislacin-espaola.html [Consulta: 25/11/2011].
Henry, S. L. (2006). Understanding Web Accessibility. [En línea] http://www.uiaccess.com/understanding.html [Consulta: 25/02/2011].
MICROSOFT. (n.d.). Silverlight Accessibility Overview. [En línea] http://msdn.microsoft.com/en-us/library/cc707824%28v=vs.95%29.aspx [Consulta: 25/02/2011].
Nielsen, J. (2007). Web 2.0 Can Be Dangerous... [En línea] http://www.useit.com/alertbox/web-2.html [Consulta: 25/02/2011].
Voces, Ramon; Codina, Lluís; Recorder Sellarés, Mª José. (2009). Comunicación audiovisual sin barreras: televisión pública, world wide web y accesibilidad. 1 ed. Santa Eulàlia de Ronçana: Anguiroda
Voces-Merayo, Ramón. (2010)."Diseño de arquitecturas de información lineales para mejorar la accesibilidad web". El profesional de la información, v. 19, n. 4, pp. 374-381.
W3C. (2008). Web Content Accessibility Guidelines 2.0. [En línea] http://www.w3.org/TR/WCAG20/ [Consulta: 25/02/2011].
W3C. (2010). WAI-ARIA 1.0 Authoring Practices. [En línea] http://www.w3.org/TR/wai-aria-practices/ [Consulta: 25/02/2011].
W3C. (2011). Accessible Rich Internet Applications (WAI-ARIA) 1.0. [En línea] http://www.w3.org/TR/wai-aria/ [Consulta: 25/02/2011].