
Acessibilidade para Sites de Servico
Hierarquia, rotulos, contraste, navegacao por teclado e formularios acessiveis. Um guia pratico para sites institucionais e de atendimento que precisam funcionar para todos.
Acessibilidade em sites institucionais nao e uma camada extra que se adiciona no final. E uma questao de arquitetura: como as paginas sao estruturadas, como os formularios sao rotulados, como a navegacao funciona sem mouse e como o conteudo se apresenta para quem usa tecnologia assistiva. Esta pagina cobre os fundamentos praticos que afetam sites de servico e atendimento, com um checklist operacional que qualquer equipe pode usar para auditar o estado atual do seu site. O foco esta no que funciona na producao, nao em conformidade teorica.
A Web Accessibility Initiative (WAI) do W3C documenta os principios e diretrizes que sustentam a acessibilidade na web. As WCAG, diretrizes de acessibilidade para conteudo web, sao a referencia internacional. Mas para equipes que mantem sites de servico, o caminho mais produtivo e comecar pelos problemas concretos que afetam usuarios reais, nao pela leitura integral das especificacoes.
Depois de auditar dezenas de sites de servico publico e institucional, os mesmos problemas aparecem repetidamente. Nao sao falhas exoticas. Sao erros de construcao basica que passam despercebidos porque o site funciona para quem ve bem e usa mouse.
Hierarquia de titulos e estrutura de pagina
A hierarquia de titulos e a primeira coisa que um leitor de tela usa para navegar uma pagina. Quando a estrutura de headings esta bagunçada, a navegacao por tecnologia assistiva quebra.
Regras praticas que resolvem a maioria dos problemas:
- Um H1 por pagina, descrevendo o conteudo principal
- H2 para secoes principais dentro da pagina
- H3 para subsecoes dentro de um H2
- Nunca pular niveis (de H2 para H4 sem H3 no meio)
- Nunca usar headings para efeito visual. Use CSS para isso.
Esse padrao parece simples, mas a maioria dos sites institucionais que auditamos viola pelo menos uma dessas regras. O problema geralmente comeca quando o editor visual do CMS permite escolher "titulo grande" ou "titulo pequeno" sem indicar o nivel semantico.
Rotulos, botoes e campos de formulario
Formularios de contato e solicitacao de servico sao a funcionalidade mais critica de um site institucional. E sao onde a acessibilidade falha com mais frequencia.
Cada campo de formulario precisa de um label associado corretamente. Placeholder nao substitui label. Um campo com placeholder "Digite seu email" mas sem label visivel nao e acessivel. O leitor de tela nao anuncia o placeholder da mesma forma.
Para botoes, o texto precisa descrever a acao: "Enviar solicitacao" e melhor que "Enviar". "Abrir menu de servicos" e melhor que um icone de hamburguer sem label. Cada elemento interativo precisa de um nome acessivel que faca sentido fora do contexto visual.
Verificacao rapida: navegue pelo formulario usando apenas a tecla Tab. Se voce nao consegue saber em qual campo esta, o usuario de leitor de tela tambem nao.
Contraste e legibilidade
O WCAG exige uma razao de contraste minima de 4.5:1 para texto normal e 3:1 para texto grande. Na pratica, isso significa: texto cinza claro sobre fundo branco nao passa. Texto branco sobre imagem de fundo sem overlay provavelmente nao passa.
Sites institucionais frequentemente erram em:
- Texto de rodape com contraste insuficiente contra fundo escuro
- Links que se distinguem do texto normal apenas por cor, sem sublinhado ou outro indicador
- Botoes com texto claro sobre fundo colorido que nao atinge o ratio minimo
- Texto sobre imagens de hero sem overlay ou fundo solido
- Campos de formulario com borda muito sutil que desaparecem para usuarios com baixa visao
Ferramentas como o verificador de contraste do navegador (nas ferramentas de desenvolvimento) mostram o ratio de cada combinacao de cores. Nao precisa de ferramenta paga.
Navegacao por teclado
Tudo que funciona com clique precisa funcionar com teclado. Isso inclui: menu de navegacao, campos de formulario, botoes, links, elementos de disclosure como FAQ e qualquer controle interativo.
O teste e direto: abra o site e tente fazer tudo usando apenas Tab, Shift+Tab, Enter e Escape. Se nao funciona, nao e acessivel.
Problemas comuns que vemos em sites de servico:
- Menu dropdown que abre com hover mas nao funciona com teclado
- Modal ou overlay que nao prende o foco e permite tabular para elementos por tras
- Links sem indicador de foco visivel (o outline que aparece quando voce Tab ate um link)
- Elementos clicaveis implementados com div em vez de button ou a
- Carrossel que nao para e nao permite navegacao por teclado
A solucao quase sempre e usar os elementos HTML corretos. Um button e focavel e ativavel por padrao. Um div com onclick nao.
A diferenca entre decoracao e funcionalidade
Um erro comum e confundir acessibilidade com adicionar atributos ARIA em tudo. Na verdade, o principio basico e: se o HTML semantico resolve, nao precisa de ARIA.
Use nav para navegacao, main para conteudo principal, button para acoes e a para links. Adicione alt em imagens informativas e alt vazio em imagens decorativas. Use fieldset e legend para agrupar campos de formulario relacionados.
ARIA e util quando a interface tem comportamentos complexos que o HTML sozinho nao descreve: abas, acordeoes, dialogs modais. Mas para a maioria dos sites institucionais, HTML correto e CSS claro resolvem 90% dos problemas de acessibilidade.
Falhas comuns em sites de servico local
Sites de cartorios, prefeituras, associacoes e escritorios de servico compartilham um conjunto previsivel de falhas:
- PDFs sem texto pesquisavel (apenas imagem escaneada)
- Tabelas de servicos sem header row definido
- Paginas inteiras construidas com imagem de texto em vez de texto real
- Videos sem legenda ou transcricao
- Mapas incorporados sem alternativa textual de endereco
- Formularios sem mensagens de erro claras e proximas ao campo com problema
- Paginas que dependem de JavaScript para mostrar conteudo basico
Cada uma dessas falhas tem solucao direta. O problema e que raramente sao testadas antes do lancamento.
Checklist operacional para equipes
Para equipes que mantêm sites de servico, uma verificacao trimestral com este checklist ja melhora significativamente a acessibilidade:
- Navegar todas as paginas principais usando apenas teclado
- Verificar contraste de texto em todas as combinacoes de cor usadas
- Testar todos os formularios com leitor de tela (NVDA no Windows e gratuito)
- Confirmar que cada pagina tem exatamente um H1
- Verificar que todas as imagens informativas tem alt text descritivo
- Testar a pagina com zoom de 200% no navegador para ver se o layout funciona
- Confirmar que links sao distinguiveis de texto normal sem depender apenas de cor
O checklist detalhado de acessibilidade para paginas de atendimento expande cada item com exemplos e solucoes praticas.
Proximos passos
Para entender como desempenho e acessibilidade se conectam, veja a secao de desempenho. Para sites que estao sendo planejados do zero, o guia de planejamento de site institucional integra acessibilidade na fase de estrutura. E para a verificacao completa de paginas de atendimento e formularios, o checklist de acessibilidade e a referencia detalhada.