Um processo de testes de acessibilidade que as equipes web conseguem manter de verdade

Um processo repetível para testar a acessibilidade de sites: o que automatizar, o que uma pessoa precisa verificar à mão, como fazer a amostragem de páginas, quem aprova, como registrar e corrigir problemas e uma barreira de lançamento que impede que novos problemas vão ao ar.

A maioria das equipes web já fez pelo menos uma auditoria de acessibilidade. Um consultor testou 40 páginas, entregou um relatório de 90 páginas e, seis meses depois, metade das correções estava feita e o dobro de problemas novos tinha ido ao ar. A auditoria não foi o erro. O que faltava era um processo: um jeito de testar que acontece toda vez que algo muda, executado por pessoas que já estão na equipe. Este guia apresenta um, na ordem em que você o implantaria.

O princípio: três camadas, cada uma pegando o que as outras deixam passar

A Web Accessibility Initiative do W3C é clara: ferramentas de avaliação ajudam, mas nenhuma ferramenta sozinha consegue determinar se um site atende aos padrões de acessibilidade. Um processo sensato, portanto, tem três camadas.

Camada	Pega	Deixa passar	Quando roda
Verificações automatizadas	Atributos alt ausentes, baixo contraste de cor em texto simples, rótulos de formulário ausentes, links vazios, IDs duplicados, idioma da página ausente	Se o texto alternativo tem sentido, se a ordem de foco faz sentido, se um widget personalizado funciona com leitor de tela, se as instruções dependem de cor ou forma	A cada alteração de página, de preferência automaticamente
Verificações manuais pela equipe	Armadilhas de teclado, foco invisível, títulos confusos, texto de link pouco claro, zoom e reajuste de layout quebrados, mensagens de erro ruins	O atrito real para pessoas que usam tecnologia assistiva todos os dias	Antes de cada lançamento e em modelos novos
Testes com usuários com deficiência	Se a tarefa pode realmente ser concluída: pagar uma conta, reservar uma sala, solicitar um alvará	A cobertura completa do padrão	Uma ou duas vezes por ano, nas tarefas mais importantes

Equipes que dependem de uma única camada obtêm resultados previsíveis. Equipes só de testes automatizados passam no scanner e falham com os usuários reais. Equipes só de testes manuais não conseguem acompanhar o volume de mudanças. Equipes que só fazem testes com usuários encontram os grandes problemas e deixam passar centenas de pequenos.

Escolha seu alvo e registre por escrito

Decida contra qual padrão você testa e coloque isso na sua política. Muitas organizações usam o WCAG 2.1 Level AA porque é o padrão da regra do Departamento de Justiça para governos estaduais e locais sob o ADA Title II. O WCAG 2.2 é a Recomendação atual do W3C; ele acrescenta critérios (por exemplo, sobre o foco não ficar oculto e sobre o tamanho dos alvos) e remove o 4.1.1 Parsing por estar obsoleto. Testar contra o 2.2 AA também cobre o 2.1 AA, exceto o Parsing, então muitas equipes testam com o 2.2 e reportam contra o que a sua obrigação legal citar. Veja Section 508 vs ADA Title II vs WCAG para saber o que se aplica a quem.

Passo 1: Escolha o que testar (amostragem)

Você não consegue testar todas as páginas à mão em cada lançamento. Use uma amostra que represente o site, uma ideia tirada da metodologia de avaliação do W3C (WCAG-EM).

Todos os modelos. Página inicial, landing page, artigo, listagem, resultados de busca, formulário, página de erro, evento, notícia, diretório da equipe. Falhas de modelo se repetem em todas as páginas que o usam, então corrigir uma corrige centenas.
Todos os componentes. Menus, acordeões, abas, carrosséis, modais, seletores de data, mapas, players de vídeo, banners de cookies, widgets de chat.
As tarefas principais. As cinco a dez coisas que a maioria das pessoas vem fazer. Para uma prefeitura, isso pode ser pagar a conta de água, reportar um buraco na rua, encontrar pautas de reuniões e solicitar um alvará.
Um punhado aleatório. Cinco a dez páginas escolhidas ao acaso, para pegar problemas de conteúdo que os modelos não explicam.

Registre a amostra em uma tabela curta e mantenha-a sob controle de versão. Acrescente itens quando surgir um modelo ou componente novo.

Passo 2: A verificação manual que todo testador executa

Este é o núcleo do processo. Leva de 15 a 30 minutos por página quando as pessoas já têm prática, e não exige nenhum software especial além de um navegador e do leitor de tela gratuito do sistema operacional.

#	Verificação	Como	A falha se parece com
1	Só teclado	Deixe o mouse de lado. Percorra a página inteira com Tab e use Enter, Espaço, setas e Esc	Algo não pode ser alcançado ou operado; o foco fica preso; um menu não pode ser fechado
2	Foco visível	Enquanto usa o Tab, você sempre consegue ver onde está?	O foco some, ou fica escondido atrás de um cabeçalho fixo
3	Ordem de foco	O foco se move em uma ordem sensata?	Pula do cabeçalho para o rodapé e volta; o modal abre, mas o foco fica atrás dele
4	Zoom e reajuste de layout	Aplique zoom de 200% e 400%; use uma janela estreita	Texto cortado, rolagem horizontal no corpo do texto, elementos sobrepostos
5	Títulos	Veja a estrutura de títulos com uma extensão do navegador ou um leitor de tela	Sem H1, níveis pulados usados para estilizar, títulos que são só texto em negrito
6	Imagens	Leia o texto alternativo fora de contexto	"image1.jpg", "foto" ou a descrição de um floreio decorativo; gráficos informativos sem equivalente em texto
7	Links e botões	Liste todos os links; eles fazem sentido sozinhos?	Dez links dizendo "Clique aqui" ou "Saiba mais"
8	Formulários	Envie vazio e depois envie valores errados	Erros mostrados só em vermelho, não anunciados ou não vinculados ao campo; rótulos que somem ao digitar
9	Passada com leitor de tela	Ative o leitor de tela e conclua a tarefa principal da página	Botões sem rótulo, conteúdo anunciado duas vezes, mudanças dinâmicas não anunciadas
10	Movimento e mídia	Reproduza vídeos, observe as animações	Sem legendas, movimento automático sem pausa, piscadas
11	Dependência de cor	A página ainda faria sentido em tons de cinza?	Campos obrigatórios ou status indicados só por cor
12	Documentos	Abra cada PDF ou arquivo de escritório vinculado na amostra	Imagens digitalizadas de texto, sem tags, sem ordem de leitura

Nossa lista de verificação de acessibilidade de sites vai critério por critério, se você quiser a versão longa. A tabela acima é a versão que as pessoas realmente vão executar toda semana.

Passo 3: Registre os problemas para que sejam corrigidos

Um bom registro é aquele que um desenvolvedor ou editor consegue corrigir sem fazer nenhuma pergunta. Use um único modelo para todos os problemas.

Campo	Exemplo
Onde	Modelo: página de evento. URL: /events/summer-concert
O que acontece	O menu "Adicionar ao calendário" abre com Enter, mas não pode ser fechado com Esc; o foco fica preso dentro dele
Quem é afetado	Usuários de teclado e de leitor de tela
Critério	WCAG 2.1.2 No Keyboard Trap
Gravidade	Bloqueador / Grave / Leve (definições abaixo)
Como reproduzir	Vá com Tab até "Adicionar ao calendário", pressione Enter, pressione Esc
Correção sugerida	Fechar o menu com Esc e devolver o foco ao botão que o abriu
Responsável	Desenvolvedor front-end (modelo) ou editor de conteúdo (conteúdo)

Definições de gravidade encurtam as discussões:

Bloqueador: alguém não consegue concluir uma tarefa. Corrija antes do lançamento; se já estiver no ar, corrija nesta semana.
Grave: a tarefa é possível, mas muito mais difícil. Corrija no próximo lançamento.
Leve: irritante, mas não impede. Corrija na próxima vez que mexer na página.

Separe os problemas por responsável. Falhas de modelos e componentes vão para os desenvolvedores e são corrigidas uma única vez. Problemas de conteúdo (texto alternativo, títulos, texto de link, documentos) vão para o departamento dono da página. Misturá-los em uma única fila é como problemas de conteúdo ficam um ano sem correção.

Passo 4: Coloque uma barreira antes da publicação

Testar depois da publicação só mede o estrago. A correção mais barata é a feita antes de uma página ir ao ar. Três barreiras, da mais leve à mais forte:

Autoverificação do editor. Uma lista de cinco linhas no treinamento do editor: títulos em ordem, texto alternativo com sentido, links descritivos, nenhum PDF novo onde uma página resolveria, legendas nos vídeos.
Verificação automatizada ao salvar. Se sua plataforma ou pipeline permitir, rode um scanner nas páginas alteradas e mostre os resultados ao editor.
Revisão antes de ir ao ar. Um revisor treinado olha páginas novas, sites novos e alterações grandes antes da publicação. É a barreira que pega os problemas que as ferramentas não pegam.

Para organizações que mantêm muitos sites, a terceira barreira é onde as plataformas se diferenciam. Na We.Inc, uma organização pode configurar qualquer site para que a publicação precise de uma aprovação em etapa única antes de o site ir ao ar, e a solicitação cai em uma fila de aprovação. Ela não testa a acessibilidade por você; ela dá ao seu revisor um momento fixo para fazer isso.

Configurações padrão de toda a marca intituladas O que seus clientes podem fazer, com chaves para cada permissão e uma lista da equipe — Permissões padrão para todos os sites da organização, definidas uma vez.

Uma fila de aprovação listando um site com os botões Aprovar e publicar e Pedir alterações — Um revisor pode aprovar ou pedir alterações. A solicitação mostrada foi montada para a captura de tela; a tela é o produto real.

O editor visual com um título selecionado e seus controles de fonte, tamanho e cor abertos — Os editores mudam títulos e estilos em um editor visual. Os níveis de título e o contraste ainda precisam ser verificados na revisão.

Um painel de código mostrando a árvore de arquivos e o código-fonte de um componente Hero, com um botão Download — Os desenvolvedores podem ler e baixar o código-fonte do site, o que ajuda quando é preciso uma correção no nível do modelo.

Passo 5: Ritmo e relatórios

Com que frequência	O quê	Quem
A cada alteração	Varredura automatizada; autoverificação do editor	Editores, pipeline
A cada lançamento	Verificação manual de 12 pontos nos modelos e componentes alterados	Testador da equipe web
Mensal	Verificação manual na amostra; contagem de problemas abertos por gravidade	Líder de acessibilidade
Duas vezes por ano	Testes baseados em tarefas com usuários com deficiência nas tarefas principais	Líder de acessibilidade, participantes remunerados
Anual	Auditoria independente contra o padrão escolhido; revisão da amostra; atualização da declaração de acessibilidade	Auditor externo

Reporte dois números à liderança todo mês: bloqueadores abertos e graves abertos. Não uma nota. Notas de ferramentas automatizadas sobem e descem por motivos que não têm nada a ver com os usuários, e convidam à manipulação.

Equipe: quem faz o quê

Líder de acessibilidade. É dono do processo, da amostra e da fila de problemas. Não precisa ser em tempo integral em uma organização pequena, mas precisa ser nomeado.
Testadores. Qualquer desenvolvedor, designer ou pessoa de QA treinado na verificação de 12 pontos. Treine pelo menos dois, para que as férias não travem os lançamentos.
Editores. Treinados na autoverificação. A maioria dos problemas de conteúdo é criada por editores bem-intencionados a quem nunca mostraram como títulos e texto alternativo funcionam.
Participantes com deficiência. Remunerados, recrutados por meio de organizações locais de pessoas com deficiência ou de um painel de pesquisa, e convidados a concluir tarefas, não a "avaliar o site".
Compras. Todo produto de um novo fornecedor passa pela mesma verificação manual antes da compra, não depois. Nossa lista de verificação de compras traz perguntas para fazer.

Erros que desfazem o processo

Comprar um overlay em vez de corrigir o código. Scripts que dizem tornar um site acessível automaticamente não corrigem a marcação subjacente, e alguns criam novos problemas para usuários de leitor de tela.
Tratar a auditoria anual como o processo. Ela é uma checagem do processo.
Testar só no desktop. Faça as verificações de teclado e de leitor de tela também no celular; muitos visitantes do setor público só usam o celular.
Aceitar "em conformidade" de um fornecedor sem evidências. Pergunte como ele testou, contra qual versão, e veja os resultados. Nenhuma plataforma, incluindo a nossa, pode prometer que o conteúdo que sua equipe adiciona será acessível.

Se você mantém muitos sites e quer uma etapa de revisão antes de cada um deles, agende uma demonstração e mostraremos as configurações de aprovação e permissões em uma marca real.

Fontes

Última verificação em 2026-10-25.

W3C WAI, Evaluating Web Accessibility Overview (ferramentas sozinhas não determinam a conformidade; WCAG-EM).
W3C, Web Content Accessibility Guidelines (WCAG) 2.2 (4.1.1 Parsing obsoleto e removido).
ADA.gov, Fact Sheet: Title II web and mobile app rule (WCAG 2.1 AA; datas de conformidade alteradas).

Este guia é informação geral, não aconselhamento jurídico.

Perguntas frequentes

Ferramentas automatizadas conseguem testar a acessibilidade sozinhas?

Não. O W3C diz que nenhuma ferramenta sozinha consegue determinar se um site atende aos padrões de acessibilidade. Verificações automatizadas pegam rapidamente uma parte dos problemas; verificações manuais e testes com usuários com deficiência pegam o resto.

Quantas páginas devemos testar à mão?

Teste uma amostra representativa em vez de todas as páginas: todos os modelos, todos os componentes, as cinco a dez tarefas principais e algumas páginas aleatórias. Acrescente itens à amostra quando surgirem modelos novos.

Devemos testar contra o WCAG 2.1 ou o 2.2?

Teste contra a versão que sua obrigação cita; o ADA Title II usa o WCAG 2.1 AA. Muitas equipes testam com o WCAG 2.2 AA, que também cobre o 2.1 AA, exceto o critério Parsing, que foi removido.

Como priorizar os problemas de acessibilidade?

Use três gravidades: bloqueadores impedem uma tarefa e são corrigidos antes do lançamento, graves tornam uma tarefa muito mais difícil e são corrigidos no próximo lançamento, e leves são corrigidos na próxima vez que alguém mexer na página.

A We.Inc torna os sites acessíveis automaticamente?

Não. A We.Inc pode exigir uma aprovação em etapa única antes de um site ir ao ar, o que dá ao seu revisor um momento fixo para testar, mas sua equipe ainda precisa testar cada site.