Como melhorar a acessibilidade do site: um guia prático

Um site acessível é aquele que as pessoas conseguem usar independentemente de deficiência ou da forma como acessam a web: com leitor de tela, apenas pelo teclado, com texto ampliado, com percepção limitada de cores ou com tremor nas mãos. As mesmas melhorias também ajudam quem está com o braço quebrado, usando um celular de tela pequena sob sol forte ou com uma conexão lenta.

A referência mais adotada são as Diretrizes de Acessibilidade para Conteúdo Web (WCAG), atualmente na versão 2.2. Muitas leis de acessibilidade e regras de compras públicas fazem referência às WCAG, quase sempre no nível AA. Este guia se concentra nas correções que eliminam as barreiras mais comuns e depois mostra como testá-las.

Comece por uma verificação automática e depois teste manualmente

Uma varredura automática é o jeito mais rápido de encontrar os problemas óbvios. O verificador de acessibilidade gratuito do Rudra carrega a sua página em um navegador de verdade e executa o axe-core, o motor de testes de código aberto mais usado do mercado. Ele lista cada regra que falha, quantos elementos são afetados e qual a gravidade do impacto: texto alternativo ausente, campos de formulário sem rótulo, contraste insuficiente, idioma da página não declarado, botões e links vazios e muito mais.

As correções que mais importam

1. Dê às imagens alternativas em texto que façam sentido

Todo <img> precisa de um atributo alt. Em imagens informativas, descreva o que a imagem transmite naquele contexto, e não apenas o que ela mostra: alt="Line chart: sign-ups doubled after the March redesign" (um gráfico de linhas e a conclusão que ele traz) é mais útil do que alt="chart". Em imagens puramente decorativas, use um alt="" vazio para que os leitores de tela as ignorem. Em uma imagem que funciona como link ou botão, descreva a ação ("Buscar", "Baixar o relatório"). Gráficos complexos também precisam dos dados principais em um texto próximo ou em uma tabela.

2. Coloque rótulo em todos os campos de formulário

Cada campo precisa de um rótulo visível que esteja associado a ele no código: <label for="email">Email address</label> seguido de <input id="email" type="email" autocomplete="email">. Texto de placeholder não é rótulo; ele some assim que a pessoa começa a digitar e costuma ter pouco contraste. Mostre os erros em texto ao lado do campo (e não só com uma borda vermelha), explique como corrigi-los e associe-os ao campo com aria-describedby.

3. Acerte o contraste de cores

• Texto normal: taxa de contraste de pelo menos 4,5:1 em relação ao fundo (WCAG 1.4.3, nível AA).
• Texto grande (pelo menos 24 px, ou cerca de 18,7 px se estiver em negrito): pelo menos 3:1.
• Componentes de interface e elementos gráficos com significado, como bordas de campos, indicadores de foco e ícones que transmitem informação: pelo menos 3:1 em relação às cores adjacentes (WCAG 1.4.11).
• Não dependa só da cor (WCAG 1.4.1). Um link dentro de um parágrafo deve se distinguir por algo além da cor, normalmente um sublinhado, e um erro não deve ser indicado apenas em vermelho.

As ferramentas de desenvolvedor do navegador mostram a taxa de contraste quando você inspeciona um elemento de texto, o que permite conferir e ajustar as cores enquanto trabalha. Fique de olho em texto cinza-claro, texto sobre fotos e texto de placeholder.

4. Faça tudo funcionar pelo teclado

Tudo o que dá para fazer com o mouse deve ser possível com Tab, Shift+Tab, Enter, Espaço, as setas e Esc. Use elementos <button> e <a href> de verdade em vez de <div>s clicáveis, que não recebem foco nem são acionados pelo teclado sem trabalho extra. Nunca remova o contorno de foco sem oferecer um substituto claramente visível; :focus-visible permite estilizá-lo apenas para quem usa teclado. Garanta que um cabeçalho fixo ou um banner de cookies não esconda o elemento em foco (um critério novo das WCAG 2.2, o 2.4.11), que as caixas de diálogo prendam o foco enquanto estão abertas e o devolvam ao serem fechadas, e inclua um link "Ir para o conteúdo principal" no topo da página.

5. Estruture as páginas com cabeçalhos e landmarks

Quem usa leitor de tela costuma navegar saltando de cabeçalho em cabeçalho. Use um único <h1> que descreva a página, depois <h2> e <h3> em ordem lógica, e escolha os níveis de cabeçalho pela estrutura, não pelo tamanho da fonte. Envolva as regiões em <header>, <nav>, <main> e <footer> para que as pessoas possam ir direto ao conteúdo.

6. Defina o idioma da página e um título único

<html lang="en"> (ou o código do seu idioma) informa aos leitores de tela como pronunciar o texto. Um <title> único e descritivo é a primeira coisa anunciada quando a página abre e é o que a identifica entre as abas do navegador.

7. Escreva links e botões que façam sentido sozinhos

Quem usa leitor de tela pode listar todos os links de uma página, e ali "Clique aqui" e "Leia mais" repetidos dez vezes não dizem nada. Prefira textos como "Leia o guia de preços". Botões só com ícone, como uma lupa ou um "×" de fechar, precisam de um nome acessível: <button aria-label="Close">.

8. Deixe as áreas de toque grandes o bastante

As WCAG 2.2 acrescentaram um requisito de nível AA (2.5.8): as áreas clicáveis devem ter pelo menos 24 × 24 pixels CSS, ou estar espaçadas de modo que um círculo de 24 pixels ao redor de cada uma não se sobreponha a outra. Áreas maiores, por volta de 44 × 44 pixels (a recomendação do nível AAA), são ainda melhores em telas sensíveis ao toque.

9. Permita zoom e refluxo do conteúdo

Nunca desative o zoom com user-scalable=no ou maximum-scale=1. O conteúdo deve se reorganizar em uma única coluna, sem rolagem horizontal, em uma largura de 320 pixels CSS, que é o que um zoom de 400% produz em uma tela de desktop comum (WCAG 1.4.10). Um layout responsivo resolve a maior parte disso; veja como tornar um site compatível com dispositivos móveis.

10. Trate mídia e movimento com cuidado

Ofereça legendas para vídeos e transcrições para áudios. Não reproduza som automaticamente. Dê a carrosséis e animações um botão de pausa e respeite a media query prefers-reduced-motion, reduzindo ou removendo as animações não essenciais para quem pediu isso.

11. Prefira HTML nativo a ARIA

Os atributos ARIA mudam o que a tecnologia assistiva anuncia, mas não o comportamento do elemento. Um <div role="button"> continua precisando de um tratamento de teclado que você mesmo tem de escrever; um <button> já vem com isso. Use elementos nativos sempre que possível e recorra a ARIA só quando o HTML não tiver equivalente, seguindo os padrões do ARIA Authoring Practices Guide, do W3C.

Um teste manual de 15 minutos

1. Desconecte o mouse. Percorra a página com Tab desde o topo. Dá para ver onde está o foco a cada passo? Você consegue alcançar e operar cada link, botão, menu e campo de formulário? Consegue fechar pop-ups com Esc?
2. Aplique zoom de 200% e depois de 400%. O texto se reorganiza ou é preciso rolar para os lados? Alguma coisa se sobrepõe ou desaparece?
3. Experimente um leitor de tela por alguns minutos: NVDA (gratuito, Windows), VoiceOver (nativo no macOS e no iOS) ou TalkBack (Android). Liste os cabeçalhos e os links e preencha um formulário. Tudo é anunciado com clareza?
4. Confira as imagens. Leia o texto alternativo (o leitor de tela ou o inspetor de acessibilidade do navegador o mostra). Ele descreve o que importa?
5. Veja a página em tons de cinza (a maioria dos sistemas operacionais tem uma opção de filtro de cor). Alguma informação é transmitida apenas pela cor?

Faça da acessibilidade parte do processo

• Corrija primeiro os problemas em componentes e templates compartilhados; um componente de cabeçalho ou de formulário corrigido conserta todas as páginas que o utilizam.
• Inclua verificações automáticas no seu pipeline de desenvolvimento, por exemplo o axe-core junto com os testes end-to-end, para pegar regressões antes do lançamento.
• Inclua verificações de teclado e de contraste na sua definição de pronto para novas funcionalidades.
• Publique uma declaração de acessibilidade com um canal para as pessoas relatarem barreiras e responda ao que elas disserem.

Erros comuns

• Confiar em um widget de sobreposição (overlay) para resolver a acessibilidade. Um script adicionado por cima da página não conserta a marcação que está por baixo, e muitas pessoas com deficiência relatam que esses overlays atrapalham.
• Encher o texto alternativo de palavras-chave ou começá-lo com "Imagem de" (os leitores de tela já anunciam que se trata de uma imagem).
• Usar texto de placeholder no lugar de rótulos.
• Remover os contornos de foco por motivos estéticos.
• Colocar aria-label em tudo, às vezes sobrescrevendo um texto visível que já era perfeitamente adequado.
• Tratar um relatório automático sem erros como prova de que o site é acessível.