Uma landing page criada por IA pode se adaptar bem ao celular e falhar quando alguém amplia o navegador. O menu cobre o título, o formulário sai da tela, uma tabela força toda a página a rolar para os lados ou o CTA desaparece atrás de uma barra fixa.

Esse problema não aparece numa captura em desktop. Também não basta reduzir a janela até 320 pixels e chamar o resultado de teste de zoom. A ampliação muda o espaço disponível, o tamanho percebido do texto e o comportamento de componentes que dependem de breakpoints.

Este guia mostra como testar zoom e reflow, encontrar a regra responsável e retestar a mesma versão depois da publicação.

O que reflow exige

O critério Reflow da WCAG 2.2 pede que conteúdo com rolagem vertical funcione numa largura equivalente a 320 CSS pixels sem perda de informação ou função e sem exigir rolagem em duas dimensões. Uma referência comum é uma viewport inicial de 1280 CSS pixels ampliada a 400%.

O objetivo não é conservar o layout desktop em miniatura. É permitir que a pessoa leia uma linha, avance para a próxima e conclua a tarefa sem arrastar a página para a esquerda e para a direita.

Alguns conteúdos dependem de uma disposição bidimensional para manter o sentido, como mapas, diagramas, vídeos e tabelas de dados. A exceção vale para esse trecho, não para liberar rolagem horizontal na página inteira. Sempre que possível, limite o overflow ao componente.

Separe três testes diferentes

Zoom, largura responsiva e aumento de texto se sobrepõem, mas não são o mesmo teste.

  • O zoom do navegador escala o conteúdo e reduz a viewport em CSS pixels. Ele revela cortes, barras fixas, modais e breakpoints frágeis.
  • A viewport estreita reduz a área disponível sem simular toda a ampliação. Ela revela problemas em grids, menus, mídia e overflow.
  • O aumento do tamanho de texto amplia as letras sem necessariamente ampliar o resto. Ele revela alturas fixas, truncamento e controles apertados.

Execute os três. Uma página que passa no modo responsivo pode quebrar a 400% de zoom. Outra pode fazer reflow corretamente e cortar texto quando o tamanho padrão da fonte muda.

O guia de responsividade em landing pages criadas por IA cobre tamanhos, orientação e teclado virtual. Aqui, o foco é manter leitura e operação quando o conteúdo precisa ocupar muito mais espaço.

Prepare uma versão e uma tarefa

Antes de mexer no CSS, registre:

fonte e versão:
URL ou build:
navegador e sistema:
viewport inicial:
níveis de zoom:
páginas incluídas:
tarefa principal:
componentes fixos ou sobrepostos:

Escolha uma tarefa completa. Uma inspeção visual isolada deixa estados importantes fora do teste. Por exemplo:

Abrir o menu, comparar os planos, preencher o formulário com um erro,
corrigir o campo e chegar à confirmação.

Isso impede que um bloco aparentemente correto esconda uma falha no modal, no banner de cookies ou no estado de erro.

Teste a largura equivalente a 320 CSS pixels

Há duas formas úteis de montar o teste:

  1. comece com uma viewport de 1280 CSS pixels a 100% e aumente o zoom do navegador gradualmente até 400%, confirmando que a largura efetiva chegou a 320 CSS pixels;
  2. use uma viewport redimensionável e ajuste a largura calculada para 320 CSS pixels.

Se começar com outra largura, ajuste o zoom ou a janela até atingir 320 CSS pixels. Por exemplo, 1440 CSS pixels a 400% ainda deixam 360 CSS pixels disponíveis e podem esconder falhas entre 320 e 359 pixels.

O Chrome DevTools recomenda a Device Toolbar para testar reflow. A ferramenta ajuda a controlar dimensões, mas não substitui o zoom real do navegador. Faça pelo menos uma passagem com cada método.

Em todos os níveis, percorra a página inteira. Procure:

  • barra horizontal no documento;
  • texto cortado ou escondido;
  • card que mantém largura mínima exagerada;
  • navegação que não cabe nem oferece alternativa;
  • modal maior que a viewport;
  • botão fixo cobrindo conteúdo;
  • campo e mensagem de erro em colunas separadas;
  • imagem ou vídeo ultrapassando o contêiner;
  • código, URL ou palavra longa empurrando o layout;
  • conteúdo removido num breakpoint estreito.

Não aceite “é só rolar para o lado” para texto corrido. Esse é exatamente o esforço que o reflow tenta evitar.

Encontre o elemento que cria o overflow

Quando a página ganha uma barra horizontal, não aplique overflow-x: hidden no body de imediato. Essa regra pode apenas esconder conteúdo inacessível.

Comece pelo elemento que ultrapassa a viewport. As causas comuns são:

width: 100vw dentro de um contêiner com padding
min-width rígido em card ou formulário
grid com colunas fixas
white-space: nowrap em texto que deveria quebrar
imagem, SVG, iframe ou vídeo sem limite de largura
posição absoluta com deslocamento fixo
transform que leva conteúdo para fora da tela
palavra, URL ou trecho de código sem oportunidade de quebra

Inspecione o tamanho calculado do elemento e dos ancestrais. Uma borda de depuração temporária ajuda a localizar qual caixa passou do limite, mas remova esse diagnóstico antes de publicar.

Corrija a causa, não o sintoma

Prefira dimensões que aceitem o espaço disponível:

.section {
  inline-size: min(100%, 72rem);
}


.media {
  max-inline-size: 100%;
  block-size: auto;
}


.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 18rem), 1fr));
}

Para texto longo, use uma estratégia de quebra compatível com o conteúdo. URLs e identificadores podem precisar de overflow-wrap: anywhere. Títulos comuns não devem ser quebrados em pontos arbitrários sem necessidade.

Evite alturas fixas em componentes que contêm texto. Quando a linha vira quatro, o card precisa crescer. Truncamento pode ser válido numa listagem, mas não deve apagar preço, condição, instrução ou mensagem de erro necessária para concluir a tarefa.

Trate tabelas e código como exceções locais

Uma tabela de comparação pode precisar manter a relação entre linhas e colunas. Nesse caso, coloque a rolagem no contêiner da tabela, mantenha cabeçalhos identificáveis e deixe o restante da página em uma coluna.

.table-region {
  max-inline-size: 100%;
  overflow-x: auto;
}

Faça o mesmo com blocos de código quando a quebra destruir a leitura. O usuário deve conseguir chegar ao componente, entender que ele rola e voltar ao fluxo da página sem mover o documento inteiro.

Uma alternativa em cards pode ajudar em telas estreitas, mas só use se preservar todas as relações e informações. Não esconda colunas para fazer a barra desaparecer.

Revise barras fixas, menus e modais

Elementos fixos ocupam uma parcela muito maior da tela quando o zoom aumenta. Um header de 80 pixels e um banner inferior podem deixar pouco espaço para ler ou operar.

Verifique se:

  • o header reduz ou deixa de ser fixo quando necessário;
  • banners podem ser dispensados sem usar um controle fora da viewport;
  • o conteúdo focado não fica totalmente encoberto;
  • o menu aberto cabe, rola internamente e pode ser fechado;
  • o modal respeita a largura e a altura disponíveis;
  • o foco continua visível em controles ampliados.

O guia de navegação por teclado detalha ordem, foco visível e dialogs. Refaça esse roteiro com o zoom alto, porque a geometria muda.

Não bloqueie o zoom no viewport

Configurações como user-scalable=no ou limites baixos de escala impedem que algumas pessoas ampliem o conteúdo. A referência da MDN para o meta viewport alerta que desabilitar zoom prejudica pessoas com baixa visão.

Use uma configuração que adapte a página ao dispositivo sem tirar o controle da pessoa:

<meta name="viewport" content="width=device-width, initial-scale=1" />

Se o layout só funciona quando o zoom está bloqueado, o problema continua no layout.

Faça uma passagem por componente e outra por tarefa

Na primeira passagem, confira componentes isolados:

  • navegação;
  • hero e CTA;
  • cards e comparações;
  • accordions;
  • formulários e validação;
  • modal;
  • banner persistente;
  • mídia e embeds;
  • rodapé.

Na segunda, repita a tarefa principal sem reduzir o zoom. Confirme que nenhum controle desapareceu, que o conteúdo mantém uma ordem compreensível e que a página não devolve o foco para uma área coberta.

Teste também contraste no estado ampliado. Sobreposições, gradientes e fundos recortados podem mudar a combinação de cores. O guia de teste de contraste ajuda a medir cada estado real.

Peça ao agente um diagnóstico limitado

Um pedido bom separa descoberta de edição:

Audite zoom e reflow desta landing page antes de editar.


Escopo:
- fonte e versão: [origem]
- páginas: [rotas]
- navegador: [nome e versão]
- tarefa principal: [descrição]
- referência: WCAG 2.2, critérios 1.4.10 e 1.4.4


Teste:
- zoom de 100%, 200% e 400%;
- viewport equivalente a 320 CSS pixels;
- navegação completa com teclado;
- conteúdo, mídia, tabelas, formulários, menus e modais;
- rolagem horizontal no documento e em exceções locais.


Retorne cada falha com rota, estado, elemento, evidência e menor correção.
Não esconda overflow globalmente e não remova conteúdo para fazer o teste passar.
Não publique antes da aprovação do diagnóstico.

Depois da aprovação, peça um diff pequeno e repita os mesmos passos. Uma correção responsiva ampla pode consertar um card e quebrar outro.

Reteste a URL publicada

O pacote local não é a última evidência. Uma folha de estilo antiga, um asset com dimensões diferentes ou uma versão errada pode chegar à URL.

Depois da publicação:

  1. confirme a URL e a versão;
  2. recarregue sem reaproveitar a página anterior;
  3. repita zoom e viewport estreita;
  4. percorra a tarefa com teclado;
  5. inspecione overflow, barras fixas, tabelas e modais;
  6. registre navegador, dimensões e resultado;
  7. republique o mesmo Site se a correção for necessária.

O contrato de Publicação do Site no Ar mantém a edição, o deploy e a versão verificáveis. A publicação não certifica acessibilidade. Ela entrega uma URL estável para o reteste da versão aprovada.

Guarde evidência que permita repetir o teste

Feche a revisão com um registro curto:

versão:
URL:
navegador e sistema:
viewport inicial:
zoom máximo testado:
largura em CSS pixels:
rolagem horizontal no documento:
exceções locais:
tarefa concluída:
falhas restantes:
responsável:

Reflow está pronto quando a pessoa amplia, lê e opera a página sem caçar conteúdo fora da tela. O resultado precisa sobreviver ao pacote e à URL publicada.