Universitat Pompeu Fabra
HIPERTEXT.NET Anuario académico sobre documentación digital y Comunicación interactiva

Rich Internet Applications (RIA) y Accesibilidad Web

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

ramon-voces

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

 

1. Introducción

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:

  1. Una alta interactividad con el usuario, a través multitud de elementos de interacción que antes sólo eran viables en entornos de escritorio (como menús, árboles, deslizadores, etc.),  programables bajo cualquier evento de usuario (como clic de ratón, pulsación de tecla, drag and drop, etc.) y con un aspecto visual totalmente personalizable.
  2. Una alta velocidad de respuesta a la interacción del usuario. La unidad de información mínima es la que desee el desarrollador: una etiqueta, una tabla o quizás toda la página. De este modo, es posible conseguir una respuesta inmediata a las acciones del usuario, descargando sólo los datos absolutamente necesarios.

figura1

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:

  1. La usabilidad. El modelo de interacción en las páginas convencionales es extremadamente simple pero también extremadamente claro. En las RIA, los desarrolladores pueden crear, utilizar y personalizar nuevos y sofisticados elementos de interacción que permiten crear interfaces absolutamente complejas que, en algunos casos, más que ayudar al usuario, pueden provocar confusión y dudas sobre su uso (Nielsen, 2007).
  2. Accesibilidad Web. En muchas ocasiones, los avances de la tecnología representan una amenaza para la accesibilidad web. Actualmente, en lo que se refiere a las páginas convencionales, la accesibilidad web ha tenido un recorrido de más de una década y se puede decir que no existe ninguna razón técnica que justifique la no accesibilidad. Un recorrido que, desgraciadamente, no es suficiente para dotar de accesibilidad a todos los cambios que han venido de la mano de las RIA.

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.

2. Construyendo una página web rica

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:

  1. Mediante el uso de tecnologías estandarizadas, como (X)HTML, CSS o JavaScript.
  2. Mediante el uso de tecnologías incrustadas, haciendo uso de unas determinadas marcas (X)HTML que permiten ejecutar una aplicación externa en el agente de usuario. Las tecnologías más habituales que siguen este modelo son las tecnologías propietarias Adobe Flash y Microsoft Silverlight.

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.

2.1 Desarrollar RIA con estándares

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.

figura2

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):

  1. La capa de estructura y contenido. Es la capa donde se definen los diferentes bloques que componen la página (cabecera, contenido, pie, navegación, etc.) y el contenido que se presenta. Normalmente, la tecnología utilizada en esta capa es (X)HTML.
  2. La capa de presentación. Es la capa donde se diseña la apariencia visual y la distribución de los bloques estructurales (o layout) y de los contenidos. Normalmente, la tecnología utilizada en esta capa es CSS.
  3. La capa de comportamiento. Es la capa donde se programa cómo debe reaccionar la página frente a las acciones del usuario. Esta capa interactúa directamente con el DOM (Document Object Model) del agente de usuario, lo que permite conocer todos los detalles de interacción (movimiento de ratón, clic, presión de tecla, etc.), acceder a todos los contenidos que se presentan en la página y modificarlos si es preciso. Por ejemplo, es muy habitual verificar que los datos introducidos por el usuario en un formulario sean correctos antes de ser enviados al servidor y modificar el color de los campos erróneos. Normalmente, la tecnología utilizada en esta capa es JavaScript.

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.

figura3

FIGURA 3

 

Flujo de datos en una petición de información mediante XMLHttpRequest

Fuente: http://java.sun.com/developer/technicalArticles/J2EE/AJAX/DesignStrategies/

 

3. Ejecutando una aplicación web accesible

Según las nuevas WCAG 2.0 (W3C, 2008), una aplicación será accesible cuando se cumplan los siguientes requisitos:

  1. Ser perceptible, en el sentido de que cualquier persona debe ser capaz de detectar el contenido que se presenta.
  2. Ser operable, en el sentido de que cualquier persona debe ser capaz de interactuar con los elementos de interacción presentes en la página.
  3. Ser inteligible, en el sentido de que cualquier persona debe ser capaz de entender el significado del contenido.
  4. Ser robusta, en el sentido de que el contenido debe ser compatible con la mayor variedad de agentes de usuarios y tecnologías asistivas.

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.

figura4

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:

  1. Un sistema operativo accesible, que permite al usuario llegar a ejecutar el agente de usuario que contendrá nuestra aplicación
  2. Una capa de accesibilidad, cuya función es ser el punto de encuentro entre las aplicaciones que se ejecutan en el sistema operativo y las tecnologías asistivas que utilizan los usuarios con discapacidad (como los lectores de pantalla).
  3. Un agente de usuario accesible, que permite ejecutar nuestra aplicación web, acceder a su información de accesibilidad y hacerla disponible a través de la capa de accesibilidad.
  4. Tecnologías asistivas que son capaces de proporcionar adecuadamente los datos de accesibilidad al usuario ya sea accediendo a la capa de accesibilidad, al DOM del agente de usuario o a través de otros medios.

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). 

4. Los problemas de accesibilidad de las RIA

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:

  1. Problemas de operabilidad. En las páginas HTML convencionales, todos sus elementos de interacción se pueden seleccionar y activar mediante el teclado o el ratón. En cambio, en las RIA, es bastante habitual encontrar interfaces cuya interacción se basa casi exclusivamente en el ratón. De este modo, aquellas personas que interactúan vía teclado o con cualquier tecnología asistiva complementaria al teclado son incapaces de enfocar e interactuar con estos elementos.
  2. Problemas de semántica de los elementos de interacción. La función de los elementos de interacción de una página convencional están claramente definidos y en (X)HTML existen marcas y atributos que permiten añadir la semántica necesaria para que las tecnologías asistivas ofrezcan la información suficiente para que un usuario con discapacidad pueda percibirlos e interactuar con ellos. En cambio, los elementos de interacción propios de las RIA carecen de este tipo de marcas y atributos. De este modo, por ejemplo, un elemento deslizador se podría presentar al usuario simplemente como dos imágenes (la barra y el marcador de posición), sin indicar su función (deslizador), su estado actual (posición 3 de 5, por ejemplo) ni sus propiedades (valor máximo y mínimo, por ejemplo).
  3. Regiones dinámicas (live-regions). La capacidad de las aplicaciones RIA de actualizar partes de la información que se presenta en la página de forma asíncrona representa un gran inconveniente para las tecnologías asistivas, puesto que, si no se implementa correctamente, pueden no percatarse de que la información ha cambiado y, por lo tanto, no informar al usuario.

5. Las soluciones para la accesibilidad de las RIA

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.

5.1 Operabilidad y WAI-ARIA

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:

  1. 1)     Un mecanismo que permita seleccionar todos los elementos de interacción de la interfaz mediante la tecla de avance.
  2. 2)     Definir las teclas que van a permitir operar con él, una vez ha sido seleccionado.

figura5

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:

  1. Si tabindex tiene un valor superior a 0, el valor que contenga será el orden de secuencia establecido.
  2. Si tabindex tiene el valor 0, se seleccionaran después de los elementos con tabindex superiores a 0 y en el orden con el que aparecen codificados en la página (X)HTML.
  3. Si tabindex tiene un valor inferior a 0 sólo se podrá seleccionar mediante programación.

figura6

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.

5.2 La semántica de los elementos de interacción y WAI-ARIA

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).

figura7

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.

5.3 Regiones dinámicas (live-regions)

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.

figura8

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:

  1. Qué parte de la página serán regiones dinámicas (o live regions), y, si es posible, especificar el tipo de región (es una alerta, un visor de noticias...)
  2. Conocer la prioridad con la que se deberá informar al usuario cuando se produzcan actualizaciones. Hay ocasiones en que será necesario informar al usuario de forma urgente (por ejemplo, una ventana de error), otras en las que se podrá esperar a que el usuario termine con la tarea que está ejecutando y otras en que ni tan sólo será preciso informar de nada.
  3. Especificar la unidad de información que se deberá ofrecer al usuario. Esto es, si será preciso volver a informar al usuario de todo el contenido que hay en la región dinámica, o bien sólo será necesario informarle de los cambios.

figura9

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").

6. Mejorando la experiencia de usuario con WAI-ARIA

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.

6.1 Semántica estructural

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, navigationsearch.

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.

figura10

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).

6.2 Formularios

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.

figura11a

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.

6.3 Etiquetaje

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.

figura12

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.

figura13

FIGURA 13

Uso de aria-labelledby

 

7. Cuando las RIA no son HTML

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.

8. Conclusiones

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:

  1. Las aplicaciones no accesibles representan un motivo fragante de exclusión social, vulnerando los derechos de muchos ciudadanos por su condición de discapacidad.
  2. En función de las características de la sede web es una obligación legal y sancionable (Carreras, 2011).
  3. No es obligatorio crear aplicaciones RIA para tener una buena aplicación web. Se pueden desarrollar excelentes aplicaciones web haciendo uso de tecnologías y directrices estandarizadas, contrastadas y accesibles, sin la necesidad de utilizar elementos de interacción avanzados ni regiones dinámicas.

    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.

    9. Bibliografía

    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].

     

    Licencia Creative Commons

    Última actualitzación 21-05-2011
    © Universitat Pompeu Fabra, Barcelona

    Universitat Pompeu Fabra. Departament de Comunicació. Grup de Recerca DigiDoc
    Campus de la Comunicació. Roc Boronat, 138, despatx 53804. Barcelona 08018
    Tels: 93 542 13 11. Correu electrònic: cristofol.rovira@upf.edu
    Depòsit Legal B-49106-2002 - ISSN 1695-5498