Como tornar um site acessível: checklist prático baseado nas WCAG

O que significa um site acessível

Um site acessível permite que pessoas com diferentes capacidades visuais, auditivas, motoras e cognitivas encontrem informações e realizem tarefas. Isso inclui quem usa leitor de tela, navega pelo teclado, amplia o conteúdo, precisa de legendas ou encontra dificuldade com instruções ambíguas.

As Diretrizes de Acessibilidade para Conteúdo Web, conhecidas como WCAG, organizam recomendações técnicas para tornar conteúdos mais acessíveis. A versão 2.2 possui critérios testáveis nos níveis A, AA e AAA. Para projetos novos ou revisados, o W3C recomenda usar a versão mais atual.

Acessibilidade também melhora situações temporárias e cotidianas: uma pessoa com o braço imobilizado, alguém usando o celular sob sol forte ou quem assiste a um vídeo sem áudio. Ainda assim, o objetivo principal deve permanecer a remoção de barreiras para pessoas com deficiência.

Os quatro princípios das WCAG

As WCAG agrupam as diretrizes em quatro princípios: perceptível, operável, compreensível e robusto. Perceptível significa que informações não dependem de uma única forma, como apenas cor ou áudio. Operável exige que controles possam ser usados por diferentes meios, inclusive teclado.

Compreensível envolve linguagem clara, navegação previsível e ajuda para corrigir erros. Robusto significa usar marcação e componentes compatíveis com navegadores e tecnologias assistivas. Esse modelo ajuda a avaliar o site como experiência completa, não como uma lista desconectada de ajustes.

• Perceptível: conteúdo disponível em formas que o usuário consegue perceber;
• Operável: navegação e controles utilizáveis sem barreiras;
• Compreensível: textos, instruções e comportamentos previsíveis;
• Robusto: código compatível com tecnologias assistivas.

Comece pela estrutura da página

Uma página bem estruturada permite que pessoas e ferramentas entendam onde estão o cabeçalho, a navegação, o conteúdo principal e o rodapé. Use elementos HTML semânticos quando eles representam corretamente a função: header, nav, main, article, section e footer.

Organize os títulos em uma hierarquia coerente. O título principal deve apresentar o assunto, e os subtítulos devem dividir etapas ou ideias. Não escolha h2 ou h3 apenas pelo tamanho visual; a aparência deve ser controlada pelo CSS. Pular níveis sem motivo torna a leitura estrutural mais confusa.

Links precisam explicar o destino. “Conheça os serviços de criação de sites” comunica mais do que vários links chamados apenas “clique aqui”. Em páginas longas, uma navegação clara e mecanismos para pular blocos repetidos reduzem esforço.

Garanta navegação completa pelo teclado

Teste o site sem mouse. Use Tab para avançar, Shift mais Tab para voltar, Enter para ativar links e Espaço quando apropriado. O foco deve passar por todos os controles interativos em uma ordem lógica e nunca ficar preso em um menu, modal ou componente.

O indicador de foco precisa ser visível. Remover o contorno padrão sem criar uma alternativa clara prejudica quem navega pelo teclado. Também confira se menus suspensos, carrosséis, chat, seletor de tema e botão do WhatsApp funcionam sem depender de hover.

Componentes personalizados exigem cuidado adicional. Sempre que possível, prefira botões, links e campos HTML nativos. Eles já oferecem comportamentos esperados que seriam difíceis de recriar corretamente usando apenas div, eventos de clique e estilos.

Revise contraste e uso de cores

Texto com baixo contraste pode desaparecer para pessoas com baixa visão, daltonismo ou em telas sob muita luz. As WCAG definem critérios mensuráveis de contraste; por isso, não avalie somente pela impressão visual no seu monitor. Use uma ferramenta de medição e verifique estados normal, hover, foco, ativo e desabilitado.

A cor não deve carregar sozinha uma informação. Em um formulário, não marque erro apenas deixando a borda vermelha: inclua uma mensagem que identifique o campo e explique como corrigir. Em gráficos, combine cores com rótulos, padrões ou símbolos.

O modo escuro precisa de revisão própria. Trocar o fundo sem recalcular textos, bordas, ícones e elementos interativos pode criar novas barreiras. Teste os dois temas e não presuma que alto contraste significa branco puro sobre preto puro em todos os elementos.

Permita ampliar e reorganizar o conteúdo

Pessoas com baixa visão podem aumentar o zoom ou o tamanho do texto. A página deve continuar utilizável sem esconder conteúdo, sobrepor botões ou exigir rolagem horizontal desnecessária. Evite alturas fixas em caixas com texto e permita que o conteúdo cresça.

Teste em larguras pequenas e com zoom elevado. Menus, formulários, tabelas e cartões são pontos comuns de falha. Um layout responsivo não é automaticamente acessível: ele pode se adaptar ao celular e ainda cortar palavras quando a fonte aumenta.

Não bloqueie o zoom no viewport. Se uma informação não cabe, reavalie a composição ou ofereça uma forma acessível de explorá-la. Em tabelas extensas, mantenha cabeçalhos identificáveis e considere uma apresentação alternativa para telas estreitas.

Escreva textos alternativos conforme a função

Imagens informativas precisam de uma alternativa textual que comunique seu significado. Uma foto de serviço pode indicar o que está sendo realizado; um gráfico precisa ter os dados importantes explicados no texto próximo ou em uma descrição mais completa.

Imagens decorativas devem usar alt vazio para serem ignoradas pelo leitor de tela. Em imagens que funcionam como botão ou link, o texto alternativo deve informar a ação, não apenas descrever o desenho. Um ícone de lupa usado para buscar precisa comunicar “Pesquisar”.

Evite repetir no alt o mesmo texto já anunciado ao lado. A qualidade depende do contexto. Uma descrição literal longa pode ser menos útil do que uma frase curta que explica por que a imagem está naquela página.

Use texto real no lugar de imagem de texto

Textos incorporados em banners e artes perdem nitidez quando ampliados, não se adaptam facilmente ao modo escuro e podem não ser lidos por tecnologias assistivas. Sempre que possível, use texto HTML estilizado por CSS.

Capas de artigos e peças de campanha podem conter palavras por decisão visual, mas as informações essenciais devem aparecer também em texto na página. Não dependa de um cartaz dentro da imagem para comunicar preço, prazo, endereço ou instrução.

Essa prática também facilita correções, tradução, responsividade e atualização de conteúdo. A arte continua apoiando a comunicação, enquanto o HTML preserva a informação em uma forma flexível.

Torne formulários fáceis de entender e corrigir

Cada campo precisa de um rótulo associado. Placeholder não substitui label porque desaparece durante a digitação e costuma ter contraste baixo. Indique claramente quais campos são obrigatórios e explique o formato esperado antes que a pessoa erre.

Quando houver erro, não mostre apenas “dados inválidos”. Informe o campo, o problema e uma forma de corrigir. Preserve os dados já preenchidos sempre que for seguro. Após o envio, apresente uma confirmação perceptível e permita que leitores de tela recebam a mensagem de status.

Formulários longos podem ser divididos em grupos lógicos. Em etapas múltiplas, mostre o progresso, repita instruções importantes e deixe etapas opcionais reconhecíveis. Para um pedido de orçamento, pergunte somente o necessário para iniciar a conversa.

Botões e áreas clicáveis precisam ser claros

Um botão deve parecer acionável, ter nome compreensível e área suficiente para toque. Ícones isolados como três pontos, setas ou lixeiras precisam de nome acessível quando a função não está escrita. Estados de carregamento também devem ser comunicados.

Não coloque dois controles diferentes com aparência idêntica ou o mesmo texto para ações incompatíveis. “Enviar orçamento”, “Abrir WhatsApp” e “Baixar proposta” deixam a consequência mais previsível do que vários botões chamados “Continuar”.

Evite mudanças inesperadas quando a pessoa apenas seleciona um campo ou recebe foco. Se uma ação abre nova janela, inicia download ou altera dados, ofereça contexto suficiente antes da ativação.

Vídeos, áudios e animações

Vídeos gravados com fala precisam de legendas sincronizadas. Quando informações visuais relevantes não são explicadas pelo áudio, considere audiodescrição ou alternativa textual. Para conteúdo somente em áudio, ofereça transcrição.

Não reproduza som automaticamente. Dê controle para pausar, parar ou ocultar conteúdos em movimento quando aplicável. Animações repetitivas podem distrair ou causar desconforto; respeite preferências de movimento reduzido configuradas no dispositivo.

Um vídeo de apresentação pode continuar atraente sem bloquear ninguém. Controles identificáveis, legendas revisadas e roteiro disponível ampliam as formas de consumir a mensagem.

Defina idioma, títulos e mensagens de status

Declare o idioma principal da página como português do Brasil. Isso ajuda leitores de tela a usar pronúncia adequada. Quando um trecho extenso estiver em outro idioma, marque essa mudança quando tecnicamente apropriado.

Cada página precisa de um title específico e descritivo. Ele ajuda usuários a reconhecer abas, histórico e resultados. Mensagens que surgem sem mover o foco, como “item adicionado” ou “formulário enviado”, devem ser expostas de maneira que tecnologias assistivas possam anunciá-las.

Menus e componentes repetidos precisam manter nomes e posições previsíveis. Se o botão abre o atendimento em uma página, não use o mesmo rótulo para baixar um arquivo em outra.

ARIA ajuda, mas não corrige HTML inadequado

WAI-ARIA pode fornecer nome, função e estado para componentes que não têm equivalente simples. Porém, adicionar atributos ARIA a uma estrutura incorreta não recria automaticamente os comportamentos de teclado, foco e interação.

A primeira escolha deve ser HTML nativo. Use ARIA quando existe necessidade real e teste com tecnologia assistiva. Um botão feito com button costuma ser mais seguro do que uma div transformada em botão com vários atributos e eventos.

Evite esconder conteúdo importante com aria-hidden e confira se rótulos não entram em conflito com o texto visível. O nome acessível de um controle deve continuar reconhecível para quem vê e para quem ouve a interface.

Ferramentas automáticas não bastam

Auditores automáticos encontram problemas como contraste insuficiente, campo sem rótulo e atributo ausente. Eles são úteis para repetir verificações, mas não conseguem decidir sozinhos se um alt descreve bem a imagem, se a ordem de foco faz sentido ou se uma instrução é compreensível.

Combine automação com testes manuais: teclado, zoom, leitor de tela, diferentes tamanhos de viewport e revisão do conteúdo. Quando possível, inclua pessoas com deficiência em avaliações reais. A experiência humana revela barreiras que uma pontuação não mostra.

Não publique um selo de conformidade apenas porque um plugin ou relatório marcou 100. Uma declaração de conformidade exige avaliar critérios e processos completos, inclusive páginas, estados, erros e fluxos críticos.

Checklist prático de revisão

Comece pelas jornadas de maior impacto: abrir o menu, entender o serviço, ler um artigo, preencher o contato e iniciar o WhatsApp. Faça a revisão na versão pública, pois diferenças de deploy, scripts e integrações podem introduzir problemas que não existiam no editor.

Para negócios de Betim, Grande BH ou atendimento online em todo o Brasil, acessibilidade não muda conforme a região. O foco é garantir que mais pessoas consigam compreender a oferta e entrar em contato sem enfrentar uma barreira evitável.

• A estrutura usa títulos, regiões e links com propósito claro;
• todas as ações funcionam pelo teclado e o foco é visível;
• textos e controles têm contraste suficiente nos dois temas;
• zoom e aumento de texto não cortam conteúdo;
• imagens possuem alternativa adequada à função;
• formulários têm labels, instruções e erros específicos;
• vídeos têm legendas e animações podem ser controladas;
• testes automáticos foram complementados por revisão manual.

Como priorizar correções

Não espere uma reconstrução completa para começar. Corrija primeiro bloqueios que impedem tarefas: menu inacessível, formulário impossível de enviar, foco preso, botão sem nome e conteúdo essencial sem alternativa. Depois trate problemas de compreensão, consistência e refinamento.

Registre cada barreira com página, componente, passos para reproduzir e impacto. Transforme padrões corrigidos em componentes reutilizáveis. Quando o botão, o campo e o modal acessíveis entram no sistema de design, páginas futuras herdam uma base melhor.

Reavalie após mudanças importantes e antes de campanhas. Novos banners, plugins, chats e formulários podem reintroduzir falhas. Acessibilidade precisa fazer parte da manutenção, não aparecer somente em uma auditoria isolada.

Conclusão: acessibilidade é parte da qualidade

Um site acessível nasce de decisões verificáveis: estrutura semântica, operação por teclado, contraste, alternativas textuais, formulários claros e mídia controlável. Nenhum recurso isolado substitui esse conjunto.

Use as WCAG 2.2 como referência técnica, priorize jornadas reais e combine ferramentas com testes manuais. O próximo passo prático é escolher uma página importante, navegar sem mouse, ampliar o conteúdo e registrar as primeiras barreiras. Depois, leve as correções para os componentes usados em todo o site.