Como tornar o seu site conforme com a WCAG 2.2

Tornar o seu site conforme com a WCAG 2.2 é um processo, não uma correção pontual. A conformidade é o resultado de um fluxo de trabalho repetível: compreender a norma, medir onde se encontra, corrigir as coisas certas pela ordem certa, validar com tecnologias de apoio reais e utilizadores reais, documentar o resultado e impedir que regrida. Este guia transforma esse fluxo de trabalho num roteiro concreto, passo a passo, que a sua equipa pode começar a usar hoje mesmo — sem recorrer aos «overlays» de acessibilidade, que mascaram os problemas no DOM em vez de os corrigir e que têm sido referidos repetidamente em processos judiciais.

Passo 1: Compreender o que a WCAG 2.2 realmente exige

Antes de auditar seja o que for, clarifique o objetivo. As Diretrizes de Acessibilidade para o Conteúdo Web organizam-se em torno de quatro princípios, resumidos pelo acrónimo POUR (em inglês):

Percetível — os utilizadores têm de conseguir percecionar o conteúdo. Pense em alternativas textuais para imagens, legendas e transcrições para multimédia, e contraste de cor suficiente.
Operável — todas as funções têm de funcionar sem rato. A plena operabilidade por teclado, indicadores de foco visíveis e a ausência de armadilhas de teclado são requisitos fundamentais.
Compreensível — o conteúdo e o comportamento têm de ser previsíveis. Etiquetas claras, navegação consistente, mensagens de erro úteis e linguagem legível inserem-se aqui.
Robusto — a marcação tem de ser interpretável pelas tecnologias de apoio atuais e futuras, o que na prática significa HTML válido e uso correto dos nomes, papéis e valores ARIA.

Cada princípio decompõe-se em critérios de sucesso testáveis, e a cada critério é atribuído um nível de conformidade: A (essencial), AA (a referência legal e prática visada pela maioria das organizações) e AAA (reforçado). Quando se fala em «WCAG 2.2 AA», entende-se a conformidade com todos os critérios de sucesso de nível A e de nível AA. A WCAG 2.2 acrescenta nove novos critérios em relação à 2.1 — incluindo Foco Não Obscurecido, Movimentos de Arrastar, Tamanho do Alvo (mínimo) e Autenticação Acessível — a maioria dos quais melhora a experiência dos utilizadores de teclado, com baixa visão e com mobilidade reduzida.

Ajuda compreender porque é este o objetivo. A conformidade AA é referenciada pelas leis e regulamentos que muito provavelmente se aplicam a si: informe-se sobre a conformidade com a WCAG enquanto norma técnica, e depois veja como se articula com o European Accessibility Act, o ADA para entidades privadas e públicas dos EUA, e a Section 508 para as agências federais dos EUA e os seus fornecedores. Se a terminologia o baralhar pelo caminho, mantenha o nosso glossário de acessibilidade aberto num separador.

Dois outros conceitos moldam qualquer declaração de conformidade honesta. O primeiro é o âmbito da conformidade: a conformidade WCAG aplica-se a páginas completas, e não a componentes isolados, e a processos completos (por exemplo, todo um fluxo de checkout) — não pode afirmar que uma página é conforme se um passo de uma tarefa com vários passos falhar. O segundo é a tecnologia suportada pela acessibilidade: só pode confiar em formas de utilizar uma funcionalidade que sejam efetivamente suportadas pelas tecnologias de apoio de que os seus utilizadores dispõem. Na prática, isto significa testar com os leitores de ecrã e navegadores atuais, em vez de presumir que só a marcação válida garante um resultado utilizável. Tenha ambos em mente ao delimitar o seu trabalho nos passos seguintes; eles determinam o que pode afirmar ter alcançado de forma defensável.

Passo 2: Executar uma análise automatizada de referência

Não se pode corrigir o que não se mede, por isso estabeleça uma referência. Os testes automatizados são rápidos, repetíveis e excelentes a detetar as falhas mecânicas de grande volume que afetam a maioria dos sites: textos alternativos em falta, contraste de cor insuficiente, ligações e botões vazios, campos de formulário sem etiqueta, idioma do documento em falta e identificadores duplicados.

As ferramentas baseadas no motor de código aberto axe-core — incluindo o software de análise de acessibilidade da QualiBooth — produzem uma lista priorizada de problemas em minutos. Se quiser apenas uma leitura rápida da sua situação, comece por uma análise de acessibilidade gratuita de algumas páginas-chave.

Algumas regras para manter a sua referência honesta:

Analise modelos representativos, não o site inteiro. Teste a sua página inicial, um modelo de conteúdo/artigo, uma página de produto ou categoria, um formulário (registo, checkout, contacto) e qualquer painel autenticado. Corrigir um modelo costuma corrigir centenas de páginas.
Teste estados reais, não apenas o carregamento inicial. Abra menus, expanda acordeões, acione janelas modais e submeta formulários com erros. Muitas violações só aparecem em estados interativos.
Registe os números. Anote a contagem de problemas por gravidade e por critério de sucesso. Este é o seu ponto de referência antes/depois e o alicerce da sua lista de correção.

Seja honesto quanto ao limite: as ferramentas automatizadas só detetam de forma fiável 30 a 40 % dos problemas WCAG. Uma análise automatizada limpa é necessária, mas nunca é suficiente para uma verdadeira declaração de conformidade.

Passo 3: Complementar a automatização com uma auditoria manual

Os restantes 60 a 70 % dos critérios WCAG exigem juízo humano. Será que este texto alternativo transmite realmente o significado da imagem, ou descreve apenas pixels? A ordem de leitura e de foco é lógica? As mensagens de erro indicam ao utilizador como recuperar? Uma lista pendente personalizada é anunciada corretamente, e consegue alcançá-la e operá-la apenas com o teclado? Nenhum motor consegue responder a isto de forma fiável.

Uma auditoria manual estruturada cobre normalmente:

Operação apenas com teclado — percorra com o teclado cada elemento interativo; confirme um indicador de foco visível, uma ordem lógica, a ausência de armadilhas e que tudo o que consegue fazer com o rato consegue fazer sem ele.
Estrutura semântica — títulos numa hierarquia coerente, marcos (landmarks), listas marcadas como listas, tabelas com cabeçalhos adequados.
Formulários — etiquetas programáticas, campos agrupados, indicação clara dos campos obrigatórios e mensagens de erro associadas aos campos que descrevem.
Conteúdo dinâmico — janelas modais que capturam e restauram o foco corretamente, regiões live que anunciam atualizações, e ARIA usado apenas onde o HTML nativo não chega.
Qualidade do conteúdo — texto de ligações significativo, contraste suficiente em contextos reais, e conteúdo que não dependa apenas da cor ou da forma.

O nosso guia de auditorias manuais de acessibilidade percorre toda a metodologia, e os problemas de acessibilidade comuns a evitar são uma lista de verificação rápida das falhas que os auditores encontram com mais frequência. Se preferir que o façam por si, a equipa de consultoria em acessibilidade da QualiBooth realiza auditorias manuais especializadas face aos critérios WCAG 2.2 AA.

Passo 4: Priorizar e corrigir

Uma longa lista de violações é avassaladora enquanto não a ordenar. Faça a triagem combinando o impacto no utilizador e o alcance:

Os bloqueios primeiro. Tudo o que torna uma tarefa impossível para um grupo de utilizadores — armadilhas de teclado, um checkout inacessível, um formulário de início de sessão sem etiqueta — vai para o topo, independentemente do número de ocorrências.
Depois os problemas frequentes em todo o site. Um problema de contraste ou de foco no seu cabeçalho, rodapé ou componente do design system multiplica-se em todas as páginas. Corrigi-lo uma vez gera o maior retorno.
Depois os problemas específicos de páginas e de conteúdo. Um texto alternativo em falta pontual, um único controlo mal etiquetado ou uma falha isolada de nível de título.

Quando corrigir, corrija a fonte, não o sintoma. Prefira elementos HTML nativos a <div> remendados com ARIA; corrija o componente do design system em vez de cada página que o utiliza; e trate as causas-raiz nos modelos e componentes partilhados para que a correção escale. Volte a analisar após cada lote, para ver as contagens descerem e evitar introduzir regressões. Este é também o momento certo para incorporar a acessibilidade nos seus design tokens — defina cores com contraste seguro, um tamanho de alvo mínimo de 24×24 px e estilos de foco visíveis por defeito, para que o trabalho novo comece conforme.

Alguns padrões de correção repetem-se com frequência suficiente para serem destacados explicitamente:

Use a plataforma. Um <button>, um <a href>, um <input>, um <select> e um <dialog> nativos trazem de borla o comportamento de teclado, a gestão do foco e um nome acessível correto. Recorra a ARIA apenas para preencher lacunas genuínas — e lembre-se da primeira regra do ARIA: não use ARIA se um elemento nativo servir.
Nomeie os elementos de forma programática. Cada controlo precisa de um nome acessível a partir de um <label>, aria-label ou aria-labelledby — e não apenas de texto visual próximo. Os botões só com ícone são o infrator mais comum.
Faça a gestão do foco de forma deliberada. Quando uma janela modal abre, mova o foco para dentro dela, capture-o enquanto estiver aberta e devolva-o ao acionador ao fechar. Quando o conteúdo é atualizado sem navegação, use uma região live para que os utilizadores de leitores de ecrã ouçam o que mudou.
Não codifique o significado apenas na cor ou na forma. Combine a cor com texto, ícones ou padrões para que a informação sobreviva para os utilizadores daltónicos e com baixa visão.

Acompanhe a correção no seu gestor de tarefas habitual, etiquetada por critério de sucesso, para que o trabalho de acessibilidade seja visível a par de tudo o resto, em vez de viver numa folha de cálculo separada que fica desatualizada.

Passo 5: Testar com tecnologias de apoio e pessoas com deficiência

A conformidade resume-se, em última análise, a saber se pessoas reais conseguem usar o seu site. Dois níveis de validação importam aqui, e não são intermutáveis.

Testes com leitor de ecrã. Verifique as suas correções com as tecnologias de apoio que as pessoas realmente usam: NVDA ou JAWS com Chrome/Firefox no Windows, e VoiceOver com Safari no macOS e iOS. Esteja atento a nomes exatos, papéis corretos, anúncio das mudanças de estado e uma ordem de leitura sensata. Uma avaliação com leitor de ecrã dá-lhe uma passagem profissional pelas principais combinações se a sua equipa não tiver experiência.

Testes de usabilidade com utilizadores com deficiência. Cumprir todos os critérios de sucesso é o piso, não o teto — um site pode ser tecnicamente conforme e, ainda assim, frustrante de usar. O sinal mais fiável vem das auditorias por pessoas com deficiência, que testam com as suas próprias tecnologias de apoio e hábitos e revelam barreiras que as listas de verificação não captam. É esta a diferença entre cumprir a letra da norma e entregar uma verdadeira acessibilidade digital.

Passo 6: Documentar a conformidade (declaração e VPAT/ACR)

Depois de corrigir e validar, registe o resultado. A documentação é o que transforma um «tentámos» numa declaração defensável e comunicável.

Declaração de acessibilidade. Uma página pública que indica o seu objetivo de conformidade (por exemplo, WCAG 2.2 AA), descreve o que fez, enumera quaisquer limitações conhecidas e dá aos utilizadores uma forma de comunicar problemas. Muitos regulamentos, incluindo o EAA, esperam que exista uma.
VPAT / Relatório de Conformidade de Acessibilidade. Um Voluntary Product Accessibility Template, depois de preenchido, torna-se um ACR — o artefacto padrão que as equipas de compras e os compradores empresariais pedem como prova. O nosso guia «o que é um VPAT/ACR» explica o documento, e o serviço de relatórios VPAT produz um relatório rigoroso, sustentado por auditoria, que pode entregar a clientes e equipas jurídicas.

Redija estes documentos com base nas provas dos seus resultados de auditoria reais, e não em aspirações. Um VPAT que exagera a conformidade é um passivo, não um ativo.

Passo 7: Manter a conformidade ao longo do tempo

A acessibilidade regride no momento em que um site muda — um novo componente, um formulário reformulado, um widget de terceiros ou uma edição de conteúdo podem reintroduzir barreiras silenciosamente. A conformidade é um estado que se mantém, não um marco que se ultrapassa uma única vez.

Integre a acessibilidade no seu ciclo de vida de software:

Desloque para a esquerda (shift left). Acrescente verificações automatizadas ao seu pipeline com a integração de acessibilidade no CI/CD, para que as violações sejam detetadas nos pull requests, antes de irem para produção — o lugar mais barato para as corrigir.
Monitorize a produção. Agende auditorias de acessibilidade recorrentes para detetar regressões e a deriva de conteúdo que as verificações pré-lançamento não veem.
Capacite a sua equipa. Equipe designers, programadores e autores de conteúdo com um kit de ferramentas de acessibilidade e padrões partilhados, para que a acessibilidade seja o reflexo de todos, e não uma reflexão tardia de um especialista.
Faça a governação à escala. Para organizações grandes ou com vários sites, uma plataforma como o Agora centraliza o acompanhamento, o reporte e a correção entre equipas.

Erros que descarrilam os esforços de conformidade

As equipas que estagnam fazem-no, normalmente, por motivos previsíveis. Esteja atento a estes:

Confiar apenas na automatização. Um relatório automatizado todo verde cobre apenas um terço dos critérios. Tratá-lo como prova de conformidade é o erro mais comum — e o mais arriscado em termos legais.
Comprar um overlay. Os overlays e os «widgets de acessibilidade» prometem conformidade instantânea injetando JavaScript que se sobrepõe à página. Não corrigem o código subjacente, interferem frequentemente com as tecnologias de apoio dos próprios utilizadores e têm sido referidos num número crescente de queixas. São um atalho para o risco, não para a conformidade.
Corrigir páginas em vez de sistemas. Corrigir páginas individuais deixando o design system avariado significa que cada nova página reintroduz os mesmos defeitos. Corrija primeiro os componentes e modelos partilhados.
Tratá-la como um projeto pontual. Sem verificações de CI/CD e auditorias recorrentes, um site conforme afasta-se da conformidade ao fim de alguns ciclos de lançamento.
Saltar os utilizadores reais. A conformidade técnica sem testes de usabilidade pode, ainda assim, deixar os utilizadores com deficiência incapazes de concluir tarefas essenciais.

Evitar estes erros impede que o seu investimento se esvaia no momento em que o projeto «vai para produção».

Juntar tudo

Um caminho realista para a WCAG 2.2 AA tem este aspeto: aprenda os princípios POUR e o objetivo AA, execute uma referência automatizada, sobreponha-lhe uma auditoria manual, corrija por impacto e alcance, valide com leitores de ecrã e utilizadores com deficiência, documente a sua conformidade numa declaração e num VPAT, e depois mantenha-a saudável com verificações de CI/CD e auditorias recorrentes. Cada passo capitaliza sobre o anterior — e nada disto depende de um overlay que disfarça o código real.

Comece pequeno e ganhe ritmo: analise um punhado de modelos esta semana, corrija os estilos de contraste e de foco do seu design system, e coloque uma verificação automatizada no seu pipeline. A partir daí, o roteiro acima leva-o o resto do caminho. Quando estiver pronto para acelerar, explore os nossos preços, solicite uma demonstração, ou fale com um especialista sobre um plano de correção adaptado à sua stack.