Onde a verificação aparece na página, e por que isso decide o funil

Toda equipe que integra verificação de identidade mede as mesmas duas coisas: quantas sessões foram criadas e quantas terminaram com decisão. A distância entre os dois números vira um relatório de abandono, e o abandono é tratado como problema de tela: o texto está confuso, a captura está difícil, o passo está longo. Quase sempre é isso mesmo. Mas existe uma classe inteira de perda que esse relatório não sabe contar, porque ela acontece antes da primeira tela, e some exatamente no ponto onde ninguém olha.

Entre criar a sessão no seu servidor e a pessoa apontar a câmera existe uma etapa que não é sua nem nossa: a sua página. É lá que o componente de verificação precisa aparecer, dentro de um layout com anos de história, folhas de estilo herdadas, e um comportamento de rolagem que ninguém revisita desde o último redesenho. Se o componente não aparece, ou aparece num lugar que o visitante não alcança, a sessão criada e a sessão abandonada ficam indistinguíveis no relatório. As duas são "criada e não concluída".

Este artigo é sobre essa etapa. Ele trata de três decisões que parecem estéticas e são de funil: onde o componente aparece, quem decide o momento de abri-lo e como saber, depois, se ele apareceu.

As três formas de aparecer, e para quem cada uma serve

A forma mais comum é a embutida: você reserva um lugar na página e o componente entra ali, dentro do seu fluxo de cadastro, na sequência natural de uma jornada que já existe. É a melhor escolha quando a verificação é obrigatória e faz parte do caminho: a pessoa chegou ali para se cadastrar, e verificar é o próximo passo, não um convite.

A segunda forma é o botão flutuante, fixo num canto da tela, que abre a verificação quando a pessoa pedir. Ela serve a um caso diferente: o produto em que a verificação é opcional, ou posterior, ou disparada por um evento que não é o cadastro. Conta bancária que só exige verificação ao passar de um limite, marketplace que verifica o vendedor depois do primeiro anúncio, plataforma que libera saque mediante confirmação de identidade. Nesses produtos, embutir a verificação no meio do fluxo principal atrapalha quem ainda não precisa dela.

A terceira é a aberta pelo seu botão. O botão continua seu, com o seu texto e o seu estilo, no lugar que o seu design escolheu, e o componente abre quando alguém clica nele. É a forma que respeita um sistema de design rígido, e a única que funciona bem quando o gatilho está numa tabela, num menu ou numa linha de lista que só existe depois de a página carregar.

A decisão entre as três não é de gosto. Ela responde a uma pergunta objetiva: a pessoa chegou nesta tela para se verificar? Se sim, embutido. Se não, um convite que ela aceita quando quiser.

O componente que o seu próprio site esconde

Existe um modo de falha que não aparece em nenhum teste de integração e que, quando acontece, produz exatamente a leitura errada do funil: o componente monta, não dá erro nenhum, e mesmo assim ninguém o vê.

As causas são banais e conhecidas de qualquer pessoa que já encaixou um componente de terceiro num site maduro. Uma regra antiga com seletor mais específico que o do componente. Um contêiner com altura fixa e conteúdo cortado. Um ancestral que cria contexto de posicionamento e muda o significado de elementos que deveriam se posicionar contra a janela, comportamento descrito na especificação CSS Positioned Layout do W3C, que define contra quem um elemento posicionado se resolve. Nenhum desses casos gera exceção, nenhum aparece no console, e o relatório continua dizendo "sessão criada, não concluída".

O ponto para quem integra é esse: abandono e invisibilidade produzem o mesmo número, e só um deles se conserta melhorando a tela. Antes de reescrever a copy do seu fluxo, vale confirmar que a tela chegou a existir para a pessoa.

O degrau de funil que faltava

A correção estrutural desse ponto cego é simples de enunciar e vale a pena exigir de qualquer fornecedor: o funil precisa de um degrau entre "sessão criada" e "verificação concluída", e esse degrau é a interface de verificação apareceu.

Com ele, o relatório passa a responder três perguntas separadas, em vez de uma só:

• criamos sessões que nunca chegaram a aparecer para ninguém? É problema de página, de rota ou de lugar do componente;
• apareceram e ninguém começou? É problema de convite, de contexto ou de momento;
• começaram e não terminaram? Aí sim é a tela, a captura, o texto, a exigência.

Repare que a definição desse degrau muda conforme a forma de aparecer, e isso importa. No modo embutido, a interface aparece quando a página monta. No botão flutuante e no gatilho, o que aparece primeiro é o convite, não a verificação: contar o botão como exibição inflaria o degrau e esconderia justamente o que ele existe para revelar. O degrau honesto é a abertura do painel.

Um detalhe de privacidade que vale cobrar junto: esse degrau não precisa de dado de pessoa nenhum para funcionar. Ele responde "esta sessão viu a tela, neste formato, neste instante", e o identificador da sessão já é opaco. Telemetria de funil que chega pedindo identificador de aparelho, endereço de rede ou agente de navegador está coletando mais do que a pergunta exige, e o princípio da necessidade do artigo 6º, inciso III da Lei 13.709/2018 é claro quanto a limitar o tratamento ao mínimo necessário para a finalidade.

Acessibilidade não é opcional em nenhuma das três formas

Quando a verificação passa a abrir em painel, ela vira uma janela modal, e janela modal tem regras. As práticas de autoria do W3C para o padrão de diálogo são explícitas: o elemento precisa se anunciar como diálogo, receber o foco ao abrir, manter o foco dentro dele enquanto estiver aberto, fechar com a tecla Escape e devolver o foco a quem o abriu ao fechar. A última é a mais esquecida e a mais cara: sem ela, quem navega por teclado fecha o painel e é jogado para o começo do documento, perdendo o lugar na página.

Vale também uma recomendação pela negativa. Nada nesse componente deve abrir, fechar ou pré-carregar por passagem de ponteiro. Eventos de ponteiro disparam em situações que a intuição não prevê, incluindo rolagem de página, e uma interface que reage a isso produz aberturas que a pessoa não pediu. Abrir verificação de identidade é ato deliberado, e o gatilho é o clique.

O que levar desta leitura

Escolha a forma de aparecer pela pergunta certa, que é se a pessoa chegou àquela tela para se verificar. Exija o degrau de funil de exibição, porque sem ele você vai reescrever a copy de uma tela que talvez nunca tenha aparecido. E trate o painel como o que ele é, uma janela modal, com as garantias de foco e teclado que qualquer janela modal deve ter.

Os três formatos e o trecho copiável de cada um estão na documentação do widget. Se a escolha anterior a essa, entre componente pronto e integração direta, ainda estiver aberta, ela está tratada em widget ou API pura, e o que a tela precisa garantir para todo mundo está em acessibilidade em verificação de identidade.

Fontes citadas

• CSS Positioned Layout Module Level 3, especificação do W3C: w3.org
• ARIA Authoring Practices Guide, padrão de diálogo modal, do W3C Web Accessibility Initiative: w3.org
• Web Content Accessibility Guidelines (WCAG) 2.2, recomendação do W3C: w3.org
• Lei 13.709/2018 (Lei Geral de Proteção de Dados Pessoais), artigo 6º: planalto.gov.br