Acessibilidade na prática

É fácil tratar acessibilidade como "polimento pra depois do prazo" — mas ela não é sobre deixar a tela mais bonita pra uma minoria. É sobre se uma parte real dos seus usuários — quem navega só com teclado, quem usa leitor de tela, quem tem baixa visão — consegue usar a funcionalidade, não só vê-la.

Label associado a input

Usar só um placeholder como identificação de campo é um erro comum: o placeholder desaparece assim que o usuário começa a digitar, e nem todo leitor de tela o anuncia como rótulo do campo.

<input type="email" placeholder="E-mail" class="border rounded-lg px-3 py-2" />

<label htmlFor="email" class="text-sm font-medium text-slate-700">E-mail</label>
<input id="email" type="email" class="border rounded-lg px-3 py-2" />

Foco de teclado

Muita gente navega uma tela inteira só com Tab, sem tocar no mouse. Se você remove o contorno padrão de foco (outline: none) sem colocar nada visível no lugar, essa pessoa perde a referência de qual elemento está ativo — o teclado continua funcionando, mas ninguém enxerga onde ele está.

<button class="bg-blue-600 text-white px-4 py-2 rounded-lg focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-blue-400 focus-visible:ring-offset-2">
  Salvar
</button>

focus-visible: aplica o anel só quando o foco veio do teclado (não de um clique de mouse) — o melhor dos dois mundos: sem anel "sujando" o clique do mouse, mas com referência clara pra quem navega via teclado.

Contraste de cor

Texto cinza-claro sobre fundo branco pode parecer "elegante" e ser ilegível pra quem tem baixa visão. A regra do WCAG pra texto normal é uma razão de contraste mínima de 4.5:1 entre texto e fundo (3:1 pra texto grande) — dá pra checar isso com o próprio DevTools do navegador, sem ferramenta externa.

<!-- text-slate-300 sobre bg-white: contraste baixo demais pra texto de corpo -->
<p class="text-slate-300 bg-white">Texto quase ilegível</p>

<!-- text-slate-600 sobre bg-white: passa no contraste mínimo -->
<p class="text-slate-600 bg-white">Texto legível</p>

Por que isso não é "polimento de depois"

Adicionar label, foco visível e contraste correto depois que a tela já foi construída sem eles custa muito mais do que fazer certo desde o início — cada componente novo criado sem esse cuidado é mais um lugar pra corrigir depois. E o problema não é abstrato: sem isso, uma pessoa real fica de fato bloqueada de completar uma tarefa, não é só uma questão estética.