LGMdevs
Back to blog
Equipe LGMdevs

Acessibilidade que não é enfeite: WCAG na prática

Acessibilidade não é um selo no fim do projeto — são decisões de contraste, foco e semântica tomadas enquanto você codifica. Os critérios que aplicamos e como verificá-los.

AcessibilidadeDXPerformance

Acessibilidade costuma virar item de auditoria no fim do projeto — e chegar tarde demais, como retrabalho caro. Tratamos como o oposto: um punhado de decisões que se toma enquanto escreve o componente, quase sem custo se feitas na hora. A referência é a WCAG 2.2, que é a Recommendation atual do W3C desde outubro de 2023. Estes são os critérios que mais mudam o resultado no dia a dia.

Contraste: números, não "achismo de designer"

O critério 1.4.3 (nível AA) é objetivo: texto normal precisa de contraste de pelo menos 4,5:1 contra o fundo; texto grande (a partir de 24px, ou 18,67px em negrito) aceita 3:1. Aquele cinza-claro elegante sobre branco quase sempre reprova — e é ilegível ao sol num celular, para qualquer pessoa.

Menos lembrado, o 1.4.11 (AA) exige 3:1 para elementos não-textuais: a borda de um campo de formulário, o traço de um ícone que carrega significado, o estado de foco. Um input cuja borda some no fundo reprova mesmo com o texto perfeito.

/* Verde no cálculo, não no olhômetro. Rode o par de cores num
   verificador de contraste (WebAIM) antes de fechar a paleta. */
color: var(--foreground);          /* ≥ 4,5:1 sobre o fundo */
border-color: var(--border);       /* ≥ 3:1 para ser percebida */

O valor computado não se arredonda: 4,49:1 não passa como 4,5:1.

Foco visível: o teclado não vê o hover

Boa parte dos usuários navega só pelo teclado — por deficiência motora, por preferência, ou porque o mouse quebrou. Para eles, o indicador de foco é o cursor. Removê-lo com outline: none sem repor nada quebra o 2.4.7 (AA) e deixa a pessoa perdida na página.

A regra prática: nunca apague o foco; troque por um anel visível e com contraste. Use :focus-visible para mostrá-lo à navegação por teclado sem poluir o clique de mouse.

:focus-visible {
  outline: 2px solid var(--primary);
  outline-offset: 2px;
}

A WCAG 2.2 ainda somou o 2.4.11 (AA): o elemento em foco não pode ficar escondido atrás de um header fixo ou de um cookie banner. Se você tem barra sticky, teste sair rolando com Tab e confirme que o foco nunca fica coberto.

Semântica: a marcação já carrega significado

Metade da acessibilidade é de graça se você usar o elemento certo. Um <button> é focável, anunciado como botão e aciona com Enter e Espaço sem uma linha de JS; uma <div> com onClick não faz nada disso até você recriar tudo na mão — e quase ninguém recria.

  • Um <h1> por página e headings em ordem (h1 → h2 → h3), sem pular nível para "ficar do tamanho certo". Leitores de tela usam a hierarquia como índice de navegação.
  • Estrutura com header, nav, main, footer: dá landmarks para pular direto ao conteúdo.
  • alt descritivo no que informa; alt="" no que é decorativo (para o leitor pular).
  • aria-label em botão só-ícone. Um botão com um ícone de lixeira e nada mais é anunciado como "botão", sem dizer o quê. aria-label="Excluir item" resolve.

ARIA entra só para preencher lacunas que o HTML não cobre — e a primeira regra do ARIA é não usar ARIA quando existe um elemento nativo que já faz o trabalho.

Alvos que dá para acertar e movimento que respeita o usuário

Dois critérios que fecham a lista:

  • Tamanho de alvo (2.5.8, AA, novo na 2.2): alvos de toque de no mínimo 24×24 pixels CSS, ou com espaçamento suficiente ao redor. Dois links de 16px colados são uma cilada no celular.
  • prefers-reduced-motion: quem sente enjoo ou desconforto com animação configura isso no sistema. Respeite. É a mesma prática que aplicamos nas animações deste site.
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Como verificamos (e o limite das ferramentas)

O fluxo que usamos, do mais barato ao mais completo:

  1. Automático, no CI e no navegador: axe DevTools ou Lighthouse pegam contraste, alt faltando, labels e ordem de headings de graça.
  2. Teclado, à mão: navegue a página inteira só com Tab, Shift+Tab e Enter. Consegue alcançar e acionar tudo? O foco está sempre visível? Isto revela o que o robô não vê.
  3. Leitor de tela, nos fluxos críticos: NVDA, VoiceOver ou Narrator no caminho de conversão (formulário, checkout).

A ressalva honesta: ferramenta automática cobre por volta de um terço dos critérios da WCAG. Ela nunca dirá se o seu alt descreve a imagem bem ou se a ordem de foco faz sentido. Automatize o que dá, mas o teste com teclado e leitor de tela é o que separa "passou no linter" de "uma pessoa real consegue usar".

E o gancho pragmático: quase tudo aqui — HTML semântico, menos JavaScript, foco cuidado — também deixa a página mais leve e melhor de SEO. Acessibilidade bem feita raramente compete com performance; costuma andar junto.

Precisa de um produto acessível de verdade, não só com o selo? Fale com a gente.

Fontes