Guia · WCAG 2.2
WCAG 2.2 para quem constrói produtos digitais
A WCAG 2.2 transforma necessidades de acessibilidade em critérios verificáveis. O valor aparece quando esses critérios deixam de ser uma auditoria no final e passam a orientar design, conteúdo, desenvolvimento e QA.
Como a WCAG 2.2 se organiza
A WCAG é organizada em quatro princípios: perceptível, operável, compreensível e robusto. Dentro deles existem diretrizes e critérios de sucesso que podem ser avaliados.
Os critérios são classificados nos níveis A, AA e AAA. Isso não significa que um critério AAA seja irrelevante, nem que cumprir AA automaticamente garanta boa experiência. O nível de conformidade é uma referência; o contexto do produto continua importando.
Para equipes de produto, a leitura fica mais útil quando cada critério é traduzido para responsabilidade concreta. Quem decide contraste? Quem especifica foco? Quem escreve instruções? Quem valida semântica? Quem testa a recuperação de erros?
WCAG para UX e UI Design
Muitos problemas de acessibilidade nascem antes do desenvolvimento. Contraste, tamanho de alvo, foco, ordem de leitura, estados, mensagens de erro, instruções e comportamento de componentes precisam ser previstos no design.
O handoff deve registrar o que acontece quando a pessoa navega por teclado, onde o foco vai depois de abrir ou fechar um modal, como erros são identificados e qual é o nome acessível esperado para controles.
Uma boa especificação reduz interpretação no desenvolvimento e cria critérios objetivos para QA.
WCAG para conteúdo e UX Writing
Conteúdo acessível depende de títulos claros, instruções que não se apoiam apenas em posição ou cor, links descritivos, alternativas textuais úteis e mensagens de erro que expliquem como resolver o problema.
Em formulários, por exemplo, placeholders não substituem rótulos. Em imagens, o texto alternativo deve comunicar a função ou informação relevante no contexto, e não simplesmente descrever tudo o que aparece.
Mídias também precisam considerar legendas, transcrições e audiodescrição quando aplicável.
WCAG para desenvolvimento e QA
No desenvolvimento, HTML semântico deve ser a primeira escolha. Elementos nativos já carregam comportamento, nome e interação esperados. ARIA é importante quando necessário, mas não corrige uma estrutura inadequada por si só.
QA precisa ir além da automação. Teste navegação por teclado, foco, zoom, reflow, contraste, rótulos, nomes acessíveis, estados e leitores de tela. Ferramentas como axe, Lighthouse e Accessibility Insights ajudam, mas não substituem inspeção manual.
O melhor resultado aparece quando critérios WCAG entram na definição de pronto e não apenas em uma auditoria separada.
O que a WCAG 2.2 reforça
A WCAG 2.2 trouxe atenção adicional para foco, tamanho de alvo, gestos de arrastar, autenticação acessível e consistência de mecanismos de ajuda. Esses temas aproximam a diretriz de problemas comuns em produtos atuais.
Para design e produto, isso reforça uma ideia importante: acessibilidade não está só em contraste e texto alternativo. Ela também está em interação, previsibilidade, esforço e capacidade de concluir tarefas.
Em vez de decorar critérios, vale organizar uma matriz por área e componente. Isso torna a aplicação mais prática no dia a dia.
Checklist para levar para o dia a dia
- Mapear critérios WCAG para design, conteúdo, desenvolvimento e QA.
- Especificar comportamento de foco e teclado no handoff.
- Preferir HTML semântico antes de recorrer a ARIA.
- Testar zoom, reflow e diferentes tamanhos de viewport.
- Verificar mensagens de erro e prevenção de erros.
- Combinar ferramentas automáticas com avaliação manual.
- Registrar requisitos por componente no Design System.
Perguntas frequentes
Qual nível da WCAG devo usar?
Isso depende do contexto, requisitos legais e compromissos do produto. Em muitos cenários o nível AA é a referência mais adotada, mas critérios AAA também podem ser relevantes para a experiência.
Cumprir WCAG garante que o produto é acessível?
Não sozinho. A WCAG cobre muitos requisitos importantes, mas usabilidade, contexto, conteúdo e experiência real também precisam ser avaliados.
ARIA deixa qualquer componente acessível?
Não. ARIA complementa a semântica quando necessário. Sempre que possível, elementos HTML nativos devem ser preferidos porque já oferecem comportamentos esperados.
Continue por outros temas
Vitor David atua com Product Design e acessibilidade digital, conectando Design Systems, pesquisa, testes, especificação, governança e operação de acessibilidade.