Opera 26: Auditorías de accesibilidad

De vez en cuando es importante profundizar en temas que crees que tienes más que “trillados”. Normalmente siempre encuentras o refrescas cosas interesantes.

Ese ha sido el caso al leer el artículo de Ópera 26: Accessibility testing disponible  en la web de Ópera Web Standards Curriculum.

En ellas descubres que la petrolera Shell tiene el compromiso de hacer todos sus sitios accesibles AA (como mínimo) y que la BBC tiene un “Guía de actuación ante la accesibilidad” documento que muchas empresas no dejan por escrito y mucho menos publican.

Otra recomendación aparecida en el artículo y que considero valiente es la de basar nuestro proyecto de accesibilidad en las WCAG 2.0 que aunque son una recomendación, tratan también las formas de atacar los problemas de accesibilidad, están actualizadas a los últimos elementos multimedia, son compatibles con las WCAG 1.0 y son el FUTURO.

En el artículo se habla de dos puntos desde los que se debe realizar una auditoría:

  • Mediante tests de usuario, al que le dedicaremos otro post.
  • Mediante tests realizados por expertos. A estos yo los llamaría auditorías de accesibilidad.

Los tests o auditorías de accesibilidad

Lo primero, además de conocer profundamente las diferentes normativas y estándares, debemos llevar la accesibilidad al lado de los usuarios. Es decir, debemos trabajar no sólo por cumplir los estándares, sino por conseguir que todos los usuarios puedan acceder a nuestra información.

Por ello es importante aplicar correctamente la normativa, por ejemplo. La norma habla sobre que todas las imágenes deben llevar texto alternativo, pero con la práctica se sabe que es un error ponérselo, por ejemplo, a las imágenes decorativas.

Un experto tiene principalmente 5 formas de realizar una auditoría de accesibilidad:

  1. Guiada por herramientas: tanto aquellas que revisan accesibilidad (TAW, TruWex, HERA, Cynthia Says, ATRC Web Accessibility Checker [no disponible desde 2016], aDesigner de IBM) como las que revisan código (xhtml validator, css validator)
  2. Revisión en pantalla: emular a un usuario e identificando los posibles problemas de accesibilidad. Por ejemplo colores, tamaños de fuente, imágenes, orden de tabulaciones… Para mi una herramienta muy interesante es la combinación Firefox + Web Developer + No-Script
  3. Revisión basada en herramientas: son aquellos que una aplicación analiza capa a capa nuestro sitio. un buen ejemplo es la aplicación instalable del TAW
  4. Revisión del código: al final siempre es necesaria la revisión manual del código. Mediante una léctura rápida nos permiten Se detectan siempre errores o “trucos”.
  5. Otros análisis como por ejemplo uso de dispositivos de navegación alternativos (teléfonos móviles, navegadores no mayoritarios y en modo texto, visualizar el contenido impreso en blanco y negro)

[2016-09] Interesante la guía How to Make Websites User Friendly and Accessible for Everybody

Bruno Rico Autor

Marketing, posicionamiento, diseño,accesibilidad, fotografía, internet...y un toque de banca (por de-formación profesional)

Deja un comentario

Tu dirección de correo electrónico no será publicada.