Una auditoría de accesibilidad de Fortune 500 identificó los problemas. Implementarlos en seis idiomas fue el verdadero trabajo.

La situación

El cliente poseía tres dominios: un sitio corporativo principal y dos propiedades de apoyo que cumplían funciones comerciales distintas. Cada uno fue publicado en seis idiomas. La auditoría se había realizado contra los tres.

Los hallazgos abarcaron el área de superficie que se esperaría a esta escala: fallas de contraste dentro de tokens de color de propiedad de la marca, componentes interactivos sin soporte para teclado o lector de pantalla, formularios a los que les faltan etiquetas programáticas y estados de error silenciosos, carruseles que se reproducían sin controles, videos sin subtítulos y una larga lista de incrustaciones de terceros (PDF, mapas y otro contenido insertado) que llegaban a la página sin ningún andamiaje de accesibilidad a su alrededor.

Ninguno de los temas individuales era exótico. Lo que hizo que el trabajo de remediación fuera sustancial fue la combinación en la que se encontraban dentro. Una presencia web de Fortune 500 con tokens de marca que no se podían editar casualmente. Tres dominios conectados. Versiones en seis idiomas de cada solución. Y una parte significativa de la superficie interactiva representada a través de componentes de React.

Por qué la remediación fue la parte difícil

Una auditoría es un documento estático. La remediación es la parte que tiene que enviarse. En una propiedad multilingüe con este tipo de alcance, esa distinción importa.

Fichas de contraste y color de propiedad de la marca

Varias fallas de contraste se encontraban dentro de las fichas de color que formaban parte del sistema de marca global del cliente. No podíamos oscurecer unilateralmente el color de una marca. Cada ajuste de contraste tenía que resolverse en la capa de uso (cambiar el fondo sobre el que se encontraba un token, aumentar el peso de la fuente, cambiar a un token aprobado diferente, ajustar los colores de estado para enlaces, botones y enfoque) o escalarse a los propietarios de la marca para obtener una variante tonal aprobada.

Esta parte del trabajo consistió tanto en coordinación como en código. Cada cambio propuesto pasó por una revisión de marca antes de llegar al entorno de puesta en escena.

Componentes interactivos renderizados por React

La parte más exigente de la reparación fue la capa interactiva renderizada a través de React. Estos componentes se crearon primero para el comportamiento visual y luego para la accesibilidad. Faltaban funciones o eran incorrectas, no se anunciaban cambios de estado, se perdía el foco en la nueva renderización y la interacción del teclado funcionaba parcialmente o no funcionaba en absoluto dependiendo del subcomponente que estaba activo.

Cada componente necesitaba una reconstrucción real de su modelo de accesibilidad. Roles, nombres y estados declarados correctamente. Concéntrese en los renderizados supervivientes y en la ruta de regreso a un lugar sensible cuando se cierren los modales, cajones y superposiciones. Los cambios de estado que son importantes para un usuario de lector de pantalla (selecciones, expansiones, errores, carga) se anuncian a través de regiones en vivo sin inundarlas. Nada de esto se pudo aplicar de manera uniforme entre los componentes porque cada uno tenía su propio modelo de estado.

Menús desplegables, formularios y estados de error

Los formularios en los tres dominios se basaban en una combinación de controles desplegables nativos y personalizados. Las selecciones nativas funcionaron. Los menús desplegables personalizados, los que preferían el estilo del sistema de diseño, fueron los que marcó la auditoría. Necesitaban roles correctos, operación del teclado, estado programático y nombres accesibles que fluyeran a través del proceso de traducción.

El trabajo sobre el estado de error fue igualmente material. Los campos defectuosos necesitaban una asociación programática entre el mensaje de error y la entrada, el mensaje en sí tenía que anunciarse cuando aparecía y el estado del campo obligatorio tenía que exponerse correctamente en lugar de dejarse como un asterisco visual. Cada solución fue traducida y verificada en las seis configuraciones regionales.

Carruseles y presentaciones de diapositivas

Los carruseles en el sitio se reproducían automáticamente, no exponían un control de pausa a la tecnología de asistencia, no manejaban limpiamente la navegación con el teclado y perdían el enfoque cuando cambiaban las diapositivas. Cada uno de estos es una solución individual de forma aislada. Juntos, significaron que había que rediseñar los componentes del carrusel, no sólo parchearlos. Controles de pausa y reproducción expuestos correctamente. Se anunciaron cambios de diapositivas donde importaba. Enfoque administrado cuando los usuarios interactuaban con los controles. Se respetan las preferencias de movimiento reducido.

Contenido integrado: vídeos, archivos PDF y mapas

Una parte significativa del contenido de la página no era propiedad de los sitios del cliente en absoluto. Los vídeos se incrustaron desde reproductores externos. Los archivos PDF estaban vinculados o incrustados dentro de iframes. Los mapas fueron integrados desde un proveedor externo. Los documentos originales no se pudieron editar como parte del compromiso.

Lo que se podía arreglar era la propia incrustación. Los videos se configuraron para cargarse con subtítulos disponibles y controles del reproductor expuestos a tecnología de asistencia. Los enlaces e incrustaciones de PDF se reescribieron para que el propósito, el tipo de archivo y el comportamiento fueran claros para el usuario del lector de pantalla antes de que se activara el enlace, con títulos iframe adecuados donde los PDF se mostraban en línea. Las incrustaciones de mapas recibieron nombres accesibles, se sacaron del orden de pestañas del teclado donde atrapaban el foco y se combinaron con alternativas basadas en texto (dirección, direcciones, contacto) para que se pudiera acceder a la información subyacente sin que se pudiera utilizar el widget del mapa.

Imágenes en seis idiomas

Los espacios en el texto alternativo estaban repartidos por toda la biblioteca de activos y no eran simétricos entre las versiones de idiomas. Algunas imágenes tenían texto alternativo en inglés y nada en las otras cinco configuraciones regionales. Otros eran decorativos en algunas páginas y significativos en otras. Cerrar esto requirió un pase por localidad, no un solo cambio global.

Versiones en seis idiomas de cada solución

Cada nombre accesible, cadena de texto de ayuda, mensaje de error y anuncio que presentamos durante el proyecto tenía que existir en los seis idiomas. Las cadenas codificadas en inglés no eran una opción. Cada nueva etiqueta y mensaje se enrutaba a través del proceso de traducción, se registraba en la memoria de traducción del sitio y se verificaba en cada ubicación antes de que se considerara enviada la corrección.

Trabajando en desarrollo, puesta en escena y producción.

El equipo tenía un entorno de desarrollo, un entorno de puesta en escena y producción. Cada cambio pasó por ese proceso antes de llegar a los usuarios reales, lo que eliminó el riesgo de enviar una solución defectuosa directamente a una presencia web de Fortune 500. Lo que no eliminó fue la multiplicación local. Una solución que pasó la verificación en inglés en la puesta en escena aún tenía que verificarse en alemán, donde las palabras compuestas duraban más y podían ajustarse donde no lo hacían en inglés, y en cada una de las otras cuatro configuraciones regionales. La promoción a producción se llevó a cabo de modo que ninguna unidad de negocios se viera sorprendida por un cambio de diseño en su idioma.

La brecha entre la auditoría y el trabajo

El documento de auditoría enumeraba problemas. No dijo, para cada problema, en cuál de los tres dominios apareció, a cuál de los seis idiomas afectó, qué componente lo generó o cuáles serían las consecuencias posteriores de solucionarlo. Construir ese mapeo fue el primer trabajo real.

Algunos hallazgos de auditoría, escritos de manera genérica, resultaron ser un único componente compartido utilizado en docenas de lugares. La reparación del componente solucionó todos los casos. Otros hallazgos, escritos como un solo número, fueron en realidad seis instancias (una por idioma) porque el DOM traducido divergió de la fuente en formas que la auditoría no había capturado. El recuento de problemas de la auditoría y el recuento de soluciones reales no coincidieron en ninguna dirección.

Reconstruimos la lista de problemas como un plan de solución organizado por plantilla, componente, tipo de inserción y configuración regional. Las correcciones que se podían realizar en la capa de código se separaron de aquellas que requerían trabajo de traducción, aprobación de la marca o configuración de inserción de terceros. Ese plan fue a partir del cual trabajó el resto del compromiso.

lo que hicimos

El trabajo se movía en pistas que corrían en paralelo donde podían y serializadas donde no podían. Cada pista fue analizada, ejecutada, verificada en las seis ubicaciones en la puesta en escena y promovida a producción antes de que comenzara el siguiente lote.

Ajustes de color y contraste.

Las fallas de contraste se resolvieron mediante cambios en la capa de uso siempre que fue posible y mediante variantes tonales aprobadas por la marca donde un token en sí tenía que cambiar. Los estados de enfoque, desplazamiento, deshabilitado y error en enlaces, botones y campos de formulario se ajustaron a la conformidad, y el equipo de la marca aprobó cada cambio antes de su envío.

Reaccionar reconstrucciones de componentes

Los componentes interactivos renderizados a través de React fueron el cuerpo de trabajo más concentrado. Cada componente recibió un modelo de accesibilidad adecuado: roles, nombres accesibles, estados, operación del teclado, administración de enfoque en el montaje y desmontaje y anuncios de los cambios de estado que eran importantes para el usuario del lector de pantalla. Los componentes se probaron tanto de forma aislada como dentro de las páginas que los utilizaban.

Formularios y menús desplegables

Los formularios en los tres dominios se reconstruyeron para asociar etiquetas mediante programación con sus entradas, exponer correctamente el estado de los campos obligatorios, anunciar errores cuando aparecían y proporcionar texto de error que los lectores de pantalla pudieran asociar con el campo defectuoso. Los menús desplegables personalizados recibieron roles correctos, manejo del teclado y nombres accesibles. Los menús desplegables nativos se dejaron donde ya funcionaban.

Carruseles y presentaciones de diapositivas

Los componentes del carrusel se rediseñaron para exponer los controles de pausa y reproducción, admitir la navegación con el teclado, administrar el enfoque cuando se cambian las diapositivas y respetar las preferencias de movimiento reducido. El comportamiento de reproducción automática se revisó según el requisito de que los usuarios tengan un control significativo sobre el contenido en movimiento.

Accesibilidad de vídeo

El vídeo integrado se configuró para cargarse con subtítulos disponibles y controles del reproductor expuestos a tecnología de asistencia. Cuando se utilizaron videos para transmitir información que no estaba disponible en otras partes de la página, la incrustación se combinó con un respaldo textual.

PDF, mapas y otras correcciones de incrustaciones

Los archivos PDF no fueron editados en la fuente. Lo que cambió fue la forma en que se hacía referencia a ellos desde los sitios: texto del enlace que describe el documento y su tipo de archivo, títulos de iframe donde los archivos PDF se incrustaban en línea e indicación clara del comportamiento antes de que se activara el enlace. Las incrustaciones de mapas recibieron nombres accesibles, se impidió que capturaran el foco del teclado y se combinaron con alternativas basadas en texto para que se pudiera acceder a la información subyacente sin el widget del mapa.

Cobertura de imágenes y texto alternativo

La biblioteca de activos se revisó por ubicación. Se agregó texto alternativo faltante en cada idioma, las imágenes decorativas se marcaron correctamente y las variantes de imagen que diferían entre las versiones de idioma recibieron texto alternativo traducido en lugar de un respaldo predeterminado.

Actualizaciones del proceso de traducción

Cada nuevo nombre accesible, texto de ayuda y anuncio introducido durante la corrección se tradujo a los seis idiomas y se registró en la memoria de traducción del sitio. No quedó nada como una cadena en inglés codificada. El proceso se amplió para que el contenido y las funciones futuras heredaran la misma cobertura.

Verificación entre localidades

Cada cambio pasó por una fase de verificación en la puesta en escena en los seis idiomas antes de ser promovido a producción. Las herramientas automatizadas detectaron las fallas estructurales (contraste, atributos faltantes, jerarquías rotas). Las pruebas manuales cubrieron las partes que requerían juicio: flujo del teclado a través de los componentes de React, anuncios que se activan en el momento adecuado, manejo de errores en formularios reales y comportamiento de incrustación de videos, archivos PDF y mapas.

El resultado

Los tres dominios alcanzaron la conformidad en los seis idiomas dentro de la ventana de participación. El sistema de marcas permaneció intacto. El conducto de traducción se amplió limpiamente para cubrir la nueva superficie de accesibilidad. Ninguna unidad de negocio experimentó una regresión en su idioma durante el lanzamiento.

La documentación interna producida durante el proyecto (el plan de remediación, las notas de verificación por ubicación, la guía a nivel de componente) se devolvió a los equipos web y de marca del cliente para que el contenido y las funciones futuras permanecieran dentro del marco de conformidad en lugar de salirse de él.

Qué significa esto para los sitios empresariales multilingües

Si gestiona un sitio web multilingüe a escala empresarial, es probable que los patrones que hicieron que esta interacción fuera sustancial ya estén presentes en su entorno.

La auditoría es el comienzo del trabajo.

Una auditoría WCAG identifica problemas. No le dice qué componente los genera, qué variantes de idioma se ven afectadas, qué correcciones requieren la aprobación de la marca o qué correcciones se extenderán a través de la traducción. Construir ese mapa es su propio trabajo y generalmente es donde se estancan los proyectos de remediación.

Multilingüe hace que cada solución sea más amplia

Una única solución de accesibilidad en un sitio monolingüe es un cambio. La misma solución en un sitio en seis idiomas puede consistir en seis cambios, cada uno con sus propios requisitos de traducción, diseño y verificación. Determinar el alcance del trabajo de accesibilidad sin tener en cuenta la multiplicación local es la forma en que los plazos se deslizan.

Los componentes personalizados de React realizan la mayor parte del trabajo.

Los componentes interactivos personalizados renderizados a través de React rara vez se comportan correctamente para la tecnología de asistencia sin una reconstrucción deliberada. Los parches de Surface no solucionan la pérdida de enfoque al volver a renderizar, la falta de anuncios de estado o los modelos de teclado rotos. Es necesario reelaborar el componente, lo que supone un perfil de costes diferente al de fijar el margen de beneficio estático.

La aprobación de la marca debe estar contemplada desde el principio

Las fallas de contraste a menudo residen dentro de las fichas de color propiedad de la marca. Remediación que no incluye al equipo de la marca en el circuito, ya sea que envíe cambios que la marca revertirá más tarde o se detenga indefinidamente esperando una aprobación que nunca se solicitó correctamente.

Puedes arreglar la incrustación cuando no puedes arreglar la fuente

Los vídeos, archivos PDF y mapas que llegan a la página desde fuentes de terceros a menudo no se pueden editar en la fuente. Lo que se puede arreglar es la forma en que están incrustados: texto de enlace, títulos de iframe, comportamiento de enfoque y alternativas basadas en texto que ponen la información subyacente al alcance de alguien que no puede usar el widget en sí.

La conformidad se desvía sin una propiedad continua

Un sitio alcanza la conformidad y luego sale de ella la próxima vez que se incluye una nueva característica, se agrega una nueva plantilla o se publica un nuevo contenido sin cobertura de traducción en sus nombres accesibles. La documentación de entrega es la que determina si el trabajo se mantiene.