Checklist de Acessibilidade Web: WCAG 2.2 para Designers na Prática

A maioria dos checklists de acessibilidade web é inútil para designers. Eles são organizados pelo número do critério de sucesso do WCAG, que é como um advogado lê a especificação e como ninguém constrói software.

Designers não abrem o Figma pensando no critério 1.4.3. Eles abrem o Figma e escolhem uma cor de texto. O checklist útil encontra o designer onde a decisão acontece, o que significa três listas separadas: uma para o arquivo de design, uma para o navegador, uma para depois do lançamento. Organize de qualquer outro jeito e vai ser ignorado.

O que o WCAG 2.2 realmente exige

O WCAG 2.2 é o padrão global atual em 2026, e acrescenta nove novos critérios de sucesso ao WCAG 2.1, com foco principalmente em mobile, alvos de toque, carga cognitiva e autenticação.

Os nove novos critérios que importam para designers são uma lista curta. O foco aparece de forma mais rigorosa (2.4.11, 2.4.13). Gestos de arrastar agora precisam de uma alternativa sem arrasto (2.5.7). Alvos de toque têm tamanho mínimo de 24 por 24 CSS pixels, a menos que o alvo tenha espaçamento suficiente ao redor (2.5.8). A posição consistente de ajuda em todas as páginas é obrigatória (3.2.6). Formulários não podem solicitar a mesma informação duas vezes sem necessidade (3.3.7). A autenticação não pode depender de um teste cognitivo como lembrar uma senha sem uma alternativa (3.3.8, 3.3.9).

AA é o nível exigido pela maioria das leis de acessibilidade globalmente, incluindo a Lei Europeia de Acessibilidade da UE, a Section 508 nos EUA e as Regulamentações de Acessibilidade para Órgãos do Setor Público do Reino Unido. AAA é mais rigoroso e reservado principalmente para governo, saúde e educação.

Um checklist organizado por números de seção do WCAG é uma especificação. Um checklist organizado por onde o trabalho acontece é uma ferramenta.

O único formato de checklist que funciona

Há três lugares onde a acessibilidade é decidida. O arquivo de design. A interface construída no navegador. O site em produção depois do lançamento.

Cerca de 70% das falhas de acessibilidade são decisões tomadas no Figma, 20% são tomadas na implementação, e 10% vazam depois do lançamento por mudanças de conteúdo, embeds de terceiros ou material gerado por usuários. Qualquer checklist que não mapeia essas três fases força o designer a traduzir da linguagem da especificação para a linguagem do fluxo de trabalho, e é na tradução que os itens são pulados.

O restante deste artigo são as três listas, em ordem. Execute-as em ordem. Qualquer coisa que falhe na verificação da fase de design nunca deve chegar à fase de build. Qualquer coisa que falhe na fase de build nunca deve ser lançada.

Checklist da fase de design (o que verificar no Figma)

Cerca de 70% das falhas de acessibilidade são decisões tomadas no arquivo de design, o que significa que também são as mais baratas de corrigir ali.

O arquivo de design é também onde você pega os novos critérios mobile do WCAG 2.2. Alvos de toque que falham em 2.5.8 quase sempre falham porque o designer estava pensando em pixels de desktop e o alvo é um ícone de 16 pixels sem padding.

Para um mergulho mais fundo em contraste especificamente, veja regras de contraste e APCA. O trabalho de cores na fase de design é onde a maioria dos sites perde a auditoria antes de uma linha de código ser escrita.

Checklist da fase de build (o que verificar no navegador)

O navegador é onde as decisões de acessibilidade são provadas ou expostas, porque é o primeiro lugar onde tecnologias assistivas reais tocam o seu trabalho.

Ferramentas automatizadas capturam cerca de 30% desses itens. O restante precisa de um humano pressionando tab e ouvindo um leitor de tela. Ambos importam, e nenhum substitui o outro.

O melhor conjunto de ferramentas para a fase de build em 2026 é pequeno: axe DevTools para varredura automatizada, Lighthouse para auditorias por página, e um leitor de tela real para a passagem manual. Três ferramentas, dez minutos por página, captura quase tudo que uma auditoria real sinalizaria.

Checklist pós-lançamento (o que verificar em produção)

A acessibilidade não termina no lançamento, porque conteúdo, embeds de terceiros e material gerado por usuários chegam depois que o designer já assinou o trabalho.

A lista pós-lançamento é onde a maioria das equipes falha. O design foi lançado de forma acessível. Os autores do CMS enchem de PDFs sem marcação, vídeos com reprodução automática e um widget de chat com proporção de contraste 2:1 no botão. Acessibilidade é uma propriedade do sistema, não um marco de lançamento.

Precisa de um site que passe no WCAG 2.2 sem um ciclo de remediação de três meses? O Brainy entrega design acessível desde o primeiro frame no Figma.

Erros comuns de designers mapeados para critérios WCAG

Todo achado de auditoria de acessibilidade remete a um critério de sucesso específico do WCAG, e a maioria dos designers comete os mesmos cinco erros contra os mesmos cinco critérios.

Os mesmos dez erros compõem a maioria de cada relatório de auditoria. Corrija esses e você está 80% do caminho para o WCAG 2.2 AA antes de qualquer consultor abrir uma planilha.

Os fundamentos de acessibilidade também se conectam ao resto de uma boa hierarquia visual. Contraste, tamanho de alvo e estados de foco são decisões de hierarquia. Um design que acerta a hierarquia acerta a maior parte do checklist de acessibilidade por padrão, e é por isso que a sobreposição entre uma boa teoria das cores e design acessível é quase total.

Como executar o checklist sem queimar uma semana

O checklist só é útil se executá-lo leva minutos, não dias, o que significa que as ferramentas precisam fazer a maior parte do trabalho.

O ritmo de trabalho é três passagens, uma por fase, cada uma feita no momento em que o trabalho chega àquela fase. Não as três no final. Não uma delas no final. Três passagens separadas, cada uma barata, cada uma aplicada por ferramentas onde possível.

1. Passagem de design: 10 minutos por tela. Stark ou o verificador de contraste do Figma em cada par de texto, deixar o frame em escala de cinza para testar informação apenas por cor, medir cada alvo de toque. Faça antes da entrega, não durante a revisão.
2. Passagem de build: 10 minutos por template. Varredura com axe DevTools, teste de navegação apenas por teclado, uma passagem com leitor de tela nas páginas mais visitadas. Integre axe-core no CI para que novo código não possa fazer merge com regressões.
3. Passagem pós-lançamento: mensal, não por release. Rastreamento completo com axe ou pa11y em produção, auditoria de PDF em qualquer biblioteca de documentos, percurso manual pelos formulários e fluxos de autenticação.

Isso é meio dia de trabalho por mês por produto e talvez 15 minutos por entrega de design. Mais do que isso e a equipe vai parar de executar. Menos do que isso e as auditorias voltam sem correção.

Perguntas frequentes

O WCAG 2.2 é legalmente obrigatório?

Sim, na maioria dos principais mercados. A Lei Europeia de Acessibilidade entrou em vigor em junho de 2025 e referencia o WCAG 2.1 como mínimo, com o 2.2 como padrão atual de trabalho. A Section 508 nos EUA referencia o WCAG 2.0, mas contratos de aquisição exigem cada vez mais o 2.2. Canadá, Reino Unido, Austrália e Japão têm requisitos semelhantes vinculados ao WCAG 2.1 ou 2.2. Se você distribui para qualquer um desses mercados, o WCAG 2.2 AA é o alvo seguro.

Quais são os novos critérios do WCAG 2.2 que preciso conhecer?

Quatro são mais importantes para designers. 2.5.7 Dragging Movements exige uma alternativa sem arrastar para interações de arrastar. 2.5.8 Target Size (Minimum) exige alvos de toque de pelo menos 24 por 24 CSS pixels com espaçamento suficiente. 2.4.11 Focus Not Obscured exige que o elemento focado permaneça visível durante a rolagem e com sobreposições fixas. 3.3.8 Accessible Authentication proíbe testes cognitivos como lembrar uma senha sem uma alternativa (SSO, passkey ou link por e-mail).

Preciso de um checklist separado para mobile?

Não. O WCAG 2.2 foi explicitamente escrito para cobrir mobile e toque, que é por isso que tantos de seus novos critérios (tamanho de alvo, arrastar, foco) são voltados para mobile. O mesmo checklist de três fases funciona para web mobile e design responsivo. Apps nativos têm diretrizes adicionais específicas de plataforma (HIG da Apple e Acessibilidade do Android), mas as regras do WCAG ainda se aplicam.

Qual é o tamanho mínimo do alvo de toque no WCAG 2.2?

24 por 24 CSS pixels é o mínimo sob 2.5.8 Target Size (Minimum), mas há exceções se os alvos têm espaçamento suficiente ao redor ou são inline com texto. O alvo prático que a maioria dos designers deve buscar é 48 por 48 CSS pixels, que corresponde às recomendações de plataforma da Apple e do Google e evita os casos extremos na especificação do WCAG.

Entregue o checklist, não o achismo

Acessibilidade não é uma tarefa de conformidade. É uma propriedade de design, construída em três momentos, aplicada por ferramentas, verificada por humanos.

As equipes que lançam sites acessíveis sem dor não são as que têm os melhores auditores. São as que moveram as verificações para a fase de design, a fase de build e a fase de lançamento, e se recusaram a deixar o trabalho avançar além de qualquer uma delas com falhas conhecidas.

Execute as três listas. Pegue os dez erros comuns antes que se acumulem. Automatize as varreduras da fase de build no CI. Audite a deriva pós-lançamento mensalmente. O WCAG 2.2 AA deixa de ser uma linha de chegada e passa a ser uma propriedade de como a equipe trabalha.

Escolha uma superfície de produto no seu site hoje. Execute o checklist da fase de design contra o arquivo Figma dela. Conte as correções. Esse número é o custo de não ter feito isso antes.

Entregue o checklist, não o achismo.

Precisa de um site que passe no WCAG 2.2 sem um ciclo de remediação de três meses? O Brainy entrega design acessível desde o primeiro frame no Figma.