O que é WCAG? As Diretrizes de Acessibilidade para Conteúdo Web explicadas

Quase 94,8% dos um milhão de sites mais acessados não atendem aos padrões básicos de acessibilidade, com uma média de cerca de 51 erros detectáveis por página inicial. Enquanto isso, mais de 5.100 processos judiciais relacionados à acessibilidade digital sob a ADA foram abertos nos Estados Unidos apenas em 2025 — e os custos legais e de reputação de ignorar a acessibilidade estão crescendo rapidamente. Seja você responsável por uma loja de e-commerce, uma plataforma SaaS ou um portal governamental, um documento está no centro de quase todas as conversas sobre acessibilidade: o WCAG, as Diretrizes de Acessibilidade para Conteúdo Web. Se você já se perguntou exatamente o que é o WCAG, por que ele existe e o que realmente exige de você, este guia é a explicação em linguagem simples que você estava procurando.

As Origens do WCAG: De Onde Vem o Padrão

O WCAG é publicado pela Web Accessibility Initiative (WAI), um programa do World Wide Web Consortium (W3C) — o mesmo órgão internacional que padroniza HTML, CSS e a maioria das tecnologias fundamentais da web. As diretrizes existem porque a web, por sua própria natureza, carrega a promessa de acesso universal. Na prática, sem escolhas de design deliberadas, essa promessa desmorona para milhões de usuários.

As raízes das diretrizes de acessibilidade na web remontam a 1995, quando Gregg Vanderheiden compilou a primeira diretriz de acessibilidade para a web logo após Tim Berners-Lee mencionar o acesso de pessoas com deficiência em uma palestra principal na Second International Conference on the World-Wide Web. Nos anos seguintes, mais de 38 diferentes diretrizes de acesso à web surgiram de vários autores e organizações, acabando por convergir nas Unified Web Site Accessibility Guidelines na University of Wisconsin–Madison. A versão 8 desse documento, publicada em 1998, tornou-se o ponto de partida para o WCAG 1.0, que se tornou uma Recomendação oficial do W3C em 5 de maio de 1999.

O WCAG 2.0 chegou em dezembro de 2008 e foi significativo o suficiente para ser adotado como um padrão ISO — ISO/IEC 40500:2012 — em outubro de 2012. O WCAG 2.1, publicado em junho de 2018, estendeu os critérios do 2.0 com 17 novos critérios de sucesso focados em usabilidade móvel, baixa visão e acessibilidade cognitiva. E a versão atual, WCAG 2.2, foi publicada como uma Recomendação do W3C em 5 de outubro de 2023 e desde então foi aprovada como ISO/IEC 40500:2025. O W3C incentiva todos a usarem a versão mais recente, e por um bom motivo: conteúdo que atende ao WCAG 2.2 automaticamente atende também ao WCAG 2.1 e ao WCAG 2.0.

Vale a pena deixar claro o que o WCAG é e o que não é. Ele é um padrão técnico — uma especificação precisa e testável desenvolvida por meio de um rigoroso processo multissetorial do W3C em cooperação com indivíduos e organizações ao redor do mundo. Ele não é um documento legal em si, mas foi incorporado por referência em leis e regulamentos em dezenas de jurisdições, tornando-se o livro de regras de fato para acessibilidade digital em todo o mundo.

Quem o WCAG Foi Projetado para Ajudar

O WCAG aborda barreiras de acessibilidade para pessoas com uma ampla gama de deficiências, incluindo deficiências visuais, auditivas, físicas, de fala, cognitivas, de linguagem, de aprendizagem e neurológicas. Trata-se de uma população notavelmente ampla. A Organização Mundial da Saúde estima que cerca de 1,3 bilhão de pessoas — aproximadamente 16% da população global — vivem com algum tipo de deficiência que afeta sua vida diária e seu acesso online. Qualquer uma dessas pessoas pode ser um cliente, cidadã, estudante ou funcionária em potencial tentando usar seu site neste exato momento.

Mas os benefícios da conformidade com o WCAG vão muito além dos usuários com deficiências permanentes. As diretrizes também ajudam pessoas idosas com limitações relacionadas à idade — visão reduzida, perda auditiva, resposta motora mais lenta — e muitas vezes melhoram a usabilidade para todos. Considere as legendas em vídeo: elas foram projetadas para pessoas surdas, mas também beneficiam quem assiste em ambientes barulhentos, falantes não nativos acompanhando o conteúdo e qualquer pessoa que prefira ler a ouvir. Da mesma forma, a navegabilidade por teclado ajuda usuários avançados que acham o mouse lento, e o contraste de cor suficiente ajuda qualquer pessoa que esteja apertando os olhos diante de uma tela brilhante ao ar livre.

O WCAG também abrange conteúdo em praticamente todos os tipos de dispositivos digitais — desktops, laptops, totens e dispositivos móveis — e é intencionalmente neutro em relação à tecnologia. Os critérios de sucesso são escritos como declarações testáveis que não prescrevem uma tecnologia específica, o que significa que permanecem relevantes à medida que HTML, frameworks JavaScript e tecnologias assistivas continuam a evoluir.

Os Princípios POUR: A Base Conceitual do WCAG

Cada critério de sucesso do WCAG — todos os 86 da versão 2.2 — é organizado sob quatro princípios de alto nível, conhecidos coletivamente pelo acrônimo POUR. Esses princípios fornecem a base conceitual de todo o padrão. Compreendê-los oferece um modelo mental intuitivo para acessibilidade, mesmo antes de você ler um único critério específico.

• Perceivable (Perceptível): Informações e componentes da interface do usuário devem ser apresentados aos usuários de maneiras que eles possam perceber. Na prática, isso significa que o conteúdo não pode ser invisível para todos os sentidos de um usuário. Se um usuário não pode ver uma imagem, deve haver uma alternativa em texto que ele possa ouvir por meio de um leitor de tela. Se um vídeo tem narração falada, devem existir legendas para usuários que não podem ouvir. Requisitos práticos sob este princípio incluem texto alternativo para imagens, legendas para vídeo, contraste de cor suficiente entre texto e fundo e a capacidade de redimensionar o texto sem perda de conteúdo.
• Operable (Operável): Componentes da interface do usuário e navegação devem ser operáveis. Nenhuma interação pode exigir uma entrada que um usuário não consiga realizar. A implicação mais comum: toda funcionalidade deve ser alcançável apenas com o teclado, e não apenas com o mouse. Este princípio também abrange dar aos usuários tempo suficiente para ler e interagir com o conteúdo, evitar conteúdo que possa desencadear convulsões e fornecer múltiplas maneiras de navegar em um site.
• Understandable (Compreensível): Informações e a operação da interface do usuário devem ser compreensíveis. O conteúdo não pode ser tão complexo ou confuso a ponto de os usuários não conseguirem utilizá-lo conforme pretendido. Isso abrange linguagem legível (incluindo especificar o idioma da página no código para que leitores de tela usem a pronúncia correta), comportamento previsível da página, instruções claras e mensagens de erro úteis que informem o que deu errado e como corrigir.
• Robust (Robusto): O conteúdo deve ser robusto o suficiente para ser interpretado de forma confiável por uma ampla variedade de agentes de usuário, incluindo tecnologias assistivas. Um site robusto usa marcação semântica limpa e válida para que leitores de tela, displays Braille e outras ferramentas assistivas possam analisar e transmitir o conteúdo corretamente — tanto agora quanto à medida que a tecnologia evolui.

Pense em POUR como quatro filtros pelos quais cada elemento do seu site deve passar. Se um componente falhar em apenas um dos quatro filtros, é provável que seja uma barreira para alguns dos seus usuários.

Esses quatro princípios permaneceram estáveis em todas as versões do WCAG — 2.0, 2.1 e 2.2 — mesmo com o crescimento e a evolução dos critérios de sucesso específicos abaixo deles. Essa estabilidade torna o POUR uma lente duradoura para avaliar a acessibilidade, independentemente de qual versão uma determinada lei referencia.

Níveis de Conformidade: A, AA e AAA Explicados

Abaixo dos quatro princípios POUR estão 13 diretrizes e, abaixo dessas diretrizes, estão os 86 critérios de sucesso testáveis — os requisitos reais e específicos que você deve atender para declarar conformidade com o WCAG. Cada critério de sucesso é atribuído a um de três níveis de conformidade.

• Nível A é o mínimo. Estes são os requisitos mais críticos, representando barreiras tão severas que determinados usuários simplesmente não conseguem acessar o conteúdo. Exemplos incluem fornecer alternativas em texto para conteúdo não textual e garantir que toda funcionalidade seja acessível por teclado. O Nível A sozinho não é suficiente para a maioria dos propósitos regulatórios, mas falhar nele significa falha fundamental.
• Nível AA é o padrão intermediário e aquele exigido pela grande maioria das leis e regulamentos globalmente. Ele satisfaz todos os critérios do Nível A, além de requisitos adicionais, como garantir relações de contraste de cor entre texto e fundo de pelo menos 4,5:1, fornecer navegação consistente entre páginas e oferecer legendas para vídeo pré-gravado. A maioria das leis de acessibilidade globais — incluindo a Section 508 nos EUA, a EN 301 549 na Europa e a AODA em Ontário, Canadá — exige conformidade com o Nível AA. Este é o alvo que praticamente toda organização deve priorizar.
• Nível AAA é o padrão mais alto e inclui critérios que são mais aspiracionais do que universalmente alcançáveis. O próprio W3C reconhece que não é possível satisfazer todos os critérios AAA para todos os tipos de conteúdo, portanto esses critérios normalmente não são definidos como exigência de política geral. Exemplos incluem interpretação em língua de sinais para todo conteúdo em áudio e um nível de leitura não mais difícil do que o ensino fundamental II.

Um ponto importante: os níveis de conformidade são cumulativos. Alcançar o Nível AA significa que você também satisfaz todos os critérios do Nível A. Alcançar o Nível AAA significa que você satisfaz A e AA também. E, crucialmente, a conformidade é tudo ou nada em cada nível — você não pode declarar conformidade AA se até mesmo um único critério AA não for atendido em uma determinada página.

Para a maioria das organizações, WCAG 2.2 Nível AA é o alvo certo. É o nível incorporado na lei, o nível que os tribunais usam como referência e o nível que realmente abre sua experiência digital para o público mais amplo possível.

O que Mudou no WCAG 2.2: Os Nove Novos Critérios de Sucesso

O WCAG 2.2, publicado em outubro de 2023, adicionou nove novos critérios de sucesso além de tudo o que já existia no WCAG 2.1. Essas adições foram impulsionadas por pesquisas contínuas sobre onde usuários com deficiência — especialmente aqueles com deficiências cognitivas, limitações motoras e baixa visão — ainda encontravam barreiras frequentes que as diretrizes anteriores não abordavam adequadamente. O WCAG 2.2 não remove nem altera nenhum requisito existente do WCAG 2.1; ele simplesmente os estende.

Dos nove novos critérios, quatro são de Nível AA (e, portanto, juridicamente relevantes para a maioria das organizações), dois são de Nível A e três são de Nível AAA. Eis o que cada critério de Nível AA e abaixo realmente significa na prática:

• 2.4.11 Focus Not Obscured — Minimum (AA): Quando um usuário de teclado navega até um componente interativo, esse componente não deve ficar totalmente oculto por outro conteúdo criado pelo autor. Esta é uma resposta direta a um padrão de design moderno comum: cabeçalhos fixos, banners de cookies e rodapés fixos que deslizam sobre o conteúdo da página e engolem silenciosamente o foco do teclado, deixando os usuários sem indicação visível de onde estão na página.
• 2.5.7 Dragging Movements (AA): Qualquer funcionalidade que exija uma ação de arrastar — pense em uploads de arquivos por arrastar e soltar, itens de lista ordenáveis ou controles deslizantes personalizados — deve ter uma alternativa de ponteiro único que não exija arrastar. Para um usuário com tremores nas mãos ou controle motor fino limitado, manter pressão contínua enquanto move um ponteiro pela tela pode ser quase impossível. Fornecer alternativas como clicar para selecionar e depois clicar para posicionar, ou botões de seta para cima/para baixo em listas ordenáveis, resolve isso.
• 2.5.8 Target Size — Minimum (AA): Alvos interativos, como botões e links, devem ter pelo menos 24×24 pixels CSS. Alvos de toque pequenos são um problema de usabilidade bem documentado para usuários móveis com limitações motoras, pessoas idosas e, na verdade, qualquer pessoa digitando em um telefone enquanto faz várias tarefas.
• 3.3.8 Accessible Authentication — Minimum (AA): Processos de autenticação não podem exigir que usuários resolvam um teste de função cognitiva — como um CAPTCHA tradicional que exige reconhecimento de caracteres ou resolução de quebra-cabeças — a menos que seja fornecida uma alternativa. Este é um critério significativo para qualquer site que use desafios CAPTCHA padrão em fluxos de login ou registro. Soluções incluem suporte a gerenciadores de senhas, links mágicos por e-mail ou SMS, autenticação biométrica ou alternativas de reconhecimento de objetos.
• 3.2.6 Consistent Help (A): Se um site fornece um mecanismo de ajuda (como um botão de chat ao vivo, link de FAQ ou número de telefone de suporte) em várias páginas, esse mecanismo deve aparecer na mesma localização relativa em todas as páginas. Usuários com deficiências cognitivas que precisam de ajuda se beneficiam enormemente de saber exatamente onde encontrá-la sem ter que procurar a cada vez.
• 3.3.7 Redundant Entry (A): Informações previamente inseridas por um usuário em um processo de múltiplas etapas devem ser preenchidas automaticamente ou selecionáveis, em vez de exigir nova digitação. Isso reduz o atrito para usuários com deficiências cognitivas ou motoras para quem o preenchimento de formulários é especialmente exaustivo.

O WCAG 2.2 também removeu formalmente um critério do 2.1: 4.1.1 Parsing. Esse critério originalmente exigia HTML estritamente válido para garantir que tecnologias assistivas pudessem analisar a marcação corretamente. Ele foi aposentado porque navegadores modernos e tecnologias assistivas agora lidam com marcação malformada de forma robusta por meio de seus próprios mecanismos de correção de erros, tornando o critério praticamente sem relevância para a acessibilidade.

WCAG e a Lei: O que a Não Conformidade Realmente Custa

O WCAG é um padrão técnico, não uma lei. Mas ele foi entrelaçado no tecido jurídico da acessibilidade digital na maioria das principais jurisdições, o que significa que a não conformidade traz uma exposição legal real.

Nos Estados Unidos, embora nem a ADA nem a Section 508 mencionem explicitamente o WCAG 2.2 em seu texto, o WCAG é usado de forma consistente como referência técnica em litígios e ações de fiscalização. O Department of Justice publicou uma Regra Final em 2024 definindo o WCAG 2.1 Nível AA como o padrão oficial para conformidade com a Section 508 e com o Título II da ADA para governos estaduais e locais. O Título III da ADA — que se aplica a acomodações públicas, incluindo a maioria das empresas privadas que operam online — é ativamente aplicado por meio de ações judiciais privadas. Em 2024, mais de 4.000 processos relacionados a propriedades digitais sob a ADA foram abertos em tribunais federais e estaduais, e a tendência continuou em alta em 2025. As penalidades civis por primeira violação da ADA foram ajustadas pela inflação em 2024 e agora podem chegar a US$ 115.231, subindo para US$ 230.464 em caso de reincidência.

Na Europa, o cenário é igualmente significativo. O European Accessibility Act (EAA) tornou-se legalmente aplicável nos estados-membros da UE em 28 de junho de 2025, exigindo que sites, aplicativos, e-books, plataformas de e-commerce e PDFs estejam em conformidade com os critérios do WCAG 2.1 AA. A norma europeia EN 301 549 atualmente faz referência ao WCAG 2.1, com a próxima versão prevista para ser atualizada para o WCAG 2.2. Para organizações com presença na Europa, a conformidade com o EAA deixou de ser opcional.

Os dados de litígios também revelam um padrão particularmente doloroso para empresas menores: a ideia de que permanecer pequeno mantém você seguro é um mito. Em 2023, 77% dos processos de acessibilidade digital sob a ADA tiveram como alvo empresas com menos de US$ 25 milhões em receita anual. O e-commerce continua sendo, de longe, o setor mais processado. E, de forma crítica, ser processado uma vez não oferece proteção contra novos processos — quase metade de todas as ações judiciais de acessibilidade digital nos últimos anos teve como alvo empresas que já haviam enfrentado pelo menos uma reclamação anterior.

As Falhas de WCAG Mais Comuns (E Como Identificá-las)

Considerando que quase 95% dos sites falham nos padrões básicos de acessibilidade, vale a pena saber quais falhas específicas são mais prevalentes. O relatório anual WebAIM Million, que audita as páginas iniciais do um milhão de sites mais acessados, identifica de forma consistente o mesmo punhado de problemas aparecendo na grande maioria das páginas:

• Baixo contraste de cor: Texto com baixo contraste afetou 79,1% das páginas iniciais na análise de 2025, com uma média de quase 30 ocorrências por página. Este é, ao mesmo tempo, o erro mais comum e um dos mais fáceis de detectar com ferramentas automatizadas. O texto deve ter uma relação de contraste de pelo menos 4,5:1 em relação ao fundo (3:1 para texto grande) para atender ao Nível AA.
• Texto alternativo ausente: A ausência de texto alternativo afeta 55,5% das páginas. Para usuários de leitores de tela que são cegos ou têm baixa visão, uma imagem sem texto alternativo é simplesmente invisível — a tecnologia assistiva vai ignorá-la silenciosamente ou ler um nome de arquivo sem sentido. Imagens com link e sem texto alternativo quebram completamente a navegação.
• Rótulos de formulário ausentes: Campos de formulário sem rótulos associados significam que um usuário de leitor de tela não consegue saber que informação é solicitada em um campo. Isso cria uma barreira intransponível em qualquer checkout, formulário de registro ou de contato.
• Links vazios: Links sem texto descritivo — muitas vezes links apenas com ícones ou imagens com link sem texto alternativo — deixam usuários de teclado e leitores de tela sem contexto sobre para onde o link leva.
• Idioma do documento ausente: Deixar de declarar o idioma de uma página no HTML significa que leitores de tela podem ler o conteúdo usando as regras de pronúncia do idioma errado, tornando o texto incompreensível.

O que chama a atenção nessa lista é que nenhum desses casos é um cenário exótico que exija engenharia avançada. São decisões simples de marcação e design. O fato de persistirem na grande maioria da web reflete uma lacuna estrutural em como a acessibilidade é (ou não é) integrada aos fluxos de trabalho típicos de desenvolvimento web, e não uma barreira técnica fundamental.

Como Abordar a Conformidade com o WCAG como Organização

Sair de onde a maioria dos sites está hoje para alcançar uma conformidade genuína com o WCAG 2.2 Nível AA exige uma abordagem sistemática. Não é um projeto pontual — é um processo contínuo, porque o conteúdo muda, frameworks são atualizados e componentes de terceiros são substituídos. Veja como estruturar o esforço de forma eficaz.

Comece com uma auditoria de base. Antes de consertar qualquer coisa, você precisa saber o que está quebrado. Ferramentas de varredura automatizada podem identificar rapidamente, em escala, um subconjunto significativo de problemas — questões de contraste de cor, ausência de texto alternativo, rótulos de formulário ausentes. No entanto, ferramentas automatizadas têm limites bem conhecidos; elas conseguem detectar cerca de 30–40% dos problemas de WCAG. O restante exige testes manuais: navegar pelo seu site usando apenas o teclado, testar com leitores de tela reais como NVDA ou JAWS no Windows e VoiceOver no macOS e iOS e, idealmente, envolver pessoas com deficiência no seu processo de testes.

Priorize por impacto e frequência. Nem todos os problemas têm o mesmo peso. A ausência de texto alternativo em um ícone decorativo é muito menos crítica do que uma armadilha de teclado que impede o usuário de sair de uma caixa de diálogo modal, ou um formulário de login totalmente inutilizável com um leitor de tela. Foque seu primeiro sprint de correção nas barreiras que bloqueiam jornadas centrais do usuário — checkout, criação de conta, busca, contato — antes de tratar itens cosméticos ou de menor impacto.

Incorpore a acessibilidade no fluxo de desenvolvimento, não no final. O trabalho de acessibilidade mais caro é a correção após o lançamento. Integrar verificações de acessibilidade ao seu design system, biblioteca de componentes, processo de revisão de código e pipeline de CI/CD captura problemas no ponto em que são mais baratos de corrigir. Estabeleça um responsável claro pela acessibilidade em sua equipe e ofereça treinamento específico por função para designers, desenvolvedores e editores de conteúdo.

Mantenha uma declaração de acessibilidade. Publicar uma declaração de acessibilidade clara e honesta em seu site — descrevendo qual padrão você adota, como usuários podem relatar barreiras e como você responde a esses relatos — demonstra boa-fé e é, na verdade, exigido por lei em algumas jurisdições, incluindo sob a EU Web Accessibility Directive. Isso também cria um ciclo de feedback que ajuda a identificar problemas que você não detectou nos testes.

Use widgets de overlay como aprimoramentos, não como substitutos da acessibilidade em nível de código. Widgets e SDKs de overlay de acessibilidade — incluindo Accsible — podem ser ferramentas valiosas para disponibilizar preferências controladas pelo usuário, como ajuste de tamanho de texto, modos de contraste e aprimoramentos de navegação por teclado. Mas os dados são claros: widgets implantados no lugar do trabalho fundamental de acessibilidade não evitam processos judiciais. A proteção legal vem do seu código subjacente atender aos critérios do WCAG, não de um widget instalado sobre uma base inacessível. Use overlays para complementar uma correção genuína, não para substituí-la.

O Caminho à Frente: WCAG 3.0 no Horizonte

Mesmo enquanto organizações ainda trabalham para atender ao WCAG 2.2, o W3C Accessibility Guidelines Working Group está desenvolvendo o WCAG 3.0, uma reestruturação mais substancial das orientações de acessibilidade na web. O primeiro rascunho público de trabalho foi lançado no início de 2021 e, no final de 2025, o rascunho de trabalho continua passando por desenvolvimento significativo. Nenhuma parte do WCAG 3.0 é ainda uma recomendação oficial, e nenhuma data de lançamento definida foi estabelecida.

Espera-se que o WCAG 3.0 se afaste de forma significativa do modelo de conformidade A/AA/AAA, introduza uma abordagem baseada em pontuação e cubra uma gama mais ampla de tipos de conteúdo digital, incluindo aplicativos móveis nativos e tecnologias emergentes. Por enquanto, as organizações devem focar no WCAG 2.2 Nível AA — é o padrão aplicável atualmente e permanecerá assim no futuro previsível. Organizações que construírem agora bases sólidas em WCAG 2.2 estarão muito melhor posicionadas para se adaptar quando o WCAG 3.0 eventualmente se tornar uma recomendação.

Pontos-Chave

• WCAG 2.2 é o padrão global atual para acessibilidade na web, publicado pelo W3C e aprovado como ISO/IEC 40500:2025. Conteúdo que atende ao WCAG 2.2 satisfaz automaticamente o 2.1 e o 2.0 — mire sempre na versão mais recente.
• O Nível AA é o alvo que importa. Quase todas as leis de acessibilidade globais — ADA, Section 508, EAA, EN 301 549, AODA — fazem referência ao Nível AA do WCAG como o nível de conformidade exigido. Concentre seus esforços nele primeiro.
• As falhas mais comuns são corrigíveis. Baixo contraste de cor, ausência de texto alternativo, rótulos de formulário ausentes e links vazios respondem pela maioria dos erros de acessibilidade na web. Eles são solucionáveis com relativamente pouco esforço e grande impacto.
• Testes automatizados são necessários, mas não suficientes. Ferramentas conseguem detectar cerca de 30–40% dos problemas de WCAG. Combine varredura automatizada com testes de teclado, testes com leitores de tela e, idealmente, testes com usuários com deficiência para obter um quadro completo.
• A acessibilidade é um processo contínuo, não um projeto pontual. O conteúdo muda, componentes de terceiros mudam e os padrões evoluem. Incorpore a acessibilidade aos seus fluxos de trabalho de design, desenvolvimento e conteúdo para que seja mantida continuamente, e não corrigida de forma reativa após uma reclamação ou processo.