Lanzamiento: criterios de salida, excepciones y documentación de conformidad

Lanzar es una decisión y, como toda decisión, necesita criterios fijados de antemano. Sin ellos gana siempre la fecha comprometida: el producto sale con barreras «que se arreglarán en la siguiente versión» y nadie deja constancia de cuáles son ni de cuándo se corregirán. En esta lección verás cómo definir criterios de salida de accesibilidad, cómo gestionar las excepciones cuando no se cumplen y qué documentación de conformidad corresponde a cada tipo de producto: la declaración de accesibilidad del sector público, la información que se exige a los servicios cubiertos por la Ley 11/2023 (PDF, se abre en una ventana nueva) y los informes de conformidad que piden clientes y pliegos.

Criterios de salida

Los criterios de salida (en inglés, la decisión go/no-go, «se lanza o no se lanza») se acuerdan al principio del proyecto, en la fase de definición que vimos en la lección sobre el ciclo de vida, y no la semana del lanzamiento. Un conjunto razonable para una versión importante:

• Ningún defecto bloqueante abierto, con la escala de severidad por impacto de la lección «Operación».
• Ningún defecto grave abierto en los flujos críticos; los graves fuera de ellos, solo con una excepción aprobada.
• Pipeline de accesibilidad en verde en todos los flujos automatizados.
• Pruebas manuales completadas en los flujos críticos con la matriz de tecnologías de apoyo acordada, con evidencias registradas.
• Evaluación previa al lanzamiento hecha y sus hallazgos clasificados.
• Defectos restantes registrados como deuda, con responsable y fecha.
• Documentación de conformidad actualizada y equipo de soporte informado.

La persona que decide la salida debe tener autoridad real para decir «no» y no debería ser la misma que responde del plazo. En muchas organizaciones decide la persona responsable de producto, con el visto bueno obligatorio de la persona responsable de accesibilidad.

La evaluación previa al lanzamiento

Su alcance debe ser proporcional al cambio. En una versión mayor o en un producto nuevo, aplica una evaluación con la metodología WCAG-EM (se abre en una ventana nueva) que estudiaste en el nivel 4: alcance definido, exploración, muestra estructurada y aleatoria, evaluación e informe. En una versión menor basta una prueba de regresión centrada en las pantallas y flujos modificados y en los componentes compartidos que se hayan tocado.

Recuerda dos requisitos de conformidad de las WCAG que suelen olvidarse con las prisas: la conformidad se aplica a páginas completas, no a partes de una página, y cuando una página forma parte de un proceso, todas las páginas del proceso deben cumplir. Un flujo de compra con todas las pantallas correctas salvo la del pago no es conforme: el proceso entero deja de serlo.

Excepciones: salir con defectos conocidos sin esconderlos

A veces no se cumplen todos los criterios y hay razones legítimas para lanzar igualmente: una obligación legal con fecha fija, un fallo de seguridad en la versión anterior o un defecto en una función secundaria cuya corrección depende de un proveedor. Lo que distingue una excepción de un descuido es que está documentada y caduca. Una ficha de excepción mínima incluye:

1. Defecto concreto, criterio WCAG afectado y severidad.
2. Motivo por el que no se corrige antes de salir.
3. Alternativa disponible desde el primer día para las personas afectadas: otro canal, asistencia, un formato alternativo.
4. Responsable y fecha límite de corrección.
5. Persona que la aprueba, distinta del equipo que la solicita.
6. Reflejo en la documentación pública cuando proceda, por ejemplo en el apartado de contenido no accesible de la declaración.

Nunca debería aprobarse una excepción sobre un defecto bloqueante: equivale a lanzar un servicio que deja fuera a una parte de la población. Y cada excepción entra automáticamente en el registro de deuda que vimos en la lección sobre el sprint, para que su fecha límite no dependa de la memoria de nadie.

Documentación de conformidad según el contexto

Qué hay que publicar depende del marco que se fijó en la fase de definición. La tabla resume los casos más habituales:

Dos consejos de experto. Primero, actualizar la declaración o la información de accesibilidad forma parte del lanzamiento, no de una tarea anual que alguien recuerda tarde: si la versión nueva cambia la situación, el documento cambia el mismo día. Segundo, un informe de conformidad que marca «Admite» en todas las filas resta credibilidad; uno que indica «Admite parcialmente» con observaciones concretas y una fecha de corrección transmite que el producto se conoce y se gestiona.

Notas de versión, soporte y primeras semanas

El lanzamiento no termina al desplegar. Tres tareas completan la puerta de salida:

• Notas de versión: informa de los cambios que afectan a la forma de uso, como un atajo de teclado nuevo, un componente que cambia de comportamiento o una función que pasa a ser utilizable con lector de pantalla. Quien usa tecnologías de apoyo agradece saber qué ha cambiado antes de encontrárselo.
• Soporte preparado: el capítulo 12 de la EN 301 549 recoge requisitos para la documentación del producto y los servicios de soporte, que deben informar sobre las funciones de accesibilidad y compatibilidad y comunicarse de forma accesible. En la práctica, el equipo de atención necesita un guion: qué funciones de accesibilidad tiene el producto, qué alternativas ofrecer y cómo escalar una barrera al proceso de incidencias.
• Vigilancia reforzada: durante las primeras semanas, revisa a diario las incidencias etiquetadas como de accesibilidad y los resultados de las pruebas sintéticas en producción. Los defectos que se escapan de una versión nueva aparecen pronto.

Resumen

• Los criterios de salida se acuerdan al inicio: sin bloqueantes, sin graves en flujos críticos, pipeline en verde, pruebas manuales hechas y documentación lista.
• La evaluación previa al lanzamiento es proporcional al cambio y respeta los requisitos de conformidad de página completa y proceso completo.
• Una excepción se documenta con alternativa, responsable, fecha límite y aprobación ajena al equipo, nunca cubre un bloqueante y entra en el registro de deuda.
• La documentación depende del contexto: declaración de accesibilidad, información exigida por la Ley 11/2023, declaración UE de conformidad o informe de conformidad.
• Notas de versión, soporte preparado según el capítulo 12 de la EN 301 549 y vigilancia reforzada cierran el lanzamiento.