O idioma do fluxo de verificação: o passo que a tradução esquece

A verificação de identidade é o momento de maior fricção do onboarding: pede câmera, documento na mão, enquadramento, luz, e tudo em tempo real. É também o passo em que o usuário mais depende de instruções: aproxime o rosto, vire o documento, procure um lugar mais iluminado. Instrução que a pessoa não entende não vira só desconforto: vira captura errada, tentativa repetida, chamado de suporte e abandono no meio do funil.

Agora componha isso com o público real de uma operação digital: o turista abrindo uma carteira de pagamento, o imigrante abrindo conta, o cliente internacional de um marketplace. Para essas pessoas, o português da interface é segunda ou terceira língua, e o momento em que a compreensão mais importa é exatamente o de apontar a câmera. O idioma do fluxo de verificação não é detalhe cosmético; é requisito funcional, com norma técnica publicada por trás.

Traduzir a landing e esquecer o meio do funil

O padrão de quebra é sempre o mesmo. A página institucional foi traduzida, o cadastro foi traduzido, e o passo de verificação ficou em português, porque o componente veio de um fornecedor, ou porque o time tratou a etapa como caixa-preta. Do ponto de vista de quem usa, o produto trocou de língua no momento mais sensível: aquele em que se entrega documento e rosto.

Além da compreensão, há o susto. Usuário treinado a desconfiar de golpe interpreta mudança abrupta de idioma como sinal de página errada, e o passo de verificação é justamente onde a desconfiança custa mais caro. Coerência de idioma ao longo do funil é também um sinal de legitimidade que o produto emite, ou deixa de emitir.

Instrução de captura não é texto de leitura

Texto institucional mal traduzido irrita; instrução de captura incompreendida quebra a tarefa. A captura é uma sequência sensório-motora executada em janela curta: entender a ordem, executar o gesto, reagir ao retorno da tela. Quem não entende a mensagem de erro repete o mesmo erro, e o fluxo de recaptura perde a sua premissa, porque a segunda chance só funciona quando a mensagem ensina o que corrigir. Mensagem que ensina numa língua que o usuário não lê não ensina nada.

A lógica é a mesma da acessibilidade: instrução incompreensível é barreira, tão concreta quanto as barreiras sensoriais e motoras da captura. E o funil, visto de fora, registra tudo do mesmo jeito: gente legítima que não completou, sem nenhum campo dizendo por quê.

O que a norma pede: lang, WCAG 3.1.1 e 3.1.2

O WCAG (Web Content Accessibility Guidelines) 2.1, do W3C, o consórcio que padroniza a web, dedica dois critérios ao assunto. O critério 3.1.1, Language of Page, nível A, exige que o idioma humano padrão de cada página possa ser determinado programaticamente; a técnica correspondente é declarar o atributo lang no elemento raiz do documento, a técnica H57 do W3C. O critério 3.1.2, Language of Parts, nível AA, estende a exigência a cada trecho do conteúdo, com exceções para nomes próprios, termos técnicos, palavras de idioma indeterminado e expressões incorporadas ao vernáculo do texto ao redor.

Isso não é burocracia de marcação. O leitor de tela escolhe o motor de pronúncia pelo atributo lang: página em espanhol declarada como português sai pronunciada de forma ininteligível para quem depende de áudio. E o critério de partes tem um caso de uso direto em verificação: componente embarcado em página de terceiro. Se a página do cliente está em inglês e o passo de verificação roda em espanhol, a subárvore do componente precisa declarar o próprio idioma, ou a tecnologia assistiva lê uma coisa com a fonética da outra. Para empresas brasileiras, vale lembrar que acessibilidade em sítios de empresas é obrigação do artigo 63 da Lei 13.146/2015, a Lei Brasileira de Inclusão, e as diretrizes internacionais que ela invoca apontam, na prática, para exatamente esses critérios.

Consistência entre widget, e-mail e SMS

O fluxo de verificação não vive só na tela. Ele manda e-mail de confirmação, dispara lembrete quando a verificação fica abandonada, envia código por mensagem de texto (SMS). Cada um desses canais costuma sair de um sistema diferente, com templates próprios, e é aí que a coerência morre: sessão de verificação em espanhol, lembrete em português, e-mail final em inglês.

O custo é dobrado. Primeiro, o canal perde a função: lembrete que a pessoa não entende não traz ninguém de volta. Segundo, a mistura de idiomas entre mensagens do mesmo processo é um padrão clássico de comunicação fraudulenta, e o usuário atento descarta como golpe justamente a mensagem legítima. A regra de desenho que resolve: o idioma é atributo da verificação, não do template. Toda mensagem que fala de uma verificação específica herda o idioma daquela sessão, seja qual for o sistema que a dispara.

Idioma congelado por sessão

Pior do que idioma errado é idioma que troca no meio. O cenário típico: a sessão começa em espanhol por parâmetro explícito, o usuário erra uma captura, a página recarrega, e a detecção automática pelo navegador devolve o passo seguinte em português. A pessoa que estava no meio de uma tarefa tensa passa a duvidar da página, e a tarefa quebra.

O desenho que evita isso tem três camadas. A conta define quais idiomas o fluxo oferece. A sessão nasce com um idioma resolvido, vindo de parâmetro explícito na criação, de preferência do usuário ou do padrão da conta, nessa ordem. E a escolha congela: a sessão morre no idioma em que nasceu, inclusive na recaptura e nas mensagens que ela dispara. Detecção pelo navegador serve como palpite inicial na ausência de sinal melhor, nunca como decisão contínua reavaliada a cada tela. Na UNIFOKAL, por exemplo, o widget de verificação fala português, inglês e espanhol, o cliente configura por conta o que oferece, e o idioma resolvido no início da sessão fica congelado até o fim dela: uma escolha de desenho para o meio do funil não trocar de língua com o usuário.

A régua de teste cabe numa frase: percorra o fluxo inteiro no segundo idioma, da página inicial ao último e-mail, e procure o ponto em que o produto troca de língua sem ser convidado. Se esse ponto existe, ele fica quase sempre no passo de verificação, e é lá que o funil está pagando por ele.

Fontes citadas

• WCAG 2.1, W3C, critérios 3.1.1 (Language of Page, nível A) e 3.1.2 (Language of Parts, nível AA): w3.org
• Técnica H57 do WCAG, uso do atributo de idioma no elemento raiz da página, W3C: w3.org
• Lei 13.146/2015, a Lei Brasileira de Inclusão, artigo 63, sobre acessibilidade nos sítios de empresas: planalto.gov.br