Presentación

Desde el desarrollo hasta la auditoría

• El proceso completo de evaluación lleva desde la revisión durante el desarrollo hasta la auditoría formal.
• El alcance y metodología utilizados en cada una de las etapas de evaluación difieren considerablemnete y dependen en gran medida de los recursos disponibles.

Necesidades

• Durante el desarrollo
  • Equipo de evaluación
  • Herramientas de revisión
• Tras el desarrollo
  • Responsable de accesibilidad
  • Herramientas de monitorización

Durante el desarrollo

• Objetivos de conformidad claros
• Planificación de la periodicidad de las revisiones
• Puede ser hecha por el propio desarrollador, actuando como experto.
• Puede ser hecha por equipos internos o externos
• Debe contarse con un buen juego de herramientas y ayudas técnicas
• Debe contarse con la ayuda de familiares y amigos.

Revisión preliminar

Elegir la muestra

Lo primero que hemos de hacer es elegir la muestra. Elegiremos páginas representativas de distintos tipos de contenido y de especial interés para los usuarios futuros:

• La página principal (home)
• La página de "contacto", especialmente si contiene un formulario y/o cualquier otra página que contenga un formulario, como por ejemplo una página para solicitar un documento, una página para hacerse socio o indicar datos personales y facturación.
• La página de resultados de una búsqueda y el formulario de búsqueda en sí mismo.
• Una página que contenga una tabla
• Cualquier página que contenga gráficas o diagramas, si la hay.
• Páginas que contengan scripts o aplicaciones que proporcionen determinada funcionalidad.

Elegir la muestra (II)

Cuando el contenido se genera dinámicamente

En este caso, además de revisar el contenido generado hemos de revisar las plantillas que proporcionan elementos comunes a todas las páginas.

Evaluar tanto el código de la plantilla como un ejemplo del contenido generado

Si las plantillas o el contenido final se generan mediante una herramienta de autoría, deberemos revisar dicha herramienta en cuanto a su cumplimiento de las "Authoring Tool Accessibility Guidelines (ATAG)"

Y con el fin de evitar errores repetitivos debidos a fallos en el gestor de contenidos que estemos usando, deberemos evaluar éste en cuanto a su conformidad con las ATAG, prestando especial atención a si:

• ¿Facilita la creación de alternativas textuales (alt) al incluir una imagen y, cuando es necesario, del longdesc?
• ¿Al generar tablas de datos se generan igualmente los elementos y atributos que facilitan su accesibilidad (Por ejemplo, el elemento caption, y los atributos id y headers en las celdas de encabezado y sus respectivas celdas asociadas)?
• ¿Si se genera vídeo, se facilita un modo de generar también los subtítulos?
• ¿Si se generan ficheros sonoros que contienen habla, se generan igualmente sus equivalentes textuales?
• ¿Valida la sintaxis del código fuente del contenido generado?

Revisar con varios navegadores gráficos

El siguiente paso será comprobar cómo se presentan los contenidos en diferentes navegadores y con diferentes configuraciones de éstos y del sistema operativo:

• Firefox
• Internet Explorer
• Opera
• Safari
• Chrome
• Otros ...

Las siguientes comprobaciones pueden llevarse a cabo modificando la configuración de los navegadores o mediante extensiones que facilitan llevar a cabo algunas de ellas:

• Web developer extension (para Firefox o Chrome)
• Web accessibility toolbar (Para Internet Explorer u Opera)

Llevaremos a cabo las siguientes comprobaciones:

• Deshabilitar las imágenes y verificar si existe un texto equivalente adecuado para ellas.
• Apagar los altavoces o poner en "off" su volumen, y comprobar si existe una alternativa textual para cualquier elemento sonoro existente.
• Ampliar el tamaño de los textos mediante las opciones del navegador, al menos un 200%, y comprobar si los textos se amplían y si las páginas siguen siendo usables a pesar de la ampliación.
• Cambiar la resolución de pantalla y/o la resolución del navegador, para comprobar que ni en la mínima ni en la máxima se generan barras de desplazamiento lateral (horizontal scrolling). Esto debe hacerse con varios navegadores o comprobando el código fuente para determinar si hay definiciones de tamaños de contenedores o fuentes en unidades de medida absoluta, para estar seguros de que el fallo no se debe a un determinado navegador.
• Configurar el sistema operativo para presentar los contenidos en escala de grises, o imprimir la página en una impresora en blanco y negro. Comprobar entonces si hay elementos que queden poco identificables o desvanecidos.
• Navegar por el sitio sólo con el teclado. Fijándose en que todos los enlaces y controles de formulario reciban el foco en el orden adecuado y en si los enlaces indican claramente a dónde llevarán al usuario.
• Examinar las páginas sin la carga de scripts, hojas de estilos y objetos, para determinar si siguen siendo comprensibles y navegables.

Revisar con navegadores especiales

Debemos revisar también la experiencia que obtendrán usuarios que dependen de escuchar las páginas o que las percibirán línea a línea. Para ello deberemos revisar la muestra con:

• Un navegador con conversión a voz o una extensión que permita leer el contenido de las páginas. Podemos usar Opera con su opción de voz activada, o podemos instalar una extensión como "Text 2 voice"
• Un navegador sólo texto, como Lynx.

Con ellos deberemos repasar la muestra para fijarnos en si:

1. ¿La información recibida a través de la conversión a voz y de la linearización de la página de los equivalentes alternativos, se ajusta a la información transmitida mediante los elementos de la interfaz gráfica?.
2. ¿Están disponibles las mismas funcionalidades?
3. ¿Tiene sentido el orden de lectura cuando se hace línea a línea?.

Revisar con herramientas de revisión automática

Nota: Cuando el desarrollador ha conseguido una buena experiencia en la revisión de la accesibilidad, puede seguir este procedimiento a la inversa, o mejor dicho de forma combinada, porque sabrá y recordará qué criterios hacen referencia a los distintos aspectos que han de evaluarse manualmente mediante los procedimientos citados y, por tanto, podrá hacer todo a la vez, en vez de secuencialmente y en este orden.

¡Nunca publicar sin antes revisar!

Por muy experto que se considere un desarrollador, no debe sucumbir a la tentación de publicar una página sin haberla revisado antes. Todos, incluso el más experto de los expertos, podemos cometer errores involuntarios, por tanto, debemos revisar siempre antes de publicar.

Cuando se proporcionan herramientas de autoría que quedarán al alcance de personal, cualificado o no, que tendrá la responsabilidad de generar o actualizar contenidos:

• Hemos de proporcionales medios que les permitan revisar antes de publicar.

En caso de que no podamos proporcionar ninguna de dichas herramientas:

• Deberemos al menos proporcionar un manual de actualización en el que se indiquen los pasos a seguir, las comprobaciones requeridas, antes de publicar ningún contenido.

Evaluación de la conformidad

Para llevar a cabo la evaluación de conformidad, es preferible contar con un equipo de personas, que han de estar supervisadas por un experto en accesibilidad. Pero para llamarse "experto" en cualquier campo, una persona ha de haber dedicado al menos 10 años de su vida a dicho campo y, por tanto, no es sencillo encontrar expertos en accesibilidad. Y no siempre es posible contar con un equipo multidisciplinar para llevar a cabo los distintos tipos de evaluaciones necesarios. Es por ello que, en la mayoría de los casos, habremos de conformarnos con contar con una persona que al menos sea conocedora de:

• Lenguajes de marcado y herramientas de revisión de la sintaxis
• Directrices de Accesibilidad y sus técnicas de aplicación
• Procesos de evaluación de la conformidad
• Herramientas de revisión de la accesibilidad
• Uso de Ayudas Técnicas y de estrategias de adaptación
• Desarrollo y diseño de sitios web

Niels Bohr: «Expert is: A person that has made every possible mistake within his or her field.»

Muestra para la evaluación de la conformidad

La muestra será más amplia que la muestra de una revisión preliminar, y deberá contener, además de las páginas ahí incluidas:

• el mapa del sitio,
• la página de información sobre accesibilidad,
• páginas de distintos niveles,
• páginas que tengan diferente aspecto dentro del sitio,
• y aquellas que resulten cruciales para los intereses de la entidad o negocio, como por ejemplo las páginas de transacciones o elección de productos.

La evaluación manual

Limitaciones de la evaluación con usuarios

Debemos considerar cuidadosamente todas las respuestas y comentarios de los usuarios, y evitar pensar que pueden ser aplicados a todas las personas con discapacidad.

Una persona no experta no tiene por qué saber cómo interactúan otros usuarios con la web ni tienen los suficientes conocimientos para orientar sobre todos los problemas de accesibilidad.

La participación de usuarios con discapacidad en la evaluación tiene muchos beneficios, sin embargo, por sí sola no puede determinar si un sitio es accesible.

Debemos combinar la participación de los usuarios con la evaluación formal de la conformidad con las WCAG para asegurar el mayor grado de accesibilidad de un sitio.

El informe de accesibilidad

La siguiente es una lista con la información sugerida en las WCAG 2.0 para incluir en un informe sobre la accesibilidad de un sitio:

1. Información del sitio
   • Nombre del sitio
   • URL de base del sitio
   • Lista de las URL incluidas en la revisión
     • Si es un sitio generado dinámicamente, proporcionar capturas de pantalla para demostrar lo que se revisó
     • Indicar las páginas revisadas manualmente y las que se revisaron con herramientas automáticas
   • Lista de las URL excluidas de la revisión
   • Fecha exacta o rango de fechas en las que se realizaron las revisiones
   • Idioma del sitio
2. Equipo revisor (en caso de que no sean anónimos)
   • Nombre de los revisores
   • Organización a la que pertenecen los revisores
   • Información de contacto de los revisores
   • Área de experiencia de los revisores
   • Idioma de los revisores
3. Proceso de revisión
   • Identificar el nivel y la versión de las WCAG usada como referencia (por ejemplo, nivel Doble A de las WCAG 2.0)
   • Identificar las herramientas de evaluación y validación usadas, indicando las versiones
   • Descripción de los métodos de revisión manual usados
4. Resultados y recomendaciones
   • Resumen interpretado de los resultados de la revisión
     • Ejemplo: este sitio parece [cumplir | no cumplir | está cerca de alcanzar] el nivel Doble A de las WCAG 2.0
     • Lista de prioridades para solucionar los problemas de accesibilidad
   • Detalle de los resultados, estructurados de acuerdo a los criterios de conformidad de las WCAG 2.0
     • Incluir enlaces a los criterios y técnicas para todos los puntos no conformes
     • Enlazar los informes de las revisiones incluidos en los apéndices
   • Describir un programa sugerido de supervisión continua de la accesibilidad, reevaluación de las herramientas de autor, etcétera
5. Referencias
   • Enlaces a toda la documentación relacionada con las WCAG 2.0 usada como referencia
6. Apéndices
   • Adjuntar todos los informes detallados de los validadores y herramientas de revisión

La auditoría de accesibilidad

A pesar de los años transcurridos y de los avances en tecnologías, las necesidades instrumentales y humanos para la auditoría de la accesibilidad siguen siendo las mismas apuntadas en:

• Requisitos para la auditoría de la accesibiliad

Esa ponencia se hizo para las VIII Jornadas Sidar, celebradas en Buenos Aires, del 24 al 26 de noviembre de 2004.

Accessibility is right not a privilege!

William Loughborugh
In memorian

¡Gracias por vuestra atención!

Emmanuelle Gutiérrez y Restrepo
emmanuelle@sidar.org