Itákora

Aunque parezca mentira, la accesibilidad en la web va más allá de las WCAG. También están las pautas para aplicaciones (user agent) y para herramientas de autor (authoring tools), entre otras. Lo que a continuación sigue es un traducción y resumen de las pautas de Authoring Tools . El original y oficial está en http://www.w3.org/TR/ATAG10/.

Pauta 1. Soportar la creación de contenidos accesibles.
Puntos de comprobación:
1.1 Asegurar que el autor pueda producir el contenido accesible en los diferentes lenguajes de código que soporte la herramienta. [Prioridad 1]
1.2 Asegurar que la herramienta conserva toda la información accesible durante la creación, transformación y conversión. [Prioridad 1]
1.3 Asegurar que, cuando la herramienta genera automáticamente código, éste se conforma con las pautas WCAG 1.0. [Prioridad relativa a lo que pidan las WCAG]
1.4 Asegurar que las plantillas proporcionadas por la herramienta se conforman con las pautas WCAG 1.0. [Prioridad relativa a lo que pidan las WCAG]

Pauta 2. Generar el código estándar válido.
Puntos de comprobación:
2.1 Utilizar las versiones más recientes de las recomendaciones de W3C cuando estén disponibles y apropiadas para una tarea. [Prioridad 2]
2.2 Asegurar que la herramienta genere automáticamente código válido. [Prioridad 1]
2.3 Si el código producido por la herramienta no se conforma con las especificaciones de W3C, informar al autor. [Prioridad 3]

Pauta 3. Apoyar la creación del contenido accesible.
Puntos de comprobación:
3.1 Invitar (Obligar) al autor proporcionar la información alternativa equivalente (e.g., subtítulos, descripciones auditivas, y transcripciones compaginadas del texto para el vídeo). [Prioridad relativa a lo que pidan las WCAG para ese elemento introducido]
3.2 Ayudar al autor a crear el contenido estructurado y a separar la información de la presentación. [Prioridad relativa a lo que pidan las WCAG]
3.3 Asegurar que el contenido generado se conforme con las pautas WCAG. [Prioridad relativa a lo que pidan las WCAG]
3.4 No generar automáticamente las alternativas equivalentes. No reutilizar las alternativas previamente creadas sin la confirmación del autor, excepto cuando la función se sabe con certeza. [Prioridad 1].
3.5 Proporcionar la funcionalidad para editar, corregir, y reusar los equivalentes alternativos para los objetos multimedias. [Prioridad 3]

Pauta 4. Proporcionar las maneras de comprobar y de corregir el contenido inaccesible.
Puntos de comprobación:
4.1 Comprobar e informar al autor de los problemas de la accesibilidad detectados. [Prioridad relativa]
4.2 Ayudar a los autores a corregir los problemas de la accesibilidad. [Prioridad relativa]
4.3 Permitir que el autor conserve el código no reconocido por la herramienta. [Prioridad 2]
4.4 Dar al autor un resumen del estado de la accesibilidad del documento. [Prioridad 3]
4.5 Permitir que el autor transforme un mal código a un código accesible. [Prioridad 3]

Pauta 5. Integrar las soluciones de la accesibilidad en el estilo de interacción de la herramienta.
Puntos de comprobación:
5.1 Asegurar que la introducción de contenido accesible esté integrada naturalmente en el estilo de interacción de la herramienta. [Prioridad 2]
5.2 Asegurar que el autor sienta que está generando contenido accesible de forma sencilla. [Prioridad 2]

Pauta 6. Promover la accesibilidad en la ayuda y la documentación.
Puntos de comprobación:
6.1 Documentar todas las características que promuevan la generación del contenido accesible. [Prioridad 1]
6.2 Asegurar que crea el contenido accesible es una parte integrada de forma natural dentro de la documentación, incluyendo ejemplos. [Prioridad 2]
6.3 En una sección dedicada, documentar todas las características de la herramienta que promuevan la producción del contenido accesible. [Prioridad 3]

Pauta 7. Asegurar que la herramienta de autor sea accesible a los autores con discapacidades.
Puntos de comprobación:
7.1 Utilizar todos los estándares y convenciones del sistema en el que se ejecuta.
En nuestro caso, como se ejecuta en la web, las pautas de WCAG
7.2 Permitir que el autor edite dentro de la vista de presentación sin afectar al código. [Prioridad 1]
7.3 Permitir que el autor corrija todas las características de cada elemento y objeto en una manera accesible. [Prioridad 1]
7.4 Asegurar que la vista de presentación permita la navegación a través de la estructura del documento de una manera accesible. [Prioridad 1]
7.5 Permitir corregir de la estructura del documento de una manera accesible. [Prioridad 2]
7.6 Permitir que el autor busque dentro del contenido dentro de la vista de presentación. [Prioridad 2]

Es un hecho conocido que, dentro de la interacción hombre-máquina, cuanto menos inseguridades genere la máquina en el humano, mejor uso de ésta se hará. Todo esto viene a cuento de que, cuando ves un manual de instrucciones en el que la mitad de las palabras están mal escritas, lo primero que se te pasa por la mente es ’si así de mal han hecho el manual, habrá que ver cómo habrán hecho la máquina’. Ahora que levante la mano el que no se haya topado con una experiencia semejante.

Dentro de las auditorías de accesibilidad que realizo, una de las cosas en las que siempre ‘crujo’ es en la redacción y ortografía. Aunque pillado un poco por los pelos, me escudo en la pauta 14.1. Es que no cuesta nada cerciorarse si tienes dudas, caramba. Que no se está pidiendo un nivel de Premio Cervantes, sólo que esté bien escrito y que quede claro, para que la persona que lo use no diga ‘¡vaya chapuceros!’

La W3C lleva dos años organizando el congreso de Fundamentos Web en Asturias, entre Noviembre y Octubre. He asistido a los dos y, en general, me han gustado bastante. Sin embargo, me llegó el otro día un aviso de que van a organizar otro, en Zaragoza y en septiembre, de Web Movil, ésta vez abierto a la participación del mundo empresarial y educativo.

Probablemente tenga que elegir entre uno y otro (mi presupuesto y mis días de vacaciones son limitados). Esperaremos a que salga el programa del primero y segundo para decidir.