Checklist WCAG 2.2 AA para produtos SaaS e aplicações web

Um produto SaaS tem duas superfícies de acessibilidade: o site de marketing que o vende e a aplicação que as pessoas usam todos os dias. O site de marketing falha das mesmas formas que qualquer site, com baixo contraste, falta de texto alternativo e formulários sem rótulos. A aplicação traz problemas próprios: fluxos de login que bloqueiam gerenciadores de senhas, diálogos que prendem o foco do teclado, navegação de página única que os leitores de tela não percebem, tabelas de dados e gráficos sem texto, arrastar e soltar sem alternativa e sessões que expiram sem aviso. Este checklist percorre o nível AA da WCAG 2.2 pelas partes de um produto SaaS típico.

Pontos principais

• A WCAG 2.2 se tornou Recomendação do W3C em outubro de 2023 e adicionou nove critérios de sucesso, seis deles nos níveis A ou AA (W3C (abre em uma nova aba)).
• Autenticação acessível (3.3.8, AA) significa que um login não pode depender de lembrar ou transcrever uma senha, a menos que a pessoa possa colá-la ou usar um gerenciador de senhas (W3C (abre em uma nova aba)).
• Alvos interativos precisam ter pelo menos 24 por 24 pixels CSS ou espaço suficiente ao redor (2.5.8, AA) (W3C (abre em uma nova aba)).
• Mensagens como “Salvo” ou “3 resultados” precisam chegar aos leitores de tela sem mover o foco (4.1.3, AA) (W3C (abre em uma nova aba)).
• Compradores corporativos e do setor público costumam pedir um relatório de conformidade de acessibilidade (ACR, Accessibility Conformance Report), geralmente escrito no modelo VPAT do Information Technology Industry Council (ITI (abre em uma nova aba)).

Por que a acessibilidade importa mais para um SaaS do que para um site institucional?

As pessoas usam um produto SaaS por horas, muitas vezes porque o empregador escolheu a ferramenta. Uma barreira em uma página de marketing faz perder um visitante; uma barreira no produto pode impedir alguém de fazer o próprio trabalho. É por isso que clientes maiores, universidades e órgãos públicos perguntam cada vez mais sobre acessibilidade antes de comprar, e é por isso que a resposta precisa cobrir a aplicação, não só o site.

Também importa porque os testes automatizados só pegam parte do problema. Ferramentas como o axe-core encontram falhas no código, como rótulos ausentes e baixo contraste. Elas não conseguem dizer se um diálogo devolve o foco ao lugar certo, se os dados de um gráfico estão disponíveis como texto ou se um fluxo de trabalho pode ser concluído com o teclado. Uma aplicação precisa tanto de verificações automatizadas quanto de testes manuais.

Como tornar o cadastro e o login acessíveis?

A autenticação é onde a WCAG 2.2 adicionou o requisito novo mais importante para SaaS.

• Permita colar e usar gerenciadores de senhas (3.3.8, AA). Não bloqueie a ação de colar em campos de senha ou de código, e use autocomplete="username", autocomplete="current-password" e autocomplete="one-time-code" para que navegadores e gerenciadores de senhas possam preenchê-los.
• Evite quebra-cabeças como única forma de entrar. Um CAPTCHA que pede para transcrever texto distorcido ou resolver um quebra-cabeça é um teste de função cognitiva. Ofereça uma alternativa e prefira verificações que não exijam ação do usuário (W3C (abre em uma nova aba)).
• Coloque rótulo em todos os campos (1.3.1 e 3.3.2, A). Use um <label> visível ligado ao campo; o texto de placeholder some quando a pessoa digita e não é um rótulo.
• Identifique os erros em texto (3.3.1, A) e sugira correções (3.3.3, AA). “A senha precisa ter pelo menos 12 caracteres” ajuda; só uma borda vermelha não.
• Não pergunte duas vezes (3.3.7, A). Se um cadastro em várias etapas já pediu o nome da empresa ou um endereço, preencha automaticamente ou deixe a pessoa selecionar em vez de digitar de novo.
• Mantenha a ajuda no mesmo lugar (3.2.6, A). Se você oferece chat, um link de ajuda ou dados de contato, coloque-os na mesma posição relativa em todas as páginas do fluxo.

Quais padrões de formulário e de erro causam mais falhas?

Os formulários concentram a maioria das falhas das aplicações. A pesquisa da WebAIM de 2026 com um milhão de páginas iniciais encontrou campos de formulário sem rótulo em 51% delas (WebAIM (abre em uma nova aba)), e as aplicações têm muito mais formulários do que as páginas iniciais.

• Dê a cada campo um nome programático e agrupe controles relacionados, como botões de opção, com <fieldset> e <legend>.
• Informe os erros onde a pessoa vai notá-los: mova o foco para um resumo de erros no topo do formulário, ou para o primeiro campo inválido, e ligue cada item do resumo ao respectivo campo.
• Indique os campos obrigatórios em texto, não só com cor (1.4.1, A).
• Não envie o formulário nem mude de contexto quando alguém apenas seleciona uma opção (3.2.2, A); espere uma ação explícita.

Como diálogos, menus e popovers devem se comportar?

Os componentes personalizados são onde o suporte a teclado e a leitores de tela mais quebra. O Guia de Práticas de Autoria do WAI-ARIA (ARIA Authoring Practices Guide) descreve o comportamento esperado de cada padrão (W3C (abre em uma nova aba)).

• Diálogos: mova o foco para dentro do diálogo quando ele abrir, mantenha o Tab dentro dele enquanto estiver aberto, feche-o com Esc e devolva o foco ao controle que o abriu. Use o elemento nativo <dialog> ou role="dialog" com aria-modal="true" e um nome.
• Sem armadilhas de teclado (2.1.2, A): deve ser possível sair de qualquer componente com o teclado.
• Foco visível (2.4.7, AA) que não fique escondido atrás de cabeçalhos fixos, banners de cookies ou widgets de chat (2.4.11, AA, novo na 2.2).
• Tooltips e popovers (1.4.13, AA) que possam ser fechados com Esc, que não sumam quando o ponteiro passa sobre eles e que fiquem visíveis até serem fechados.
• Atalhos de uma tecla (2.1.4, A): se pressionar uma letra dispara uma ação, deixe as pessoas desativarem ou remapearem os atalhos, ou faça com que só funcionem quando o componente relevante estiver em foco.

Como lidar com a navegação em uma aplicação de página única?

Em uma aplicação de página única (SPA), a URL muda sem carregar uma nova página, então os leitores de tela podem não anunciar que algo aconteceu.

• Atualize o título do documento a cada mudança de rota, para que cada tela tenha um título descritivo (2.4.2, A).
• Mova o foco para o título principal da nova tela, ou anuncie a mudança em uma live region educada (polite); frameworks como o Next.js incluem um anunciador de rotas para isso.
• Mantenha uma ordem de foco lógica (2.4.3, A): depois que um item é excluído, o foco deve ir para um vizinho que faça sentido, não voltar para o topo da página.
• Ofereça uma forma de pular a navegação repetida (2.4.1, A), como um link para pular para o conteúdo ou landmarks.

Como tornar dashboards, tabelas de dados e gráficos acessíveis?

• Tabelas: use marcação <table> de verdade, com <th> e scope nos cabeçalhos, e uma legenda (1.3.1, A). Grades montadas com elementos <div> precisam do padrão grid de ARIA completo, que é bem mais difícil de acertar.
• Gráficos: dê a cada gráfico uma alternativa em texto que diga a ideia principal e ofereça os dados em uma tabela (1.1.1, A). Não dependa só da cor para diferenciar as séries (1.4.1, A); adicione rótulos ou padrões.
• Contraste: o texto precisa de 4.5:1 (1.4.3, AA), e linhas de gráficos, ícones e bordas de campos precisam de 3:1 em relação ao fundo (1.4.11, AA). Verifique o modo escuro separadamente. O nosso verificador de contraste de cores testa qualquer par de cores.
• Mensagens de status (4.1.3, AA): “Salvo”, “Upload concluído” e contagens de resultados devem usar role="status" ou uma live region, para que os leitores de tela as anunciem sem que a pessoa perca o lugar onde estava.

O que os novos critérios da WCAG 2.2 mudam para aplicações web?

A WCAG 2.2 também removeu o 4.1.1 Parsing, que não tem mais efeito prático na acessibilidade (W3C (abre em uma nova aba)).

E tempo limite, layout e zoom?

• Tempo limite da sessão (2.2.1, A): avise antes de a sessão expirar e deixe a pessoa estendê-la com uma ação simples, a menos que o limite de tempo seja essencial ou maior que 20 horas. Salvar o trabalho em andamento evita o pior desfecho.
• Refluxo (1.4.10, AA): o conteúdo precisa funcionar com 320 pixels CSS de largura (o equivalente a um zoom de 400% em uma tela de 1280 pixels) sem rolagem em duas direções; tabelas de dados e conteúdos parecidos são isentos.
• Espaçamento de texto (1.4.12, AA): aumentar a altura da linha e o espaçamento entre letras não pode cortar o texto, o que contêineres de altura fixa costumam fazer.
• Orientação (1.3.4, AA): não trave a aplicação em retrato ou paisagem, a menos que seja essencial.

O que é um ACR e você precisa de um?

Um relatório de conformidade de acessibilidade (ACR) documenta como um produto atende a cada critério de acessibilidade: atende, atende parcialmente ou não atende, com observações. A maioria é escrita no modelo VPAT publicado pelo Information Technology Industry Council, que tem edições para a WCAG, para as normas da Seção 508 dos EUA e para a norma europeia EN 301 549 (ITI (abre em uma nova aba)).

As agências federais dos EUA precisam comprar tecnologia acessível segundo a Seção 508 (Section508.gov (abre em uma nova aba)), e os órgãos públicos da UE usam como referência a EN 301 549, então produtos B2B que vendem para esses clientes costumam receber pedidos de ACR durante a contratação. Um ACR honesto, com as lacunas conhecidas listadas, é mais útil para os compradores do que um que alega suporte total. Ele deve se basear em testes do produto, incluindo testes manuais; uma análise automatizada sozinha não consegue preenchê-lo.

Se você vende para consumidores na UE, a Lei Europeia de Acessibilidade também pode se aplicar à forma como você vende on-line; o nosso guia sobre a EAA explica o alcance dela. Isto não é aconselhamento jurídico.

Como uma equipe de SaaS deve testar a acessibilidade?

1. Automatize o básico. Rode o axe-core ou um mecanismo parecido nos seus testes de ponta a ponta e no site de marketing, e faça o build falhar quando surgirem violações novas. O nosso verificador de acessibilidade grátis roda o mesmo mecanismo em qualquer página pública.
2. Teste com o teclado. Conclua os seus fluxos principais, como cadastro, criação de um registro e alteração de configurações, usando só Tab, Shift+Tab, Enter, barra de espaço, Esc e as setas.
3. Teste com um leitor de tela. O NVDA no Windows e o VoiceOver no macOS e no iOS são gratuitos. Verifique se nomes, funções, estados e mensagens são anunciados.
4. Dê zoom e redimensione. Verifique o texto com zoom de 200% e uma janela de 320 pixels de largura.
5. Corrija no design system. A maioria das falhas vem de componentes compartilhados; corrigir um botão ou um diálogo uma vez corrige em todo lugar.

Perguntas frequentes

A WCAG se aplica às áreas logadas de uma aplicação web?

A WCAG se aplica a qualquer conteúdo web, incluindo páginas que exigem login. Se uma lei obriga um produto específico a atendê-la depende da jurisdição e do cliente, mas os compradores que perguntam sobre acessibilidade normalmente estão falando do produto inteiro.

Um overlay pode tornar um produto SaaS acessível?

Não. Os overlays não mudam o código por trás dos componentes personalizados, que é onde ficam as falhas das aplicações. O nosso guia sobre overlays de acessibilidade trata da ação da FTC contra um dos principais fornecedores de overlays.

Quanto da WCAG as ferramentas automatizadas conseguem verificar?

Só uma parte. As regras automatizadas encontram com segurança nomes e rótulos ausentes e falhas de contraste, mas muitos critérios, como uma ordem de foco que faça sentido, um texto alternativo útil e mensagens de erro compreensíveis, precisam do julgamento de uma pessoa.

Qual versão da WCAG devemos adotar como meta?

A WCAG 2.2 nível AA é a versão atual. Muitas leis e regras de compras públicas ainda citam a WCAG 2.1 AA; atender à 2.2 AA também atende à 2.1 AA, exceto pelo critério Parsing, que foi removido.

Precisamos atender ao nível AAA?

O W3C não recomenda exigir AAA para produtos inteiros, porque alguns conteúdos não conseguem atender a todos os critérios AAA. O nível AA é a meta habitual.

Fontes

• W3C: What's new in WCAG 2.2 (abre em uma nova aba)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (abre em uma nova aba)
• W3C: Understanding 3.3.8 Accessible Authentication (Minimum) (abre em uma nova aba)
• W3C: Understanding 2.5.8 Target Size (Minimum) (abre em uma nova aba)
• W3C: Understanding 4.1.3 Status Messages (abre em uma nova aba)
• W3C: ARIA Authoring Practices Guide: Dialog (modal) pattern (abre em uma nova aba)
• W3C: Inaccessibility of CAPTCHA (abre em uma nova aba)
• ITI: Voluntary Product Accessibility Template (VPAT) (abre em uma nova aba)
• GSA: Section508.gov (abre em uma nova aba)
• WebAIM: The WebAIM Million (2026) (abre em uma nova aba)