De onde vem a regra do botão desabilitado, e por que ela causa problemas de acessibilidade

A regra do botão desabilitado não nasceu para botões. A versão escrita mais antiga que se conhece é para menus, nas diretrizes de interface do Lisa, da Apple. O documento Lisa User Interface Standards, de setembro de 1980, assinado por Bill Atkinson, tinha uma seção chamada "Menu items that do nothing". Ela permitia esmaecer um comando sem efeito, mas dizia que o item ainda podia ser invocado se o usuário quisesse. Em 1983, o manual do LisaDraw já registrava o contrário: item esmaecido não pode ser escolhido. Nenhum documento do Lisa disponível hoje explica quando nem por que a regra mudou.

Dali a regra passou ao Macintosh (o Inside Macintosh, de 1985, aplica o mesmo princípio a itens de diálogo) e ao HTML 4, de 1997, com o atributo disabled: controles desabilitados não recebem foco e são pulados na navegação por Tab. A comparação entre oito design systems mostra o efeito prático. O texto desabilitado fica entre 1,36:1 e 3,35:1 de contraste, e em todos os oito o botão não é clicável nem alcançável pelo teclado. Primer, Atlassian e GOV.UK recomendam evitar o estado. Material (softDisabled) e Primer (inactive) criaram versões que continuam focáveis, e o aria-disabled segue a mesma lógica, deixando ao dev o trabalho de bloquear a ação.

Para quem desenha formulários e componentes, a leitura é que o cinza não explica nada. Usuário de teclado ou leitor de tela pode nem descobrir que o botão existe, e muito menos saber o que falta. Na prática, vale considerar manter o botão acionável com mensagens de validação claras, ou usar um estado focável quando a causa puder ser resolvida. O estado estrito fica para ações que realmente não podem ser tentadas. Isso custa mais para construir, e o design system precisa assumir esse custo.