Blog

Acessibilidade em verificação de identidade: o funil que exclui também reprova

UNIFOKAL6 min de leituraProduto e integração

A Lei Brasileira de Inclusão exige acessibilidade nos sites de empresas, e a captura de selfie e documento é a etapa que mais exclui. O que o WCAG 2.2 pede num fluxo de verificação.

Fluxo de verificação de identidade é feito de tarefas sensoriais e motoras: enquadrar o rosto numa moldura, segurar o documento parado, reagir a instruções na tela em poucos segundos. Para uma parte real dos usuários, pessoa cega ou com baixa visão, com tremor nas mãos, com mobilidade reduzida, ou simplesmente com mais idade e menos intimidade com câmera, cada uma dessas tarefas é uma barreira.

Barreira em verificação não vira só frustração: vira recusa. O usuário legítimo que não consegue completar a captura é indistinguível, nos números do funil, do fraudador que abandonou no meio, e o funil registra os dois como perda. Acessibilidade, nesse contexto, é ao mesmo tempo obrigação legal, requisito de justiça do processo e alavanca de conversão. Este artigo percorre os três ângulos: o que a lei exige, quais critérios técnicos mais importam nesse tipo de fluxo e o que muda no desenho da captura.

A obrigação legal existe e alcança empresas privadas

A Lei 13.146/2015, a LBI (Lei Brasileira de Inclusão), determina no artigo 63 que é obrigatória a acessibilidade nos sítios da internet mantidos por empresas com sede ou representação comercial no país, conforme as melhores práticas e diretrizes de acessibilidade adotadas internacionalmente. Não é norma restrita ao setor público: o destinatário expresso é a empresa. As "diretrizes adotadas internacionalmente", na prática, apontam para o WCAG (Web Content Accessibility Guidelines), do W3C, o consórcio que padroniza a web, hoje na versão 2.2. No governo federal, o eMAG, Modelo de Acessibilidade em Governo Eletrônico, adapta essas diretrizes para os sítios públicos, e serve de referência de como uma régua internacional vira norma local.

Quem opera onboarding digital, portanto, não está diante de uma boa prática opcional: está diante do artigo 63 e de uma régua técnica publicada e verificável.

Os critérios do WCAG que mais pegam em captura

O WCAG 2.2 tem dezenas de critérios; quatro concentram os problemas típicos de um fluxo de câmera:

  • Contraste (critério 1.4.3, nível AA): texto comum precisa de razão de contraste de pelo menos 4,5:1 contra o fundo. Instrução de captura em cinza claro flutuando sobre o vídeo da câmera falha com folga, porque o fundo muda a cada quadro; texto de orientação precisa de fundo próprio.
  • Tempo ajustável (critério 2.2.1, nível A): limite de tempo deve poder ser desligado, ajustado ou estendido, salvo exceções estritas. Contagem regressiva de captura automática e sessão que expira em silêncio são exatamente o alvo do critério.
  • Gestos de ponteiro (critério 2.5.1, nível A): funcionalidade que exige gesto de trajetória ou multitoque precisa de alternativa de ponteiro simples. O espírito vale para desafios de movimento: se o fluxo exige virar a cabeça com velocidade, precisa existir caminho que não exija.
  • Tamanho do alvo (critério 2.5.8, nível AA, novo na versão 2.2): alvo de toque de pelo menos 24 por 24 pixels CSS, salvo exceções. O botão do obturador e o link "não consigo fazer isso agora" não podem ser miniaturas.

Por baixo desses, os fundamentos de sempre: alternativa em texto para conteúdo não textual (critério 1.1.1) e nome, função e estado expostos à tecnologia assistiva (critério 4.1.2). A moldura que fica verde quando o rosto entra no enquadramento comunica por cor e por nada mais; o leitor de tela precisa anunciar o mesmo estado em palavras, ou o usuário cego fica diante de um aplicativo mudo esperando algo que ele não sabe o quê.

O que muda no desenho da captura

Traduzindo os critérios em decisões concretas de produto:

  • Anunciar estado, não só pintar. Cada transição relevante, rosto detectado, documento enquadrado, foto enviada, análise concluída, vira texto anunciado por leitor de tela, com região dinâmica marcada para que a mudança seja falada sem roubar o foco.
  • Erro que ensina. "Falha na captura" não orienta ninguém; "a foto ficou escura, procure um lugar mais iluminado" orienta qualquer pessoa e reduz repetição. É o mesmo princípio do fluxo de recaptura: a segunda chance só funciona se a pessoa entende o que corrigir na primeira.
  • Sem gesto rápido obrigatório. Prova de vida que só aceita movimento veloz exclui quem tem mobilidade reduzida. Alternativa passiva, ou de movimento lento com janela generosa, precisa existir no fluxo, não em um telefone de suporte.
  • Tempo sob controle do usuário. Captura automática com contagem precisa de botão de captura manual; sessão que expira precisa avisar e oferecer extensão.
  • Operável por teclado e com foco visível. No desktop, o fluxo inteiro precisa andar sem mouse; no celular, sem depender de toque de precisão.

Nada disso enfraquece a segurança. A decisão sobre o conteúdo capturado, o rosto é vivo, o documento é íntegro, continua na análise; o que muda é o caminho até a captura, que deixa de exigir habilidades que não têm relação com identidade.

Acessibilidade é conversão com outro nome

Cada barreira de captura aparece nos números como abandono ou como falso positivo: gente legítima que o funil perdeu por razão nenhuma de risco. E as melhorias transbordam para todo mundo, porque limitação situacional é o caso geral: sol na tela é baixa visão temporária, mão ocupada é limitação motora temporária, ambiente barulhento é surdez temporária. O texto de erro claro, o tempo generoso e o alvo grande convertem melhor para todos os usuários, não só para quem a LBI protege.

Quem integra por widget pronto herda essas decisões do fornecedor, para o bem e para o mal, então vale perguntar na avaliação: como o componente se comporta com leitor de tela? O contraste do tema é configurável? Existe alternativa ao gesto rápido? Na UNIFOKAL, por exemplo, o widget de captura trata isso como requisito do componente: tema com contraste configurável pelo cliente e estados da captura anunciados em rótulos para leitor de tela, em vez de acessibilidade remendada por cima depois.

A régua final é simples de enunciar: ninguém deveria ser reprovado numa verificação de identidade por causa do corpo que tem. O artigo 63 da LBI faz dessa régua uma obrigação; o WCAG faz dela uma lista de verificação; e o funil, medido com honestidade, faz dela um argumento de receita.

Fontes citadas