Ferramenta gratuita: Acessibilidade

Verificador de acessibilidade de sites

Digite o endereço do seu site e testamos essa página e até quatro páginas-chave em um navegador real com as regras da WCAG 2.2 níveis A e AA. Cada barreira vem com o elemento, a página, uma captura de tela e uma explicação de quem ela afeta.

Grátis. Testa até cinco páginas-chave em cerca de um minuto.

O que esta ferramenta verifica

  • Cinco páginas que representam seu site

    A página que você digitar, mais até quatro páginas escolhidas entre os links dela de acordo com o tipo de site. Em uma loja, isso significa uma coleção, um produto, o carrinho e uma página de conteúdo; em outros sites, páginas como preços, contato, um artigo ou serviços. Os templates se repetem, então uma única página de produto costuma mostrar os problemas de todas elas.

  • Regras da WCAG na página renderizada

    Cada página é carregada no Chromium em 1366 × 900, e o axe-core, o mecanismo de regras de código aberto da Deque, executa suas regras da WCAG 2.0, 2.1 e 2.2 níveis A e AA depois que os scripts da página rodam. Assim são detectados problemas que um tema ou app só cria quando a página é montada no navegador.

  • Impacto e critérios de sucesso

    Cada regra com falha mostra seu impacto (crítico, grave, moderado ou leve), os critérios de sucesso da WCAG a que corresponde e quantos elementos e páginas ela afeta.

  • O elemento com falha, destacado

    O HTML de um elemento de exemplo e uma captura de tela da página com esse elemento contornado, para que você ou seu desenvolvedor o encontrem no template sem precisar adivinhar.

  • Itens que uma pessoa precisa avaliar

    Quando o axe-core encontra algo que não consegue resolver, como um texto sobre uma imagem de fundo cujo contraste ele não consegue medir, o item aparece como “requer revisão”. Ele nunca é contado como falha.

  • Um teste de teclado

    Na primeira página, pressionamos Tab 40 vezes e registramos para onde o foco vai: se ele se move, se fica preso em um loop (muitas vezes dentro de um banner de cookies), se a primeira parada é um link para pular ao conteúdo (skip link) e quais elementos focados não mostram um indicador de foco visível. Essa última verificação é uma heurística, por isso aparece como “requer revisão”.

O que ela não consegue verificar

  • Ouvir o que um leitor de tela anuncia. Um software pode confirmar que um botão tem um nome, mas não que esse nome faz sentido quando lido em voz alta.
  • Avaliar legendas, transcrições ou audiodescrição de vídeos e áudios.
  • Avaliar critérios cognitivos e de conteúdo, como se as instruções são claras ou se as mensagens de erro ajudam as pessoas a corrigir o problema.
  • Testar páginas protegidas por login, senha ou proteção contra bots, nem passar por um checkout.
  • Dizer se o seu site está em conformidade com a WCAG ou se cumpre qualquer lei. Regras automatizadas encontram parte dos problemas; o restante exige pessoas.

Por que isso importa

Barreiras de acessibilidade costumam ser pequenos erros de template com grandes efeitos. Um botão de carrinho só com ícone e sem nome acessível é anunciado apenas como “botão”, então quem usa leitor de tela não sabe o que ele faz. Texto cinza sobre fundo branco que não atinge a razão de contraste de 4,5:1 é difícil de ler para muitas pessoas com baixa visão e para qualquer um que use o celular sob sol forte.

Como o mesmo cabeçalho, o mesmo card de produto e o mesmo rodapé aparecem em todas as páginas, uma única correção em um template pode eliminar centenas de falhas de uma vez. Por isso os resultados são agrupados por regra, com a contagem de elementos e páginas, em vez de listar cada ocorrência como um problema separado.

A acessibilidade também tem um lado jurídico em muitos países. Uma análise não pode dizer se uma lei se aplica a você nem se você a cumpre. O que ela oferece é uma lista datada de barreiras reais nas suas próprias páginas, que é o ponto de partida prático em qualquer caso.

Como interpretar os resultados

Crítico
A barreira pode impedir completamente algumas pessoas de usar o elemento, por exemplo um campo de formulário sem rótulo ou um botão sem nome. Corrija esses primeiro.
Grave
A barreira torna uma tarefa muito mais difícil para algumas pessoas, como um texto do corpo da página que não atinge a razão de contraste.
Moderado
A barreira causa dificuldade ou confusão, mas as pessoas geralmente conseguem contorná-la.
Leve
Um problema pequeno ou um incômodo. Ainda vale a pena corrigir na próxima vez que você editar esse template.
Critérios de sucesso da WCAG
Os números ao lado de uma regra, como 1.1.1 ou 1.4.3, são os critérios que ela testa. Uma regra sem critério listado é uma boa prática, e não um requisito da WCAG.
Elementos e páginas
Quantos elementos falharam na regra e em quantas das páginas testadas. Uma regra que falha em todas as páginas geralmente está em uma parte compartilhada, como o cabeçalho, o menu ou o rodapé.
Requer revisão
O axe-core encontrou algo que não conseguiu decidir. Examine o elemento você mesmo: ele pode passar ou falhar. Esses itens não são contados como falhas.
Armadilha de foco
O Tab ficou circulando pelos mesmos poucos elementos. Se eles pertencem a um banner de cookies, quem navega pelo teclado pode não conseguir chegar ao resto da página.
O foco não se move (Focus doesn’t move)
Pressionar Tab nunca colocou o foco em nada. Os links e botões podem ter sido feitos com elementos div ou span, ou um script pode estar engolindo a tecla.
Link para pular ao conteúdo
Se a primeira parada do Tab é um link “Pular para o conteúdo”. Sem ele, quem navega pelo teclado precisa passar por todo o cabeçalho em cada página. Landmarks e títulos (headings) também podem atender ao critério 2.4.1 Ignorar Blocos da WCAG.
Sem indicador de foco visível
Elementos focados em que não vimos contorno (outline), sombra (box shadow) nem sublinhado. Um estilo diferente, como uma mudança de cor, ainda pode ser visível, então percorra esses elementos com Tab você mesmo para confirmar.

Como corrigir os problemas mais comuns

  • Texto que não atinge a razão de contraste

    Texto normal precisa de pelo menos 4,5:1 em relação ao fundo, e texto grande (cerca de 24 px, ou cerca de 18,7 px em negrito) precisa de 3:1. Mude a cor nas configurações do tema ou nos design tokens, e não elemento por elemento; depois verifique de novo o texto de placeholder, os estados de hover e os textos sobre imagens.

  • Imagens sem texto alternativo

    Dê a cada imagem significativa um atributo alt que diga o que ela mostra ou faz, como o nome e a cor do produto. Imagens decorativas recebem um alt vazio (alt="") para que os leitores de tela as ignorem. No Shopify, você adiciona o texto alternativo pela imagem na seção Mídia do produto; no WordPress, no campo Texto alternativo da Biblioteca de mídia.

  • Campos de formulário sem rótulo

    Associe um rótulo a cada campo com <label for> correspondente ao id do campo, ou use aria-label quando não houver texto visível. Não use o texto de placeholder como único rótulo: ele desaparece assim que alguém começa a digitar. Os cadastros de newsletter e as caixas de busca no cabeçalho são os culpados de sempre.

  • Botões e links sem nome acessível

    Controles com ícone para carrinho, busca, menu ou perfis em redes sociais muitas vezes contêm só um SVG. Adicione um texto visível ou um aria-label que diga o que o controle faz (“Abrir carrinho”, e não “ícone”) e adicione aria-hidden="true" ao próprio SVG.

  • Um banner de cookies que prende o foco

    Garanta que cada botão do banner possa ser alcançado com Tab e acionado com Enter ou Espaço, que fechar o banner devolva o foco à página e que um banner que não bloqueia a página não segure o foco de forma alguma. Confira as configurações da sua ferramenta de consentimento e atualize-a se o script for antigo.

  • Contornos de foco removidos no CSS

    Procure nas suas folhas de estilo por outline: none ou outline: 0 em links, botões e :focus. Substitua por um estilo visível, como :focus-visible { outline: 2px solid currentColor; outline-offset: 2px; }.

Perguntas sobre esta ferramenta

Este verificador de acessibilidade é gratuito?

Sim. Não é preciso se cadastrar; você só confirma que é dono do site ou que o administra. O Relatório de Acessibilidade pago acrescenta até 20 páginas a mais do seu sitemap, um percurso feito só com o teclado, uma verificação de refluxo (reflow) em 320 px, código de antes e depois criado a partir da sua marcação com falha, prompts de IA, um PDF e 5 novos testes.

Quanto da WCAG um verificador automático consegue testar?

Só uma parte. Uma regra consegue verificar se uma imagem tem texto alternativo, mas não se o texto descreve a imagem, e se um campo tem rótulo, mas não se o rótulo é claro. Trate os resultados como uma lista de problemas certos e teste o restante com o teclado e um leitor de tela.

Se a análise não encontrar nada, meu site está em conformidade com a ADA ou com a WCAG?

Não. Nenhum teste automatizado pode mostrar que um site está em conformidade com a WCAG ou que cumpre a ADA, a Lei Europeia de Acessibilidade (European Accessibility Act) ou qualquer outra lei. Um resultado limpo significa que as regras automatizadas não encontraram falhas nas páginas testadas.

Posso verificar um site de homologação ou páginas protegidas por login?

Páginas protegidas por login, senha ou proteção contra bots não podem ser testadas. Se a sua proteção contra bots bloquear a análise, libere o user agent FixReportsScanner ou teste uma cópia pública do ambiente de homologação.

Corrigi um problema. Por que o resultado continua igual?

Os resultados para o mesmo endereço podem ser reaproveitados de uma análise feita na última hora. Espere essa hora passar e limpe qualquer cache de página ou de CDN antes de testar de novo.

Fontes

Ferramentas relacionadas

O Relatório de Acessibilidade ($174, pagamento único) parte da análise gratuita completa e acrescenta mais páginas, a mudança a fazer para cada achado, um PDF e novos testes para verificar suas correções.

Sobre o Relatório de Acessibilidade