FW2006: Accessibility in Rich Internet Applications: Findings & Implications – Bob Regan

Ponente: Bob Regan

Bob Regan es un arquitecto de soluciones para mercados verticales en Adobe Systems, Inc. Realiza las labores de Director Técnico para mercados relacionados con la Educación, Administración, Servicios Financieros, Manufacturación, Telecomunicaciones y Ciencias de la Vida.

Qué bien habla inglés este tio. Aunque, siguiendo la tradición, me voy a quedar con la traducción de la amable señorita.

Bob trata de ganarse al personal con una bromas que me temo nadie ha entendido.

Nos cuenta por encima en qué consisten las aplicaciones RIA en la web. Nada nuevo bajo el sol.

Dice que nos va a contar cosas sobre Flash. Bob trabaja en Adobe.

Va a contarnos cosas respecto de la accesibilidad aplicada a RIAs. Nuevamente aparece la omnipresente separación de presentación y contenido.

La traducción tiembla por momentos.

Hay que asegurar que la aplicación es accesible a través de dispositivos de ayuda, como lectores de pantalla.

Mucho me temo que nos está contando los planes de su empresa para con la aplicación de normas de usabilidad resultantes del trabajo con sus herramientas. Espero que la cosa no siga por este camino.

Es de los que sostiene que la accesibilidad y la usabilidad sean cosas distintas.

Dice que hay que considerar aspectos de usabilidad desde el inicio del diseño de nuevos desarrollos, sobre todo teniendo en cuenta a las personas con discapacidad. si se incorpora la accesibilidad desde un primer momento, entre un 10 y un 25% de incremento de presupuesto. Si no se incorpora desde el inicio podemos estar hablando del 100% de aumento. No olvidemos que estamos hablando de RIAs.

Plantea cómo abordar un proyecto en función del tipo de discapacidad del público objetivo que va a ser usuario de la aplicación.

Va muy deprisa.

Habla de la dificultad de incorporar video en las RIA accesibles, pues es necesaria una pista sonora que describa lo que se está desarrollando en el citado video.

Nos es más fácil asimilar la información en función del formato en la que se presenta. Vuelve a hablar de las bondades de flash al respecto.

Si se van a desarrollar RIAs accesibles, es necesario aprender a utilizar lectores de pantalla. Dice que recomienda a los trabajadores de Adobe que trabajan ene sos proyectos, trabajar todos los días 30 minutos con un lector de pantalla. En 6 semanas cuenta que ya se han habituado a ello.

Cuenta que el proceso de trabajo de RIAs accesibles implica el test diario durante dos ocasiones, para asegurar que no se comenten fallos, o que no se estropean parte de los desarrollos. De ahí la necesidad de testear dos veces el desarrollo con lectores de pantalla.

Nos cuenta que si no somos ciegos no sabemos cómo usan la aplicación las personas que no ven.

Nos va a contar las estrategias de abordaje de desarrollo de RIAs. Pero nuevamente sólo parece que vaya a hablar de las herramientas de Adobe. Bueno vale, aceptamos barco.

Conceptos clave. En html existen 12 elementos básicos. Es una lista bastante corta. En una RIA hay bastantes (más) controles.

El uso de comandos de teclado facilita la accesibilidad de algunas aplicaciones RIA.

Parece que el JAWS que lleva en el portátil le está dejando colgado. No le funciona.

Sigue hablando de controles en las RIA.

Hay que asegurarse de que cada uno de los controles tiene un label diferente.

Pausa. Parece que va a reiniciar su portátil, entre bromas anglosajonas, me temo.

Reinicia JAWS. Bravo.

Golpe de efecto. Nos enseña en direto cómo funciona y se utiliza JAWS para a acceder a RIAs. Parece que está captando, por fin, la ateción del personal.

Efectivamente. Usar JAWS en directo para mostrar lo accesible que es una RIA es la mejor forma de que todo el mundo se quede con la copla. Nos demuestra lo importante que es asignar un label a cada botón para que JAWS lo lea de forma personalizada y a quien escucha lo que dice JAWS sepa distinguir lo que es cada uno de los botones.

En realidad no es nada nuevo, pero una demostración en vivo es la mejor forma de abrir los ojos a una realidad que está ahí. Nos dice cómo se puede hacer con las herramientas de Macromedia (Adobe) y cómo hacerlo con Ajax.

Nos hace una demostración de cómo lee JAWS una pantalla de Google Maps. Mucho me temo que lo está poniendo como ejemplo negativo. Al menos eso me ha parecido deducir.

Efectivamente, así es.

Otro ejemplo. Creado con Flex (de Adobe, no lo olviden). Demuestra lo bien que lee JAWS la pantalla de la RIA desarrollada con Flex.

JAWS va explicando la función de cada uno de los controles que aparecen en la pantalla de la RIA. Hay una navegación en forma de árbol, y JAWS lo está leyendo perfectamente, explicando qué contenido hay dentro de cada una de las categorías del árbol. Muy perfecto.

Cada contro debería contar con una siempre con una información relevante, que nos de la idea de qué control se trata, qué lleva dentro, y si existe o no un cambio de sección en el contenido, sin olvidar la selección en la que está el usuario.

Hay que asegurarse que la información que se presenta esté disponible para el lector de pantalla, es decir para el usuario.

Advierte que va a hablar rápidamente. Va a ser complejo poder seguirle.

Habla del concepto del orden de lectura. El lector de pantalla va a tratar de intuír el orden de lectura de los contenidos. Da la pista de la importancia del orden de lectura de los contenidos, que implicará una significación u otra.

Quedan 5 minutos de charla.

Conceptos clave:

• Coreografía. Vamos a servirnos de la animación para colocar la información más importante de la aplicación cuando el usuario la pida.
• Screen updates, o lo que es lo mismo, actualizaciones de la pantalla. No hay grandes modelos para resolver esto en las RIAs.

El tiempo de la charla se termina. Bob va a terminar y yo tengo que ahorrar batería.

Luego más.