A fábula da cegonha e o design de software: Por que sua "acessibilidade" ainda é exclusão

Fala, devs.

Lembram da fábula da raposa e da cegonha? A raposa convida a cegonha para jantar e serve a sopa num prato raso. A cegonha não consegue comer. Depois, a cegonha convida a raposa e serve num vaso estreito. A raposa não alcança.

A moral: quando você projeta só para si mesmo, você exclui quem é diferente.

**Isso é exatamente o que acontece com 90% das implementações de "acessibilidade" em software.**

**O problema não é falta de boa vontade. É falta de lógica arquitetural.**

Quando um dev adiciona `alt=""` em todas as imagens, ou coloca um botão com `aria-label="clique aqui"`, ele acha que está sendo inclusivo. Mas está servindo a sopa no prato raso.

A cegonha (usuário cego, motor, cognitivo) ainda não consegue comer.

**O que acessibilidade de verdade parece:**

• **Canal agnóstico:** a informação chega pelo canal que o usuário tem disponível — visual, sonoro, tátil. Não é "adicionar uma versão alternativa". É arquitetar para múltiplos canais desde o zero.
• **Decisão de arquitetura, não camada de verniz:** acessibilidade adicionada no final é um remendo. Acessibilidade projetada desde o início é uma feature.
• **Feedback de erro acessível:** não adianta destacar o campo em vermelho se o usuário não enxerga. O erro precisa ser anunciado, descrito e acionável via teclado/leitor de tela.

**Por que isso importa pra você, dev?**

Porque mercado de trabalho está cada vez mais exigindo isso. Porque a legislação brasileira (LBI - Lei 13.146/2015) já obriga. E porque um sistema verdadeiramente acessível é simplesmente um sistema melhor — mais semântico, mais testável, mais manutenível.

Tenho trabalhado com inclusão digital há anos e vi de perto o que funciona e o que é só performance de acessibilidade. Se tiver curiosidade, escrevo mais sobre as decisões técnicas concretas.

**O que vocês acham? Alguém já teve que retrofitar acessibilidade num sistema legado?**