Técnicas de accesibilidad para la discapacidad cognitiva

El impacto que tiene la discapacidad cognitiva en el uso de la Web es de los temas de la accesibilidad web que menos ha sido estudiado. La discapacidad cognitiva agrupa diferentes tipos de discapacidades o síndromes que dificultan la sistematización de las soluciones que se deben aplicar.

Muy importante: no se debe confundir discapacidad cognitiva con discapacidad intelectual. Una puede implicar la otra y vice versa, pero no son lo mismo. Algún día lo explicaré...

El W3C acaba de publicar el primer borrador de Techniques for the The Cognitive and Learning Disabilities Accessibility Task Force (COGA). Realmente, no se puede llamar ni borrador, es más bien un esquema de lo que se pretende redactar, muchas de sus secciones están vacías. Sin embargo, es un buen inicio.

Por ahora, las principales técnicas que se deben aplicar para garantizar la accesibilidad son:

1. Use a clear structure with easy to follow sections short paragraphs manageable chunks
2. Use an easy to follow writing style
3. Provide rapid and direct feedback
4. Help the user understand the content and orientate themselves in the content.
5. Help users complete and check their work by less likely that the user will make mistakes and easy to undo mistakes when they occur
6. Provide help
7. Help the user focus and help restore the context if attention is lost
8. Enable adaptability and personalization, so that symbols text and other features rare familiar and helpful to the user
9. Minimize the cognitive skills required to use the content and avoid barriers that stop people with cognitive disabilities from using content, such as hard to use security mechanisms.

La accesibilidad de la web móvil

En el congreso 10th International Cross-Disciplinary Conference on Web Accessibility (W4A 2013), varios miembros del WAI presentaron el artículo Essential Components of Mobile Web Accessibility.

Algunas de las cuestiones sin resolver que planteaba el artículo son:

• ¿Cómo de bien soportan las características que mejoran la accesibilidad las plataformas móviles?
• ¿Qué similitudes y diferencias existen en los modelos para la accesibilidad web entre las plataformas tradiciones (escritorio) y las plataformas móviles?
• ¿Cuáles son los cambios en los requisitos de accesibilidad para cada componente web debido al diferente papel que desempeñan en los contextos móviles?

El WAI dedica una parte de sus esfuerzos a la accesibilidad de los dispositivos móviles: Mobile Accessibility.

Y también se pueden encontrar guías de terceros, como Mobile accessibility guidelines.

Navegación a través de landmarks en Firefox

Los landmark roles de Accessible Rich Internet Applications (WAI-ARIA) 1.0 son regiones especiales de una página web que se definen para que el usuario pueda navegar fácilmente entre ellas. Aunque es una característica que mejora la accesibilidad web, su empleo puede mejorar la usabilidad y, por tanto, puede ser beneficioso para todos los usuarios.

Los landmark roles que se han definido hasta ahora son:

• application
• banner
• complementary
• contentinfo
• form
• main
• navigation
• search

Algunos tienen un equivalente en las etiquetas HTML, como aside, nav o la nueva etiqueta main, mientras que otros no (Using WAI-ARIA Landmarks – 2013).

Los lectores de pantalla modernos son capaces de interpretar los landmark roles. Por ejemplo, en el siguiente vídeo, How ARIA landmark roles help screen reader users, vemos y escuchamos una demostración de su uso:


¿Pero qué pasa con los usuarios que no necesitan y no usan un lector de pantallas, como por ejemplo los usuarios que manejan el ordenador con el teclado? Estos usuarios también se pueden beneficiar de los landmark roles, pero desgraciadamente, los navegadores actuales no proporcionan ningún mecanismo para su uso.

Sin embargo, en el caso de Mozilla Firefox, existe una extensión que resuelve el problema: Enabling landmark-based keyboard navigation in Firefox.

IndieUI

Independent User Interface (IndieUI) es una nueva iniciativa de WAI que tiene como objetivo facilitar el desarrollo de aplicaciones preparadas para ser compatibles con diferentes dispositivos y contextos de uso.

Por ejemplo, el siguiente gráfico representa diferentes formas de lanzar el mismo evento, una solicitud de desplazamiento (scroll) en un interfaz gráfico:

Informe sobre métricas de la accesibilidad web

Hace unos días se envió un mensaje al grupo de interés del WAI en el que se anunciaba la publicación del Research Report on Web Accessibility Metrics.

Las métricas de accesibilidad ayudan a extender el actual modelo de conformidad basado en WCAG 2.0, ya que ofrecen resultados del nivel de accesibilidad de un sitio web con más profundidad y detalle. Pero las métricas necesitan un análisis de su validez, fiabilidad, sensibilidad, idoneidad y complejidad, y eso es lo que se estudia en este informe.

Este informe recoge las conclusiones del Website Accessibility Metrics Symposium que se celebró en diciembre de 2011.

El lío de las guías de la accesibilidad web

Hace unos años, en el 2006, escribí la entrada La accesibilidad en la Web tiene que mejorar mucho, en la que hablaba de una entrevista que le habían hecho a Tim Berners-Lee, el padre de la Web. En la entrevista hizo un comentario muy interesante sobre las pautas o guías de accesibilidad web:

When OUT-LAW asked whether he thinks further regulation is necessary to improve accessibility, Berners-Lee declined to take sides. Diplomatically, he pointed out that regulation is not his field of expertise. "What I would say is that everyone should reference the same guidelines", he said.

His point is that W3C has written the de facto standard; but governments and non-governmental organisations have seen fit to write their own versions. "You can't design a site and try to make it compete with 152 different sets of guidelines from 152 different states," he said. "Keeping the standards homogenous is really important".

In short, everyone should follow WCAG.

Tim Berners-Lee nos dice: "No puedes diseñar un sitio e intentar que cumpla 152 grupos de guías diferentes de 152 diferentes países".

Afortunadamente, muchos países han adoptado las pautas del W3C, ya sea WCAG 1.0 o WCAG 2.0, directamente.

Otros, como España, las han adoptado de forma indirecta, con alguna ligera modificación, porque su ordenamiento jurídico no permite hacer referencia directa a WCAG.

¿Cuál es el beneficio de la situación que hay en España para los usuarios y desarrolladores? Ninguno.

¿Cuál es el perjuicio de la situación que hay en España para los usuarios y desarrolladores? Se me ocurren muchos, como por ejemplo, que si un producto está certificado que cumple WCAG, en España no tendría ninguna validez y se debería de volver a certificar conforme a la norma española. O si una empresa extranjera quiere hacer un desarrollo web en España se encontrará con que debe cumplir una norma extraña, que al final resultará que es WCAG, pero que a priori puede causar extrañeza y rechazo.

España, ninguna ventaja, todo problemas.

La universalidad de la Web

Desde hace unos meses colaboro con Ayudatec, un blog sobre discapacidad, accesibilidad y tecnología creado en Chile.

El pasado 3 de septiembre publicaron mi primer artículo La universalidad de la Web que copio a continuación:

En la página principal de la Iniciativa para la Accesibilidad Web, la Web Accessibility Initiative hay una pequeña cita de Tim Berners-Lee, considerado el padre de la Web y director del World Wide Web Consortium (W3C) desde su fundación en el año 1994:

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Que se puede traducir al castellano por:

El poder de la Web está en su universalidad. Un acceso por todo el mundo, independientemente de su discapacidad es un aspecto esencial.

¿Qué significa la “universalidad de la Web”? Cuando en marzo de 1989, Tim Berners-Lee le presentó a Mike Sendall, su jefe en el CERN, su informe Information Management: A Proposal que contenía su propuesta de desarrollar un sistema de hipertexto que acabaría dando nacimiento a la Web a los pocos años, uno de los problemas que Tim Berners-Lee quería resolver era la heterogeneidad en el acceso a los datos: que cualquiera, independientemente del sistema informático que usase (VM/CMS, Macintosh, VAX/VMS, Unix escribió Tim Berners-Lee en su propuesta) pudiese acceder a los datos en igualdad de condiciones.

Ese objetivo se logró, y hoy en día podemos hablar de la universalidad de la Web respecto a los dispositivos: es posible acceder a la Web no sólo desde un ordenador (con Windows, Macintosh o Linux), sino también desde teléfonos móviles, tabletas, frigoríficos, automóviles y prácticamente desde cualquier dispositivo que se pida que lo haga. No hay límites, la Web es una plataforma universal a la que se puede conectar cualquier dispositivo.

Sin embargo, en la actualidad, todavía falta algo importante para que la Web sea totalmente universal: la universalidad de la Web respecto a las personas. Existen grupos de personas que tienen dificultades para acceder a la Web o, en el peor de los casos, son incapaces de acceder. Y no me estoy refiriendo a ese 70% de la población mundial que no tiene acceso a Internet.

Cuando Tim Berners-Lee dice Un acceso por todo el mundo, independientemente de su discapacidad es un aspecto esencial se está refiriendo a esas personas, a las personas con algún tipo de discapacidad.

Si las páginas web no se desarrollan correctamente, pueden presentar problemas que impidan que ciertos grupos de usuarios las puedan utilizar en igualdad de oportunidades.

¿Cómo afectan las diferentes discapacidades al acceso a la Web? Las personas con visión reducida pueden tener problemas con los textos pequeños o con combinaciones de colores con poco contraste; las personas ciegas no pueden ver las imágenes u otros elementos multimedia como los vídeos; las personas sordas no pueden escuchar el audio de los vídeos o pueden tener problemas para comprender los textos largos y complejos; las personas con discapacidad física pueden tener problemas con las interfaces de usuario que sólo se pueden utilizar con el ratón; y muchas situaciones más.

Para resolver estos problemas, dentro del W3C se estableció en el año 1997 la Web Accessibility Initiative, que desarrolla pautas y técnicas que proporcionan soluciones accesibles para los desarrolladores web. Las pautas de la WAI son consideradas como estándares internacionales de accesibilidad web y en muchos países han sido adoptadas en su marco legislativo.

El fin último del WAI es lograr la universalidad de la Web respecto a las personas: que todas las personas, incluidas las personas con discapacidad, puedan percibir, entender, navegar e interactuar con la Web.

Si deseas aprender más cosas sobre la accesibilidad web, te aconsejo que visites mi sitio web Accesibilidad web y me sigas a través de mi blog Accesibilidad en la Web o a través de mi cuenta en Twitter.

Recomendaciones para medir el grado de accesibilidad y usabilidad

Hace unos días recibí la siguiente consulta por correo electrónico:

Hola,

Soy autónoma y estoy apuntada en un Máster de comunicación 2.0. He visto en internet tus recomendaciones.

Como ejemplo, tenemos que analizar una web de noticias desde el punto de vista de la accesibilidad y usabilidad. Como ejemplo, he elegido la web : http://www.lainformacion.com.

Me gustaría saber cuales son los procesos a seguir para conocer el grado de accesibilidad y de usabilidad de esta web. Entiendo que para la accesibilidad, hay que mirar por ejemplo los componentes como imagenes y animaciones, mapas de imagen, enlaces, organización de paginas....etc....pero no sé como aplicar estos criterios a la web que he elegido....Estoy un poco confusa. Me puedes ayudar por favor. He empezado una presentación.

Muchas gracias por tu colaboración,

Reciba un cordial saludo

Además de este correo electrónico, la lectora también me envió una presentación en formato Microsoft PowerPoint con un esquema del ejercicio que piensa desarrollar.

Lo que esta lectora necesita es una metodología de evaluación de la accesibilidad web. Desgraciadamente (o afortunadamente), metodologías hay muchas y muchos usuarios acaban desarrollando su propia metodología, ya sea empezando desde cero o adaptando alguna existente.

A continuación, una lista de las principales metodologías que conozco (el orden no indica absolutamente nada):

• Pautas de Accesibilidad al Contenido en la Web 1.0: Apéndice A - Validación.
• Evaluating Websites for Accessibility: Overview del W3C.
• Unified Web Evaluation Methodology version 1.2 (UWEM) de WAB Cluster.
• Los artículos de Olga Carreras:
• Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España
• Metodología para la evaluación de la accesibilidad web: "Evaluating Web Sites for Accessibility" de la WAI
• Metodología de Evaluación de Conformidad con la Accesibilidad en sitios web (WCAG-EM)
• Libro blanco de eXaminator: Metodología de trabajo.
• Web Accessibility Assessment Methodology del Gobierno de Canadá.

Y por último, un artículo científico con una comparativa de diferentes métodos para evaluar la accesibilidad web: A comparative test of web accessibility evaluation methods, de Giorgio Brajnik.

Canadá, un ejemplo de compromiso del gobierno con la accesibilidad web

El Gobierno de Canadá actualizó el año pasado su normativa en materia de accesibilidad web de los sitios web de las administraciones públicas. He publicado en mi sitio web un resumen de la legislación actual que se aplica en Canadá, que se alinea con WCAG 2.0.

Esta nueva normativa entró en vigor el 1 de agosto de 2011 y se implementará a lo largo de tres fases hasta el 31 de julio de 2013.

Y en España, ¿cuándo se actualizará la legislación a WCAG 2.0? Bueno, parece que habrá que esperar a nueva Ley Europea de Accesibilidad, que está prevista para otoño de 2012. Mientras tanto, según me han comentado un par de veces, parece que ya se está trabajando en la nueva norma UNE que se adaptará a WCAG 2.0.

Diseñador de layouts con roles de WAI-ARIA

YUI CSS Grid Builder es una herramienta gratuita de Yahoo! que permite diseñar maquetas (layouts) o rejillas (grids) de páginas web. Existen muchas herramientas similares a esta, pero me ha sorprendido que este generador incluye la posibilidad de asignar un rol de WAI-ARIA a las distintas partes de la página.

Además, esta herramienta también permite visualizar el orden de lectura del contenido de la página. Al final, existe un botón para generar el código HTML de la página, que hace referencia al framework de CSS de Yahoo!

Recordemos que WAI-ARIA, Accessible Rich Internet Applications 1.0 (que todavía no es una recomendación), proporciona una serie de mecanismos (roles, estados y propiedades) para que las aplicaciones ricas de Internet (rich internet applications) sean accesibles.

Un elemento clave son los roles, que permite definir la función (la semántica) de cualquier parte de una página. Así, por ejemplo, existen roles de tipo widget para definir lo que es un botón o una barra de desplazamiento, roles de tipo estructura de documento para definir las distintas partes de una página como un encabezado o un artículo, y los roles de punto destacado para definir elementos significativos de una página como un formulario o un cuadro de búsqueda.

En la siguiente imagen podemos ver la taxonomía de roles de WAI-ARIA, que es bastante compleja.

Las personas mayores y la accesibilidad web

Poco he escrito sobre este tema, principalmente por desconocimiento. Me parece que sólo la entrada Accesibilidad web para personas mayores (09/07/2008). Ahora me han pedido que prepare una conferencia sobre este tema, así que "me tengo que poner las pilas" y desde aquí os invito a todos a que me echéis una mano publicando algún comentario con información interesante.

La conferencia que tengo que impartir se engloba en las actividades que la Universidad de Alicante está realizando por motivo del Año Europeo del Envejecimiento Activo y de la Solidaridad Intergeneracional 2012. El porcentaje de personas mayores cada vez es mayor respecto al resto de la población (El número de personas mayores excederá por primera vez al de la población infantil en 2045) y la sociedad se tiene que preparar para esta situación.

De entrada, hay que dejar bien claro que, como en cualquier otro colectivo, existe una gran diversidad y "no todos los cisnes son blancos", aunque mucha gente crea que es así. Existen algunos patrones muy generalizados, pero siempre hay excepciones.

Desgraciadamente, existe una tendencia a equiparar la situación de las personas mayores con la discapacidad y la dependencia.  Aunque sí que es cierto que conforme envejecemos los procesos degenerativos se acentúan, lo cual puede ocasionar diferentes tipos de discapacidades y puede aumentar la prevalencia de situaciones de dependencia, eso no significa que sea así en todos los casos. Además, al asociar personas mayores con discapacidad se suelen obviar otras características de las personas mayores.

¿Qué características que presentan las personas mayores pueden ocasionar problemas en el uso de la Web? Por un lado, todas las asociadas a diferentes tipos de discapacidades:

• Visual, como por ejemplo una pérdida de la agudeza visual (por ejemplo, vista cansada) o la aparición de enfermedades como las cataratas o el glaucoma que al final pueden derivar en una ceguera total.
• Auditiva, como por ejemplo una disminución del umbral auditivo o la pérdida total de la audición.
• Motora, como por ejemplo la disminución de la destreza para manipular objetos.
• Cognitiva, como por ejemplo una reducción de la memoria reciente, lo que influye en la rápida toma de decisiones o en la capacidad de aprendizaje.

Pero también presentan algunas características propias que no están asociadas a una discapacidad, como por ejemplo:

• Situación económica: las personas mayores suelen tener un menor poder adquisitivo, por lo que es menos probable que puedan cambiar de ordenador "cada tres años" para adaptarse a los últimos avances tecnológicos.
• Motivación para aprender: las personas mayores suelen estar menos dispuestas a aceptar cambios, en parte por su reducción de la memoria reciente. Por tanto, suelen estar menos dispuestas a aprender un nuevo interfaz de usuario, por lo que son más reticentes a cambiar de versión del software ("a mí déjamelo como estaba antes, que yo sabía donde estaban las cosas y ahora no las encuentro").

Los dos puntos anteriores implican un discapacidad tecnológica.

Por ahora, además de pequeños artículos, sólo tengo localizados dos documentos realmente interesantes sobre las personas mayores y la accesibilidad web:

• El W3C publicó en mayo del 2008 el documento Web Accessibility for Older Users: A Literature Review, donde se trata con mucho detalle los problemas que presentan estos usuarios y las soluciones que se pueden aplicar. Este documento se basa en la revisión de una serie de publicaciones (principalmente artículos científicos) que han estudiado este tema.
• El Análisis de usabilidad de los portales en español para personas mayores publicado en junio del 2008, donde se explican los problemas de las personas mayores en su interacción con el ordenador, una evaluación de los portales para mayores en español y una serie de recomendaciones para diseñadores de webs para personas mayores.

¿Conoces algún consejo o recurso interesante sobre este tema? ¿Alguna experiencia con personas mayores y la Web que puedas compartir?

Para terminar, un aviso para los que no les interese que la Web sea accesible: Todos nosotros seremos los mayores beneficiarios de una web accesible en el futuro cuando seamos personas mayores.

[Actualización 20/04/2012]
Justo el próximo jueves 24 de abril, el CENTAC (Centro Nacional de Tecnologías de la Accesibilidad) organiza un encuentro, un desayuno sectorial, dedicado a TIC, accesibilidad y envejecimiento activo. El encuentro se podrá seguir en directo a través de su sitio web.

[Actualización 12/05/2012]
Otro recurso del W3C: Web Accessibility and Older People: Meeting the Needs of Ageing Web Users.

Pequeña mejora en la accesibilidad de Blogger

Recordemos que según la Web Accessibility Initiative (WAI), la accesibilidad web depende de tres elementos (Essential Components of Web Accessibility):

• Los desarrolladores web, que emplean las herramientas de autor,
• para crear el contenido web,
• al que los usuarios acceden mediante agentes de usuario (navegadores) y productos de apoyo.

Para que la accesibilidad web funcione, los tres elementos deben funcionar correctamente. Para cada uno de esos elementos, el WAI ha creado guías concretas:

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

Los gestores de contenido (Content Management Systems, CMS) es el software más popular que se emplea hoy en día para crear sitios web. Ejemplos de este software son WordPress o Blogger, el software con el que está hecho este blog. Los gestores de contenido son herramientas de autor y, por tanto, se les aplican las pautas de ATAG.

El punto de verificación 3.1 de ATAG 1.0 dice:

3.1 Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video).

Traducido al castellano:

3.1 Pida al autor que proporcione información alternativa equivalente (por ejemplo, títulos, descripciones auditivas, y transcripciones intercaladas de texto para el vídeo).

Si consultamos el documento de técnicas para este punto de verificación, comprobamos que se relaciona con diferentes puntos de verificación de WCAG 1.0, como por ejemplo el 1.1 "Proporcione un texto equivalente para todo elemento no textual".

Desde hace años, cuando doy un curso y explico la accesibilidad de los gestores de contenido, comparo la forma de cumplir esta pauta en WordPress y en Blogger cuando se inserta una imagen.

En el caso de WordPress, al insertar una imagen se muestra un panel para que el usuario/autor introduzca información sobre la imagen, incluido el texto alternativo de la imagen que se utilizará en el atributo alt.

Sin embargo, en Blogger, hasta hace poco, era imposible introducir el texto alternativo. Existía una opción llamada "Añadir leyenda" que podía parecer que servía para eso, pero simplemente añadía el texto como pie de figura. Si alguien quería definir el texto alternativo de una imagen lo tenía que hacer editando directamente el código HTML, cosa que la mayoría de los usuarios de Blogger o de WordPress no saben hacer.

Afortunadamente, en Blogger recientemente han añadido una opción más llamada "Properties" (es tan reciente que todavía no han tenido tiempo de traducirla al castellano), como podemos ver en la siguiente imagen:

Al pulsar en "Properties" se muestra un panel en el que se puede introducir tanto el texto para el atributo title como para el atributo alt (otra vez, se les ha olvidado traducirlo al castellano):

Finalmente, si revisamos el código HTML que genera Blogger, podemos verificar que sí que se añaden los atributos title y alt a la etiqueta img:

El proceso de estandarización del W3C

Ayer escribí la entrada De los estándares, normas, recomendaciones y otras "tonterías" en la que quise explicar lo importante que son los estándares en nuestras vidas y los beneficios que nos aportan. Aunque no nos demos cuenta, estamos rodeados de estándares por todas partes: el tamaño del papel que tengo encima de mi mesa, el casquillo de la bombilla que ilumina mi oficina, el conector USB del teclado y del ratón que estoy usando ahora mismo, la disposición de las teclas en el teclado que estoy usando ahora mismo para escribir este texto, etc., todo eso y mucho más está basado en estándares internacionales que nos hacen la vida un poco más sencilla. Sin los estándares, la vida podría ser un auténtico caos.

Y por supuesto, el lenguaje HTML, CSS, DOM y JavaScript con el que está creado Blogger y que me permite usarlo con cualquier navegador, lo que me evita el tener que tener un navegador concreto que me exija Google para poder usar Blogger. Mejor no imaginemos qué pasaría si no hubiese estándares en el desarrollo web...

Los estándares (también llamados normas) se pueden clasificar de diferentes formas. Así, por ejemplo, podemos hablar de:

• Estándar cerrado, abierto o libre.
• Estándar legal (de iure) o de hecho (de facto).
• Estándar nacional, internacional o industrial.

Los estándares normalmente son creados por organizaciones, públicas o privadas, como puede ser AENOR en España, DIN en Alemania, ANSI en Estados Unidos o ISO a nivel internacional. Estos estándares pueden estar oficialmente respaldados en el ordenamiento jurídico de un país, es decir, son de obligado cumplimiento por ley.

El World Wide Web Consortium (W3C) es un consorcio internacional e independiente que fue fundado en octubre de 1994. Está formado por empresas, organizaciones gubernamentales y no gubernamentales, que tiene como misión guiar la Web hacia su máximo potencial. Para ello, el W3C promueve la evolución e interoperatividad de la Web desarrollando especificaciones, protocolos y recomendaciones.

En la actualidad, el W3C no tiene el mismo peso legal que tiene, por ejemplo, ISO. Supongo que por ello, las especificaciones y protocolos que crea el W3C se llaman "recomendaciones", aunque en el mundo del desarrollo web reciben la misma consideración que cualquier estándar en otra industria. Las recomendaciones del W3C son estándares de hecho: estándares no oficiales, pero que debido a su enorme penetración y aceptación en el mercado, tienen el mismo peso que un estándar oficial.

Desgraciadamente, un estándar no es siempre la mejor opción posible entre todas las existentes, y muchas veces se tarda mucho en desarrollar un estándar porque hay que encontrar un consenso entre muchas partes, cada una con sus propios intereses (no creamos que W3C es una organización tan independiente como se pueda pensar, ya que está formada principalmente por personas de las empresas y organizaciones que más intereses tienen en el tema, como Microsoft, Google, Apple, Opera y Mozilla). Es el precio que hay que pagar para luego poder tener una serie de beneficios.

Para lograr el consenso entre todas las partes implicadas, el W3C tiene definido un proceso (World Wide Web Consortium Process Document). Este proceso consta de siete pasos:

1. Submission: un miembro del W3C puede enviar una propuesta de estándar al W3C.
2. Note: a menudo, la propuesta se convierte en una nota que se hace pública. Una nota es simplemente la exposición pública de una propuesta. No supone en ningún modo que tenga el apoyo del W3C, no supone que se haya iniciado ningún trabajo de estandarización y el único propósito es crear un foro de discusión.
3. Working Group: cuando el W3C reconoce que una propuesta tiene interés y se debe desarrollar, se establece un grupo de trabajo. El grupo de trabajo establece un calendario de trabajo y publica un primer borrador con la propuesta que se quiere estandarizar.
4. Working Draft: un borrador de trabajo es un documento que se expone públicamente para mostrar el progreso en el desarrollo de una nueva recomendación. Junto con su publicación se establece un calendario para que el público pueda participar y enviar comentarios y correcciones. Un borrador de trabajo nunca se debería emplear como material de referencia, porque puede ser actualizado, reemplazado o incluso declarado como obsoleto en cualquier momento.
5. Candidate Recommendation: una recomendación candidata es un borrador de trabajo que ha alcanzado un alto nivel de madurez, pero que también puede ser actualizado, reemplazado o incluso declarado como obsoleto en cualquier momento, como cualquier otro borrador de trabajo. El propósito de la recomendación candidata es que sea implementada y probada para comprobar que su uso es factible.
6. Proposed Recommendation: después de que todas las características de la recomendación candidata hayan sido implementadas, se publica la propuesta de recomendación que representa la última etapa previa a la publicación definitiva de la recomendación.
7. Recommendation: una vez que la propuesta de recomendación haya recibido el apoyo suficiente, se publica la recomendación, que ya tiene el carácter de documento estable. A partir de ese momento, el W3C sí que apoya y fomenta su uso y difusión.

Posteriormente, una recomendación puede ser actualizada para corregir errores y clarificar algunos aspectos que puedan ser confusos o ambiguos. Pero esto no se convierte en una nueva recomendación, sino que es una nueva edición de la recomendación ya existente. Por ejemplo, XML 1.0 ya va por su quinta edición (26 de noviembre de 2008), aunque la primera edición fue publicada el 10 de febrero de 1998.

Evidentemente, algunas especificaciones son más complejas que otras, y pueden requerir más tiempo, más pruebas y la participación de más gente. Por ejemplo, WCAG 2.0 fue publicada el 11 de diciembre de 2008. Pero podemos encontrar un borrador de trabajo del 25 de enero de 2001.

Y algunas no llegan nunca a ser recomendación. Por ejemplo, el W3C estuvo trabajando en XHTML 2.0 más de ocho años (existe un borrador de trabajo del 5 de agosto de 2002) para nada, ya que su desarrollo fue cerrado el 17 de diciembre de 2010 en favor de HTML5.

Por tanto, como podemos intuir por todo lo anterior, crear una recomendación dentro del W3C no es el resultado de "cinco amiguetes que se reúnen dos tardes y escriben un documento". Es el resultado de un largo y laborioso proceso.

Para el que quiera saber algo más, le recomiendo la lectura de How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute, que ha sido traducido al castellano en Como la WAI desarrolla las pautas de accesibilidad en el proceso de la W3C: Hitos y oportunidades para contribuir.

¿WCAG 1.0, WCAG 2.0, Norma UNE 139803 o qué?

El otro día me dejaron el siguiente comentario:

Tremendo lio tengo... muchos cursos ya estan orientados a WCAG 2.0, pero claro si te presentas a algún proyecto "avanza" te requieren las WCAG 1.0, por ley también...

La duda es razonable: ¿qué debo aplicar? ¿WCAG 1.0? ¿WCAG 2.0? ¿Norma UNE 139803?

Desde mi punto de vista, la respuesta es clara: si hay una ley que nos obligue a algo, lo que diga la ley, ya que eso es lo que nos van a exigir, aunque sea incorrecto (normalmente, es inútil discutir con un funcionario o político este tipo de cosas). Por tanto, en España, y hasta que no haya una nueva ley, lo que hay que aplicar es la Norma UNE 139803. Otro cosa es que no estemos "bajo el imperio de la ley": en ese caso, entre WCAG 1.0 y WCAG 2.0, mejor WCAG 2.0. Así, por lo menos nos olvidaremos de los puntos de control desfasados que comienzan con "Hasta que las aplicaciones de usuario permitan...".

Sin embargo, sí que tiene mucho sentido discutir si WCAG 1.0, WCAG 2.0 o la Norma UNE 139803 son el mejor camino o lo único que debemos de tener en cuenta para lograr la accesibilidad web.

Sobre este tema ya escribí hace un tiempo:

• ¿Las pautas de WCAG garantizan realmente la accesibilidad? (30/09/2009)
• ¿Las pautas de WCAG garantizan realmente la accesibilidad? (01/03/2010)

Cualquiera que desarrolle sitios web con el requisito de la accesibilidad, se habrá encontrado con situaciones en las que cumplir las pautas de accesibilidad existentes no sea la mejor elección. Y sin embargo, hay que hacerlo si se quiere lograr la conformidad y "demostrar" que el sitio web es accesible.

Sobre este tema hay dos buenos artículos que recomiendo:

• Beyond Conformance: The Role of Accessibility Evaluation Methods, de Giorgio Brajnik, publicado en el congreso WISE 2008.
• Evaluating Web Site Accessibility: Validating the WAI Guidelines through Usability Testing with Disabled Users, de Dagfinn Rømen y Dag Svanæs, publicado en NordiCHI 2008.

Mi consejo: las pautas y normas son un buen punto de inicio, pero no son lo único. Muchas veces, hay que aplicar el sentido común. Y en caso de duda, lo mejor es simular la posible situación conflictiva (por ejemplo, desactivar las imágenes de una página) o, mucho mejor, consultar a un usuario final que se pueda ver afectado.

Vocabularios reducidos para crear textos sencillos

La legibilidad de un texto es una característica que indica la dificultad de lectura y comprensión de un texto. Sobre el tema de la legibilidad de los textos he escrito varias veces:

• Legibilidad de una página web (13/12/2007)
• Legibilidad: facilidad de lectura y comprensión (14/10/2008)
• Más sobre legibilidad (facilidad de lectura y comprensión) (20/05/2009)

En la accesibilidad web, hay que tener en cuenta la legibilidad de los textos porque un texto complejo será difícil de comprender por la mayoría de las personas sordas y por las personas con algunos tipos de discapacidad cognitiva. Recordemos que las Pautas de Accesibilidad del Contenido en la Web 1.0 dicen en el punto de verificación 14.1 "Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio" (prioridad 1).

Está claro que en sitios web muy específicos (por ejemplo, en sitios web con información técnica o científica) no se puede evitar utilizar términos y construcciones gramaticales muy concretas, pero en sitios web de caracter general se puede emplear un vocabulario simplificado y sencillo que evite el uso de términos "rebuscados", con varios significados, poco utilizados, etc.

En inglés existen varios vocabularios reducidos o simplificados que se emplean en la enseñanza del inglés. Por ejemplo, para crear versiones simplificadas o adaptaciones (abridged versions) de libros famosos. Estos vocabularios también se pueden emplear para crear textos sencillos para todo el mundo y así cumplir con la pauta 14.1.

Un par de ejemplos de estos vocabularios para el inglés son:

• Voice of America Special English Word Book (lista en la Wikipedia), con aproximadamente 1.500 palabras (inglés americano) que se emplean en las emisiones con inglés simplificado. Esta lista se publica desde el año 1962 y cada año va cambiando, ya que la lengua es algo vivo.
• The Oxford 3000, con 3.000 palabras (inglés británico) que se emplean como base en numerosas obras de la editorial Oxford University Press.

¿Qué recursos similares existen para el español?

Visualización de las teclas de acceso rápido o atajos de teclado

Las teclas de acceso rápido o atajos de teclado son pulsaciones de varias teclas que permiten acceder directamente o ejecutar una opción de un programa. Por ejemplo, en Microsoft Word, la pulsación de Ctrl+N aplica el formato negrita o la pulsación de Alt+A permite acceder al menú archivo.

En este blog he escrito varias veces sobre este tema en el pasado:

• Las teclas de acceso rápido o atajos de teclado (5/1/2007)
• Las teclas de acceso rápido o atajos de teclado: ¿consenso? (6/1/2007)
• Ejemplo de uso de los atajos de teclado (21/11/2008)

En las Pautas de Accesibilidad al Contenido en la Web 1.0 del WAI, el punto de verificación 9.5 dice:

9.5 Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los mapas de imagen de cliente), los controles de formulario y los grupos de controles de formulario. [Prioridad 3]
Por ejemplo, en HTML, especifique los atajos a través del atributo "accesskey".

Desgraciadamente, el empleo de los atajos de teclado no está muy extendido y siempre ha habido gente a favor y en contra de su uso por los problemas que conlleva:

• El usuario no sabe si están definidos o no los atajos de teclado.
• El usuario no sabe qué teclas se han asignado a los atajos de teclado.
• Los atajos de teclado pueden causar conflicto con los atajos de teclado del navegador, con los del sistema operativo o con los del lector de pantallas.
• El usuario no sabe cómo activar los atajos de teclado (cambia de un navegador a otro y de un sistema operativo a otro).
• El usuario no puede pulsar las combinaciones de tecla de los atajos de teclado.

Acabo de descubrir que en el navegador Opera los dos primeros problemas están resueltos, como vamos a ver a continuación.

La página web de la Seguridad Social de España tiene definidos algunos atajos de teclado. Normalmente, en la página dedicada a la accesibilidad se suele incluir la lista de atajos de teclado de un sitio web, y así ocurre en la página sobre accesibilidad de la Seguridad Social:

En el navegador Opera la combinación de teclado Mays (Shift) + Esc muestra una ventana flotante en la que se listan los atajos de teclado que contiene la página:

Como podemos ver en la imagen anterior, en primer lugar aparece la tecla correspondiente al atajo de teclado y a continuación aparece la URL de destino del enlace, ya que en este caso los atajos de teclado están asociados a enlaces. Sin embargo, que aparezca la URL no es muy útil, ya que muchas veces la URL no es suficientemente significativa como para que el usuario sepa cuál es el destino del enlace.

He realizado una prueba: he creado una página web sencilla con una lista de enlaces y un formulario con varios controles. Tanto los enlaces como los controles del formulario tienen definido un atajo de teclado con el atributto accesskey. Además, he usado el atributo title para proporcionar información adicional sobre los enlaces o los controles. Como se puede ver en la siguiente imagen, cuando un enlace o un control tiene el atributo title definido, Opera lo emplea al mostrar la lista de atajos de teclado, por lo que se puede emplear para proporcionar información sobre el uso y finalidad de los atajos de teclado.

Por ahora, me parece que Opera es el único navegador que ofrece esta funcionalidad, ya que he consultado los atajos de teclado de Mozilla Firefox, y no aparece nada parecido.

Presentaciones y transcripción de Website Accessibility Metrics

El W3C, a través del WAI, organizó Website Accessibility Metrics Online Symposium el pasado 5 de diciembre de 2011. El objetivo principal de este simposio era reunir, analizar y discutir experiencias prácticas relacionadas con la medición de la accesibilidad web:

The primary objective of this symposium is to gather, analyze, and discuss practical experience with measuring website accessibility. These may include approaches for measuring 'accessibility in terms of conformance' (metrics that reflect violations of conformance of web content with accessibility guidelines such as WCAG or derivatives such as Section 508) and 'accessibility in use' (metrics that reflect the impact that accessibility issues have on real users, regardless of guidelines). The papers resulting from this symposium will constitute the basis from which to further explore a research and development roadmap for website accessibility metrics.

Se presentaron 11 artículos. Además de las transparencias de los artículos, también se ha publicado la transcripción de la teleconferencia que tuvo lugar.

Relacionado con este tema, el W3C mantiene el Benchmarking Web Accessibility Metrics, en el que se puede encontrar información sobre qué características debe tener una buena métrica.

El vídeo musical de las WCAG

Bueno, el vídeo WCAG 2.0 Theme Song Web Content Accessibility Guidelines - Disability es un poco "inclasificable", aunque si se ve con una mente abierta puede llegar a ser gracioso.

Lo más interesante del vídeo es que se pueden ver algunos usuarios con sus tecnologías de apoyo (ayudas técnicas).

El antes y después de un sitio web accesible

El W3C ha publicado el sitio web Before and After Demostration que muestra cómo un sitio web no accesible se puede convertir en accesible. El sitio web está compuesto por cinco páginas, y para cada una se incluye la versión no accesible y la versión accesible, junto con comentarios que explican los cambios realizados.

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.