La auditoría

El proceso de evaluación consta de cinco fases, definidas en la sección Evaluation Procedure de la WCAG-EM:

1. Definir el alcance de la evaluación.
2. Explorar el sitio web objetivo.
3. Seleccionar una muestra representativa.
4. Auditar la muestra seleccionada.
5. Reportar lo que se encontró.

Para facilitar el seguimiento de los pasos y la redacción del reporte final, usé la Herramienta de reportes de WCAG-EM, que es una aplicación web que se puede usar sin conexión a Internet y que permite guardar el progreso de la evaluación y exportar el reporte final.

Cada paso, si se usa la herramienta de reportes, explica con detalle qué hay que hacer y proporciona enlaces a técnicas de evaluación y de reconocimiento de fallas. Sin embargo, hay criterios que tuve que leer y releer para poder entenderlos —y otros no sé si los interpreté bien—.

De la fase 3 saqué una forma más precisa de determinar si un sitio web es pequeño o no:

Si es prácticamente posible hacerle una auditoría de accesibilidad a todas las páginas y contenido de un sitio web, entonces el sitio es pequeño.

Mi sitio tenía, para la versión evaluada, 503 páginas. Imposible evaluarlas todas. Así que tuve que seleccionar una muestra representativa, que resultó en 9 páginas para evaluar —correspondientes a un ejemplar de página por plantilla usada en el sitio y una página seleccionada aleatoriamente, por recomendación de la metodología de referencia—.

La fase 4 es la más difícil de todas por varias razones. Por un lado está la repetitividad del proceso y la carga mental que genera el cambio constante de herramientas de evaluación (ir de un navegador a otro, por ejemplo). Por el otro está la complejidad de la interfaz de la herramienta de reportes en este punto —aunque no se me ocurrió cómo se podría mejorar—.

Este no es un proceso lineal. De cada fase se puede sacar algo que alimenta a las demás, así que generalmente iba de fase en fase completando y aclarando información.

Resultados

El sitio no cumple completamente con los criterios del Nivel AA de accesibilidad —que es el nivel mínimo de accesibilidad que quiero para él—.

La evaluación indicó que la muestra de páginas seleccionada cumple en un 76% con los criterios de éxito del nivel intermedio de accesibilidad, Nivel AA, y en un 92% con los criterios de éxito del nivel básico de accesibilidad, Nivel A.

Los problemas de accesibilidad más comunes fueron el contraste insuficiente entre color de texto y color de fondo y la ausencia de por lo menos una manera alternativa para que los usuarios puedan encontrar las páginas del sitio (por ejemplo, proporcionar un mapa del sitio como complemento de la navegación principal).

En total, reporté 14 problemas de accesibilidad al sistema de seguimiento de tareas de mi sitio y 3 sugerencias, también para mejorar la accesibilidad.

Si le interesa, puede descargar el reporte formal y completo de la evaluación, que contiene detalles sobre los problemas reportados.

¿Cuánto me demoré?

Me demoré seis días (6 horas de trabajo por día) para terminar la auditoría completa, de los cuales dediqué más o menos cinco a la evaluación de la muestra (de nueve páginas en total).

Pero, repito, mi auditoría fue superficial. Por ejemplo, como tecnología base para la evaluación, solamente usé un navegador gráfico (Firefox) y uno de texto ( Lynx ).

Para una auditoría de accesibilidad más completa, la tecnología base debería incluir como mínimo:

• Un navegador web gráfico por motor de composición o de navegación ( Gecko , WebKit , EdgeHTML ), para confirmar que el sitio se ve y se comporta de manera similar en todos ellos.
• Un navegador web de texto como Lynx para revisar que la estructura de la información tenga sentido sin imágenes, CSS, ni JavaScript —pensando en los usuarios con discapacidad visual—.
• El lector de pantalla ORCA usado con uno de los navegadores gráficos compatibles ( GNOME Web o Firefox).

Con esta tecnología base, e incluyendo evaluación de estados de las páginas —por ejemplo, vistas adaptables según dispositivo (smartphone, tablet, computador de escritorio, etc.)—, el tiempo de evaluación de cada página aumentaría por lo menos el doble (una página por día, obviamente dependiendo de la complejidad de la página misma).

Nota sobre el software de evaluación de accesibilidad

Durante la fase 4 de la auditoría, que es donde se evalúa la accesibilidad de cada una de las páginas y otro tipo de contenido web de la muestra usando los criterios de las WCAG, uno puede usar software que le ayude a identificar rápidamente ciertos problemas. Por ejemplo, durante la evaluación yo usé dos herramientas:

• HTML CodeSniffer , para facilitar la identificación de errores de contraste, imágenes sin texto alternativo y otros problemas de accesibilidad detectables automáticamente.
• Validador de HTML del W3C con la opción «Show layout» activada para revisar si la jerarquía de encabezados tendría sentido para personas invidentes.

Sin embargo, hay que tener en cuenta que estas herramientas no pueden afirmar si un sitio o cualquiera de sus páginas o recursos web cumplen con un nivel específico de accesibilidad (Nivel A, Nivel AA o Nivel AAA) —cosa que descubre uno mismo en la práctica cuando hace la auditoría—. El documento de la WCAG-EM enfatiza que el cumplimiento de un nivel específico de WCAG 2.0 no lo puede determinar completamente un programa de manera automática. Esta metodología está diseñada para ser desarrollada por seres humanos y el software que se use en el proceso es solamente una herramienta de asistencia. [1] [2]

Es decir, cuando uno ejecuta HTML CodeSniffer sobre una página y ve que no salen errores, no se puede concluir que la página es accesible.