Hacia las pautas WCAG 2.0

El Centro de Referencia en Accesibilidad y Estándares Web, dependiente de INTECO, ha publicado recientemente el documento Hacia las Pautas WCAG 2.0: Guía de transición para evaluadores y desarrolladores.

Aunque por el título puede parecer que este documento va a explicar cómo pasar de WCAG 1.0 a WCAG 2.0, en realidad ofrece una introducción a las nuevas pautas, explicando los documentos que componen las nuevas pautas y la forma de leerlos e interpretarlos.

Al inicio de este documento podemos encontrar la siguiente explicación:

Esta Guía ofrece una visión general de las nuevas Pautas, tanto de su filosofía y organización como de otros aspectos más prácticos que permitan entender su significado en el día a día.

En primer lugar, se ofrece un resumen de los antecedentes históricos de las Pautas 2.0, así como el proceso de aprobación seguido por el W3C.

A continuación se analiza la nueva estructura y organización de las WCAG 2.0 y su documentación asociada, destacando las principales diferencias con respecto de sus predecesoras.

Por último, se ofrecen explicaciones detalladas sobre la aplicación y significado de las WCAG 2.0 en relación a los distintos elementos encontrados en las páginas web, tratando de establecer las similitudes y diferencias con respecto de la versión 1.0 de las Pautas.

Accesibilidad de las webs de los principales partidos políticos en las elecciones europeas

Me han hecho llegar el infome Breve análisis del grado de accesibilidad de las web de los partidos políticos españoles en las elecciones al Parlamento Europeo 2009.

El resumen del informe dice:

Los principales partidos políticos españoles para el Parlamento Europeo no cumplen los mínimos de accesibilidad web

Con una posibilidad de alcanzar un record de abstención el próximo 7 de junio, las webs de nuestros principales partidos políticos siguen sin adaptarse a la legislación en materia de accesibilidad web, discriminando a parte del electorado.

Ninguno de los partidos analizados cumple los requisitos recomendados por la ley española para desarrollar en la red sitios accesibles para personas mayores y con discapacidades, según concluye un estudio de la consultora Accesibiliweb.

Para conocer el nivel de accesibilidad de estos sitios web, los autores del informe han analizado en qué medida cumplen ciertos criterios reconocidos internacionalmente para calificar la accesibilidad de un sitio en la Red, conocidos como WAI (Web Accessibility Iniciative).

Imágenes sin texto alternativo, páginas que no funcionan correctamente sin scripts, fallos de código, contraste de letras y fondo insuficiente,… Estas son algunos de los fallos más comunes que aparecen en el informe. Si bien el estudio no precisa cual es el sitio web más accesible, se puede comprobar que todos los partidos analizados incumplen la mayoría de los 12 criterios analizados.

Hace unos años se cumplió el plazo para que todas las webs de entidades públicas cumplieran el nivel “WAI doble-A (AA)” (de tres existentes) de accesibilidad según las recomendaciones internacionales del W3C y todavía en sitios web realizados hace escaso meses seguimo viendo que la accesibilidad no es prioritaria.

"El principal problema que encontramos es el desconocimiento total de las normas o técnicas para hacer una web accesible.” nos comenta Lucas Bride, director de Accesibiliweb. “Se prefiere apostar por la web 2.0 (redes sociales, videos, marketing viral,…) que por una tecnología no-discriminatoria y estándar”

Más sobre captcha y accesibilidad

A raíz de una entrada que escribí hace tiempo sobre Los captcha y la accesibilidad web me han escrito un comentario donde me hablan de un proyecto de accesibilidad en los captcha.

En la página el Formulario con captcha accesible se puede probar este captcha y además se puede descargar su código fuente en PHP. La idea es muy sencilla: no se muestra la típica imagen donde es difícil averiguar que texto contiene, sino que se muestra una frase y se realiza una pregunta a partir de esa frase. Algunos ejemplos de preguntas son:

• ¿Cuánto es dos mas dos? (responde con palabras no con número)
• Escribe la tercera palabra de: Hoy está lloviendo
• Escribe la segunda palabra de: Ayer tuve frio

La idea es muy sencilla y, en efecto, resolvería el problema de las imágenes, pero presenta un problema importante, la barrera del idioma: la comprensión por parte de un usuario que no sepa español. Mientras que con los captcha basados en una imagen, la mayoría de la gente ya sabe qué responder, aunque el formulario esté escrito en chino, con este método, o conoces el idioma en el que está escrita la página o prácticamente es imposible responder la pregunta.

A raíz de este comentario he buscado en Google captcha accessibility y esto es lo más interesante que he encontrado:

• Inaccessibility of CAPTCHA: informe de un grupo de trabajo del W3C sobre los captcha. Ofrece algunas soluciones, como los puzzles lógicos y la salida auditiva o limitar la actividad diaria de las cuentas.
  
• Accessibility of CAPTCHA: critica el uso de los captcha, ya que lo que hacen es verificar las "capacidades" de los usuarios y propone como alternativa el empleo de redes sociales para lograr un nivel de confianza cuando un usuario se registra.
• CAPTCHAs, CAPTCHAs everywhere: comenta varios sistemas y describe algunas soluciones alternativas.
  
• Evaluating Existing Audio CAPTCHAs and an Interface Optimized for Non-Visual Use: excelente artículo que evalúa y compara distintas soluciones de captchas auditivos.
• Proposal for an Accessible Captcha: propone un captcha auditivo pero sin emplear distorsiones que dificultan enormemente entender lo que se dice.
  

WAVE en español

En el blog de WAVE han anunciado la traducción al español de la barra de herramientas WAVE para Firefox: WAVE in Spanish (WAVE en español).

Esta herramienta también está disponible online.

Android accesible

Android es una plataforma de software y un sistema operativo para dispositivos móviles como los teléfonos móviles auspiciada por Google.

En el artículo Eyes-Free para Android nos explican que existe la librería Text-To-Speech (TTS) que permite añadir voz a las aplicaciones.

Introducción a la accesibilidad web

He publicado un fichero pdf con la charla que impartí hace unos días en un curso de doctorado en la Universidad de Alicante: Introducción a la accesibilidad web. El contenido de la charla fue:

• Qué es la accesibilidad web?
• ¿Accesibilidad = usabilidad?
• Ayudas técnicas para los discapacitados
• ¿Cómo hago que mi sitio web sea accesible?
• Legislación en España
• Más información

Más sobre legibilidad (facilidad de lectura y comprensión)

Hace unos meses escribí la entrada Legibilidad: facilidad de lectura y comprensión, donde hacía referencia a los puntos de revisión del WAI que recomiendan emplear un lenguaje sencillo a la hora de escribir los textos de un sitio web. Esta claro que este es uno de los temas donde la accesibilidad y la usabilidad coinciden plenamente.

Acabo de encontrar más información sobre la legibilidad de los textos. Por un lado, el libro gratuito The Principles of Readability. En este libro podemos encontrar una revisión exhaustiva de las principales técnicas y fórmulas que se emplean para medir la legibilidad y el nivel de comprensión lectora de un texto.

Por otro lado, he encontrado Flesh, un programa grautito basado en Java, que dispone versión para línea de comandos o con interfaz gráfico. Este programa permite procesar diferentes formatos de ficheros, incluídos Microsoft Word y Adobe PDF. El cálculo de la legibilidad de un texto lo realiza mediante el Flesch-Kincaid Readability Test, que emplea dos indicadores: Flesch Reading Ease y Flesch–Kincaid Grade Level. Ambos indicadores se basan en el número de frases, el número de palabras y el número de sílabas que contiene un texto.

Accessibility Color Wheel

Hace un par de meses escribí una entrada sobre el color y el contraste y comentaba un par de herramientas que permiten calcular la diferencia de brillo y contraste entre dos colores.

Un antiguo alumno me dejó un comentario sobre una herramienta, Accessibility Color Wheel que es muy interesante. Por un lado, permite emplear el algoritmo de cálculo de la diferencia de brillo y contraste entre dos colores de WCAG 1.0 o el algoritmo de WCAG 2.0. Por otro lado, muestra cómo ven la combinación de colores elegidas tres colectivos de usuarios con ceguera a ciertos colores (daltonismo): deutanopia, protanopia y tritanopia.

El CERMI recuerda a las Administraciones Públicas y a las grandes empresas el deber legal de hacer accesibles sus páginas de internet

Acabo de leer en Discapnet la noticia El CERMI recuerda a las Administraciones Públicas y a las grandes empresas el deber legal de hacer accesibles sus páginas de internet.

Recordemos que las leyes que obligan a las Administraciones Públicas y a las grandes empresas son:

• REAL DECRETO 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de comunicación social.
• LEY 49/2007, de 26 de diciembre, por la que se establece el régimen de infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad.
• LEY 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información.

Relacionado con este tema, un par de noticias pasadas donde el CERMI denuncia la falta de accesibilidad de dos sitios web:

• El Cermi denuncia a Metro de Madrid por carecer de accesibilidad en su página Web
• La página web de la Universidad Autónoma de Madrid suspende en accesibilidad
  

Vídeo del seminario "Usabilidad e inclusión digital"

Ya está disponible el vídeo del seminario "Usabilidad e inclusión digital", impartido por Albert Carles i Prat el 13 de marzo de 2009 en Alicante.

Control mental, a la española

El año pasado escribí la entrada Más sobre control mental donde comentaba el dispositivo Emotiv EPOC que se supone que permite controlar un ordenador con la mente sin la necesidad de implantar electrodos en el cerebro: es un casco que te colocas y a controlar el ordenador con el pensamiento. ¿Y dónde se compra esto? Pues el año pasado el fabricante decía que estaría disponible a finales del 2008, pero ahora dicen que será en 2009.

Mientras tanto, van saliendo otras soluciones y ahora nos tenemos que alegrar porque según leo en la noticia Una silla de ruedas guiada por el cerebro, en la Universidad de Zaragoza han desarrollado un sistema que combina por un lado la detección de las ondas cerebrales y por otro lado un sistema avanzado de navegación. ¡Enhorabuena!

En el siguiente vídeo Brain-Controlled Wheelchair podemos ver una demostración de este sistema:

¿Una sorpresa en accesibilidad web?

Acabo de leer en El País la noticia Vinton Cerf: "Cuanto más flexibles sean los medios, mejor les irá en Internet". Vinton Cerf es considerado unos de los "padres de Internet" (en el año 2002 le dieron el Premio Príncipe de Asturias de Investigación Científica y Técnica por ello) y en la actualidad trabaja en Google. Lo que me ha sorprendido de esta entrevista es la contestación a la última pregunta que le han hecho:

P: ¿Qué sorpresas podemos esperar de su compañía en 2009?

R: Se supone que no puedo contarlo. (Risas). Sí puedo contarte que siempre invito a mis compañeros a desarrollar ideas relacionadas con el acceso a la información para discapacitados. Como puedes ver uso un audífono para poder escuchar, así que tengo problemas con los vídeos en Internet, leo bien los labios pero a veces me cuesta entender. Deseo que en accesibilidad nos den pronto alguna sorpresa.

Centrado vertical con CSS

¿Cómo se puede centrar verticalmente un contenido con CSS? La solución no es obvia, existen diferentes métodos con sus ventajas y desventajas. En el artículo Vertical Centering With CSS nos explican cinco métodos.

¿El mejor método? El método 3: consiste en introducir un div vacio antes del div con el contenido. Este div vacío tendrá de altura el 50% menos la mitad de la altura del contenido. Para quitarle la mitad de la altura del contenido se emplea la propiedad CSS margin-bottom. ¡Genial!

<div id="top">
Título de la página
</div>
<div id="floater"></div>

<div id="content">
El contenido que se quiere centrar verticalmente
</div>

Y el CSS:

#floater {float:left; height:50%; margin-bottom:-120px;}
#top  {float:right; width:100%; text-align:center;}
#content {clear:both; height:240px; position:relative;}

Workshop de la ACM sobre mejoras de acceso para los usuarios discapacitados

Una compañera me acaba de pasar el "call for papers" de un workshop en el que participa como miembro del comité de programa, 1st ACM international Workshop on Media Studies and implementations that help Improving Access to Disabled Users, en Pekín. El que quiera mandar algo tiene de tiempo hasta el 26 de junio. Los temas del workshop son:

• Usability and Accessibility.
• Accessible Multimedia.
• Accessibility for all.
• Trends in Disability.
• Person behavior and Interaction Analysis.
• Applications in Virtual Reality, Multimedia and Gaming.
• Technological novelties, evaluations and solutions.
• User-Experience studies and evaluations.
• Human-Centered Computing.
• Human-Computer Interfaces.
• Human Affect Analysis and Affective Computing.
• Perceptual and Multimodal user interfaces.
• Accessible Architecture.

Internet (la Web) en la tele

Acabo de leer en El País el artículo Internet, al asalto de su última frontera. Como de costumbre, en la noticia confuden Internet con la Web y consideran "la parte como el todo".

Existen opiniones enfrentadas sobre si triunfará o fracasará el acceso a Internet a través del televisor. Es una opción que ya existe desde hace años, pero poca gente emplea (yo no conozco a nadie). ¿Se generalizará? Si así ocurriese, tendremos que tenerlo en cuenta a la hora de plantear la accesibiliad de las páginas web:

• ¿Qué dispositivo empleará el usuario? El mando a distancia en vez del ratón y el teclado.
• ¿Qué resoluciones de pantalla tendrá el usuario? Muy variadas, y muy distintas de las que empleamos en el ordenador.
• ¿Qué tamaños de letra tendremos que emplear? Si el usuario está a 5 metros del televisor, un texto con un tamaño de letra de 12 puntos se verá como una línea.
• Y así muchas otras preguntas...
  

El navegador para niños autistas triunfa

Hace casi un año publiqué la entrada Un navegador web para niños autistas. Ahora acabo de leer en El País la noticia El navegador Zac Browser ayuda a los niños autistas a moverse en la Red.

Según la noticia, el navegador tiene una comunidad de más de 750.000 usuarios. Además, la empresa del creador está preparando navegadores para personas con distinto tipo de discapacidad. Según la noticia:

Su empresa de software, People CD Inc, está desarrollando una serie de navegadores para personas con discapacidad física, algo que no existe todavía y que les permitirá bucear en la Red sin tocar el ordenador.

"Llevamos ocho años trabajando en ello y queremos sacarlos para después de junio. Habrá seis variantes, cada uno dedicado a un tipo de discapacidad". También trabajan en navegadores para niños y para adultos con autismo.

El navegador se puede encontrar en ZAC Browser.

Dos errores típicos en Total Validator

Total Validator es un validador muy pontente, ya que permite:

• Validar el (X)HTML
• Revisar la accesibilidad
• Verificar la ortografía (inglés, francés, español, italiano y alemán)
  
• Comprobar los enlaces rotos
  

En la entrada Introducción a la evaluación de la accesibilidad web, un amigo de México me preguntó por el error E649 que genera este validador. Como he visto que varias personas han llegado a esa entrada buscando ese error en Google, creo que se merece una entrada propia.

Puede ser que tengamos una página correcta, que pasa el validador del W3C, pero que Total Validator nos muestra estos errores:

E649 The default scripting language must be specified for an intrinsic event

E650 The default style sheet language must be specified when style attributes are used

¿Qué significan estos errores?

Si consultamos la documentación de Total Validator, encontramos la siguiente explicación:

E649	The default scripting language must be specified for an intrinsic event	When intrinsic events (onclick, onmouseover etc) are specified the default scripting language should be specified using a Content-Script-Type HTTP header or <meta> tag. See http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.2.1 (displayed in new window).
E650	The default style sheet language must be specified when style attributes are used	When style attributes are used the default style sheet language should be specified using a Content-Style-Type HTTP header or <meta> tag. See http://www.w3.org/TR/html401/present/styles.html#h-14.2.1 (displayed in new window).

¿La solución?

E649 The default scripting language must be specified for an intrinsic event

Este error se debe a que no se ha indicado un lenguaje de script por defecto, y entonces cuando se usa un evento intrínseco (los eventos que tienen algunos elementos de HTML, como "input" o "select") no sabe qué lenguaje es. Este error se soluciona añadiendo en el "head" la instrucción:

<meta http-equiv="Content-Script-Type" content="text/javascript" />

E650 The default style sheet language must be specified when style attributes are used

Este error se debe a que no se ha indicado un lenguaje de hoja de estilo por defecto, y entonces cuando se usa el atributo "style" no sabe qué lenguaje es. Este error se soluciona añadiendo en el "head":

<meta http-equiv="Content-Style-Type" content="text/css" />

Accesibilidad de Joomla!

Estoy leyendo el libro Joomla! Accessibility, de Joshue O Connor, editorial Packt Publishing.

¿Qué es Joomla!? Según la Wikipedia:

Joomla! es un sistema de administración de contenidos de código abierto construido con PHP bajo una licencia GPL. Este administrador de contenidos se usa para publicar en Internet e intranets utilizando una base de datos MySQL. En Joomla! se incluyen características como: hacer caché de páginas para mejorar el rendimiento, indexamiento web, feed RSS, versiones imprimibles de páginas, flash con noticias, blogs, foros, polls (encuestas), calendarios, búsqueda en el sitio web, e internacionalización del lenguaje. Su nombre es una pronunciación fonética para anglófonos de la palabra swahili jumla que significa "todos juntos" o "como un todo". Se escogió como una reflexión del compromiso del grupo de desarrolladores y la comunidad del proyecto.

La primera versión de Joomla! (Joomla! 1.0.0) fue publicada el 16 de septiembre de 2005. Se trataba de una versión mejorada de Mambo 4.5.2.3 combinada con otras modificaciones de seguridad y anti-bugs. Actualmente los programadores han publicado Joomla! 1.5 estable bajo un código completamente reescrito y construido bajo PHP 5.

Por tanto, Joomla! es un gestor de contenidos y una herramienta de autor. Hace poco escribí dos entradas sobre estos temas: Accesibilidad de los gestores de contenidos y Accesibilidad de las herramientas de autor.

¿Qué se aprende con este libro? Según dice el mismo libro:

• Get under the hood with Joomla! and learn how to modify Joomla! HTML output in order to make more accessible websites.
• Understand how to use WYSIWYG editors like TinyMCE and XStandard to create accessible content.
• Create accessible Joomla! templates.
• Understand some of the most popular assistive technologies (AT) and how they work.
• Gain a deeper understanding of some different disabilities.
• Get an overview of the legal requirement to be accessible.
• Gain some very practical guidance based on the authors’ years of practical experience working as a web developer and with people with disabilities.

¿Qué estoy aprendido yo? ¿Qué encuentro interesante? Algunas cosas son obvias, pero vale la pena repetirlas porque se olvidan:

• Joomla! no transforma mágicamente el contenido en accesible. El principio "garbage in - garbage out" se sigue aplicando: si le metes basura, obtendrás basura.
• Cómo crear contenido accesible: utilizar encabezados y otros elementos de HTML (listas) para dotar de estructura al contenido, proporcionar una descripción alternativa de las imágenes (alt y longdesc), utilizar textos descriptivos en los enlaces, utilizar tablas para mostrar datos y etiquetarlas correctamente.
• Cómo crear plantillas (templates) accesibles: las versiones anteriores a la 1.5 utilizaban tablas para la maquetación (layout). A partir de la versión 1.5 se pueden evitar con CSS. Joomla! tiene su propio conjunto de etiquetas para indicar los módulos que se desean incluir en la plantilla. Consejos: utilizar tamaños del texto relativos, destacar los enlaces de la página y añadir un enlace de "saltar al contenido". Existe la plantilla Beez donde se ha tenido un cuidado especial para cumplir los estándares web y los principios de la accesibilidad.
• Características de los editores: Joomla! permite elegir entre Tiny MCE y XStandard. Ambos incorporan características de accesibilidad.
  

Por cierto, existe la Comunidad Joomla! con recursos en español donde se puede encontrar mucha información sobre Joomla!.

Workshop sobre usabilidad y accesibilidad

Una compañera me acaba de pasar el "call for papers" de un workshop que organiza, 3rd International Workshop on Web Usability and Accessibility (IWWUA 2009), en Polonia. El que quiera mandar algo tiene de tiempo hasta el 1 de mayo. Los temas del workshop son:

• Usability and accessibility guidelines, factors, criteria, metrics, patterns, and recommendations.
• Ergonomic/HCI criteria and principles
• Usability and accessibility criteria for vertical domains (e.g., e-commerce, e-government, e-learning)
• Management of usability and accessibility requirements in Web projects
• Usability and accessibility evaluation
• Integration of usability and accessibility evaluation activities in development processes
• Early usability evaluation (e.g., based on models, user interfaces prototypes, etc.)
• Usability testing
• Evaluation of users' performance and satisfaction
• Tools for automatic evaluation of usability and accessibility
• User Experience
• Comparative analysis of usability/accessibility metrics
• Theoretical/empirical validation of usability/accessibility metrics
• Empirical studies
• Industrial experiences

Accesibilidad de las herramientas de autor

Hace unos días escribí sobre la accesibilidad de los gestores de contenidos. Como comente, los gestores de contenidos son herramientas de autor. Según el WAI, "las herramientas de autor permiten, facilitan y promueven la aportación de texto alternativo en una página Web".

Para las herramientas de autor existen una serie de pautas, Authoring Tool Accessibility Guidelines (ATAG). ¿Qué nos dicen estas pautas? La ATAG 1.0 (febrero 2000) se compone 7 pautas y 28 puntos de verificación:

• PAUTA 1: Facilitar la accesibilidad de la autoría.

Si las marcas se generan de forma automática, muchos autores no se darán cuenta de la accesibilidad del producto final, a menos que le dediquen un esfuerzo añadido para realizar las correcciones oportunas a mano.

Puesto que a un número importante de autores la accesibilidad no les resulta familiar, las herramientas de autor son responsables de generar marcado accesible de forma automática y, donde sea adecuado, de guiar al autor para producir contenido accesible.

• PAUTA 2: Generar marcado estándar.

La conformidad con estándares promueve la interoperabilidad y la accesibilidad al facilitar que existan navegadores especializados para usuarios concretos.

• PAUTA 3: Dar soporte a la creación de contenido accesible.

Una información bien estructurada y la incorporación de contenidos accesibles equivalentes son fundamentales para un diseño accesible.

Sin embargo, por ejemplo, la producción de información equivalente útil para las herramientas de accesibilidad, puede ser uno de los aspectos más complejos del diseño web y las herramientas de autor deben facilitar y automatizar este proceso.

• PAUTA 4: Proporcionar medios par verificar y corregir contenido inaccesible.

Muchas herramientas permiten al autor crear documentos con poco o ningún conocimiento de las marcas subyacentes. Para asegurar la accesibilidad, las herramientas de autor deben ser diseñadas de forma que puedan identificarse automáticamente contenidos inaccesibles, y permitir su corrección incluso en los casos en los que las marcas están ocultas al autor.

• PAUTA 5: Integrar las soluciones de accesibilidad en la interfaz de usuario.

Cuando se añade una nueva característica a una herramienta existente sin una integración apropiada, el resultado es una discontinuidad obvia. Por lo tanto, es importante que la creación de contenido accesible sea un proceso natural dentro de la herramienta.

• PAUTA 6: Promover la accesibilidad en la ayuda y documentación.

Los autores pueden no estar familiarizados con los problemas de accesibilidad que surgen al crear contenido web. La ayuda y la documentación deberían explicar los problemas habituales de accesibilidad y sus soluciones con ejemplos ilustrativos.

• PAUTA 7: Asegurar que la herramienta de autor sea accesible para autores con discapacidad.

Las herramientas de autor son aplicaciones con elementos de interfaz de usuario estándar y como tal tienen que seguir una pauta de accesibilidad.