Como testar a acessibilidade de um site: ferramentas e verificações

Esta é uma história que ouvimos muitas vezes. Alguém corre o Lighthouse, tem um 100 verde em acessibilidade e passa à frente. Uma semana depois, um cliente escreve a dizer que não conseguiu pagar, porque o formulário do cartão não se alcança com o teclado. As duas coisas são verdade. O teste automático passou e, ainda assim, o site falhou a uma pessoa real.

Este guia mostra como testar bem com pouco orçamento: que ferramentas gratuitas usar, uma rotina manual de 15 minutos, uma primeira experiência com um leitor de ecrã e quando vale a pena pagar uma auditoria.

Um verificador automático consegue dizer-me se o meu site é acessível?

Não. Os verificadores automáticos encontram alguns problemas depressa, mas muitas questões de acessibilidade precisam de uma pessoa para lhes responder. Quando o Government Digital Service britânico testou 10 ferramentas numa página com 143 falhas conhecidas, a melhor encontrou 41%. O W3C di-lo sem rodeios: as ferramentas de avaliação «não conseguem determinar a acessibilidade, só podem ajudar a fazê-lo».

O teste do GDS (abre num novo separador) é de fevereiro de 2017, e os seus 41% (do Asqatasun) incluíam os avisos da própria ferramenta para verificações manuais. As ferramentas melhoraram desde então, mas a lacuna tem a mesma causa. Um software consegue perceber que uma imagem não tem texto alternativo. Não consegue perceber que «vestido vermelho» é a descrição errada para a fotografia de um fato azul, nem se a ordem do foco faz sentido.

Por isso, trate um verificador como um detetor de fumo, não como uma vistoria ao edifício. Mesmo assim, vale a pena usá-lo: o WebAIM Million 2026 (abre num novo separador) encontrou falhas detetáveis em 95,9% das páginas iniciais do milhão de sites mais visitados, por isso na maioria dos sites há melhorias fáceis de fazer. Como diz o guia do W3C para escolher ferramentas (abre num novo separador), «é necessário o juízo humano».

Que ferramentas gratuitas de teste de acessibilidade devo usar?

Use um ou dois verificadores automáticos, um verificador de contraste e um leitor de ecrã. As ferramentas aplicam regras diferentes e apresentam os resultados de formas diferentes, por isso dois verificadores costumam apanhar mais do que um. Todas as ferramentas abaixo têm uma versão gratuita. Confirme as condições atuais de cada uma antes de confiar nela, porque os nomes, as funcionalidades e os preços mudam.

O que posso verificar manualmente em 15 minutos?

Bastante. As Easy Checks do W3C (abre num novo separador) («verificações simples») cobrem títulos de página, texto alternativo, títulos de secção, contraste, ligações para saltar conteúdo, foco visível do teclado, idioma da página, zoom, legendas e etiquetas de formulários. Escolha uma página importante, como uma página de produto ou o formulário de reserva, e dê um ou dois minutos a cada verificação. Vai encontrar coisas que nenhum verificador assinala.

O W3C avisa que estas verificações «abrangem apenas alguns problemas de acessibilidade», por isso não são uma avaliação completa. Ainda assim, são o melhor quarto de hora que pode gastar:

1. Título da página (1 minuto). O separador do navegador diz o que é a página, como «Reservar mesa | Cozinha da Rosa», em vez de «Início» em todo o lado?
2. Imagens (2 minutos). Mostre o texto alternativo com o WAVE ou uma ferramenta semelhante. É rigoroso? As imagens decorativas são ignoradas?
3. Títulos (2 minutos). Liste os títulos e leia-os isoladamente. Funcionam como um índice?
4. Contraste (2 minutos). Verifique o texto corrido, o texto cinzento pequeno, o texto dos botões e o texto sobre imagens.
5. Teclado (4 minutos). Ponha o rato de lado e percorra a página com Tab (veja a secção seguinte).
6. Zoom (2 minutos). A 200% e depois a 400%, ainda consegue ler tudo e usar o menu sem deslocar a página para o lado?
7. Formulários e idioma (2 minutos). Clique na etiqueta de cada campo; num formulário bem feito, isso coloca o cursor no campo. Veja no relatório da ferramenta se falta o idioma da página.

Como testar com o teclado?

Ponha o rato de parte. Prima Tab para avançar, Shift+Tab para recuar, Enter para seguir ligações, a barra de espaços ou Enter para premir botões, e as setas dentro de menus e botões de opção. Todos os elementos interativos devem ser alcançáveis, deve ver sempre onde está e nunca deve ficar preso.

Num Mac, o Safari salta as ligações quando prime Tab até ativar, nas definições avançadas, a opção para realçar cada elemento da página web com a tecla Tab. Depois verifique:

• Vê sempre onde está? Se o contorno do foco desaparecer, quem usa o teclado fica perdido.
• A ordem é lógica? O foco deve seguir a ordem de leitura.
• Há alguma coisa tapada? Um cabeçalho fixo ou uma faixa de cookies que esconde o elemento com foco falha o critério Foco não obscurecido das WCAG 2.2.
• Consegue voltar a sair? Abra cada menu, janela pop-up e seletor de datas e tente sair. A tecla Escape deve fechar as caixas de diálogo.
• O percurso completo funciona? Adicione um produto, mude a quantidade, aplique um código promocional e chegue ao pagamento sem o rato.

Registe cada falha com precisão: «O seletor de tamanho na página de produto não abre com Enter nem com a barra de espaços» é corrigido muito mais depressa do que «o teclado não funciona».

Como testar com um leitor de ecrã pela primeira vez?

Comece pelo leitor de ecrã que o seu dispositivo já tem, ou pelo NVDA no Windows, e ouça uma página. Não se trata de o usar como um especialista, mas de verificar se os títulos, as ligações, os botões, as imagens e os campos de formulário são anunciados com nomes que fazem sentido, e se nada de importante fica em silêncio.

• Mac: Command+F5 liga e desliga o VoiceOver; Control+Option+U abre o rotor, uma lista de títulos, ligações e controlos de formulário.
• Windows: no NVDA, prima H para saltar entre títulos e Insert+F7 para listar ligações e títulos.
• Telemóvel: ative o VoiceOver (iPhone) ou o TalkBack (Android) e deslize para a direita para passar de elemento em elemento. Aprenda primeiro a desligá-lo.

Esteja atento ao que mais importa. No inquérito da WebAIM de 2024 a utilizadores de leitores de ecrã (abre num novo separador), 71,6% disseram que percorrem primeiro uma página longa pelos títulos, por isso comece por aí. Depois abra a lista de ligações: cinco ligações chamadas «Ler mais» não dizem nada a ninguém. «Adicionar ao carrinho, camisola azul-marinho» é um botão útil; «botão» não é. Por fim, preencha um formulário e confirme que todos os campos e erros são lidos.

Seja modesto nas conclusões. Se lhe parecer que não funciona, provavelmente não funciona; se lhe parecer que está bem, isso não prova nada. Para saber como trabalham de facto os utilizadores experientes, leia como as pessoas com deficiência usam a web.

Como verificar o zoom, o realinhamento e o espaçamento do texto?

Amplie o navegador para 200% e verifique se o texto aumenta sem ficar cortado nem sobreposto. Depois teste o realinhamento (reflow): com zoom a 400% numa janela com 1280 píxeis de largura, o conteúdo deve caber sem deslocação horizontal. Por fim, aumente o espaçamento entre letras, palavras, linhas e parágrafos, e verifique se nada se desconfigura ou desaparece.

Estes testes correspondem aos critérios das WCAG Redimensionar texto (1.4.4), Realinhar (1.4.10) (abre num novo separador) e Espaçamento de texto (1.4.12) (abre num novo separador). O realinhamento usa uma largura de 320 píxeis CSS, que o W3C nota ser «equivalente a uma janela com uma largura inicial de 1280 píxeis CSS com zoom a 400%». O espaçamento de texto exige que nada se perca quando o leitor define a altura de linha em 1,5 vezes o tamanho da fonte, o espaçamento entre parágrafos em 2 vezes, o espaçamento entre letras em 0,12 vezes e o espaçamento entre palavras em 0,16 vezes.

Um bookmarklet de espaçamento de texto, um pequeno script guardado como marcador, aplica os quatro valores com um clique. Procure texto a sair dos botões e etiquetas cortadas na margem. Com zoom a 400%, um portátil mostra mais ou menos o mesmo que um telemóvel pequeno, por isso um site responsivo bem construído já passa em boa parte disto.

Como verificar formulários, erros e checkout?

Preencha cada formulário importante três vezes: uma corretamente, outra com todos os campos vazios e outra com erros propositados. Cada campo deve ter uma etiqueta visível, cada erro deve ser explicado por palavras junto ao respetivo campo, e deve conseguir colar nos campos de palavra-passe e de código de verificação.

• Erros. «Dados inválidos» a vermelho não chega. «Introduza a data de validade no formato MM/AA», junto ao campo, chega. Depois de submeter, o foco deve passar para o resumo de erros ou para o primeiro campo com problemas.
• Inícios de sessão e códigos. Segundo o critério de autenticação acessível (abre num novo separador) das WCAG 2.2, bloquear a função colar ou os gestores de palavras-passe falha, a não ser que haja outra forma de entrar.
• CAPTCHA e limites de tempo. No inquérito da WebAIM, os utilizadores de leitores de ecrã classificaram o CAPTCHA como o elemento mais problemático da web. Verifique se há uma alternativa acessível e se os limites de tempo podem ser prolongados.

A nossa lista de verificação de acessibilidade web tem uma lista mais completa para lojas, que inclui faixas de cookies e janelas pop-up.

O que inclui uma auditoria de acessibilidade profissional e quando preciso de uma?

Uma auditoria de acessibilidade é uma revisão estruturada, feita por um especialista, com base numa norma concreta, normalmente as WCAG 2.1 ou 2.2 de nível AA. Combina análises automáticas com testes manuais e com tecnologias de apoio dos seus modelos e percursos principais, e termina num relatório com prioridades. Precisa de uma quando a lei se aplica a si, antes de um lançamento importante ou quando os clientes lhe pedem provas.

Antes de acordar um preço, pergunte:

• Com que norma, versão e nível vão testar?
• Que modelos e percursos estão incluídos no âmbito? Numa loja: página inicial, categoria, produto, carrinho, checkout, páginas de conta e formulários.
• Testam manualmente com leitores de ecrã, teclado e zoom, e em que navegadores e dispositivos?
• O relatório ordena os problemas por gravidade, localiza-os e sugere correções?
• Está incluído um novo teste depois das correções?

Os preços variam muito com o fornecedor, o país e o âmbito, por isso compare o que está incluído. Se o Ato Europeu da Acessibilidade se aplicar a si, uma auditoria também sustenta a sua declaração pública; o nosso guia sobre o EAA explica quem está abrangido.

Porquê testar com pessoas com deficiência?

Porque cumprir uma norma e ser fácil de usar não são a mesma coisa. Um checkout pode cumprir todos os critérios das WCAG e mesmo assim levar vinte minutos a um utilizador de leitor de ecrã. O W3C diz que avaliar com utilizadores com deficiência «identifica problemas de usabilidade que não são descobertos apenas pela avaliação da conformidade», e mostra à sua equipa como as pessoas usam realmente o site.

Não precisa de um laboratório. Algumas sessões sobre a sua tarefa mais importante, como encontrar um produto e pagar, ensinam-lhe mais do que outra ronda de análises. Recrute participantes através de organizações de pessoas com deficiência, empresas de estudos de mercado ou dos seus próprios clientes, e pague às pessoas pelo seu tempo. Deixe-as usar os seus próprios dispositivos e definições. O guia do W3C sobre como envolver os utilizadores na avaliação (abre num novo separador) trata da parte prática.

O que faço com os resultados?

Ordene os problemas pela gravidade com que bloqueiam as pessoas e pelo sítio onde acontecem, corrija-os no código e nos conteúdos do próprio site, volte a testar e registe o que ficou por resolver. Um campo sem etiqueta no checkout importa mais do que um deslize de contraste no rodapé, e uma correção num modelo partilhado repara todas as páginas que o usam.

1. Defina prioridades. Primeiro os bloqueios nos percursos principais (checkout, reserva, registo), depois os modelos partilhados e por fim as páginas isoladas.
2. Corrija na origem. Altere o tema, o componente ou o conteúdo, e não apenas o sintoma.
3. Volte a testar. Repita as mesmas verificações, manualmente e não só com ferramentas.
4. Documente. Liste os problemas conhecidos, com datas, na sua declaração de acessibilidade. O nosso guia das WCAG 2.2 explica os critérios mais recentes.
5. Repita. Acrescente uma verificação com teclado e uma análise automática a cada nova versão.

Se usa um widget de acessibilidade, incluindo o nosso, teste com o painel fechado. Um painel como a SiteAccessible dá aos visitantes mais formas de ajustar a página, mas as WCAG avaliam se a página funciona no seu estado predefinido. Alguns sistemas de auditoria não avaliam páginas com um script do tipo overlay, por isso confirme primeiro com o auditor.