Acessibilidade na web: por que importa (e como fazer direito)

Mais de um bilhão de pessoas no mundo vivem com alguma deficiência. Some a isso quem tem baixa visão pela idade, quem navega no sol forte do celular, quem usa só o teclado, quem tem dislexia ou sensibilidade a movimento — e fica claro que acessibilidade não é um nicho. É a condição para que o site sirva a todo mundo.

Construir para esse público não é caridade nem enfeite técnico. É direito, é alcance e, na prática, é qualidade de software. Este texto resume por que isso importa e como aplicar — com as fontes oficiais no fim.

Por que importa

É direito. No Brasil, a Lei Brasileira de Inclusão (LBI, Lei nº 13.146/2015) torna a acessibilidade digital uma obrigação, não uma gentileza.
É alcance. Cada barreira é uma pessoa que desiste. Um contraste fraco, um botão que só funciona no mouse, uma imagem sem descrição — cada um exclui alguém silenciosamente.
É qualidade. Quase tudo que torna um site acessível também o torna melhor para todos: HTML semântico, bom contraste, navegação por teclado, textos claros. Acessibilidade e usabilidade andam juntas.

Os quatro princípios (POUR)

As diretrizes internacionais (WCAG) se organizam em quatro princípios. Um site precisa ser:

Perceptível — o conteúdo pode ser percebido por todos os sentidos (ex.: imagens têm descrição, vídeos têm legenda, o contraste é suficiente).
Operável — dá para usar de várias formas (ex.: tudo funciona pelo teclado, sem depender do mouse; nada pisca de forma perigosa).
Compreensível — a linguagem e o funcionamento são previsíveis e claros.
Robusto — funciona com tecnologias assistivas, como leitores de tela.

Práticas concretas

Sem precisar ser especialista, dá para cobrir o essencial:

Contraste suficiente entre texto e fundo (a meta comum é a relação 4,5:1 para texto normal).
Texto alternativo (alt) descritivo em imagens informativas; imagens decorativas marcadas para o leitor de tela ignorar.
Navegação por teclado: todo link, botão e campo alcançável por Tab, com foco visível e ordem lógica.
HTML semântico: usar <button>, <nav>, <main>, títulos (<h1>…<h2>) na hierarquia certa — não <div> para tudo.
Formulários com rótulos (<label>) ligados aos campos, erros descritos em texto e anunciados.
Respeitar o movimento: honrar a preferência prefers-reduced-motion para quem tem sensibilidade vestibular ou fotossensibilidade.
Não depender só da cor para transmitir informação (um erro não pode ser "só o campo ficou vermelho").
ARIA com parcimônia: a primeira regra do ARIA é não usar ARIA quando o HTML nativo já resolve. Quando preciso, usar aria-live para anunciar mudanças dinâmicas.

Como testar

Navegue o site só com o teclado (Tab, Shift+Tab, Enter, Espaço). Se você se perder, outras pessoas também se perdem.
Aumente a fonte do navegador para 200% e veja se nada quebra.
Rode um verificador automático (como o WAVE ou o axe) — eles pegam parte dos problemas; o resto é teste humano.
Se possível, teste com um leitor de tela (NVDA no Windows, VoiceOver no Mac).

Fontes oficiais

Quando bater dúvida, vá direto à fonte:

W3C WAI — Web Accessibility Initiative — o ponto de partida oficial sobre acessibilidade na web.
WCAG 2.2 (Web Content Accessibility Guidelines) — a norma de referência mundial.
Guia rápido do WCAG (Quick Reference) — os critérios em formato prático e filtrável.
WAI-ARIA Authoring Practices — padrões para componentes interativos.
MDN — Accessibility — referência técnica para quem desenvolve.
e-MAG — Modelo de Acessibilidade em Governo Eletrônico (gov.br) — a referência brasileira.

Acessibilidade não é uma caixa que se marca uma vez. É um cuidado contínuo — o mesmo cuidado, aliás, que a gente tenta ter com o corpo: notar quem foi deixado de fora e abrir espaço.