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

<https://www.fixreports.com/pt-br/blog/wcag-2-2-checklist-saas-web-apps>

Atualizado em 2026-10-26

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](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- 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](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Alvos interativos precisam ter pelo menos 24 por 24 pixels CSS ou espaço suficiente ao redor (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Mensagens como “Salvo” ou “3 resultados” precisam chegar aos leitores de tela sem mover o foco (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- 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](https://www.itic.org/policy/accessibility/vpat)).

## 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](https://www.w3.org/TR/turingtest/)).
- **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](https://webaim.org/projects/million/)), 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](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **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](/pt-br/color-contrast-checker) 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?

| Critério | Nível | O que significa em uma aplicação |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Barras de ferramentas fixas, banners e widgets de chat não podem cobrir totalmente o elemento em foco |
| 2.5.7 Dragging Movements | AA | Tudo o que se faz arrastando, como reordenar um quadro kanban, precisa de uma alternativa com um único ponteiro, por exemplo um menu ou botões de subir e descer |
| 2.5.8 Target Size (Minimum) | AA | Botões e links com pelo menos 24 × 24 pixels CSS, ou espaçados de forma que um círculo de 24 pixels ao redor de cada um não se sobreponha a outro |
| 3.2.6 Consistent Help | A | Links de ajuda, chat e dados de contato no mesmo lugar relativo em todas as páginas |
| 3.3.7 Redundant Entry | A | Informações já inseridas no mesmo processo são preenchidas automaticamente ou podem ser selecionadas |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login sem memorizar nem transcrever, a menos que seja permitido colar, usar gerenciadores de senhas ou outro método |

A WCAG 2.2 também removeu o 4.1.1 Parsing, que não tem mais efeito prático na acessibilidade ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## 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](https://www.itic.org/policy/accessibility/vpat)).

As agências federais dos EUA precisam comprar tecnologia acessível segundo a Seção 508 ([Section508.gov](https://www.section508.gov/)), 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](/pt-br/blog/european-accessibility-act-online-stores) 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](/pt-br/website-accessibility-checker) 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](/pt-br/blog/accessibility-overlays-ftc-order) 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](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)