¿Cómo se localizan las funciones de accesibilidad, como el texto alternativo y las etiquetas ARIA?

Última revisión: 31 de agosto de 2026

¿Qué se necesita para localizar correctamente el contenido de accesibilidad?

Localizar correctamente el contenido de accesibilidad depende de que cinco capas trabajen juntas, no solo de traducir las cadenas.

• Captura completa del contenido: todos los atributos traducibles (alt, title, aria-label, aria-describedby) tienen que identificarse e introducirse en el flujo de trabajo junto con el texto visible del cuerpo y el botón, no tratarlos como un paso manual independiente.
• Contexto para los traductores — como estas cadenas no tienen un renderizado visual propio, los traductores necesitan ver el elemento de interfaz que describe una etiqueta para evitar una reproducción literal, palabra por palabra, que suene extrañamente en voz alta.
• Consistencia de estilo y tono : el glosario y la guía de estilo que mantienen coherente la copia visible de la interfaz deberían extenderse también a las cadenas de accesibilidad, de modo que un lector de pantalla en francés o japonés suene como el mismo producto que la interfaz visible.
• Verificación de calidad por región: las comprobaciones de conformidad de las WCAG deben realizarse en todos los lugares enviados, no solo en la fuente en inglés, ya que una auditoría en inglés aprobada no dice nada sobre la versión alemana o japonesa.
• Sincronización continua: a medida que los desarrolladores añaden o editan cadenas de interfaz de usuario, el texto alternativo y las etiquetas ARIA tienen que volver a detectarse y ponerse en cola para su traducción automáticamente, del mismo modo que las cadenas visibles, para que el contenido de accesibilidad no se desincronice tras el lanzamiento.

¿Qué criterios de éxito de WCAG cubren contenido de accesibilidad localizada?

El contenido de accesibilidad localizado se ajusta a criterios de éxito específicos y numerados de las WCAG 2.2, no solo a una buena práctica general.

¿Cómo localizáis el contenido de accesibilidad en la práctica?

Las capas de flujo de trabajo anteriores se traducen en una secuencia concreta que la mayoría de los equipos pueden ejecutar junto con su proceso de localización actual.

1. Audite las cadenas no visibles: rastree o exporte el producto de origen para cada atributo alt, title, aria-label y aria-describedby junto con las cadenas de interfaz de usuario estándar; son las cadenas que es más probable que falten en un inventario de contenido de primera pasada.
2. Configurar la captura automática: establezca las directivas de archivo del flujo de trabajo, como la regla include_translatable_attributes, de modo que el texto alternativo y los atributos ARIA se capturen para su traducción de la misma manera que el cuerpo del texto visible, en lugar de confiar en que alguien los marque manualmente.
3. Da contexto a los traductores, no solo cadenas : adjunta contexto visual o estructural a cada cadena de accesibilidad para que el traductor pueda ver el elemento de la interfaz que describe y traducirlo según cómo se escuchará, no solo cómo se leería.
4. Compruebe el glosario y la guía de estilo: ejecute el mismo perfil de cumplimiento y control de calidad del glosario que se utiliza para el texto visible comparándolo con las cadenas de accesibilidad, detectando terminología incoherente o truncando según los límites de caracteres específicos de la plataforma.
5. Vuelve a verificar la conformidad de WCAG por localidad — realiza un pase de lector de pantalla y un escaneo automatizado de WCAG con cada compilación de localización publicada, no solo con el idioma fuente, antes de declarar que una versión es accesible completa.

Este enfoque se adapta a los equipos que...

• Lanzar un producto web o móvil en varios idiomas y ya seguir la conformidad con WCAG 2.2 AA en el idioma de origen
• Guarda texto alternativo, etiquetas ARIA y cadenas de lector de pantalla en la misma base de código o CMS como copia visible de la interfaz
• Tienen un flujo de trabajo de traducción existente — glosario, guía de estilo, controles de calidad — que quieren extender a contenido no visible en lugar de ejecutar un segundo proceso separado
• Necesito contenido de accesibilidad para mantenerse sincronizado mientras los desarrolladores lanzan nuevas cadenas de interfaz, no solo gestionado una vez en el lanzamiento

Cuando puede que esta no sea la principal prioridad

• Un producto con una base de usuarios de un solo idioma y sin un plan a corto plazo para un lanzamiento multilingüe
• Contenido de marketing estático con pocos componentes interactivos, mensajes de estado dinámicos o campos de formulario, en los que los atributos ARIA rara vez se utilizan en primer lugar

Lista de evaluación: preguntas que debe hacer antes de localizar el contenido de accesibilidad

¿Nuestro proceso de captura de contenido extrae atributos HTML/JSX o solo texto visible?
Si una exportación o conector solo extrae cadenas renderizadas, es probable que se salten el texto alternativo y las etiquetas ARIA sin que nadie se dé cuenta.

¿Los traductores reciben contexto para cadenas que nunca se renderizan en pantalla?
Una cadena como aria-label= " Close " tiene que verse junto con el control que etiqueta, o un traductor adivina el tono y la longitud.

¿Se aplican las reglas del glosario y la guía de estilo a las cadenas de accesibilidad, no solo a los textos visibles?
Sin eso, la experiencia de un lector de pantalla puede derivar de la terminología y la voz visibles de un producto en todos los lugares.

¿Se verifica la conformidad de las WCAG por localidad o solo una vez en el idioma de origen?
Una construcción inglesa conforme no garantiza una versión conforme alemana, japonesa o árabe.

¿Qué ocurre cuando un desarrollador añade una nueva etiqueta ARIA tras el lanzamiento?
Confirma si se detecta y se pone en cola para traducirlo, o si depende de que alguien recuerde marcarlo.

¿Cómo apoya Smartling la localización del contenido de accesibilidad?

La Global Delivery Network (GDN) de Smartling trata por defecto los atributos alt, título y marcador como contenido traducible, capturándolos de la misma manera que captura el texto visible del cuerpo y de los botones, por lo que las cadenas de accesibilidad no requieren un paso de exportación separado ni que un desarrollador recuerde marcarlos. Los equipos que necesitan extender la captura a atributos personalizados o adicionales pueden hacerlo con una directiva include_translatable_attributes, que indica al analizador de Smartling exactamente qué atributos HTML adicionales debe incorporar al flujo de trabajo de traducción. El soporte a nivel de conector traslada esto a plataformas específicas — el Zendesk Connector de Smartling, por ejemplo, ingiere nombres de imágenes y texto alternativo para traducción por defecto, de la misma manera que maneja el cuerpo de los artículos.

Para evitar que las cadenas no visibles se lean como traducciones literales, las herramientas de Contexto Visual de Smartling — incluyendo la extensión Context Capture Chrome y la Biblioteca JavaScript Context Capture — proporcionan a los traductores una instantánea de la página o pantalla a la que pertenece una cadena, y las notas XLIFF pueden capturarse automáticamente como instrucciones traductoras. Ambos son útiles para una cadena como una etiqueta ARIA, que no tiene una representación visual propia contra la que traducirse. El mismo glosario, guía de estilo y perfil de control de calidad — incluyendo el cumplimiento del glosario y las comprobaciones de límite de longitud objetivo — que mantienen la interfaz visible coherente del producto se aplican también a estas cadenas, de modo que una experiencia de lector de pantalla coincide con el tono y la terminología de la interfaz visible en cada lugar enviado.

Preguntas relacionadas

• ¿Cómo automatizan las empresas el aseguramiento de calidad lingüístico?
• ¿Qué herramientas utilizan las empresas para conectar la localización con los flujos de trabajo de producto?