Quando se fala em acessibilidade web, ainda é comum pensar num botão que aumenta o texto, muda as cores ou ativa um modo de alto contraste. Essas opções podem ser úteis, mas não são o ponto de partida. Um site acessível começa muito antes: na estrutura do HTML, nas cores escolhidas, na forma como os formulários são construídos, na navegação por teclado e até na maneira como decidimos animar uma página.
No meu trabalho, gosto de olhar para acessibilidade como uma consequência de fazer melhores interfaces. Muitas das decisões que ajudam uma pessoa com deficiência também tornam o site mais claro para quem está num telemóvel ao sol, usa um rato com dificuldade, está cansado, tem uma ligação lenta ou simplesmente quer encontrar uma informação sem esforço.
1. Começar pelo teclado é uma forma simples de encontrar problemas
Um dos testes mais rápidos que faço é deixar o rato de lado e percorrer a página apenas com a tecla Tab. Consigo chegar ao menu? Aos filtros? Aos botões? Aos campos do formulário? Consigo perceber visualmente onde estou?
Se a resposta for “não” em algum destes pontos, há um problema de utilização. O foco de teclado não deve desaparecer por causa de um outline: none, nem ficar escondido por menus fixos ou elementos flutuantes. As WCAG 2.2 reforçam precisamente esta questão: um elemento focado deve continuar visível e utilizável.
Também é importante que componentes que abrem — menus, modais, accordions — possam ser fechados pelo teclado, normalmente com Escape, e que o foco volte para o sítio certo quando são fechados.
2. Contraste não é só “preto no branco”
É fácil escolher uma cor bonita para um texto secundário e só depois perceber que, num portátil com pouco brilho ou num telemóvel em exterior, quase não se lê. Por isso tento não avaliar contraste apenas “a olho”.
O mesmo se aplica a botões. Um botão em tom pastel com texto branco pode parecer elegante num mockup e falhar completamente em utilização real. Muitas vezes basta escurecer o texto, reforçar a borda ou reservar as cores mais suaves para fundos e detalhes decorativos.
Também evito depender apenas da cor para transmitir estado. Um erro num formulário, por exemplo, não deve ser apenas uma borda vermelha: deve existir uma mensagem clara a explicar o que aconteceu e como corrigir.
3. O tamanho das áreas clicáveis importa mais no mobile
Um link pequeno pode ser fácil de clicar com um rato e frustrante num telemóvel. Botões, ícones e controlos precisam de área suficiente para serem usados sem precisão excessiva. As WCAG 2.2 introduzem critérios específicos para o tamanho mínimo dos alvos de interação.
Na prática, isto significa evitar ícones minúsculos colados uns aos outros, dar espaço entre ações e não transformar uma interface mobile numa versão simplesmente “encolhida” do desktop.
4. A hierarquia dos títulos ajuda pessoas e motores de pesquisa
Um h1 não é apenas texto grande. Um h2 não é apenas um subtítulo visual. A estrutura dos headings cria um mapa da página para tecnologias de apoio e ajuda qualquer pessoa a perceber a organização do conteúdo.
Tento manter uma hierarquia lógica: um título principal, secções em h2, subtópicos em h3. Se preciso de alterar o tamanho visual, faço-o em CSS em vez de escolher um heading apenas porque “fica melhor”.
5. Formulários devem explicar antes de acusar o erro
Os formulários são uma das zonas onde pequenos detalhes criam muita fricção. Um placeholder não substitui uma label. Um asterisco isolado nem sempre explica o que é obrigatório. E uma mensagem genérica como “Erro no formulário” obriga a pessoa a descobrir sozinha o que correu mal.
Prefiro:
- labels visíveis e associadas corretamente aos campos;
- indicação clara dos campos obrigatórios;
- instruções antes do erro, quando existe um formato específico;
- mensagens junto ao campo que precisa de correção;
- feedback de sucesso que também possa ser anunciado por leitores de ecrã.
6. Imagens precisam de contexto, não de descrições automáticas
O atributo alt deve transmitir a informação que a imagem acrescenta naquele contexto. Nem todas as imagens precisam de uma descrição. Se uma fotografia é puramente decorativa, um alt="" pode ser a escolha certa.
Por outro lado, se uma imagem mostra um gráfico, um produto ou uma funcionalidade importante, a alternativa deve transmitir o conteúdo útil — não algo genérico como “imagem” ou “foto do site”.
7. Movimento também pode ser uma barreira
Animações podem dar vida a uma interface, mas também podem causar desconforto ou dificultar a leitura. Uma prática que aplico é respeitar prefers-reduced-motion, reduzindo ou removendo transições e movimentos quando o utilizador configurou essa preferência no sistema.
Isto não significa eliminar toda a animação. Significa garantir que a experiência continua a funcionar sem depender dela.
8. Acessibilidade deve ser testada no conteúdo real
Uma página vazia ou com texto de exemplo quase sempre parece simples. Os problemas aparecem quando entram títulos longos, mensagens de erro, menus reais, imagens, filtros, traduções e diferentes tamanhos de ecrã.
Por isso, além das ferramentas automáticas, faço testes manuais: teclado, zoom, mobile, contraste, formulários e estados de erro. As ferramentas ajudam a encontrar problemas, mas não conseguem decidir se uma interface é clara ou frustrante.
O que mudou na forma como olho para acessibilidade
Durante muito tempo, a acessibilidade foi tratada como uma camada adicional: primeiro fazemos o site, depois “vemos a acessibilidade”. Hoje faz mais sentido integrá-la nas decisões normais de desenvolvimento.
Quando um botão tem bom contraste, o foco é visível, o formulário explica os erros e a página funciona com teclado, não estamos apenas a cumprir uma norma. Estamos a reduzir obstáculos.
E esse é, para mim, o ponto mais importante: um site acessível tende a ser um site melhor pensado.
Checklist rápida antes de publicar uma página
- Consigo navegar pela página sem rato?
- Consigo ver claramente onde está o foco?
- Os textos e botões têm contraste suficiente?
- Os links e botões têm áreas clicáveis confortáveis no mobile?
- Os headings seguem uma hierarquia lógica?
- Os formulários têm labels e mensagens de erro úteis?
- As imagens informativas têm alternativas adequadas?
- O site continua funcional com movimento reduzido?
- Consigo aumentar o zoom sem perder conteúdo?
Se várias respostas forem “não”, provavelmente há trabalho a fazer — e normalmente não exige reconstruir o site inteiro. Muitas melhorias começam em decisões pequenas.
Leitura adicional
Para quem quer aprofundar o tema, recomendo começar pelas Web Content Accessibility Guidelines (WCAG) e pelo resumo das novidades da WCAG 2.2.