Quién hace qué: la accesibilidad como responsabilidad compartida

Al desmontar el mito de que la accesibilidad «es cosa de los desarrolladores» vimos que las barreras nacen en todas las fases de un proyecto y en todos los departamentos. Pero decir que la accesibilidad «es responsabilidad de todos» sin concretar más suele acabar en que no es responsabilidad de nadie. En esta lección bajamos a lo concreto: qué decide cada perfil, qué barreras puede evitar y en qué momento del ciclo de vida interviene. También te servirá para situarte en el resto de este programa.

De «todos» a «quién y cuándo»

El W3C publica un recurso pensado precisamente para esto, el ARRM (Accessibility Roles and Responsibilities Mapping, mapa de funciones y responsabilidades de accesibilidad). Propone asignar cada tarea de accesibilidad a un responsable principal, que decide y responde de ella; a responsables secundarios, que la apoyan; y a contribuyentes, que aportan información o revisan.

Un ejemplo: el texto alternativo de una fotografía de una noticia es responsabilidad principal de quien redacta la noticia, porque es quien sabe qué información aporta la imagen. Diseño contribuye indicando qué imágenes de la plantilla son decorativas, y desarrollo es responsable secundario: debe garantizar que el CMS permite escribir ese texto y que llega correctamente al código. Si nadie tiene asignada la tarea, cada uno supondrá que la hace otro.

Qué hace cada perfil

Esta tabla resume, para los perfiles más habituales, sobre qué deciden y qué barreras pueden evitar con esas decisiones:

Perfil	Decide sobre	Barreras que puede evitar
Dirección y gerencia	Prioridades, presupuesto, plazos, política de accesibilidad	Proyectos sin tiempo para probar, compras sin requisitos, equipos sin formación
Gestión de producto y de proyecto	Requisitos, criterios de aceptación, planificación	Funcionalidades concebidas sin pensar en teclado, lector de pantalla o zoom
Diseño UX/UI	Colores, tipografía, foco, tamaños, flujos, componentes	Contraste insuficiente, objetivos táctiles pequeños, información transmitida solo con color, flujos confusos
Redacción, contenidos y comunicación	Textos, imágenes, vídeos, documentos, redes sociales	Lenguaje complejo, enlaces «pinche aquí», imágenes sin alternativa, PDF escaneados, vídeos sin subtítulos
Desarrollo	Código, componentes, integraciones	Controles sin nombre ni rol, trampas de teclado, foco perdido, errores que no se anuncian
Pruebas y calidad	Planes de prueba, verificación antes de publicar	Publicar sin haber probado con teclado, zoom y lector de pantalla
Compras y contratación	Pliegos, contratos, selección de proveedores	Comprar un CMS, una pasarela de pago o un componente que no se puede hacer accesible
Atención a la ciudadanía o al cliente	Canales de contacto, gestión de quejas	Quejas que nunca llegan al equipo técnico y personas sin alternativa cuando algo falla

Fíjate en que varios perfiles no escriben ni una línea de código y, sin embargo, sus decisiones determinan buena parte del resultado. Un plazo de entrega que no deja tiempo para probar, o un contrato que no menciona la accesibilidad, generan más barreras que cualquier error de programación aislado.

La accesibilidad en el ciclo de vida

Además de por perfiles, conviene pensar por fases. En cada una hay una pregunta que alguien debe hacerse:

1. Concepción y requisitos: ¿hemos incluido la accesibilidad (por ejemplo, WCAG 2.2 nivel AA) entre los requisitos y en los criterios de aceptación?
2. Diseño: ¿los colores, los tamaños, el foco y los estados de error funcionan para todo el mundo? ¿Hemos anotado en el diseño el orden de lectura, los encabezados y los textos alternativos?
3. Desarrollo: ¿usamos HTML nativo y componentes probados? ¿Todo funciona con teclado?
4. Contenido: ¿el texto es claro, las imágenes tienen alternativa y los documentos y vídeos son accesibles?
5. Pruebas: ¿hemos probado las tareas principales con teclado, zoom y lector de pantalla, además de con herramientas automáticas?
6. Publicación y mantenimiento: ¿cada contenido nuevo se revisa? ¿Hay un canal para recibir quejas y alguien que las atienda?

Es el enfoque shift-left que mencionamos en la lección de mitos: mover la accesibilidad hacia el principio, donde cambiar algo cuesta poco. En el nivel 7, un curso entero se dedica a integrarla en el ciclo de vida del producto.

Figuras de coordinación

Además del trabajo de cada perfil, alguien tiene que coordinar. En el sector público, el RD 1112/2018 (PDF, se abre en una ventana nueva) prevé que las administraciones cuenten con una unidad responsable de accesibilidad, con funciones de coordinación, seguimiento del cumplimiento y atención de las comunicaciones de la ciudadanía; lo verás en el curso de marco legal y, a fondo, en el nivel 5. En el sector privado no existe una figura obligatoria equivalente, pero muchas organizaciones designan una persona responsable de accesibilidad y una red de referentes (champions) en cada equipo: personas con más formación que resuelven dudas cercanas y detectan problemas antes de que se publiquen.

Tu itinerario en este programa

Esta certificación está organizada para que cada perfil encuentre su parte. Tras este nivel 1 de fundamentos, el nivel 2 se centra en contenidos y diseño (redacción, imágenes, color, interfaces, multimedia y documentos cotidianos); el nivel 3, en desarrollo web (HTML, formularios, teclado, ARIA y componentes); el nivel 4, en auditoría con WCAG 2.2; el nivel 5, en normativa, gestión y contratación pública; el nivel 6, en documentos PDF y ofimáticos, aplicaciones móviles, multimedia avanzada y accesibilidad cognitiva; y el nivel 7, en estrategia, formación, investigación con personas usuarias y peritaje.

Aunque luego te especialices, te recomendamos completar al menos los niveles 1 y 2: son el vocabulario común que te permitirá entenderte con el resto del equipo. Una diseñadora que sabe qué necesita desarrollo, o un desarrollador que entiende por qué un texto alternativo es responsabilidad de contenidos, colaboran mucho mejor.

Resumen

• «Es responsabilidad de todos» solo funciona si cada tarea tiene un responsable principal, como propone el ARRM del W3C.
• Dirección, producto, diseño, contenidos, desarrollo, pruebas, compras y atención al público evitan barreras distintas con sus decisiones.
• Cada fase del ciclo de vida tiene su pregunta de accesibilidad; cuanto antes se plantea, más barato es resolverla.
• En el sector público, el RD 1112/2018 prevé una unidad responsable de accesibilidad; en el privado, una persona responsable y una red de referentes son buena práctica.