Uma Startup Na Area De Saude E Acessibilidade

Construindo uma solução de saúde acessível: o que ninguém te conta

O mercado de saúde digital está lotado. O problema é que a maioria dos produtos que chegam lá foram construídos por pessoas que nunca precisaram de uma cadeira de rodas, nunca tiveram dificuldade para ler uma tela pequena com os olhos tremidos ou nunca dependeram de um leitor de tela para fazer algo simples como marcar um horário médico. Isso gera produtos que funcionam na teoria e falham no primeiro dia de uso real. A primeira coisa que precisa ficar clara é que acessibilidade não é um plugin que você instala no final do desenvolvimento. Já vi equipes gastarem semanas tentando "encaixar" legendas, navegação por teclado e contraste em um app que já estava rodando em produção. O resultado foi um remendo que quebrava a experiência para todos os usuários, não só para quem tem deficiência. A abordagem correta é diferente. Você começa com os casos extremos. Não com o usuário médio, mas com os que têm pior experiência possível no seu produto. Se o seu app de telemedicina não funciona com um leitor de telaVoiceOver ou TalkBack, ele não funciona para milhares de pessoas. Ponto. A partir daí, o restante da funcionalidade se desenha com muito mais clareza.

No meu caso, estava revisando um fluxo de agendamento online para um sistema de clínicas quando percebi que o botão de confirmação de consulta tinha apenas um ícone de relógio dentro de um botão sem texto. Para quem usava leitor de tela, aquele botão era simplesmente "botão". Sem contexto, sem ação, sem destino. A solução técnica foi adicionar aria-label e aria-describedby corretamente, mas o problema real era que o designer nem pensou em quem não ia enxergar aquele ícone. Corrigimos em duas horas, mas a lição ficou: acessibilidade precisa ser parte do brief de design, não do QA. Existem algumas armadilhas que aparecem repetidamente e que vale a pena evitar antes que virem problema caro. A primeira é achar que seguir as diretrizes WCAG 2.1 nível AA é suficiente. As diretrizes são um piso, não um teto. Elas cobrem o básico, mas não resolvem problemas reais de interação. Um exemplo: um formulário de cadastro de paciente com campos que mudam dinamicamente conforme a resposta anterior. As diretrizes dizem para usar aria-live, mas na prática você também precisa garantir que o foco não se perca e que a mudança de conteúdo não confunda o usuário que navega por teclado. Isso exige teste manual, não uma verificação automatizada. A segunda armadilha é mais sutil e está relacionada à diversidade de deficiências. Você pode ter um app perfeitamente navegável por teclado e ainda assim ser inutilizável para alguém com tremores nas mãos. Ou ter um design com contraste perfeito e ainda assim falhar para quem tem daltonismo. O teste com usuários reais com deficiência é o único jeito de descobrir essas falhas. Ferramentas automáticas como axe ou Lighthouse cobrem cerca de 30 a 40% dos problemas. Os outros 60 a 70% aparecem só no uso real.

Sobre tecnologia, há uma escolha importante no início que define muito do resto do projeto: você constrói nativo ou usa uma framework híbrida. Apps nativos em iOS e Android têm APIs de acessibilidade mais maduras e consistentes. Flutter e React Native melhoraram muito, mas ainda enfrentam problemas de sincronia entre o acessibilidade do widget e a implementação do sistema operacional. Se o seu público-alvo inclui pessoas que dependem fortemente de tecnologias assistivas, nativo é mais seguro. Se o orçamento é apertado e o produto é simples, uma framework híbrida com testes rigorosos pode funcionar, mas reserve tempo extra para isso. O fluxo de validação que eu recomendo funciona assim. Primeira fase: revisões de design com checklists de acessibilidade integradas. Segunda fase: protótipo navegável testado com pelo menos cinco usuários com diferentes tipos de deficiência. Terceira fase: implementação com testes automatizados em cada pull request. Quarta fase: testes manuais com screen readers em dispositivos reais, não em emuladores. Quinta fase: lançamento com um canal aberto de feedback específico para acessibilidade. A fase dois é onde a maioria das startups erra. Elas testam com dois ou três usuários e acham que está bom. A variabilidade entre pessoas com deficiência é enorme. Um usuário cego que usa leitor de tela pode ter anos de experiência e conhecimento técnico avançado. Outro pode ser um idoso que nunca touchou um smartphone antes. Seus produtos precisam funcionar para ambos, e você só descobre isso testando com um grupo diverso.

Outro ponto que merece atenção é a documentação. Se o seu produto tem uma API, ela precisa ser documentada com exemplos de uso acessível. Se é um app, os guides de navegação precisam considerar usuários de teclado e de voz. Isso parece óbvio, mas a maioria das startups de saúde negligencia porque o foco cai sobre funcionalidades clínicas. A verdade é que uma funcionalidade clínica inacessível não é uma funcionalidade clínica, é uma barreira. Se você está começando agora, não tente resolver tudo de uma vez. Escolha um problema específico de acessibilidade em saúde — talvez o agendamento online, talvez o acesso a resultados de exames, talvez a comunicação com profissionais — e resolva bem. Produtos de saúde com acessibilidade genuína são raros. O mercado está cheio de apps bonitos que ninguém com deficiência consegue usar. O que diferencia uma startup que consegue escala nessa área é a velocidade de iteração baseada no feedback real. Não o feedback de consultoria de acessibilidade que entrega um relatório bonito com 87 issues mapeadas. O feedback de um usuário dizendo que não conseguiu marcar consulta porque o botão seguinte desaparecia da tela quando o teclado virtual abria. Esses detalhes pequenos são os que fazem ou quebram um produto nessa área.