¡A mover el esqueleto!
¡Qué buena la discusión entre el cantante y ‘Sharky’ al final!
Uno de los pequeños quebraderos de cabeza que traen el baile de pautas dependiendo de la normativa en la que nos encontremos es que no podemos utilizar las herramientas de validación con la misma alegría que antes. Como Vaga BuenaTM, me he creado mi propia normativa UNE 139803 para aplicarla al programa de validación automático PISTA.
Para la versión 2.0 del archivo le pondremos la correspondencia de la numeración de las pautas con la norma. Si alguien se anima, por favor, que me avise para actualizar el post.
Como sabéis, la legislación española referente a accesibilidad opta por dar validez a Una Norma Española (UNE) 139803/2004 frente a las pautas internacionales WCAG 1.0.
A estas alturas no descubro nada nuevo cuando digo que la norma UNE es exactamente lo mismo que las WCAG 1 pero con el orden y las prioridades cambiadas. Para los revisores de accesibilidad, la vida se complica un poquito, sobre todo por el baile en las prioridades: hay que cumplir con las prioridades 1 y 2 de la norma UNE, la cual no corresponde al 100% con las WCAG. Los cambios que he detectado:
| Pauta | Prioridad WCAG | Prioridad UNE |
|---|---|---|
| Identifique claramente el objetivo de cada vínculo. | 2 | 1 |
| Identifique el idioma principal de un documento. | 3 | 1 |
| Proporcione resúmenes de las tablas. | 3 | 2 |
| Cree un orden lógico para navegar con el tabulador a través de vínculos, controles de formulario y objetos. | 3 | 2 |
Para ayudarme a aprender los cambios, desarrollé una pequeña herramienta en Excel que comparaba las dos normativas, y que a la larga la he ido utilizando en los diversos cursos y trabajos que he desarrollado. En ella pongo todas las normas de la WCAG y a lado su correspondencia con la UNE. Es similar a lo que podéis encontrar en los anexos de la UNE, pero de forma inteligible y manejable. De esta forma, cuando tienes que evaluar los puntos de prioridad 1 y 2 de la UNE, los puedes identificar rápidamente ordenando por la columna correspondiente de prioridad UNE. Si por el contrario tienes que evaluar según la prioridad 1 y 2 de la WCAG, pues lo mismo pero con la columna de prioridades WCAG.
Espero que os ayude en las revisiones. Si encontráis alguna errata, por favor, decídmelo.
Si después de la crónica de Fran Tarifa sobre la jornada de accesibilidad web de AENOR te quedaste con las ganas de saber más, puedes descargar las ponencias desde la propia web del evento.
As well as evidence that awareness levels may be low, there is also evidence that attitudes to accessibility amongst learning technologist may not be overly positive. For example, Lazar et al. (2004) report on a survey, which asked webmasters about their knowledge of web accessibility and their perceptions of when and why websites should or should not be accessible. Most webmasters who responded to the survey supported the concept of web accessibility, but cited roadblocks to accessibility such as lack of time, lack of training, lack of managerial support, lack of client support, inadequate software tools, and confusing accessibility guidelines. However, there were some webmasters who objected to the idea that websites should be accessible, did not like the interference in ‘their’ web design, and would only make websites accessible if the government forced them to.
Del libro: E-learning and Disability in Higher Education. Accessibility research and practice. Jane K. Seale. (Resumen del libro) Las negritas son mías.
Cita: Lazar, J., Dudley-Sponaugle, A. and Greenidge, K-D. (2004) Improving web accessibility: a study of webmasters perceptions. Computers in Human Behaviour, 20, 269-288. (Ver ficha bibliográfica)
Cuando te dedicas a vender cualquier producto o servicio, tienes que tener un argumentario de venta sólido. Tan sólido como poder hacer frente a cualquier ‘pero’ de forma eficaz y elegante. Con diseño gráfico accesible es lo mismo, con el añadido de que el tema de la accesibilidad en el diseño web es relativamente nuevo para el gran público.
Lo primero que debe hacer una empresa que quiera vender diseño gráfico accesible es crear un DAFO realista sobre el servicio que tratan de vender. Que si es cierto que el diseño accesible tiene muchas virtudes, también lo es que tiene defectos:
Por otro lado, tenemos que enfrentarmos al ‘divismo’ de los diseñadores: que si hay que emplear una gama determinada de colores para que pase la validación de contraste, que los tamaños de las fuentes tienen que ser porcentuales, que si no puedes poner “pinche aquí”… Muchas restricciones para que les quede un” web bonito”.
Ahora, si quieres vender diseño accesible, sobre todo a pymes, ve preparando argumentos contra estos ‘peros’ que te vas a encontrar.
Lo cierto es que me alegro de estar un proyecto donde no hay que ‘vender accesibilidad’ porque ésta es obligatoria. Pero recuerdo cuando he tenido que hacerlo para pymes: cuando menos, es agotador y en la mayoría de los casos, frustrante.
No contento con el artículo que escribió cosa de un año sobre lo tontos que somos los profesionales de la usabilidad, ahora le toca el turno a “los accesibles”.
En la columna que ha publicado hoy en el periódico El País, el periodista y escritor cuenta sus vicisitudes a la hora de rediseñar su sitio web, que lleva desde 2001 y ya es hora de “cambiarle el traje”. Resumo un poco la historia: Millás contacta con una importante agencia de diseño web y les muestra un boceto bastante trabajado de lo que quiere: organización, colores, imágenes, fuentes… Lo normal que podemos encontrar cualquiera de nosotros en un día de trabajo.
La cuestión es cuando en la agencia intenta asesorarle de que sería mejor no hacerlo en Flash como está ahora, sino siguiendo “los estándares”, a Millás se le va la pinza. No sé qué habrán dicho exactamente los de la agencia, pero provoca respuestas como “es como si yo tuviera que escribir mis libros sin subordinadas porque los de la ESO no lo entienden” o “los sitios que me mostraron eran feos y carentes de atractivo alguno. Ni se movían ni sonaba ni nada.” o “Menudo paso atrás para el arte digital son estos accesibles“.
En fin, que yo no voy a añadir nada más porque él sólo lo dice todo. Os recomiendo encarecidamente que leáis el artículo original.
Si lo que quieres es pasar el validador automático, es posible que funcione. Pero con chapuzadas de las que tan orgullosos se muestran en el manual, pues no, señores, no será accesible.
Hoy ha salido el Accessibility Kit para MOSS (AKS). Antes de evaluarlo, veamos qué dice la documentación (traducción y resumen míos):
AKS es un conjunto de ficheros, programas y utilidades que facilitan un código accesible y usable de Microsoft Office Server SharePoint (MOSS) 2007 y Windows SharePoint Services (WSS). Aunque el kit no es la varita mágica que hace que la aplicación sea accesible, sí representa un salto en cuanto a tecnología porque proporciona nuevas hojas CSS, MasterPages, múltiples control adapters y ejemplos de contenido reusable para ayudar a los diseñadores y desarrolladores. AKS no contempla un proceso automatizado para remediar cualquier tema de usabilidad o accesibilidad de aplicaciones desarrolladas aparte del CORE de los estilos y masters de SharePoint. Sin embargo, puede aplicarse AKS a sitios ya creados.
A simple vista parecen un montón de bonitas palabras publicitarias. Microsoft me ha defraudado tanto, durante tanto tiempo, en cuestiones de accesiblidad, que va a ser necesario algo más para que cambie mi “prejuicio”. Sin embargo, quiero creer que, a los que bregamos con el Sharepoint, intentando que renderice un código decente, nos va a quitar un poquito de trabajo . Casi me conformaría con que no cree infinitas tablas anidadas para dar formato, pero no estoy segura de que lo vaya a hacer este kit. ¡Qué ganas tengo de que lo instalemos en el trabajo para probarlo!
Por decirlo de forma rápida, es el hermano mayor de TAW.
Se parece bastante en las funcionalidades, como seguir enlaces, guardar revisiones o exportar resultados, pero, comparado con él, tiene algunas mejoras, como gestor de sitios web por organizaciones, análisis de html y css por separado, registro de revisiones y reparaciones, autentificación de páginas, programación de análisis… Como puntos malos, que no consigo hacerlo funcionar para sitios en local y que es bastante lento de cargar. Por lo demás, muy bueno para la validación automática de la accesibilidad de sitios web.
Parece que la página original desde donde se tendría que descargar lo ha retirado. He dejado una copia en mi servidor para que lo descarguéis y lo probéis (23MB) durante un mes.
Descarga PISTA ACCESIBILIDAD desde la web de Ministerio de Industria. Aunque hay que rellenar un formulario, luego aparece la página de descarga.
Actualización: gracias a un comentario de Jorge me di cuenta de que el duende de la blogosfera movió algunas palabras de sitio y otras las borró, con lo cual quedaba una información incorrecta.
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]
RSS