Acessibilidade não é checklist, é decisão de design

A sessão que mudou tudo

Jason Han, designer de produto, assistiu a uma sessão de usabilidade em que Daniel, um homem cego que usa o leitor de tela JAWS há mais de uma década, tentava reservar um voo no produto da equipe. O seletor de datas anunciava-se apenas como "button", sem contexto sobre o que abria ou como navegar. O mapa de seleção de assentos, construído como elemento canvas sem estrutura acessível, era completamente invisível ao leitor de tela. Daniel levou onze minutos para completar um fluxo que, em média, levava menos de noventa segundos. Ninguém na sala era uma pessoa ruim - a acessibilidade havia sido discutida em quase todas as reuniões de planejamento por dois anos e despriorizada em todas elas, sempre com uma justificativa que soava responsável: "depois do redesign", "quando o fluxo central estabilizar", "no próximo trimestre".

A desculpa que soa como razão

Han identifica que a acessibilidade raramente é explicitamente rejeitada em documentos de planejamento. Ela simplesmente nunca aparece na lista, e sua ausência faz a decisão silenciosamente. A desculpa mais comum - "vamos resolver depois do lançamento" - quase nunca se concretiza, porque as prioridades concorrentes que a tornavam inconveniente antes não desaparecem; são substituídas por outras com o mesmo formato. A segunda desculpa, "nossos usuários não precisam disso", trata a deficiência como um caso de nicho, quando a OMS estima que mais de um bilhão de pessoas vivem com alguma forma de deficiência globalmente. O problema não é que as equipes pesem acessibilidade contra outras prioridades e escolham conscientemente outra coisa - é que ela raramente chega a ser pesada.

O que "conformidade" realmente esconde

Han faz uma distinção crucial entre conformidade com as WCAG e usabilidade real para pessoas com deficiência. Ferramentas automatizadas capturam cerca de um terço dos problemas reais de acessibilidade, porque grande parte do que torna uma interface utilizável depende de contexto, sequência e intenção que um script não consegue avaliar. O seletor de datas de Daniel passava em scans automatizados - tinha atributo de role e label -, mas na prática era funcionalmente inútil. A equipe mudou sua definição de "pronto": o scan automatizado passou a ser o piso mínimo, não a evidência de acessibilidade.

Por que a acessibilidade perde a briga por prioridade

Parte da resposta é estrutural: interfaces inacessíveis não geram feedback loops visíveis como um checkout quebrado, porque as pessoas afetadas estão sistematicamente sub-representadas nos canais que normalmente surfacem problemas. Parte é psicológica: decisões de priorização são feitas com base no que é visível, urgente e pessoalmente relacionável para quem está na sala. Han também aponta um problema de enquadramento de negócio - tratar acessibilidade apenas como mitigação de risco legal garante trabalho reativo e mínimo, enquanto ignorar o risco legal perde a argumentação com quem controla o orçamento. A solução que funcionou foi recusar a separação entre o caso ético e o caso de negócio, apresentando a gravação de Daniel em uma sala de决策-makers.

Um framework para tornar acessibilidade uma decisão

Han implementou quatro mudanças: mover a revisão de acessibilidade para a fase de design (não QA); atribuir ownership explícito a uma pessoa com autoridade para bloquear um lançamento; testar com usuários reais de tecnologia assistiva em painel recorrente; e tratar "não tivemos tempo" com o mesmo escrutínio de qualquer outro requisito não cumprido. Nenhuma mudança exigiu nova tecnologia ou grande aumento de orçamento - exigiram a disposição de parar de tratar acessibilidade como um acréscimo agradável e começar a tratá-la como parte da definição de trabalho real. Como observa Robin Christopherson, da AbilityNet, falhas de acessibilidade raramente são um problema de recursos e quase sempre um problema de prioridade.