Productos existentes: línea base, rediseños, migraciones y retirada

La mayoría de los equipos no empieza de cero: hereda un producto con años de historia, código de varias generaciones y contenido publicado por decenas de personas. Las lecciones anteriores describen cómo debería funcionar el ciclo; esta explica cómo incorporarlo a un producto que ya existe y cómo atravesar sin perder accesibilidad los tres momentos más delicados de su vida: el rediseño, la migración de plataforma y la retirada.

Establecer la línea base

Antes de decidir nada, mide de dónde partes. La línea base combina una evaluación manual sobre una muestra representativa, siguiendo WCAG-EM (se abre en una ventana nueva) e incluyendo los procesos completos, y un rastreo automático de todo el sitio o de la mayor parte posible. Lo valioso no es el número total de hallazgos, sino clasificarlos por origen:

• Plantilla o componente: el fallo está en la cabecera, el menú, el pie, un formulario compartido o un componente que se repite. Se corrige una vez y desaparece de todas las páginas.
• Contenido: imágenes sin texto alternativo, PDF sin etiquetar, encabezados usados por su aspecto. Se corrige elemento a elemento y, sobre todo, se evita formando a quien publica y configurando el gestor de contenidos.
• Terceros: chat, pagos, mapas, cookies. Se resuelve negociando con el proveedor o sustituyéndolo.
• Flujo: problemas que solo aparecen al recorrer un proceso, como un tiempo límite, un paso que pierde los datos o un CAPTCHA sin alternativa. Exige rediseñar el paso.

Esta clasificación suele revelar que una parte importante de los hallazgos procede de unas pocas plantillas y componentes. Ahí está la primera oportunidad, porque es la corrección con más retorno; regístralos en el registro de deuda que viste en la lección sobre el sprint.

Remediar, reconstruir o sustituir por partes

Con la línea base en la mano, la pregunta estratégica es qué hacer con el producto. Hay tres caminos, y la elección depende más de la arquitectura y de la vida que le queda al producto que de la gravedad de los hallazgos.

El tercer camino se conoce en ingeniería como patrón strangler fig («higuera estranguladora»): la aplicación nueva va sustituyendo secciones de la antigua hasta que esta deja de usarse. Para la accesibilidad suele ser una buena opción, porque cada sección nueva sale ya con los componentes accesibles del design system y la mejora llega a las personas usuarias desde los primeros meses, no al final de un proyecto de dos años.

Rediseños: no perder lo que ya funcionaba

Un rediseño es la mejor ocasión para aplicar el ciclo completo desde la fase de definición: la accesibilidad entra en el encargo de diseño, la nueva paleta se valida como tokens antes de aprobarse y los componentes se construyen sobre patrones APG (se abre en una ventana nueva). Pero también es una ocasión frecuente de retroceso: el nuevo diseño elimina el enlace para saltar al contenido, aplana la jerarquía de encabezados por estética, sustituye botones con texto por iconos sin nombre o rebaja el contraste del texto secundario. Protégete con dos prácticas:

• Inventario de lo que funciona: antes de rediseñar, lista lo que la versión actual hace bien (enlaces de salto, atajos, tablas bien marcadas, formularios correctos) y conviértelo en requisitos del nuevo diseño.
• Comparación con la línea base: ejecuta las mismas pruebas automáticas y manuales sobre las mismas pantallas en la versión antigua y en la nueva. La nueva no debería salir con más hallazgos que la antigua en ninguna categoría.

Migraciones de plataforma y de contenido

Cambiar de gestor de contenidos, de framework o de plataforma de comercio electrónico es una operación de alto riesgo para la accesibilidad del contenido, porque los scripts de migración trasladan datos, no significado. Los problemas típicos son:

• El texto alternativo se pierde porque el campo de origen no se ha asignado a ningún campo de destino.
• Los encabezados se convierten en párrafos en negrita, o al revés.
• Las tablas de datos pierden sus celdas de encabezado o llegan convertidas en imágenes.
• Los vídeos llegan sin subtítulos y los documentos sin sus versiones accesibles.
• Desaparece la marca de idioma de los fragmentos en otra lengua (3.1.2 Idioma de las partes), algo habitual en webs bilingües de comunidades con lengua cooficial.

<!-- Origen -->
<h2>Requisitos</h2>
<img src="oficina.jpg" alt="Entrada de la oficina de atención, con rampa de acceso">

<!-- Destino tras una migración mal mapeada -->
<p><strong>Requisitos</strong></p>
<img src="oficina.jpg">

Prevenirlo es sencillo si se planifica: incluye los campos de accesibilidad en el mapa de campos de la migración, migra primero una muestra y compárala con el origen, y automatiza comprobaciones antes y después: número de imágenes sin alt, estructura de encabezados, tablas sin th, vídeos sin pista de subtítulos, fragmentos con atributo lang. Si cualquiera de esas cifras empeora, la migración se detiene hasta saber por qué.

Si la migración incluye elegir un gestor de contenidos nuevo, evalúalo también como herramienta de autor. Las Authoring Tool Accessibility Guidelines 2.0 (ATAG 2.0 (se abre en una ventana nueva)) del W3C distinguen dos partes: que la interfaz de la propia herramienta sea accesible para quien publica (parte A) y que la herramienta ayude a producir contenido accesible (parte B), por ejemplo pidiendo el texto alternativo al subir una imagen, ofreciendo encabezados reales en el editor o avisando de problemas antes de publicar. Una herramienta que cumple la parte B frena buena parte de la degradación por contenido que viste en la lección «Operación».

Retirada y archivo

El ciclo de vida también termina. Al retirar un servicio, una sección o una app:

• Anuncia la retirada con antelación por canales accesibles e indica la alternativa: otro servicio, otro canal o la atención presencial.
• Mantén redirecciones hacia la alternativa durante un tiempo razonable; un enlace roto en mitad de un trámite deja a cualquiera sin salida.
• Actualiza la declaración de accesibilidad y retira la app de las tiendas si deja de mantenerse.
• Trata con cuidado el contenido de archivo. La Directiva (UE) 2016/2102 (PDF, se abre en una ventana nueva) y el RD 1112/2018 (PDF, se abre en una ventana nueva) excluyen, con condiciones, los contenidos de archivo que no se necesitan para procesos administrativos activos ni se actualizan después de la fecha que fija la norma. La exclusión no sirve para apartar contenido que sigue en uso: si un documento antiguo se necesita para un trámite vigente, debe ofrecerse en formato accesible, al menos cuando se solicite.

document.querySelectorAll('img:not([alt])').length
[...document.querySelectorAll('h1,h2,h3,h4,h5,h6')].map(h => h.tagName + ' ' + h.textContent.trim()).join('\n')

Resumen

• La línea base combina evaluación manual con WCAG-EM y rastreo automático, y clasifica los hallazgos por origen: plantilla, contenido, terceros o flujo.
• Remediar, reconstruir o sustituir por partes se decide por la arquitectura y la vida restante del producto; mientras se reconstruye, los bloqueantes actuales se corrigen igualmente.
• En un rediseño, inventaría lo que ya funciona y compara la versión nueva con la línea base para no retroceder.
• Las migraciones trasladan datos, no significado: mapea los campos de accesibilidad, prueba con una muestra, compara antes y después y evalúa el nuevo gestor con ATAG 2.0.
• La retirada se comunica con alternativa y redirecciones, y la exclusión de contenidos de archivo no ampara contenido que sigue en uso.