Un problema de accesibilidad con Flash

Hace unos días, publiqué la entrada El extraño caso de la Confederación Hidrográfica del Segura, en el que mostraba un error que presenta el sitio web de esa entidad.

No tengo ningún problema con esa web, al contrario, me parece que se han preocupado en lograr que sea una buena web, y la accesibilidad ha sido una de sus preocupaciones.

En la página principal hay un panel que muestra el estado de los embalses de la cuenca:

El panel se puede leer bien con un tamaño normal del texto:

Sin embargo, si se amplia mucho el tamaño de la página (si se hace zoom), ocurre algo:

¿Qué ha pasado? ¿Por qué se ve así de mal la leyenda y las etiquetas del gráfico?

¡Es Flash!

Bueno, la culpa no la tiene del todo Flash, porque la lista desplegable en la que se puede elegir un embalse sí que se visualiza correctamente.

¿Qué es mejor, Flash o HTML5?

¿Qué es mejor, Flash o HTML5? La pregunta no debería tener respuesta, porque es como comparar naranjas y limones, pero hay mucha gente que se hace este tipo de preguntas.

Hace unos días recibí la siguiente consulta:

Últimamente he estado introduciéndome en el mundo de la accesibilidad, y, aunque ahora no me dedico a ello, es un tema que siempre tengo en cuenta.

Ahora mismo, trabajo creando cursos en Moodle, y me surge la duda de qué tecnología o herramientas usar para ello. Los últimos años se ha plagado los cursos de eLearning de contenidos hechos en Flash y subidos como paquetes SCORM. Pero dado que Flash está en extinción, y viendo todos los inconvenientes que tiene, entre ellos, los referentes a accesibilidad, me estaba preguntando si HTML5 sería la mejor elección para los contenidos de los cursos de eLearning.

Sé que tu especialidad es la accesibilidad, pero te agradecería enormemente si me dieras tu opinión acerca de esto. He leído los artículos de tu blog acerca de HTML5 y de Flash. No tengo dudas de abandonar completamente el Flash, la duda es si además de HTML5 hay alguna otra tecnología para crear contenidos accesibles, multiplataforma, etc. En definitiva, si hay más tecnologías que puedan ser tan accesibles (hablando ya en un sentido más general, tanto a nivel humano como del dispositivo que uses) como HTML5. También me preocupa desarrollar ya contenidos en HTML5 y que haya problemas para verlos dependiendo del navegador.

Y mi respuesta fue:

Flash no tenía características de accesibilidad desde el principio. Posteriormente se añadieron, pero por necesidad, porque lo pidió la gente. Incluso así, aunque se utilicen las características de accesibilidad de Flash, los objetos hechos en Flash siempre han tenido un problema: en algunos navegadores no se puede acceder a ellos directamente con el teclado (nosotros no nos damos cuenta de ello porque lo usamos con ratón). Una persona ciega o una persona con problemas de movilidad que utilice sólo el teclado, tendrá graves problemas de accesibilidad con los objetos hechos en Flash.

HTML siempre ha tenido en cuenta la accesibilidad. Puede ser mejor o peor, aún tiene muchas cosas por solucionar, pero se tiene el compromiso de ello. Por tanto, entre Flash y HTML5, sin duda HTML5 es mejor. Aquí puedes encontrar algo de información interesante sobre HTML5 y la accesibilidad: http://html5accessibility.com/

Un problema importante para que HTML5 triunfe es la falta de buenas herramientas de autor. Flash siempre ha tenido buenos (o malos) entornos de desarrollo, pero por ahora HTML5 carece de ello. Sin embargo, todo es cuestión de tiempo. Incluso Adobe está desarrollando su propia herramienta, Edge (http://labs.adobe.com/technologies/edge/) o Wallaby
(http://labs.adobe.com/technologies/wallaby/), su propio conversor de Flash a HTML5.
Yo no conozco otra tecnología que permita crear contenidos accesibles, multiplataforma, etc. HTML5 no es perfecto, pero es la única tecnología estándar que tenemos por el momento, y eso es un gran avance.

Sobre lo de crear ya contenidos en HTML5, el W3C anima a ello, no hay que esperar a que HTML5 sea una recomendación (lo cual se espera que ocurra en el año 2014). Pero hay que saber usar HTML5 con cuidado y ser consciente de lo que funciona en la mayoría de los últimos navegadores. En el caso de los contenidos educativos no veo ningún problema, porque es muy normal en los cursos online exigir unos requisitos mínimos de software a los alumnos, así que se puede exigir a los alumnos que utilicen unos navegadores concretos.

Hoy en día, las últimas versiones de los navegadores de verdad (Firefox, Opera, Chrome y Safari) implementan ya muchas de las nuevas características de HTML5. Para saber el nivel de compatibilidad con HTML5 te recomiendo la página The HTML5 test, en el apartado Other browsers hay una comparativa. A día de hoy, el navegador más compatible es Google Chrome 17:

• Google Chrome 17.0: 374 puntos
• Mozilla Firefox 10.0: 332 puntos
• Opera 11.60: 329 puntos
• Apple Safari 5.1: 302 puntos
• Microsoft Internet Explorer 9: 141 puntos

HTML5: situación actual y futuro

HTML5 es "el milagro, la piedra filosofal, el Dorado del desarrollo web". Los que llevamos muchos años en el desarrollo web la estábamos esperando desde hacía tiempo: una tecnología estándar, compatible con todos los dispositivos y con las suficientes características que nos permitan hacer todo lo que queramos sin tener que depender de terceras tecnologías. Una tecnología que nos permita construir desde un "Smart a un Hummer", desde un "Lada a un Lamborghini". Desgraciadamente, por ahora es un espejismo.

El artículo HTML5 still taking shape nos cuenta algunas cosas interesantes sobre la situación actual de HTML5 y sobre las expectativas que se han creado a su alrededor. Además, plantea el dilema entre desarrollar una aplicación nativa para cada dispositivo o el desarrollo de una aplicación web compatible con todos los dispositivos. A continuación, la traducción de los párrafos más interesantes:

Hoy en día, hay pocas dudas de que la industria ha adoptado HTML5 como la mejor solución para el desarrollo y distribución de aplicaciones ricas (rich applications) compatibles con múltiples navegadores y dispositivos. Somos testigos de la desaparición de Flex, del reposicionamiento de Flash, y del anuncio de Microsoft de que Silverlight 5 será la última versión para navegador.

[...]

"Esto no tiene precedentes en nuestra industria", dijo [Todd Anglin]. "Cada uno ha querido construir y poseer la plataforma, pero con la explosión de dispositivos en el mercado, ahora quieren ser dueños de las herramientas y los servicios".

¿Puede que todo esto se remonte a la decisión de Apple de no permitir plugi-ns y entornos de ejecución en su iPhone? En parte. Pero también se debe al creciente número de nuevos dispositivos que salen al mercado, cada uno con diferentes sistemas operativos. "Los plug-ins simplemente no se pueden mantener al día con el rápido aumento de todos estos dispositivos", dijo Anglin. "Incluso si se les permitiese, no podrían mantener el ritmo".

Jacobs citó un estudio que declaraba que dos mil millones de teléfonos móviles con navegadores estarán en circulación en dos años a partir de ahora, y todos esos navegadores afirman soportar los desarrollos basados en HTML5.

Pero es demasiado pronto para declarar a HTML5 el ganador en el desarrollo de aplicaciones web, afirman los expertos. De acuerdo con el sitio web builtwith.com, sólo el 8% de los principales 100.000 sitios web tienen algo de HTML5 detrás de ellos, y sólo el 14% de los principales 10.000 sitios tienen algo de HTML5, aunque sólo sea el empleo de Canvas. Además, sólo el 46% de los usuarios de Internet actuales tienen un navegador compatible con HTML5.

El problema, según Anthony Franco, presidente y cofundador de la empresa de desarrollo de software EffectiveUI, es que HTML5 aún no es un estándar. "Sólo porque alguien dice que su navegador es compatible con HTML5 no quiere decir que sea un estándar. Todos los navegadores soportan la recomendación del W3C [por HTML5] de diferentes formas", dijo.

[...]

Por lo tanto, ¿ha llegado HTML5 al nivel de Flash y Silverlight? La mayoría de los expertos dicen que todavía no, pero se está camino de ello.

[...]

También dijo el Grupo de Trabajo de Aplicaciones Web del W3C está trabajando en una nueva iniciativa para hacer frente "al acceso universal a las aplicaciones web mediante una amplia gama de dispositivos y por una gran diversidad de usuarios".

[...]

Uno de estos debates gira en torno a las necesidades del usuario y la experiencia del usuario. Montones de investigaciones muestran que los usuarios abandonan un sitio web si es lento en responder o no puede ofrecer lo que el usuario desea. Así que, una decisión a la que los desarrolladores web se deben enfrentar es la de escribir una aplicación que es nativa para un dispositivo, o utilizar los estándares web para llegar a más dispositivos.
[...]

¿Qué aproximación se debe adoptar?¿Flash? ¿Silverlight? ¿HTML5/JavaScript/CSS3/SVG?

Anthony Franco, presidente y cofundador de la empresa de desarrollo de software EffectiveUI, dijo que se debe contestar una serie de preguntas antes de elegir la plataforma de desarrollo:

1. ¿Cuál es la duración esperada de la aplicación? ¿Con qué frecuencia se volverá a rescribir?
2. ¿Cuál es el conjunto de habilidades de los desarrolladores? Las estadísticas muestran que hay cerca de 5 millones de desarrolladores web en el mundo, mientras que hay menos de 200.000 desarrolladores de Objective-C (para escribir aplicaciones nativas de iOS).
3. ¿Dónde tiene que residir la aplicación?
4. ¿Cómo de "rica" necesita ser la aplicación?
5. ¿Cómo de integrada en los sistemas software actuales necesita estar?
6. ¿Cuánto está dispuesto a poner en peligro las características de la aplicación en función de la plataforma elegida?

Más información:

• Accesibilidad en HTML5 (28/05/2011)
• ¿Qué le falta a la especificación de HTML5? (28/02/2011)
• Nuevo calendario para HTML5 (21/02/2011)
• El futuro de la accesibilidad web con HTML5 (04/11/2010)

Accesibilidad de los vídeos en HTML5

Hoy he recibido un correo electrónico con la siguiente pregunta de un lector de este blog:

Bueno te escribía por si me puedes ayudar con la accesibilidad en HTML5, quiero insertar un vídeo con la etiqueta <video>, pero me estoy dando de bruces, pues este vídeo, no trae subtítulos, y no puedo meter un alt, ni legend, bueno que no sé cómo hacer este vídeo accesible.

Si no ha habido cambios en los últimos meses, la respuesta es NO, no se puede por ahora. En el artículo Future Web Accessibility: HTML5 <video> nos lo explican muy bien. Así que, por ahora hay que buscar otras alternativas.

Los vídeos normalmente se han mostrado en la web mediante un objeto Flash. Esto ocasionaba dos problemas importantes de accesibilidad (suponiendo que el vídeo estuviese correctamente subtitulado):

1. Había que tener instalado el componente (plugin) de Flash en el navegador. Y además, no sobraba con tener instalada una versión cualquiera, normalmente se tenía que tener instalada la "última de la última" de las versiones del plugin.
2. En algunos navegadores, los controles del reproductor Flash no eran directamente accesibles mediante teclado.

La nueva etiqueta <video> de HTML5 resuelve estos dos problemas:

1. La etiqueta forma parte de la especificación de HTML5 y en un corto plazo de tiempo será soportada por todos los navegadores. Si buscamos el soporte de video en When can I use.., veremos que los principales navegadores la soportan desde hace tiempo. Sin embargo, hay un problema que no está todavía resuelto, la estandarización de los codecs, pero ese es otro problema.
2. Los controles del reproductor son proporcionados directamente por el navegador, por lo que se pueden manejar mediante el teclado sin problemas. En el artículo Keyboard Access for HTML5 Video se presenta un pequeño test que hizo el autor en agosto de 2010: los resultados fueron bastante positivos, por lo que es de suponer que más de un año después la situación sea incluso mejor.

Desgraciadamente, como explican en el artículo Future Web Accessibility: HTML5 <video>, por ahora existe un problema grave de accesibilidad que se está intentado resolver: la especificación actual no contempla ningún mecanismo para proporcionar subtítulos.

Por cierto, desde hace tiempo YouTube ofrece la posibilidad de visualizar sus vídeos utilizando un reproductor HTML5, aunque con ciertas restricciones.

Y también el usuario

Ayer escribí una entrada sobre la accesibilidad de Flash, y como respuesta recibí dos comentarios muy interesantes.

El primero estaba relacionado principalmente con el siguiente párrafo:

Hace unos días me hicieron una consulta sobre este tema, sobre si Flash puede ser accesible. La contestación rápida y corta es "Sí, puede ser accesible". Todo depende del desarrollador (y también del usuario final).

Y el segundo con el siguiente párrafo:

Además, las características de Flash sólo son accesibles en ciertos sistemas operativos, bajo ciertos navegadores y mediante el uso de algunos lectores de pantalla.

 En la página Essential Components of Web Accessibility podemos encontrar el siguiente gráfico:

Para el WAI, la accesibilidad se basa en tres pilares:

• La accesibilidad de las herramientas de autor (Authoring Tool Accessibility Guidelines, ATAG) .
• La accesibilidad de los agentes de usuario (User Agent Accessibility Guidelines, UAAG).
• La accesibilidad del contenido web (Web Content Accessibility Guidelines, WCAG).

Para que la accesibilidad funcione, los usuarios finales también tienen que poner de su parte. Y claro está, los fabricantes del software que emplean los usuarios finales (por mucho que los usuarios quieran, si los fabricantes de software no aplican la accesibilidad, poco pueden hacer los usuarios finales). Para ambos, el WAI ha desarrollado las User Agent Accessibility Guidelines.

¿Qué tiene que hacer el usuario final? El usuario final tiene que intentar utilizar el software más apropiado y tiene que asegurarse de que su software esté actualizado.

Por ejemplo, de nada sirve que un desarrollador web utilice las últimas características de accesibilidad de HTML5 o de WAI-ARIA en sus páginas web, si el usuario sigue utilizando el sistema operativo Microsoft Windows 95, con el navegador Microsoft Internet Explorer 6 y el lector de pantallas JAWS 6. Todas las últimas características de accesibilidad que el desarrollador pueda implementar pasarán desapercibidas para ese usuario final.

El caso de Flash, claro está, es un caso extremo de esta situación. O más bien se encuentra totalmente fuera de esta explicación, ya que no se trata de una tecnología estándar y por tanto los usuarios "no estamos obligados a aceptarlo". Pero sí que hay otras situaciones donde, aún empleando los estándares, habrá usuarios que tendrán problemas de accesibilidad porque el sistema que emplean no reconoce algunas características accesibles. En ese caso, yo creo que la responsabilidad es del usuario final: el usuario final tiene que estar preparado para aceptar las últimas características en materia de accesibilidad web.

Flash accesible

La accesibilidad de Flash es un tema que muy pocas veces he tratado, por principios y "por manía". Que recuerde, sólo he escrito un par de veces sobre este tema, una era cuando hacía referencia a un tutorial sobre accesibilidad en diferentes medios, y la otra fue cuando escribí sobre el consejo 3 "Multimedia" de la Guía breve para crear sitios web accesibles del W3C.

Hace unos días me hicieron una consulta sobre este tema, sobre si Flash puede ser accesible. La contestación rápida y corta es "Sí, puede ser accesible". Todo depende del desarrollador (y también del usuario final).

[Actualización: oihana me ha dejado un comentario muy interesante:

Pues precisamente por los motivos que has expuesto (sólo es accesible en parte y en algunos sistemas y navegadores) la respuesta creo que debería ser: "No, Flash no es accesible".

Por lo que he aprendido hasta ahora de accesibilidad, una cosa no puede ser parcialmente accesible, o lo es o no lo es. ¿No?

Comparto parcialmente este comentario. Aunque en el caso de Flash lo comparto plenamente: para mí Flash no es una tecnología estándar, es una tecnología propietaria con graves problemas de accesibilidad y, por tanto, no se debería emplear. Pero una puntualización sobre "o lo es o no lo es".

Asegurar que un sitio web es 100% accesible es un mito. Debido al amplio rango de discapacidades que existen, es imposible crear un sitio web que tenga en cuenta todo ese rango. Por tanto, la accesibilidad es una propiedad continua (hay diferentes niveles de accesibilidad), no una propiedad constante (es o no es). Por supuesto, el objetivo es lograr la máxima accesibilidad posible para llegar al máximo número de usuarios, pero el 100% de accesibilidad es un mito (por ejemplo, el idioma también se podría considerar una "discapacidad" y, por tanto, deberíamos ofrecer los sitios web en todos los idiomas que existen para no discriminar a nadie.
]

Flash siempre ha tenido graves problemas de accesibilidad. Recordemos el artículo de Jakob Nielsen Flash: 99% Bad del año 2000, en el que además de señalarse los problemas de accesibilidad de Flash, se destacaban otros muchos problemas que afectan a todos los usuarios.

A partir de la versión 6 de Flash se introdujeron ciertas características de accesibilidad, como el texto alternativo. Desde entonces, la accesibilidad de Flash ha ido mejorando, pero a día de hoy todavía hay algunas características básicas y sencillas, como indicar el idioma de un fragmento de texto (punto de verificación 4.1 "Identifique claramente los cambios en el idioma del texto del documento y en cualquier texto equivalente" de las Pautas de Accesibilidad al Contenido en la Web 1.0), que todavía no se pueden hacer (sólo se puede indicar el idioma de todo el objeto Flash).

Sin embargo, por mucho que mejore la accesibilidad de Flash, siempre existirá un problema: no es una tecnología estándar y siempre presentará problemas. La pauta 11 de las Pautas de Accesibilidad al Contenido en la Web 1.0 nos aconseja que utilicemos las tecnologías y pautas de W3C siempre que sea posible.

Además, las características de Flash sólo son accesibles en ciertos sistemas operativos, bajo ciertos navegadores y mediante el uso de algunos lectores de pantalla.

Además, hoy en día existen multitud de diferentes dispositivos que permiten navegar por la Web, y muchos de ellos no tienen soporte para Flash. Por ejemplo, hace unos días estuve probando el navegador web que incorpora Kindle, el lector de libros electrónicos de Amazon. Este dispositivo no soporta ni Flash ni los applets realizados en Java, por lo que muchas páginas web "desaparecen misteriosamente".

Pero además, hoy en día HTML5 puede sustituir a Flash en la mayoría de las situaciones en que se usa. En realidad, desde hace tiempo ya se podía sustituir a Flash por simple HTML + CSS + JavaScript + DOM. Estoy cansado de navegar por sitios web donde se emplea Flash simplemente para lograr un efecto visual en la barra de navegación principal (por ejemplo, para crear menús desplegables), cuando eso se puede crear con las tecnologías estándar desde hace años.

Para terminar, y volviendo al tema de cómo crear Flash accesible, unas referencias interesantes donde se puede encontrar información sobre este tema:

• WebAIM, Creating Accesible Flash Content: un tutorial con cuatro partes.
• Adobe, Best Practices for Accessible Flash Design: consejos generales y las características específicas de accesibilidad de Flash.
• Adobe, Creating Accessible Content with Flash Professional: de enero de 2011, así que está bastante actualizado.
• The Paciello Group, WCAG 2 Compliance With Flash: presentación de un seminario sobre la accesibilidad de Flash y WCAG 2.0.
• W3C, Flash Techniques for WCAG 2.0: las técnicas de WCAG 2.0 que son específicas para Flash.

Tutorial sobre la accesibilidad en diferentes medios

accesselearning es un tutorial gratuito desarrollado por la universidad Georgia Institute of Technology en el que explican cómo hacer accesibles diversos tipos de contenidos, como vídeos, presentaciones PowerPoint, documentos PDF y, por supuesto, páginas web.

El contenido de este tutorial es:
   1. Accessibility Issues of Disabilities in Distance Education
   2. Planning for Accessibility in Distance Education
   3. Making PowerPoint Slides Accessible
   4. Making Video Accessible
   5. Making Flash Accessible
   6. Making Word Documents Accessible
   7. Making Excel Documents Accessible
   8. Making PDF Documents Accessible
   9. Making Webpages Accessible
  10. Making Scripts and Java Accessible

Serie "Guía breve": Multimedia

Consejo 3: Multimedia: Proporcione subtítulos y transcripción del sonido, y descripción del vídeo.

Los elementos multimedia que tanto se utilizan en las páginas web hoy en día pueden ocasionar graves problemas de accesibilidad, ya no sólo a las personas con algún tipo de discapacidad, sino a todo el mundo en general. ¿Por qué?

Porque al ser elementos que no son HTML requieren, en la mayoría de los casos, la instalación de un visor específico (plug-in, add-in o extensión) que sea capaz de interpretar el elemento multimedia. Y no todo el mundo tiene su ordenador actualizado con los últimos visores.

Por tanto, como regla general, no se debe abusar de los elementos multimedia y el diseñador de una página web se tiene que preguntar, antes de incluirlo en una página web, si es un elemento esencial que no se puede eliminar o sustituir por otro más accesible.

Si nos centramos en los problemas de accesibilidad que pueden tener las personas con discapacidad, los elementos multimedia más problemáticos son los vídeos, las grabaciones sonoras y las animaciones.

Respecto a los vídeos y las grabaciones sonoras, en ambos casos se tiene que proporcionar una transcripción de los dialógos y una descripción de los sonidos. En el caso de los vídeos también se tiene que proporcionar una descripción del vídeo en sí (de la imagen). Un par de artículos sobre subtítulos y descripciones: Captioning y Audio description.

Hoy en día existen tecnologías que permiten sincronizar los subtítulos o una transcripción con un vídeo o una grabación sonora. Las dos tecnologías que más se emplean son Synchronized Multimedia Integration Language (SMIL), una tecnología promovida por el W3C, y por otro lado Microsoft Synchronized Accessible Media Interchange (SAMI). Hace unos días publiqué una entrada llamada SMIL y la accesibilidad web donde comento brevemente estas dos tecnologías.

En el caso de las animaciones, lo más normal hoy en día es que se realicen con Adobe (Macromedia) Flash. Para conocer los problemas de accesibilidad que presentan los elementos multimedia creados con Flash y cómo hacer que sean accesibles, recomiendo la lectura de las siguientes páginas:

• Flash y Accesibilidad Web: una relación complicada: en este artículo podemos leer que la accesibiliad de Flash sólo esta disponible en el sistema operativo Microsoft Windows y con el navegador Microsoft Internet Explorer, ya que Flash utiliza la tecnología tecnología Microsoft Active Accesibility (MSAA) para ofrecer las carecterísticas de accesibilidad.
• Creating Accessible Macromedia Flash Content
• Flash 8 Accessibility Design Guidelines: de Adobe.
• Flash 8 Accessibility Design Guidelines: similar al anterior.
• Best Practices for Accessible Flash Design: de Adobe.

(Actualización 22/11/2007) Otro tipo de elemento problemático, que no es del todo multimedia, pero que se puede incluir dentro de este consejo son los documentos PDF (Portable Document Format). Algunos páginas donde nos explican cómo hacer que un PDF sea accesible:

• Técnicas para el desarrollo de documentos PDFs accesibles
• PDF accesibles
• Creating accessible Adobe PDF Files
• Guía Accesibilidad en Documentos PDF

Adobe ofrece un servicio llamado Online conversion tools for Adobe PDF documents que convierte un documento PDF a HTML o texto plano para aquellos usuarios que no dispongan de un visor de PDF o que su lector de pantalla no sea compatible con Adobe Acrobat Reader.