Auditoria de la accesibilidad web de las Naciones Unidas

Según las Naciones Unidas, Global Audit of Web Accessibility fue la primera auditoria de este tipo y fue realizada en el año 2006. El resumen dice:

The United Nations contracted Nomensa to conduct this audit on Internet accessibility for persons with disabilities. The audit, the first of its kind, investigated the accessibility of 100 leading websites from 20 countries from around the world.

The aim of the survey, which was not intended to be exhaustive, was to obtain an indication concerning the existing status of accessibility of websites that people with disabilities might access as part of their daily lives.

This snapshot produced stark results: most of the leading websites around the world do not meet international standards for accessibility. Some of the sites investigated could be easily upgraded to remove the obstacles that prevent many people with disabilities from using the sites. However, the majority of sites need considerable work.

Los sitios web analizados en España fueron:

Transporte: http://www.iberia.com/OneToOne/v3/Home.do
Finanzas: http://www.bbva.es/TLBS/tlbs/jsp/esp/home/index.jsp?rf=
Medios de comunicación: http://www.elpais.es/
Política: http://www.la-moncloa.es/default.htm
Comercio: http://www.elcorteingles.es/

¿Los resultados? El sitio web de La Moncloa se salvó y alcanzó el nivel A de WCAG 1.0. El resto, al hoyo.

Herramientas de validación

Algunas herramientas online que permiten la validación de páginas web:

• W3C Markup Validation Service: el oficial del W3C, el de toda la vida.
• W3C Nu Markup Validation Service: un validador no basado en DTD como el oficial del W3C.
• Validator.nu: el validador original que sirve de motor del anterior.
• Nu Markup Validation Service Bookmarklets: un bookmarklet para el navegador que permite utilizar Validator.nu desde cualquier página que se esté visualizando.

Y un par de herramientas de validación que se han quedado un poco antiguas, pero que ofrecen algunas características interesantes:

• Validome
• WDG HTML Validator

Los captchas han muerto

Los captchas son esas imágenes con letras y números que debemos descifrar en muchos sitios web para que "nos dejen pasar".

En Así funcionan los bots que adivinan los «captchas» nos explican que los captchas ya no son tan efectivos como podríamos pensar. En realidad, viendo el vídeo que acompaña a este artículo, me parece que los bots que resuelven captchas "son más humanos" que los humanos.

Cómo funcionan los lectores de pantalla

Los lectores de pantalla (screen readers) son difíciles de usar por varias razones. Una de ellas es que los lectores de pantalla tienen diferentes modos de funcionamiento. En el artículo How Windows Screen Readers Work on the Web se explican las dos formas principales de funcionamiento:

Modo documento
También llamado modo "virtual" o "browse". En este modo, el usuario no interactúa directamente con la página, sino con una copia cacheada por el lector de pantallas.

La interacción con el teclado es capturada y no se pasa directamente a la página web.

Este modo puede plantear problemas cuando se programa una funcionalidad asociada al teclado.

También plantea problemas el contenido dinámico, ya que los cambios pueden pasar desapercibidos para el lector de pantallas.

Modo aplicación
También llamado modo "form" o "focus".

Es el utilizado para interactuar con un formulario. Las pulsaciones de teclado son pasadas directamente a la página web, lo que permite utilizar los controles de un formulario.

Mitos sobre la accesibilidad web

Alguna vez he escrito sobre los mitos erróneos que existen alrededor de la accesibilidad web. En Internet se pueden encontrar muchos artículos sobre ello:

• Myths of Web Accessibility
• Web accessibility myths 2011 – a call for accessibility advocates to be more business-minded
• Web Accessibility Myths 2011 part 2
• 7 web accessibility myths
• Web accessibility myths

Mejorar la legibilidad

La legibilidad es un indicador de calidad que se refiere a la facilidad de lectura y comprensión de un texto. Que un texto sea legible ayuda a hacer el contenido de un sitio más fácil de leer para todos y en especial para las personas con discapacidades para la lectura y/o cognitivas.

Una buena legibilidad mejora la accesibilidad de una página web, en especial de cara a los usuarios con problemas cognitivos.

Existen herramientas que permiten evaluar la legibilidad de los textos. Hace unos días me topé con dos recursos que se pueden aplicar a la legibilidad.

Por un lado, style-check es una herramienta que ayuda a mejorar los textos científicos. Básicamente, detecta aquello que es redundante o aquello que en realidad no dice nada (si se usase esta herramienta con los discursos de los políticos, se quedarían mudos).

Por otro lado, el artículo Make your research papers easy to skim ofrece unos sencillos consejos para que los artículos científicos sean fáciles de ojear. Lo que se dice ahí se puede aplicar también a las páginas web.

La usabilidad

Me ha sorprendido encontrar en el Manual de estilo para nuevos medios de Fundéu un artículo dedicado a la usabilidad, ya que la palabra "usabilidad" no aparece en el diccionario de la RAE: Usabilidad en el diseño.

En este artículo, la usabilidad se define como:

La usabilidad es la disciplina que trata de estudiar, analizar y crear sistemas de fácil aprendizaje y utilización. Sus principales objetivos en relación con el desarrollo de aplicaciones multimedia (software) son:

• La eficiencia para cumplir adecuadamente la función asignada o deseada en la aplicación.
• La efectividad de la interfaz, de la aplicación o del sistema para conseguir un efecto deseado.
• La sensación de seguridad del usuario con respecto a sus errores y a la capacidad de repararlos.
• La utilidad, que satisfaga las necesidades humanas.
• La facilidad de aprendizaje del sistema.

¿Las páginas tienen que ser válidas para ser accesibles?

Validar o no validar, e ahí la cuestión...

En WCAG 1.0, la pauta 3 "Utilice marcadores y hojas de estilo y hágalo apropiadamente" decía:

3.2 Cree documentos que estén validados por las gramáticas formales publicadas. [Prioridad 2]

Está claro que para cumplir WCAG 1.0, las páginas web tenían que ser válidas.

Sin embargo, en WCAG 2.0 hay un poco de confusión. La pauta 4 "Robusto" dice en su único punto 4.1 Maximizar la compatibilidad con las aplicaciones de usuario actuales y futuras, incluyendo las ayudas técnicas:

4.1.1 Procesamiento: En los contenidos implementados mediante el uso de lenguajes de marcas, los elementos tienen las etiquetas de apertura y cierre completas; los elementos están anidados de acuerdo a sus especificaciones; los elementos no contienen atributos duplicados y los ID son únicos, excepto cuando las especificaciones permitan estas características. (Nivel A) 

Nota: Las etiquetas de apertura y cierre a las que les falte un carácter crítico para su formación, como un signo de "mayor qué", o en las que falten las comillas de apertura o cierre en el valor de un atributo, no se consideran completas.

Y si se consulta Cómo cumplir 4.1.1, la técnica G134 Validating Web pages hace referencia explícita a la validación de HTML y CSS.

Por tanto, sí que las páginas tienen que seguir siendo válidas para poder cumplir con WCAG 2.0. Y hay varios expertos que confirman la importancia de validar el código:

• Parsing - clean code means a website your customers can use
• WCAG 2.0 parsing error bookmarklet

Sin embargo, hay algunos autores que no piensan los mismo. Por ejemplo, en el artículo WCAG Next pone:

Remove Parsing Requirement
While the intentions are noble, SC 4.1.1 (Level A), which requires that significant coding validation errors be avoided, has little impact on end-user accessibility and is next to impossible to evaluate. The areas in which coding errors impact accessibility are already sufficiently covered by other success criteria (such as proper form labeling, frame titles, table headers, etc.). I can’t think of a single instance where a significant coding issue would impact assistive technology specifically. The parsing requirement should be removed or perhaps changed to require strict validation at Level AAA.

Para terminar, unos vídeos en los que explico la importancia de validar las páginas web:

Código para crear un mega menú accesible

Los mega menús son menús de tipo desplegable o drop down con decenas o cientos de opciones. En la página 25 Examples of Mega Menus in Web Design.

Estos menús plantean un reto, tanto desde el punto de vista de la usabilidad y la accesibilidad.

Adobe liberó hace unos meses el código que utiliza en sus mega menús: Open-source accessible mega menus. En la página Accessible Mega Menu se describe cómo está hecho y se muestra una demostración.

¿WCAG es la "biblia" de la accesibilidad?

Siguiendo con lo que se comentó en mi entrada anterior Más allá del cumplimiento de WCAG, ¿qué es lo que dice el W3C al respecto?

Lo podemos leer en la introducción de WCAG 2.0:

Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.

[...]

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.

Es lo que hay... pero por lo menos tenemos esto. Mucho mejor es tener WCAG, aunque no sean perfectas, que no tener nada.

Cómo mejorar la accesibilidad web para las personas con discapacidad cognitiva o intelectual

En la accesibilidad web, la discapacidad cognitiva e intelectual (¿son lo mismo?, hasta la propia definición no está muy clara) es la que menos se estudia y se trata. Hasta el propio W3C lo deja claro en la introducción de WCAG 2.0:

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas.

En este blog creo que sólo tengo un par de entradas en las que proporciono consejos para mejorar la accesibilidad web para las personas con discapacidad cognitiva o intelectual:

• Seis consejos para mejorar la accesibilidad para las personas con dislexia (24/04/2011)
• Cómo mejorar la accesibilidad para las personas con problemas cognitivos (26/09/2012)

Por eso, encontrar un artículo que proporcione consejos se agradece mucho.

En el artículo An Accessibility Frontier: Cognitive disabilities and learning difficulties se ofrecen muchos consejos que se agrupan en tres temas:

• Cómo se puede modificar la presentación del contenido web para que sea más accesible.
• El diseño de los sistemas de navegación en un sitio web.
• Adaptación de los contenidos a las necesidades de los diferentes tipos de audiencia.

La accesibilidad es buena para Ontario

Una infografía publicada en Understanding accessibility:

También existe la vesión sólo texto de esta infografía.

Cómo hacer un cuadro de diálogo modal accesible

Imprescindible el artículo The Incredible Accessible Modal Dialog, que explica cómo hacer un cuadro de diálogo modal accesible que tenga en cuenta a los usuarios que utilizan el ordenador con teclado o a los usuarios ciegos (que también lo usan con el teclado, pero que presentan otras consideraciones propias).

La idea general de esta solución es:

• The first focusable item in the modal dialog should receive the keyboard focus.
• The window behind the modal dialog should not be allowed to be clicked on
• The modal dialog must trap the keyboard focus inside the modal dialog so the user can’t accidentally interact with the window behind the modal dialog.
  • When the user is on the last focusable item and presses Tab, the user should be taken to the first focusable item in the modal dialog.
  • When the user is on the first focusable item and presses Shift-Tab, the user should be taken to the last focusable item in the modal dialog.
• The position of the keyboard focus before the modal window opens must be saved, and the focus must be restored to this location after the modal dialog closes.

Párrafos correctos

Algo tan simple como la etiqueta "p" de párrafo se puede usar de forma incorrecta y puede acabar originando problemas de usabilidad y accesibilidad.

En el artículo Use the p element to create paragraphs nos explican las ventajas de crear párrafos que son realmente párrafos y no usar la etiqueta "br" para separar el texto:

• Hace más fácil controlar los márgenes de los párrafos con CSS.
• Permite a los usuarios de lectores de pantallas y otros productos de apoyo "ojear" un documento saltando de un párrafo a otro párrafo.
• Describe semánticamente el texto como lo que es, un párrafo.

Además, en las recomendaciones de HTML del W3C podemos encontrar lo siguiente:

• HTML4: 9.3.1 Paragraphs: the p element: no uses párrafos vacíos para separar el contenido.
• HTML5: 4.5.1 The p element: no uses el elemento p cuando exista uno más específico (por ejemplo, address), un párrafo no puede contener una lista.

Contenido dinámico accesible

Mañana sábado 19 de octubre, en el marco de Codemotion, el gran Ramón Corominas dará la charla Contenido dinámico accesible: Yes we can!

La descripción de la charla es:

Desde simples menús desplegables, pasando por carruseles, lightboxes... a bloques de información actualizada mediante AJAX; muchos de estos contenidos pueden provocar graves barreras de accesibilidad que deben tenerse en cuenta para no dejar fuera a nadie.

Contenido:

1. Lectores de pantalla y buffer virtual
2. Casos típicos y sus problemas
3. Posibles soluciones accesibles

Adiós a useit.com

Acabo de descubrir que useit.com, el sito web de Jakob Nielsen, el famoso gurú de la usabilidad, desapareció el 31 de diciembre de 2012.

Este sitio web estuvo en funcionamiento 18 años, y fue bastante criticado ya que su aspecto no ayudaba a su usabilidad... Hasta el periódico The Guardian se hizo eco de ello en el año 2007: The web design guru that web designers love to hate.

En realidad no ha desaparecido, se ha integrado en el sitio web de su empresa, Nielsen Norman Group:

Tampoco es una maravilla del diseño, pero mejorar sí que ha mejorado.

Por cierto, los artículos no se han perdido, los podemos encontrar en Articles.

Y si quieres saber las razones de este cambio, en Alertbox Columns Moved From Useit.com to NNgroup.com las explican.

Evaluación de la accesibilidad web

Aunque un poco viejo, es de abril de 2006, el artículo Evaluating website accessibility sigue siendo muy interesante.

Dividido en tres partes, explica paso a paso cómo realizar la accesibilidad de un sitio web. para ello, propone el uso de diversas herramientas, como programas para verificar que el contraste de color es suficiente o Fangs para simular la navegación mediante un lector de pantallas.

Día Mundial de la Vista

El 10 de octubre es el Día Mundial de la Vista. La siguiente infografía creada por la Secretaría de Salud de México nos recuerda algunos datos importantes sobre los problemas relacionados con la vista:

Artículos sobre la accesibilidad web para las personas mayores

Está página ya tiene unos años, es del año 2008, pero contiene material muy interesante: Web Accessibility for Older Users: A Literature Review.

Entrevista a una persona sordociega

Hace un par de meses publiqué unos vídeos de una entrevista que realicé a Santi Trigueros, una persona sordociega. A continuación incluyo los tres vídeos que forman la entrevista (los vídeos incluyen subtítulos), junto con un enlace a la publicación original en la que se puede encontrar la transcripción del audio de cada vídeo:

Entrevista a una persona sordociega (parte 1)

Entrevista a una persona sordociega (parte 2)

Entrevista a una persona sordociega (parte 3)