Accesibilidad en equipo: definir responsables y aprobaciones

Fijar un objetivo verificable

«Mejoramos la web» es difícil de planificar. Formula en su lugar un encargo delimitado: «Revisamos el registro y el formulario de contacto según nuestro objetivo WCAG definido, corregimos las barreras que bloquean y documentamos los puntos pendientes». Indica el estándar objetivo, las ofertas analizadas, el tiempo disponible y la próxima fecha de revisión. Además, tienes que clasificar adecuadamente los requisitos legales de tu oferta concreta.

Anota también qué áreas quedan por ahora fuera de la revisión. Así, un encargo de revisión bien acotado resulta trazable y no se convierte en una afirmación sobre todo el sitio web.

Nombrar tareas, no solo una persona responsable

Una persona coordinadora mantiene la visión de conjunto. Aun así, el trabajo se reparte: diseño revisa contrastes y estados, el equipo editorial revisa la estructura y los textos, y desarrollo revisa la semántica y las interacciones. La persona responsable del contenido confirma que un proceso modificado sigue cumpliendo su finalidad. En una empresa pequeña, varias tareas pueden recaer en la misma persona; aun así, deberían nombrarse expresamente.

Aclarad con las agencias externas y los proveedores de componentes quién acepta un hallazgo, entrega la corrección y documenta la nueva revisión. Un punto de traspaso sin aclarar deja sin resolver incluso un error bien descrito.

Priorizar según el impacto

Empieza por las barreras que impiden una tarea importante: un botón de pedido que no se puede usar, un error de formulario incomprensible o una navegación sin acceso por teclado. Los componentes compartidos merecen especial atención, porque corregirlos mejora muchas páginas. Ten en cuenta los problemas comunicados y los contenidos más utilizados.

Un orden posible es: finalización bloqueada, uso muy dificultado, otras mejoras. Añade en cada caso la tarea afectada, el alcance y el esfuerzo. Un gran número de hallazgos similares no debería ocultar automáticamente una única interrupción completa de un proceso.

Convertir los hallazgos en tickets accionables

1. 1Indica la URL o el componente y la tarea que alguien quiere realizar.
2. 2Describe el estado inicial, los pasos de la prueba, el comportamiento observado y el resultado esperado.
3. 3Añade el entorno de pruebas y, en su caso, la referencia a las WCAG y una captura de pantalla o la salida.
4. 4Asigna una persona responsable, una prioridad y una fecha realista.
5. 5Cierra el ticket solo después de volver a revisar el mismo proceso y documenta el resultado.

Incluir la revisión en la aprobación

Define un breve control editorial para las páginas nuevas y una prueba manual adecuada para los componentes nuevos. Las revisiones automáticas pueden hacer visibles pronto los problemas técnicos recurrentes. Planifica revisiones más amplias para los procesos nuevos o modificados sustancialmente. Un pequeño conjunto fijo de tareas de prueba facilita las comparaciones entre versiones.

Involucra pronto a personas con distintas discapacidades y planifica para ello tiempo y una remuneración adecuada. Sus comentarios explican obstáculos reales de uso. Complementan la revisión según el estándar, pero no la sustituyen.

Informar del progreso de forma comprensible

Informa de qué tareas se han revisado, qué barreras se han corregido y qué sigue pendiente. Para los puntos pendientes, añade la persona responsable y el siguiente paso. Una única puntuación deja estas preguntas sin respuesta. Recoge comentarios a través de un contacto accesible y analiza las causas recurrentes: ¿falta un componente adecuado, una plantilla editorial o conocimientos en el equipo? De ahí surgen mejoras concretas para la siguiente ronda de trabajo.