Quem não consegue usar seu produto não aparece no dashboard

Todo dashboard responde a uma pergunta: o que fizeram as pessoas que chegaram até aqui? Ele não responde o que aconteceu com quem tentou e não conseguiu. Essas pessoas somem dos números, e é por isso que ninguém sente falta delas.

Resumo rápido: o dashboard mede quem conseguiu usar o produto. Quem esbarra em uma barreira de acessibilidade sai sem deixar rastro, então o problema não aparece como erro. É um viés de sobrevivência. A saída é medir os pontos de abandono, testar os fluxos principais e tratar a ausência de dados como pista.

O dashboard conta quem chegou, não quem tentou

Um funil mostra quantas pessoas passaram de uma etapa para a outra. Se 100 pessoas abrem o formulário e 40 o concluem, o relatório mostra os 40. Os outros 60 viram uma taxa de abandono.

Essa taxa mistura motivos muito diferentes. Uma pessoa desistiu do preço, outra foi interrompida, outra não conseguiu preencher o campo porque o leitor de tela não anunciou o erro. No gráfico, as três são iguais.

Esse padrão tem nome: viés de sobrevivência. Você analisa só quem passou pelo filtro e conclui que o filtro não existe. Aqui, o filtro é a barreira de acessibilidade.

Quantas pessoas ficam de fora

Segundo a PNAD Contínua de 2022, o Brasil tinha 18,6 milhões de pessoas com deficiência. Elas somam 8,9% da população de 2 anos ou mais. O dado consta na publicação do IBGE Pessoas com deficiência têm menor acesso à educação, ao trabalho e à renda (divulgada em 2023, consultada em 17/10/2026).

O critério do IBGE é restrito. Conta quem respondeu ter muita dificuldade ou não conseguir de modo algum em ao menos uma das atividades investigadas. O instituto avisa que a pesquisa não é comparável com levantamentos anteriores, por mudanças na pergunta e na faixa etária.

Dois cuidados sobre o uso desse número:

• Ele descreve a população do país, não o público do seu produto. A fatia real depende de quem você atende.
• Ele não cobre limitações temporárias ou de contexto, como um braço quebrado ou uma tela sob sol forte.

Não uso o número para prometer ganho de conversão. Uso para mostrar que a pergunta "isso afeta muita gente?" tem uma resposta mensurável, e que ela não é "uma minoria irrelevante".

As barreiras mais comuns são básicas

Você pode imaginar que a barreira exige um cenário raro. Os dados de varredura automática indicam outra coisa.

O WebAIM Million analisou, em fevereiro de 2025, a página inicial de um milhão de sites. Em 94,8% delas, a ferramenta detectou falhas de WCAG 2. As mais frequentes foram:

• texto com baixo contraste, em 79,1% das páginas;
• imagens sem texto alternativo, em 55,5%;
• campos de formulário sem rótulo, em 48,2%;
• links vazios, em 45,4%;
• botões vazios, em 29,6%.

O próprio WebAIM adverte que nenhuma ferramenta automática detecta tudo, e que a ausência de erros detectados não prova que a página seja acessível. Também vale notar que o estudo mede páginas iniciais, não fluxos autenticados nem checkouts.

Esses números não dizem que o seu produto tem o problema. Dizem que o problema é comum, e que formulários e botões estão entre os pontos mais afetados. É onde a conversão acontece.

Como a barreira vira ausência nos dados

Vejo três mecanismos pelos quais a barreira desaparece do relatório. São minha leitura, não resultados medidos.

1. Abandono sem erro registrado. Se o campo falha para um leitor de tela, o sistema não registra erro algum. A pessoa fecha a aba. O evento de saída é igual ao de quem se distraiu.

2. Métricas que filtram o engajamento. No GA4, os relatórios mostram usuários ativos, que dependem de engajamento. Quem sai em poucos segundos pode contar no total e não no ativo. Expliquei a diferença no artigo Por que Amplitude e GA4 não mostram o mesmo número?.

3. Testes A/B que medem só quem consegue usar a variante. Um teste compara conversão entre variantes. Se uma variante cria uma barreira nova, parte do público some do funil, e o resultado reflete só quem passou. O vencedor pode ser o que mais exclui.

O que não afirmo

Não sei quanto o seu produto perde por causa de acessibilidade, e ninguém sabe sem medir. Não existe um percentual genérico que eu possa citar com segurança, e inventar um seria o mesmo erro que o artigo critica.

Também não proponho identificar quem usa tecnologia assistiva. Informação sobre deficiência pode ser considerada dado pessoal sensível pela LGPD. Tentar detectar isso por analytics cria risco jurídico e ético. Converse com o jurídico antes de coletar qualquer sinal do tipo.

O que dá para fazer é medir onde o fluxo falha, sem saber quem falhou.

Como começar a medir sem coletar dado sensível

1. Registre os erros de formulário. Crie eventos para erro de validação exibido, por campo. Se um campo concentra erros, investigue.
2. Meça o abandono por etapa, não só o total. Procure etapas em que a saída é desproporcional à complexidade.
3. Teste os três fluxos mais importantes só com teclado. Cadastro, pagamento e o principal fluxo de uso. Se você não chega ao fim sem o mouse, a barreira existe.
4. Faça o mesmo com um leitor de tela. NVDA, no Windows, é gratuito. Veja se o erro de um campo é anunciado.
5. Leia os canais de suporte. Reclamações como "o botão não responde" ou "não consigo enviar" costumam apontar a barreira antes do dashboard.
6. Compare a conversão antes e depois de cada correção, usando a sua linha de base. Não use um número de outro produto como meta.

O que fazer agora

Escolha o fluxo que mais importa para o seu negócio e percorra-o só com o teclado. Anote cada ponto em que travar. Esse é o primeiro passo, não custa nada além do seu tempo, e mostra o que o dashboard não mostra.