Critérios de Sucesso WCAG · Level AA

WCAG 1.4.10: Refluxo

WCAG 1.4.10 Reflow exige que o conteúdo possa ser apresentado sem perda de informação ou funcionalidade, e sem exigir rolagem em duas dimensões, quando exibido em uma largura equivalente a 320 pixels CSS. Isso garante que usuários que dependem de zoom ou de janelas de visualização pequenas — incluindo pessoas com baixa visão e usuários de dispositivos móveis — possam acessar todo o conteúdo sem rolagem horizontal.

O que Esta Regra Significa

WCAG 1.4.10 Reflow é um critério de sucesso de Nível AA introduzido no WCAG 2.1 e mantido no WCAG 2.2. Ele especifica que o conteúdo da web deve ser capaz de se reajustar — isto é, se reorganizar e redimensionar — de modo que permaneça totalmente utilizável em uma largura de viewport equivalente a 320 pixels CSS, sem exigir que o usuário role horizontalmente para ler ou interagir com o conteúdo. O ponto de referência de 320 pixels CSS corresponde ao que um usuário vê quando define o nível de zoom do navegador para 400% em uma tela padrão com 1280px de largura.

O requisito central é que nenhuma perda de informação ou funcionalidade ocorra nessa largura limitada. Todo o texto deve permanecer legível, todos os controles interativos devem continuar operáveis e todo o conteúdo significativo deve permanecer visível sem acionar rolagem bidimensional. A rolagem vertical é permitida — o critério apenas proíbe a rolagem horizontal para conteúdo com fluxo vertical (e rolagem vertical para conteúdo com fluxo horizontal, embora isso seja raro). Um layout que obriga os usuários a rolar para cima e para baixo e para a esquerda e para a direita simultaneamente para ler um parágrafo de texto falharia nesse critério.

O W3C define exceções explícitas em que a rolagem bidimensional é aceitável. Elas incluem conteúdo em que o layout bidimensional é essencial para seu uso e significado: grandes tabelas de dados com muitas colunas, mapas complexos e diagramas geográficos, players de vídeo e seus controles de reprodução, barras de ferramentas com vários botões de ação dispostos lado a lado e jogos ou diagramas interativos que exigem uma relação espacial precisa entre elementos. Essas exceções devem ser interpretadas de forma restrita — a isenção se aplica ao conteúdo em si (por exemplo, as células de uma tabela de dados), não à navegação, aos cabeçalhos ou ao texto explicativo que o acompanha.

Uma página passa nesse critério se: quando o navegador é ampliado para 400% (ou o viewport é definido para 320px de largura), o conteúdo se reorganiza em uma única coluna, a navegação se recolhe ou se empilha adequadamente, as imagens são redimensionadas proporcionalmente e o usuário consegue realizar tudo o que poderia no nível de zoom padrão usando apenas rolagem vertical. Uma página falha se a rolagem horizontal for necessária para ler frases, alcançar botões ou acessar qualquer conteúdo não isento.

Por Que Isso Importa

Aproximadamente 2,2 bilhões de pessoas em todo o mundo vivem com algum tipo de deficiência visual, de acordo com a Organização Mundial da Saúde. Uma proporção significativa dessas pessoas depende do zoom do navegador, da ampliação do sistema operacional ou de softwares dedicados de ampliação de tela (como ZoomText ou Lupa do Windows) para tornar o texto e os elementos de interface grandes o suficiente para serem percebidos confortavelmente. Quando um layout se quebra em níveis altos de zoom — forçando o conteúdo para fora da tela ou exigindo rolagem horizontal — esses usuários enfrentam uma experiência de leitura fragmentada em que cada frase exige um movimento de panorâmica de vai-e-volta. Isso não é apenas inconveniente; pode tornar conteúdo complexo efetivamente inacessível.

Considere uma pessoa usuária de 65 anos com degeneração macular relacionada à idade que navega no portal de agendamento de consultas de um hospital turco com o navegador definido para 300% de zoom. Se o formulário de agendamento for renderizado com colunas de largura fixa, o botão "Enviar" pode ser empurrado completamente para fora da borda direita da área visível. A pessoa não tem como saber que o botão existe, muito menos interagir com ele. Ela não consegue marcar sua consulta de forma independente. Este é um dano direto e concreto causado pela falha em Reflow.

Além de pessoas com baixa visão, Reflow beneficia uma ampla gama de pessoas. Usuários com deficiências motoras que utilizam acesso por varredura ou dispositivos de rastreamento de cabeça consideram a rolagem horizontal extremamente difícil ou impossível de realizar de forma confiável. A deficiência cognitiva afeta uma parte significativa da população, e pesquisas mostram de forma consistente que layouts estreitos de coluna única — típicos de um Reflow bem implementado — reduzem a carga cognitiva e melhoram a compreensão de leitura. Pessoas que usam dispositivos com telas pequenas ou leem em modo de tela dividida também se beneficiam diretamente, mesmo sem qualquer deficiência.

Do ponto de vista técnico e de negócios, implementar Reflow corretamente se sobrepõe quase totalmente à construção de um design responsivo bem estruturado. Isso significa que a conformidade com 1.4.10 naturalmente melhora a usabilidade em dispositivos móveis, reduz taxas de rejeição e contribui positivamente para métricas de Core Web Vitals que influenciam classificações em mecanismos de busca. Para plataformas de e-commerce turcas em particular, onde o tráfego móvel domina, a conformidade com Reflow e a otimização comercial para dispositivos móveis são essencialmente o mesmo objetivo.

Regras Relacionadas do Axe-core

WCAG 1.4.10 Reflow exige testes manuais em vez de varredura automatizada. Nenhuma regra do axe-core pode automatizar totalmente a detecção de falhas de Reflow porque o critério depende do comportamento visual e funcional de todo um layout renderizado em um tamanho específico de viewport — algo que exige um ambiente real de navegador, julgamento humano sobre a rolagem e verificação de que nenhuma informação foi perdida. Ferramentas automatizadas não conseguem distinguir de forma confiável entre rolagem bidimensional intencional (para um mapa ou tabela isentos) e um transbordamento de layout não intencional causado por um contêiner de largura fixa.

  • Teste manual — largura de viewport de 320px: Redimensione o viewport do navegador para exatamente 320 pixels CSS de largura (ou aplique zoom de 400% em uma tela com 1280px de largura) e role verticalmente por todos os templates de página, estados de tela e componentes interativos. Verifique se nenhum conteúdo é cortado, se nenhuma barra de rolagem horizontal aparece para conteúdo não isento e se toda a funcionalidade permanece acessível. O Axe DevTools sinalizará isso como um item "Needs Review" em vez de uma violação automática, porque a análise de layout baseada em ferramenta não consegue determinar se o transbordamento representa uma falha real ou se se enquadra em uma isenção.
  • Sinal parcial automatizado — verificação da meta tag de viewport: O axe-core pode detectar se a página usa uma tag meta name='viewport' com user-scalable=no ou maximum-scale=1, ambas impedindo que os usuários apliquem zoom e, portanto, tornando impossível atingir o estado de zoom de 400% que Reflow exige. Embora isso seja tecnicamente um problema separado (WCAG 1.4.4), é intimamente relacionado e sua presença garante uma falha em Reflow. O Axe sinaliza isso sob a regra meta-viewport. Qualquer página que bloqueia o zoom também bloqueia a conformidade com Reflow por definição.
  • Auditoria manual de componentes: Além do layout de página inteira, componentes individuais como carrosséis, cabeçalhos fixos, diálogos modais, widgets de chat flutuantes, banners de cookies e tabelas de dados exigem verificação individual em 320px. Um cabeçalho de página pode se reajustar corretamente enquanto um modal promocional é renderizado com largura fixa de 600px e um botão de fechar inalcançável — uma falha que apenas uma revisão manual componente por componente irá detectar.

Como Testar

  1. Pré-varredura automatizada: Execute o axe DevTools ou o Lighthouse no Chrome DevTools em cada página. Procure especificamente pela violação de meta-viewport, que indica que o zoom está bloqueado e garante uma falha em Reflow. Observe também quaisquer avisos relacionados a transbordamento sinalizados como "Needs Review". Registre os resultados, mas entenda que uma varredura automatizada limpa não confirma a conformidade com Reflow — etapas manuais são obrigatórias.
  2. Defina o viewport para 320px: No Chrome ou Firefox DevTools, abra a barra de ferramentas de dispositivos (Ctrl+Shift+M / Cmd+Shift+M), insira um tamanho de dispositivo personalizado de 320×568 pixels (ou qualquer altura) e defina a proporção de pixels do dispositivo para 1. Alternativamente, abra uma janela de navegador com 1280px de largura e aplique zoom de 400% usando Ctrl+= (Cmd+= no Mac). Ambos os métodos simulam a condição de 320 pixels CSS especificada pelo WCAG.
  3. Role verticalmente por toda a página: Começando do topo da página, role apenas para baixo usando a barra de rolagem vertical ou a roda do mouse. Em nenhum momento uma barra de rolagem horizontal deve aparecer para conteúdo não isento. Se aparecer, a página falha. Confirme que todo o texto está totalmente legível — nenhuma frase é cortada, nenhum caractere é recortado pela borda do viewport.
  4. Teste toda a funcionalidade interativa: Com a largura em 320px, tente concluir todas as principais tarefas do usuário: preencher e enviar formulários, abrir menus de navegação, ativar modais e diálogos, usar acordeões e abas, interagir com carrosséis e acionar qualquer conteúdo dinâmico. Cada controle deve ser alcançável e operável usando apenas rolagem vertical e interação normal.
  5. Verifique todos os templates e estados de página: Teste a página inicial, páginas internas de conteúdo, formulários, fluxos de checkout, estados de erro e quaisquer visões autenticadas. Uma navegação responsiva que se recolhe corretamente na página inicial pode ainda se quebrar em uma página de produto profundamente aninhada com um template diferente.
  6. Pareamento com leitor de tela (suplementar): Use NVDA com Firefox ou VoiceOver com Safari em largura de 320px para confirmar que a ordem e o significado do conteúdo são preservados após o reajuste. Às vezes, o Reflow baseado em CSS altera a ordem visual sem alterar a ordem no DOM, fazendo com que os anúncios do leitor de tela se tornem confusos. Isso não é estritamente um teste de Reflow, mas detecta implementações de Reflow que criam problemas de acessibilidade separados.
  7. Documente as isenções: Para qualquer conteúdo que exija rolagem horizontal (tabelas de dados, mapas, blocos de código), verifique e documente que ele realmente se enquadra em uma exceção definida pelo WCAG. Confirme que o conteúdo ao redor da página (títulos, instruções, navegação) ainda se reajusta corretamente, mesmo que o componente incorporado não o faça.

Como Corrigir

Contêiner de largura fixa quebrando o layout — Incorreto

<!-- Fixed pixel width forces horizontal scrolling at small viewports -->
<div style='width: 960px; margin: 0 auto;'>
  <p>This content will overflow a 320px viewport and require horizontal scrolling.</p>
  <button>Submit Application</button>
</div>

Contêiner de largura fixa quebrando o layout — Correto

<!-- Use max-width with 100% so container never exceeds its parent but shrinks on small screens -->
<div class='content-wrapper'>
  <p>This content reflows naturally at any viewport width.</p>
  <button>Submit Application</button>
</div>

<!-- In your CSS (external stylesheet) -->
<!-- .content-wrapper { max-width: 960px; width: 100%; margin: 0 auto; box-sizing: border-box; padding: 0 1rem; } -->

Meta tag de viewport bloqueando zoom — Incorreto

<!-- This prevents users from zooming at all, making Reflow impossible to achieve -->
<meta name='viewport' content='width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no'>

Meta tag de viewport bloqueando zoom — Correto

<!-- Allow zooming by removing maximum-scale and user-scalable restrictions -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!-- Users can now zoom to 400% and content will reflow as required by WCAG 1.4.10 -->

Barra de navegação horizontal transbordando — Incorreto

<!-- Navigation items forced into a single row with no wrapping or collapse mechanism -->
<nav aria-label='Primary navigation'>
  <ul style='display: flex; flex-wrap: nowrap; white-space: nowrap;'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>

Barra de navegação horizontal transbordando — Correto

<!-- Hamburger/disclosure pattern for small viewports; full navigation accessible at all sizes -->
<nav aria-label='Primary navigation'>
  <button aria-expanded='false' aria-controls='nav-menu' id='nav-toggle'>
    Menu
  </button>
  <ul id='nav-menu'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>
<!-- CSS media query hides #nav-menu by default below a breakpoint and shows it on toggle -->
<!-- The button is hidden above the breakpoint where the full nav is always visible -->

Tabela de dados sem acomodação de reflow — Incorreto

<!-- Wide table with no scroll container; overflows the viewport with no warning to users -->
<table>
  <caption>Quarterly Sales Data</caption>
  <thead>
    <tr>
      <th scope='col'>Region</th>
      <th scope='col'>Q1</th>
      <th scope='col'>Q2</th>
      <th scope='col'>Q3</th>
      <th scope='col'>Q4</th>
      <th scope='col'>Total</th>
    </tr>
  </thead>
</table>

Tabela de dados sem acomodação de reflow — Correto

<!-- Wrap the table in a scrollable container scoped to just the table element -->
<!-- This is an explicit WCAG 1.4.10 exception for complex data tables -->
<div role='region' aria-labelledby='table-caption' tabindex='0' class='table-scroll-container'>
  <table>
    <caption id='table-caption'>Quarterly Sales Data (scroll horizontally to view all columns)</caption>
    <thead>
      <tr>
        <th scope='col'>Region</th>
        <th scope='col'>Q1</th>
        <th scope='col'>Q2</th>
        <th scope='col'>Q3</th>
        <th scope='col'>Q4</th>
        <th scope='col'>Total</th>
      </tr>
    </thead>
  </table>
</div>
<!-- CSS: .table-scroll-container { overflow-x: auto; } -->
<!-- The caption warns users, role=region + aria-labelledby makes it keyboard-focusable -->

Erros Comuns

  • Usar overflow: hidden no <body> ou em um wrapper de nível superior para suprimir barras de rolagem horizontais sem corrigir o transbordamento subjacente: Isso oculta a barra de rolagem, mas o conteúdo ainda é cortado e inacessível, o que é possivelmente pior do que o transbordamento visível porque o usuário não tem indicação de que existe conteúdo além da borda do viewport.
  • Definir max-scale=1 ou user-scalable=no na meta tag de viewport para evitar que um layout móvel "pareça quebrado" em alto zoom: Isso desabilita totalmente a capacidade de zoom do usuário, o que é tanto uma falha em Reflow quanto uma violação do WCAG 1.4.4 Resize Text.
  • Aplicar white-space: nowrap a contêineres de texto, listas de navegação ou grupos de botões sem uma substituição específica por breakpoint: Isso força o texto a ficar em uma única linha independentemente do espaço disponível e é uma das causas mais comuns de transbordamento horizontal em 320px.
  • Usar valores absolutos em pixels em definições de CSS Grid grid-template-columns (por exemplo, grid-template-columns: 300px 600px) sem um fallback responsivo: Em 320px as duas colunas totalizam 900px e irão transbordar sem Reflow, a menos que uma media query substitua a definição por 1fr ou 100%.
  • Incorporar elementos <iframe> com atributos fixos de width e height apontando para conteúdo de terceiros (mapas, vídeos, formulários): Iframes não são escalonados automaticamente, então um mapa incorporado com 600px de largura irá transbordar um viewport de 320px. Envolva iframes em um contêiner que preserve a proporção e defina o próprio iframe como width: 100%.
  • Projetar diálogos modais e painéis off-canvas com uma largura mínima fixa maior que 320px: Um modal com min-width: 500px irá transbordar e provavelmente ocultar seu botão de fechar fora da tela, prendendo usuários de teclado dentro do diálogo em larguras pequenas de viewport.
  • Tratar blocos de código e elementos <pre> como isentos de Reflow sem envolvê-los em um contêiner rolável horizontalmente: Blocos de código brutos não estão listados como exceção no WCAG. Embora o próprio conteúdo de código possa ser complexo, a página ao redor deve se reajustar; o bloco de código deve rolar independentemente dentro de um wrapper com overflow-x: auto, e não causar rolagem horizontal da página inteira.
  • Esquecer de testar estados autenticados e dinâmicos: Muitas equipes testam apenas a página inicial deslogada. Dashboards, páginas de perfil de usuário, formulários em múltiplas etapas e estados de erro carregados via JavaScript são frequentemente construídos com suposições de largura fixa e falham em Reflow mesmo quando as páginas de marketing passam.
  • Usar CSS transform: scale() para encolher visualmente o conteúdo em vez de implementar um layout verdadeiramente responsivo: O escalonamento reduz o tamanho aparente, mas não reorganiza o conteúdo — o texto fica minúsculo e ilegível em vez de se reorganizar em uma coluna única legível, o que falha tanto nos critérios de Reflow quanto de Resize Text.
  • Assumir que um design responsivo para dispositivos móveis passa automaticamente em Reflow: O design responsivo normalmente mira breakpoints em 360px, 768px e 1024px. O ponto de referência de 320px do WCAG é mais estreito do que a maioria dos breakpoints móveis, o que significa que conteúdo que parece correto em um telefone pequeno padrão ainda pode transbordar em 320px. Sempre teste exatamente em 320px, não em um tamanho "móvel" genérico.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial de número 32933 em 21 de junho de 2025, estabelece requisitos obrigatórios de acessibilidade para uma ampla gama de prestadores de serviços digitais que operam na Turquia. A circular determina a conformidade com padrões internacionais de acessibilidade na web — tendo o WCAG 2.1 Nível AA como base — para as entidades abrangidas. WCAG 2.2 Nível AA, que incorpora todos os critérios do 2.1, incluindo 1.4.10 Reflow, é fortemente incentivado e é o padrão exigido para obtenção do Erişilebilirlik Logosu (Logotipo de Acessibilidade) emitido pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı).

Os tipos de entidades abrangidas pela Circular Presidencial 2025/10 incluem instituições públicas e órgãos governamentais em todos os níveis, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, plataformas de e-commerce, agências de viagens, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (Millî Eğitim Bakanlığı). Para cada um desses setores, a expectativa é que todas as interfaces digitais voltadas ao público — sites, aplicações web e conteúdo web móvel — sejam acessíveis a pessoas com deficiência, incluindo aquelas que dependem de zoom e ajuste de viewport para perceber o conteúdo.

WCAG 1.4.10 Reflow é particularmente relevante no contexto turco por várias razões. Primeiro, a penetração da internet móvel na Turquia é excepcionalmente alta, e uma parcela substancial de usuários acessa serviços governamentais, portais bancários e plataformas de e-commerce por meio de navegadores móveis em diferentes níveis de zoom. Um sistema de agendamento de consultas hospitalares que falha em Reflow pode impedir que pacientes idosos com baixa visão marquem consultas de forma independente — uma falha direta tanto da legislação de acessibilidade quanto da missão de serviço público das instituições abrangidas. Segundo, o programa Erişilebilirlik Logosu exige uma auditoria de conformidade cobrindo todos os critérios de sucesso de Nível AA; falhar em 1.4.10 desqualificaria um site de outra forma conforme de receber o logotipo. Terceiro, para empresas de telecomunicações com grandes bases de assinantes, portais de autoatendimento acessíveis e interfaces de gestão de contas são essenciais — um painel de conta de largura fixa que transborda em zoom de 400% prejudica diretamente assinantes com deficiências visuais que, de outra forma, não precisariam visitar uma loja física ou ligar para uma central de suporte.

Organizações que buscam demonstrar conformidade com os regulamentos de acessibilidade turcos devem garantir que suas implementações de design responsivo sejam especificamente validadas no limite de 320 pixels CSS, que nenhuma meta tag de viewport bloqueie o zoom do usuário e que toda a funcionalidade interativa — incluindo fluxos de autenticação, envio de formulários e download de documentos — permaneça totalmente operável sem rolagem horizontal. Incluir testes de Reflow como parte de um trilho de auditoria de acessibilidade documentado será essencial para demonstrar conformidade a órgãos reguladores e para manter a elegibilidade ao Erişilebilirlik Logosu.