Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web
El objetivo de este artículo es difundir un documento colaborativo del W3C en formato Wiki que me parece de gran importancia conocer.
Este documento desglosa los 61 criterios de conformidad de las WCAG 2.0 en listas de control más pequeñas, una para cada rol profesional implicado en un desarrollo web.
De esta manera, cada profesional del equipo de desarrollo puede conocer las responsabilidades que tiene en cuanto a la accesibilidad del producto e integrarlas en su práctica diaria.
Documento original: Accessibility Responsibility Breakdown, del W3C
Herramienta complementaria: Interactive WCAG 2.0. Listado de pautas y criterios de las WCAG 2.0 filtrables por el perfil responsable.
¿Por qué es importante?
Los criterios de conformidad de las WCAG 2.0 no son difíciles de aplicar en su mayoría. Sin embargo, si se desconocen, es fácil cometer errores que sí serán muy costosos de solucionar a posteriori.
Cuando se intenta abordar la accesibilidad web al final del desarrollo, el equipo se da cuenta demasiado tarde de que muchas cuestiones deberían haberse tenido en cuenta en fases anteriores. Abordar esos cambios una vez terminado el proyecto resulta mucho más costoso. Incluso puede ocurrir que no se tengan ya los medios ni los recursos adecuados para llevar a cabo los cambios.
La única manera de conseguir efectivamente un sitio accesible, y con el menor coste posible, es integrar los requisitos de accesibilidad en el plan de trabajo del equipo de desarrollo. Es necesario por tanto planificar desde el principio la responsabilidad de los diferentes actores: de quién es responsabilidad el cumplimiento de cada requisito y en qué momento del desarrollo debe tenerse en cuenta.
Roles profesionales definidos
Vista del mapa con cada rol desplegado y sus criterios de conformidad asociados (en Mind42.com), autor Olga Carreras
Los roles profesionales definidos en el documento son:
- Project management
Tienen un papel vital: asegurarse de que todos los interesados conocen cuál es su rol y responsabilidad en la accesibilidad del producto. Sus responsabilidades son entre otras la planificación de la accesibilidad en cada etapa del ciclo de vida del proyecto, la asignación de responsabilidades entre las personas del equipo o garantizar que se están cumpliendo los criterios en cada hito.
- Analysis, bajo su resposabilidad tiene 9 criterios de conformidad.
- Architecture, bajo su resposabilidad tiene 9 criterios de conformidad.
- Interaction Design / Usability, bajo su resposabilidad tiene 36 criterios de conformidad.
- Graphic Design, bajo su resposabilidad tiene 32 criterios de conformidad.
- Content Strategy, bajo su resposabilidad tiene 21 criterios de conformidad.
- Search Engine Optimization, bajo su resposabilidad tiene 28 criterios de conformidad.
- HTML/CSS Prototyping, bajo su resposabilidad tiene 25 criterios de conformidad.
- Front-end Development, bajo su resposabilidad tiene 60 criterios de conformidad.
- Back-end Development, bajo su resposabilidad tiene 32 criterios de conformidad.
- Quality Control, bajo su resposabilidad tiene los 61 criterios de conformidad.
Cada uno de estos roles tiene una página en la Wiki. En ella se puede consultar una tabla con los criterios que están bajo su responsabilidad, organizados por los cuatros principios (Perceptible, Operable, Comprensible y Robusto) y por cada nivel de adecuación (A, AA, AAA) Además también se incluye una tabla detalle, por cada principio, con cada criterio de éxito, su descripción, los beneficios que reporta y un enlace a las técnicas suficientes asociadas.
Tabla resumen por criterio de conformidad y rol profesional
Últimos artículos relacionados actualizados:
* Como todos los artículos de este blog, este es un artículo NO promocionado.
Autor: Olga Carreras Montoto
Etiquetas: accesibilidad metodología, WCAG 2.0
Hola Olga,
estoy totalmente de acuerdo en que debemos tener en cuenta los requisitos de accesibilidad desde la fase de Análisis para minimizar el coste del desarrollo.
Es de gran interés la tabla resumen por criterio de conformidad y rol profesional, para ser conscientes de los requisitos de accesibilidad a tener en cuenta en cada fase del ciclo de vida de un proyecto.
En nuestro caso vamos a comenzar el desarrollo de un portal web para la administración pública y tenemos que cumplir los requisitos de la Norma UNE 139803:2012.
Además, y teniendo en cuenta que ahora ya es candidato a recomendación, nos estamos planteando implementarlo con HTML 5 y utilizar los nuevos elementos semánticos del tipo (article, section, aside, header, footer, nav, ...). Entendemos que a priori no es incompatible con el cumplimiento de las WCAG 2.0, pero no tenemos muy claros los beneficios e inconvenientes con respecto a otras versiones de html.
Hemos visto que uno de los inconvenientes que indicas en algún comentario, hace referencia al diferente soporte de cada navegador para los diferentes elementos y atributos ¿Es mucho el trabajo extra que sería necesario para buscar alternativas accesibles y compatibles para el resto de navegadores y versiones?
En definitiva ¿a día de hoy, sería recomendable implementar un portal para la administración pública en HTML 5? ¿Existe algún portal web implementado en HTML 5, que cumpla las WCAG 2.0?
Eliminar comentario de ' Anónimo ' con fecha de 10 de abril de 2013, 10:26
Hola, espero que mi nuevo artículo (“Pro HTML5 Accessibility” ) conteste tus preguntas.
Eliminar comentario de ' Olga Carreras ' con fecha de 27 de abril de 2013, 1:05