Acessibilidade Web: o Básico Que Já Resolve Muita Coisa

Acessibilidade tem fama de ser um assunto enorme e cheio de norma. Ela é grande mesmo, mas a distribuição dos problemas não é uniforme. Um punhado de erros repetidos responde pela maior parte das barreiras que as pessoas encontram na web, e quase todos são baratos de corrigir se você fizer isso durante a construção, e não depois.

Este texto cobre esse punhado. Não é a norma inteira. É o conjunto que, se você resolver, já coloca o seu site acima de boa parte do que existe no ar.

Quem fica de fora quando o site é inacessível

É tentador imaginar um único perfil de usuário, a pessoa cega usando leitor de tela. Ela existe e importa, mas o grupo afetado é muito maior e menos óbvio.

• Quem tem baixa visão e usa zoom de 200 por cento no navegador.
• Quem tem daltonismo e não distingue o estado de erro sinalizado só por cor vermelha.
• Quem tem limitação motora e navega só por teclado, ou por um dispositivo que simula teclado.
• Quem tem dislexia e trava em blocos de texto justificado, sem hierarquia, com linhas longas demais.
• Quem tem sensibilidade vestibular e passa mal com parallax e carrossel automático.
• Quem está com o braço engessado. Quem está no sol forte segurando o celular. Quem tem 78 anos.

Acessibilidade não é um recurso para uma minoria fixa. É a margem de tolerância do seu site a condições que qualquer pessoa pode ter, temporária ou permanentemente. E ela se sobrepõe quase inteiramente a boas práticas de usabilidade: um site acessível costuma ser mais rápido de entender para todo mundo.

Contraste de cor e como testar

Este é o único ponto do artigo com números fixos, e vale decorar. A WCAG define razão de contraste entre a cor do texto e a cor de fundo, numa escala que vai de 1:1 (invisível) a 21:1 (preto puro sobre branco puro).

No nível AA, que é a referência prática usada pela maioria das políticas:

• Texto normal precisa de pelo menos 4,5:1.
• Texto grande precisa de pelo menos 3:1. Texto grande, na definição da norma, é a partir de 18 pontos, ou 14 pontos em negrito, o que na prática costuma cair perto de 24px e 18,66px em negrito.
• Componentes de interface e elementos gráficos essenciais precisam de 3:1. Isso inclui a borda de um campo de formulário, o ícone que carrega significado sozinho e o indicador de foco.

Os erros mais comuns são sempre os mesmos: texto cinza claro sobre fundo branco porque "fica mais elegante"; placeholder usado como rótulo; texto branco sobre foto sem camada de escurecimento; botão com marca clara e texto branco em cima.

Testar leva segundos. O DevTools do Chrome mostra a razão de contraste no seletor de cor do inspetor. O Lighthouse aponta as falhas automaticamente. Qualquer verificador de contraste online resolve para um par de cores isolado. E o teste mais honesto de todos: abra o site no celular, na rua, no meio do dia.

Uma armadilha específica: se você usa imagem de fundo atrás de texto, o contraste varia pixel a pixel. Coloque uma camada sólida ou um gradiente com opacidade suficiente e teste no ponto mais claro da imagem, não na média. E se as imagens do seu site estão pesadas a ponto de a camada demorar a aparecer, vale rever a otimização de imagens em WebP e AVIF.

Navegação por teclado e foco visível

Teste de trinta segundos: abra a sua home e aperte Tab repetidamente, sem tocar no mouse. Três coisas precisam ser verdade.

1. Você consegue enxergar onde está. Cada elemento focado precisa de um indicador visível. Se alguém no seu projeto escreveu outline: none no CSS sem colocar nada no lugar, esse é provavelmente o bug de acessibilidade mais grave do site.
2. A ordem faz sentido. O foco deve seguir a ordem visual da página. Ordem estranha quase sempre é sintoma de layout construído com posicionamento absoluto ou de ordem de DOM que não bate com a ordem de leitura.
3. Você consegue chegar em tudo e sair de tudo. Menu, dropdown, modal, carrossel. Se um modal abre e o Tab continua passeando pelo conteúdo atrás dele, ou se Esc não fecha, está quebrado. Se você entra num componente e não consegue sair, isso é uma armadilha de teclado, um dos poucos erros que a norma trata como falha crítica sem meio-termo.

O melhor indicador de foco é aquele que você projeta de propósito: um contorno de dois pixels, com contraste de pelo menos 3:1 contra o fundo, e um pequeno deslocamento para não colar no elemento. Use :focus-visible para que ele apareça na navegação por teclado sem poluir o clique de mouse.

Dois detalhes que resolvem muito: use elementos nativos sempre que possível, button para ação, a para navegação, porque eles já vêm com foco, papel e comportamento de teclado prontos; e coloque um link de pular para o conteúdo no topo, para quem não quer atravessar o menu inteiro a cada página.

Texto alternativo que serve para alguma coisa

Alt não é legenda, não é nome de arquivo e não é lugar para palavra-chave. Ele é o que a imagem faz na página, dito em texto.

A distinção mais importante, e a mais ignorada, é entre imagem informativa e imagem decorativa.

• Imagem decorativa recebe alt vazio: alt="". Vazio de propósito, com as aspas presentes. Isso diz ao leitor de tela para pular a imagem. Serve para ornamentos, texturas, ícones que apenas repetem um texto que já está ao lado. Um ícone de telefone ao lado da palavra "Telefone" não precisa ser anunciado duas vezes.
• Imagem informativa recebe alt descritivo. Descreva a informação, não o arquivo. Numa página de portfólio, "Página inicial do site da clínica, com agendamento em destaque" vale mais do que "projeto-01".
• Nunca omita o atributo. Sem alt, muitos leitores de tela leem o nome do arquivo em voz alta. Nada é pior do que ouvir "IMG underscore 4471 ponto jotapegue".
• Imagem que é link recebe o alt do destino. Se o logotipo leva para a home, o alt descreve a ação, não o desenho.
• Imagem com texto dentro precisa que o texto esteja no alt. E, de preferência, não deveria existir: texto em imagem não escala com zoom e não é selecionável.

Um bom teste: leia a página em voz alta substituindo cada imagem pelo seu alt. Se o resultado ainda faz sentido e não fica repetitivo, você acertou.

Headings como estrutura, não como estilo

Usuários de leitor de tela navegam por títulos do mesmo jeito que você passa o olho pela página. É o atalho mais usado. Um site com headings bem feitos é navegável; um site que usa h3 porque "ficou do tamanho certo" é um labirinto.

As regras são poucas:

• Um h1 por página, descrevendo o assunto daquela página.
• Não pule níveis descendo. De h2 vá para h3, não direto para h4.
• Heading é hierarquia, não tamanho. Se o título precisa ser menor, mude o CSS, não a tag.
• Texto em negrito e grande não é heading. Para o leitor de tela, é só um parágrafo gordo.

Existe um bônus: a mesma estrutura que ajuda o leitor de tela ajuda os buscadores a entender o documento. Acessibilidade e SEO técnico se sobrepõem bastante nesse ponto, como aparece no checklist de SEO técnico para pequenos negócios.

Formulários com label de verdade

Formulário é onde acessibilidade quebrada vira perda de dinheiro direta, porque é exatamente ali que a conversão acontece.

1. Todo campo tem um label associado. Com for apontando para o id do campo. Isso dá nome ao campo para o leitor de tela e ainda faz o clique no rótulo focar o campo, o que ajuda todo mundo no celular.
2. Placeholder não é rótulo. Ele some quando a pessoa começa a digitar, costuma ter contraste baixo e não é lido de forma confiável. Use placeholder para exemplo de formato, nunca para o nome do campo.
3. Erro precisa de texto, não só de cor. Borda vermelha sozinha não comunica nada para quem tem daltonismo. Escreva a mensagem, coloque perto do campo e associe programaticamente.
4. A mensagem precisa dizer o que fazer. "Campo inválido" não ajuda. "Digite o telefone com DDD, apenas números" ajuda.
5. Use os tipos e o autocomplete certos. type="email", type="tel" e os valores de autocomplete trocam o teclado no celular e permitem preenchimento automático. Isso é acessibilidade cognitiva e motora, além de conversão, assunto que se cruza com a anatomia de uma landing page que converte.

Movimento e prefers-reduced-motion

Animação grande, parallax, carrossel que gira sozinho e transições de página com deslocamento amplo causam desconforto real em pessoas com sensibilidade vestibular, de enjoo a enxaqueca.

A norma pede duas coisas. Primeiro, qualquer conteúdo que se move, pisca ou rola automaticamente por mais de cinco segundos precisa de um jeito de pausar. Segundo, e mais fácil, respeite a preferência do sistema. Todo sistema operacional moderno tem uma opção de reduzir movimento, e o navegador expõe isso via prefers-reduced-motion.

Na prática: mantenha as transições de opacidade e de cor, que raramente incomodam, e desligue deslocamentos grandes, zooms e parallax quando a preferência estiver ativa. É um bloco pequeno de CSS e resolve a categoria inteira. Ganho colateral: menos animação pesada costuma melhorar também a estabilidade visual medida pelos Core Web Vitals.

E evite qualquer coisa que pisque mais de três vezes por segundo. Esse é um limite de segurança, não de conforto: piscadas nessa frequência podem desencadear crises em pessoas com epilepsia fotossensível.

Testar com leitor de tela em quinze minutos

Você não precisa virar usuário avançado de leitor de tela. Precisa ouvir a sua própria página uma vez. É desconfortável e extremamente eficiente.

No Windows, instale o NVDA, que é gratuito. No macOS e no iOS, o VoiceOver já vem instalado. No Android, o TalkBack também.

Roteiro de quinze minutos:

1. Ligue o leitor, feche os olhos e tente descobrir o que a página oferece só pelo áudio.
2. Navegue pela lista de títulos e veja se a estrutura faz sentido sem o visual.
3. Navegue pela lista de links. Se você ouvir "clique aqui", "saiba mais", "leia mais" repetidos, os textos dos seus links não funcionam fora de contexto.
4. Preencha o formulário de contato inteiro. Cada campo foi anunciado com nome? Os erros foram lidos?
5. Abra o menu mobile e feche. Você conseguiu?

Ferramenta automática, Lighthouse, axe, WAVE, encontra uma parte relevante dos problemas, mas não todos: ela sabe que existe um alt, não sabe se o alt está certo. Use as duas coisas.

WCAG sem precisar decorar a norma

A WCAG se organiza em quatro princípios, e conhecer só eles já orienta bem uma decisão: o conteúdo precisa ser perceptível, operável, compreensível e robusto. Os critérios se dividem em três níveis, A, AA e AAA. AA é a régua adotada pela maioria das políticas públicas e privadas, e é uma meta realista para um site comum. AAA é rígido demais para conteúdo geral.

Se você fizer só o que está neste artigo, contraste dentro de 4,5:1 e 3:1, teclado funcional com foco visível, alt correto, headings hierárquicos, labels reais e respeito à preferência de movimento, você cobre uma fatia grande do nível AA sem abrir o documento da norma uma vez.

O resto vem depois, e vem mais fácil, porque a base já está no lugar. O caro é sempre o contrário: descobrir tudo isso num site pronto e ter que reabrir cada componente.

Se você quer um site construído com esse básico embutido desde o primeiro componente, veja nosso portfólio e fale com a ALB Seven.