Antes de explorar a WCAG 3.0, convém deixar claro o essencial: ela ainda não está pronta.
A WCAG 3.0 segue como um Working Draft do W3C, com partes importantes ainda em desenvolvimento. O próprio W3C é transparente: diretrizes e requisitos podem ser alterados, adicionados, combinados ou removidos. Portanto, não enfrentamos uma substituição imediata da WCAG 2.2.
Mas a realidade é oposta ao óbvio: isso não significa que devemos esperar a versão final. Muito pelo contrário. O momento é agora para compreender a mudança de pensamento que está em curso. A WCAG 3.0 não é simplesmente uma WCAG 2.2 expandida com novos critérios. O W3C está construindo uma estrutura diferente, um modelo de conformidade distinto e um escopo ampliado que inclui conteúdo web, aplicativos, ferramentas, publicação e tecnologias emergentes.
Algumas dessas mudanças merecem nossa atenção imediata.
Das Regras para as Necessidades Reais
As diretrizes migram de critérios técnicos para necessidades funcionais. Isso muda a pergunta fundamental.
Em vez de questionar apenas qual critério foi violado, precisamos compreender: qual barreira foi criada? Quem ela afeta? O que essa pessoa fica impedida de fazer?
A técnica continua essencial. Mas não pode ser o fim da análise. É o começo.
Do Componente para a Jornada Completa
A WCAG 3.0 permite avaliar não apenas páginas ou interfaces isoladas, mas processos completos. O draft exige que, quando um processo está em escopo, cada etapa única seja representada na avaliação.
Isso é crucial porque ninguém entra em um site para testar um botão. Entram para comprar, aprender, trabalhar, pagar uma conta, contratar um serviço, resolver um problema.
Você pode ter componentes tecnicamente acessíveis e, ainda assim, uma jornada que o usuário não consegue completar. O todo é maior que a soma das partes.
Um Novo Modelo de Conformidade
O modelo atual opera com três tipos principais de provisões:
Core Requirements o mínimo obrigatório. Supplemental Requirements — o que vai além, amplificando a acessibilidade. Assertions declarações documentadas sobre práticas de acessibilidade que a organização realiza.
Além desses, existem Best Practices recomendações que melhoram a acessibilidade, mas não obrigam conformidade.
Essa estrutura amplia a conversa. Não olhamos apenas para o que existe no código. Começamos a olhar para como a acessibilidade é construída e como é mantida.
Processos Como Protagonistas
As Assertions são particularmente relevantes. Podem envolver treinamento em acessibilidade, documentação de processos, definição clara de responsabilidades, testes com usuários reais e testes com tecnologias assistivas. Elas não substituem os Core Requirements; complementam.
E provocam uma pergunta diferente:
Não apenas: “Este produto está acessível?”
Mas também: “Esta organização consegue produzir acessibilidade continuamente?”
Corrigir uma barreira é importante. Criar sistemas que evitem que ela volte a surgir é ainda melhor.
A Realidade Além do Código
Outra discussão crítica: o suporte no mundo real.
Uma técnica pode estar correta no código e ainda falhar dependendo da combinação específica entre navegador, sistema operacional e tecnologia assistiva. Por isso o modelo trabalha com o conceito de Accessibility Supported verificações contra conjuntos definidos de tecnologias.
A lição: código correto não garante, sozinho, uma experiência acessível. Precisamos verificar o resultado de verdade.
Os Níveis: Bronze, Silver e Gold
O draft propõe três níveis de conformidade com esses nomes. Bronze seria o mínimo; Silver e Gold representam patamares progressivamente maiores.
Um cuidado necessário: esse modelo ainda é exploratório. O próprio documento deixa em aberto quanto dos requisitos suplementares e Assertions será exigido em cada nível.
Portanto, não é correto tratar Bronze, Silver e Gold como um modelo definitivo ainda.
A Mudança Maior, Que Não Está nos Nomes
Core Requirements. Supplemental Requirements. Assertions. Bronze. Silver. Gold.
Esses nomes chamam atenção. Mas a mudança mais profunda está além deles.
Estamos aproximando conformidade de experiência real.
A pergunta deixa de ser apenas:
- “Está de acordo com a WCAG?”
E passa a incluir:
- “A pessoa consegue perceber?”
- “Consegue compreender?”
- “Consegue interagir?”
- “Consegue tomar uma decisão informada?”
- “Consegue concluir aquilo que veio fazer?”
O Centro da Questão
Aqui está o essencial: acessibilidade é técnica, mas antes de tudo é sobre seres humanos.
Precisamos de WCAG. Precisamos de HTML semântico, ARIA, contraste adequado, testes com teclado e tecnologias assistivas. Precisamos de critérios objetivos.
Mas tudo isso é meio, não fim.
O objetivo é claro: permitir que pessoas tenham autonomia para participar do ambiente digital. Para agir, escolher, criar, aprender, trabalhar sem barreiras impostas pelo código.
Por isso vale começar a estudar a WCAG 3.0 agora — não para aplicar uma norma que ainda não está pronta, mas para preparar nossa forma de pensar para o que vem pela frente. Para mudar não apenas o que fazemos, mas por que fazemos.
WCAG 3.0 — Links Oficiais
Documentos Principais
Working Draft Oficial (W3C):
- WCAG 3.0 Working Draft — versão mais recente
Editor’s Draft (em desenvolvimento contínuo):
- WCAG 3.0 Guidelines — Editor’s Draft — versão em tempo real com as mudanças mais recentes
Versão Específica de Março de 2026:
Avisos e Atualizações
Anúncio Oficial da Atualização (Março 2026):
WCAG 3 Introduction:
- W3C WAI — WCAG 3 Introduction — contexto, timeline e informações de background
Recomendação: Comece pela WCAG 3 Introduction para entender o contexto geral e a timeline. Depois, explore o Editor’s Draft para acompanhar as mudanças contínuas.
Sources: