O Que Adianta Ter As Maos E Nao Poder Tocar

A sensação de ter capacidade sem acesso

Existe um ditado popular em português que resume algo que muita gente vive sem conseguir nomear: o que adianta ter as mãos e não poder tocar. Não é uma questão filosófica, é uma situação prática e recorrente em várias áreas. Tecnologia, saúde, educação, trabalho. O padrão se repete com pouca variação. Eu já vi isso na prática quando comecei a trabalhar com acessibilidade digital há alguns anos. Tinha uma equipe capacitada, ferramentas adequadas, orçamento aprovado. Mas o produto final ainda excluía pessoas com deficiência visual porque ninguém tinha testado com leitores de tela reais. As mãos estavam aí, o toque não acontecia.

O que adianta ter as mãos e não poder tocar: casos concretos

Vamos direto aos exemplos. O primeiro que me vem à cabeça é a área da saúde. Tenho um colega que trabalha com telemedicina e relatou um problema específico: plataformas que permitem consulta remota mas não oferecem legenda em Libras nem adaptação para surdos. O médico tem o conhecimento, o paciente tem a necessidade, mas o canal não conecta os dois. Outro exemplo comum é em instituições educacionais. Universidades compram plataformas digitais caras, com recursos sofisticados, mas esquecem de garantir que o conteúdo seja acessível em formato alternativo. Alunos cegos ou com baixa visão ficam do lado de fora. As mãos existem. O toque não. No ambiente corporativo vejo frequentemente o mesmo padrão. Empresas desenvolvem apps internos complexos para gestão, mas omitem totalmente a navegação por teclado ou a compatibilidade com tecnologias assistivas. Funcionários com mobilidade reduzida perdem acesso a ferramentas que seus colegas usam rotineiramente.

Como identificar e corrigir na prática

O ponto de partida é entender que o problema não é falta de mão de obra ou de recursos financeiros. É falta de teste com usuários reais nas condições em que a ferramenta será usada. Eu resolvi isso no meu projeto aplicando um método simples: antes de qualquer entrega, fazer uma sessão de teste com pelo menos três pessoas que utilizam a tecnologia assistiva relevante para o público-alvo. Na minha experiência, esse procedimento costuma reduzir o tempo de correção posterior em cerca de 60%. Sem ele, os ajustes precisam ser feitos após o lançamento, o que encarece o processo e atrasa o cronograma em semanas. Outro ponto importante é envolver especialistas em acessibilidade desde a fase de planejamento, não como verificação final. Quando a acessibilidade entra no fim do ciclo, ela vira um remendo. Quando entra no início, o custo adicional fica entre 5% e 10% do orçamento total, dependendo da complexidade do projeto.

Um caso que marquei foi o desenvolvimento de um sistema de agendamento online. O teste com usuários de leitor de tela revelou que os botões de confirmação não tinham texto alternativo adequado. A solução foi simples: adicionar atributos ARIA label em todos os elementos interativos e garantir que a sequência de tabulação seguisse a ordem lógica da interface. Levou duas horas para corrigir. Se tivesse sido descoberto após o lançamento, levaria dias de retrabalho e uma atualização de versão.

Limitações e cenários onde isso não funciona

É preciso ser honesto sobre o que essa abordagem não resolve. Testes com usuários de tecnologia assistiva melhoram a experiência geral, mas não garantem conformidade total com todas as normas técnicas. O WCAG 2.1 tem critérios que só podem ser verificados por auditoria especializada, como requisitos relacionados a contraste de cor em diferentes condições de iluminação ou compatibilidade com hardware específico. Além disso, em projetos com prazos extremamente apertados, a inclusão de testes de acessibilidade pode ser a primeira item cortado. Isso é um erro crônico. A redução de custo imediato parece tentadora, mas o risco de retrabalho posterior ou de ação judicial por discriminação digital é real e documentado em diversos casos no Brasil. Uma alternativa viável quando o orçamento é realmente limitado é aproveitar ferramentas gratuitas de verificação automática, como o axe DevTools ou o WAVE. Elas não substituem o teste com usuários humanos, mas identificam rapidamente erros óbvios de marcação sem custo adicional. O ideal é combinar as duas abordagens: automação para a triagem inicial e teste humano para os detalhes que a máquina não captura.

O que adianta ter as mãos e não poder tocar é, no fundo, um lembrete de que capacidade sem acesso é apenas potencial desperdiçado. A correção existe. Ela só precisa ser considerada antes da linha de chegada.