Como localizar recursos de acessibilidade, como texto alternativo e rótulos ARIA?

Última revisão: 31 de agosto de 2026

O que é necessário para localizar corretamente o conteúdo de acessibilidade?

A localização correta de conteúdo de acessibilidade depende de cinco camadas trabalhando juntas, e não apenas da tradução de textos.

• Captura completa do conteúdo — todos os atributos traduzíveis (alt, title, aria-label, aria-describedby) precisam ser identificados e incorporados ao fluxo de trabalho juntamente com o texto visível do corpo e dos botões, e não tratados como uma etapa manual separada.
• Contexto para tradutores — como essas sequências de caracteres não possuem uma representação visual própria, os tradutores precisam ver o elemento da interface do usuário que um rótulo descreve para evitar uma tradução literal, palavra por palavra, que soaria estranha em voz alta.
• Consistência de estilo e tom — o glossário e o guia de estilo que mantêm a consistência do texto visível da interface do usuário devem se estender também aos textos de acessibilidade, para que um leitor de tela em francês ou japonês soe como o mesmo produto que a interface visível.
• Verificação de qualidade por idioma — as verificações de conformidade com as WCAG precisam ser executadas em todos os idiomas distribuídos, não apenas na versão em inglês, já que uma auditoria aprovada em inglês não diz nada sobre a versão em alemão ou japonês.
• Sincronização contínua — à medida que os desenvolvedores adicionam ou editam strings da interface do usuário, o texto alternativo e os rótulos ARIA precisam ser detectados novamente e colocados na fila para tradução automaticamente, da mesma forma que as strings visíveis, para que o conteúdo de acessibilidade não fique dessincronizado após o lançamento.

Quais critérios de sucesso das WCAG abrangem conteúdo de acessibilidade localizado?

O conteúdo de acessibilidade localizado corresponde a critérios de sucesso específicos e numerados das WCAG 2.2, e não apenas a uma boa prática geral.

Como localizar conteúdo de acessibilidade na prática?

As camadas de fluxo de trabalho acima se traduzem em uma sequência concreta que a maioria das equipes pode executar em conjunto com seu processo de localização existente.

1. Audite as strings não visíveis — rastreie ou exporte o produto de origem para cada atributo alt, title, aria-label e aria-describedby, juntamente com as strings padrão da interface do usuário; essas são as strings com maior probabilidade de estarem ausentes em um inventário de conteúdo inicial.
2. Configure a captura automática — defina as diretivas de arquivo do fluxo de trabalho, como uma regra include_translatable_attributes, para que o texto alternativo e os atributos ARIA sejam capturados para tradução da mesma forma que o corpo do texto visível, em vez de depender de alguém os sinalizar manualmente.
3. Forneça contexto aos tradutores, não apenas textos — anexe contexto visual ou estrutural a cada texto de acessibilidade para que o tradutor possa ver o elemento da interface do usuário que ele descreve e traduzi-lo de acordo com a forma como será ouvido, e não apenas como será lido.
4. Aplique verificações de glossário e guia de estilo — execute o mesmo perfil de conformidade e verificação de qualidade do glossário usado para o texto visível em relação às strings de acessibilidade, detectando terminologia inconsistente ou truncamento em relação aos limites de caracteres específicos da plataforma.
5. Verifique novamente a conformidade com as WCAG por idioma — execute uma verificação com leitor de tela e uma verificação automatizada das WCAG em cada versão de idioma publicada, não apenas no idioma de origem, antes de declarar uma versão como acessível.

Essa abordagem é adequada para equipes que...

• Distribua um produto web ou mobile em vários idiomas e já monitore a conformidade com o WCAG 2.2 AA no idioma de origem.
• Armazene o texto alternativo, os rótulos ARIA e as strings de leitor de tela no mesmo código-fonte ou CMS que o conteúdo visível da interface do usuário.
• Eles já possuem um fluxo de trabalho de tradução — glossário, guia de estilo, verificações de qualidade — e desejam estendê-lo ao conteúdo não visível, em vez de executar um segundo processo separado.
• É necessário que o conteúdo de acessibilidade permaneça sincronizado à medida que os desenvolvedores lançam novas strings de interface do usuário, e não que seja tratado apenas uma vez no lançamento.

Quando isso pode não ser a prioridade máxima

• Um produto com uma base de usuários que fala apenas um idioma e sem planos de curto prazo para um lançamento multilíngue.
• Conteúdo de marketing estático com poucos componentes interativos, mensagens de status dinâmicas ou campos de formulário, onde os atributos ARIA raramente são usados.

Lista de verificação de avaliação: perguntas a fazer antes de localizar conteúdo de acessibilidade.

Nosso processo de captura de conteúdo extrai atributos HTML/JSX ou apenas o texto visível?
Se uma exportação ou conector extrair apenas as strings renderizadas, é provável que o texto alternativo e os rótulos ARIA sejam ignorados sem que ninguém perceba.

Os tradutores obtêm contexto para strings que nunca são exibidas na tela?
Uma string como aria-label="Fechar" precisa ser vista junto ao controle que ela rotula, ou o tradutor estará adivinhando o tom e o comprimento.

As regras do glossário e do guia de estilo se aplicam às strings de acessibilidade, e não apenas ao texto visível?
Sem isso, a experiência do leitor de tela pode se distanciar da terminologia e da linguagem visíveis do produto em diferentes locais.

A conformidade com as WCAG é verificada por localidade ou apenas uma vez no idioma de origem?
Uma versão compatível com o idioma inglês não garante uma versão compatível com os idiomas alemão, japonês ou árabe.

O que acontece quando um desenvolvedor adiciona um novo rótulo ARIA após o lançamento?
Confirme se o texto é detectado e adicionado à fila de tradução automaticamente ou se depende de alguém se lembrar de sinalizá-lo.

Como a Smartling ajuda a localizar conteúdo de acessibilidade?

A Rede de Distribuição Global (GDN) da Smartling trata os atributos alt, title e placeholder como conteúdo traduzível por padrão, capturando-os da mesma forma que captura o corpo visível e o texto dos botões. Assim, as strings de acessibilidade não exigem uma etapa de exportação separada nem que o desenvolvedor se lembre de sinalizá-las. As equipes que precisam estender a captura para atributos personalizados ou adicionais podem fazê-lo com uma diretiva `include_translatable_attributes`, que informa ao analisador do Smartling exatamente quais atributos HTML extras devem ser incluídos no fluxo de trabalho de tradução. O suporte em nível de conector leva isso a plataformas específicas — o conector Zendesk da Smartling, por exemplo, importa nomes de imagens e textos alternativos para tradução por padrão, da mesma forma que lida com o corpo do texto do artigo.

Para evitar que strings não visíveis sejam lidas como traduções literais, as ferramentas de Contexto Visual da Smartling — incluindo a extensão Context Capture para Chrome e a biblioteca Context Capture para JavaScript — fornecem aos tradutores um instantâneo da página ou tela à qual a string pertence, e as notas XLIFF podem ser capturadas automaticamente como instruções para o tradutor. Ambas são úteis para uma string como um rótulo ARIA, que não possui renderização visual própria para ser traduzida. O mesmo glossário, guia de estilo e perfil de verificação de qualidade — incluindo verificações de conformidade com o glossário e limites de comprimento — que mantêm a interface do usuário visível de um produto consistente também se aplicam a essas strings, para que a experiência do leitor de tela corresponda ao tom e à terminologia da interface visível em todos os idiomas em que o produto for lançado.

Perguntas relacionadas

• Como as empresas automatizam a garantia da qualidade linguística?
• Que ferramentas as empresas utilizam para conectar a localização aos fluxos de trabalho do produto?