WCAG 1.4.4: Redimensionar texto

O Que Esta Regra Significa

WCAG 1.4.4 Redimensionar Texto (Nível AA) estabelece que o texto deve poder ser redimensionado em até 200 por cento sem o uso de tecnologia assistiva e sem perda de conteúdo ou funcionalidade. Em termos simples, quando uma pessoa usuária amplia o zoom do navegador para 200% ou aumenta o tamanho base da fonte pelas configurações do navegador ou do sistema operacional, todo o texto na página deve continuar legível e toda a funcionalidade deve permanecer intacta.

O critério se aplica de forma ampla a todo o texto renderizado em uma página web, incluindo corpo do texto, títulos, rótulos, texto de botões, texto de placeholder dentro de campos de formulário, links de navegação, conteúdo de tabelas e legendas. Ele não se aplica a texto que faça parte de um logotipo ou nome de marca, nem a texto decorativo que não transmita informação e seja apresentado apenas como conteúdo de imagem (como uma fotografia escaneada de um bilhete manuscrito em que o texto em si não é o conteúdo acessível).

Para aprovação, é necessário que, com zoom de 200% — obtido tanto pelo zoom de página embutido no navegador (Ctrl/Cmd + tecla de mais ou pelo menu Ver > Zoom) quanto pela configuração de tamanho mínimo de fonte do navegador —, as seguintes condições sejam verdadeiras: nenhum texto é cortado ou ocultado por seu contêiner, nenhum texto se sobrepõe a outro texto ou a elementos interativos, nenhuma barra de rolagem horizontal aparece na largura total da janela de visualização (exceto para conteúdo que realmente exija rolagem bidimensional, como mapas ou tabelas de dados) e todos os controles interativos permanecem operáveis.

Um erro é registrado quando valores fixos em pixels travam o texto em um tamanho que não pode crescer, quando contêineres usam alturas fixas que cortam texto que transborda, quando meta tags de viewport usam user-scalable=no ou maximum-scale=1.0 para bloquear o gesto de pinça para zoom em dispositivos móveis, ou quando JavaScript intercepta gestos de zoom para impedir o escalonamento. O critério é explicitamente neutro em relação à tecnologia: independentemente de a implementação usar CSS, texto em SVG ou texto renderizado em canvas, o que importa é o resultado para a pessoa usuária. Observe que texto em SVG e texto renderizado em canvas são inerentemente difíceis de redimensionar e frequentemente exigem atenção adicional de engenharia.

Por Que Isso Importa

Aproximadamente 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual, de acordo com a Organização Mundial da Saúde. Entre elas, uma proporção muito grande apresenta baixa visão — uma condição em que a visão não pode ser totalmente corrigida com óculos ou lentes de contato, mas em que a pessoa não é totalmente cega. Pessoas com baixa visão rotineiramente definem o zoom do navegador em 150%, 200% ou mais, ou configuram o sistema operacional para renderizar texto em um tamanho base maior. Quando sites bloqueiam ou quebram esse comportamento, essas pessoas são totalmente excluídas do conteúdo.

Além da baixa visão diagnosticada, fatores situacionais afetam praticamente toda pessoa usuária de internet em algum momento: telas pequenas, luz solar intensa, fadiga, envelhecimento da visão ou leitura em um idioma pouco familiar podem tornar textos menores mais difíceis de compreender. Pessoas idosas em particular — um grupo demográfico em rápido crescimento globalmente e na Turquia — frequentemente dependem do zoom como acomodação de acessibilidade de primeira linha antes de recorrer a tecnologia assistiva especializada.

Considere um cenário concreto: uma paciente na faixa dos sessenta anos está tentando ler a confirmação de consulta online em um portal hospitalar no smartphone. A folha de estilos móvel do hospital define o tamanho da fonte do corpo do texto como 12px usando um valor fixo em pixels e a meta tag de viewport inclui maximum-scale=1.0. A paciente tenta usar o gesto de pinça para ampliar, mas a interface trava. Ela não consegue ler a data nem o nome do departamento com clareza suficiente para ter segurança. Ela liga para o helpdesk do hospital, consumindo tempo da equipe e gerando ansiedade para a paciente — um resultado totalmente evitável se o critério tivesse sido atendido.

Do ponto de vista puramente comercial, tamanhos de texto acessíveis se correlacionam com melhorias mais amplas de usabilidade que beneficiam todas as pessoas usuárias. Mecanismos de busca também recompensam sites que apresentam texto legível em tamanhos normais e ampliados, porque o Googlebot avalia sinais de legibilidade como parte do Core Web Vitals e dos fatores de ranqueamento de experiência de página. Corrigir problemas de redimensionamento, portanto, melhora simultaneamente o SEO, reduz a carga de suporte e amplia o público potencial.

Regras Relacionadas do Axe-core

WCAG 1.4.4 é principalmente um critério de teste manual. Ferramentas automatizadas podem sinalizar um conjunto restrito de condições que se sabe impedirem o redimensionamento de texto, mas não conseguem simular e avaliar de forma confiável todos os resultados de layout com zoom de 200%. As condições a seguir são o que as ferramentas automatizadas tentam detectar e o que exige acompanhamento manual:

• meta tag de viewport bloqueando zoom (verificação manual necessária): Axe-core inclui a regra meta-viewport, que sinaliza qualquer tag <meta name='viewport'> que defina user-scalable=no ou maximum-scale com valor 1.0 ou menor. Este é o único cenário em que uma detecção totalmente automatizada é possível, porque a violação é declarativa e não depende do resultado de layout. No entanto, nem mesmo essa regra consegue determinar se um site usa JavaScript para impedir programaticamente o zoom, portanto a verificação manual é sempre necessária.
• Tamanhos de fonte fixos em pixels (verificação manual necessária): Ferramentas automatizadas podem relatar quando valores de font-size em CSS são definidos em unidades absolutas de pixel (px) em vez de unidades relativas (em, rem, % ou unidades relativas à viewport). No entanto, navegadores modernos substituem tamanhos de fonte absolutos em pixels quando a pessoa usuária altera o tamanho padrão da fonte do navegador, de modo que um valor em pixels por si só não constitui uma falha garantida — isso depende do comportamento do navegador e de o site respeitar ou não a herança de font-size. Inspeção manual de estilos computados e verificação visual são necessárias para confirmar uma falha real.
• Transbordo de conteúdo e corte com zoom de 200% (apenas manual): Nenhuma ferramenta automatizada consegue renderizar uma página de forma confiável em 200% e avaliar se todo o texto permanece visível e todos os elementos interativos permanecem operáveis. Isso exige que uma pessoa testadora defina o nível de zoom do navegador, role pela página e verifique cada área de conteúdo. Ferramentas automatizadas não têm acesso ao estado renderizado após o zoom.
• Texto em imagens e canvas (apenas manual): Texto incorporado em imagens raster (<img> contendo capturas de tela de texto) ou renderizado em um elemento <canvas> não pode ser redimensionado pelo navegador. Ferramentas automatizadas podem sinalizar a presença de elementos canvas para revisão manual, mas não conseguem determinar se esses elementos canvas contêm texto significativo que a pessoa usuária precisa ler.

Como Testar

1. Execute primeiro uma varredura automatizada. Abra a página no Chrome ou Firefox e execute o axe DevTools (extensão de navegador) ou o Lighthouse (Chrome DevTools, aba Lighthouse). Procure especificamente pela violação da regra meta-viewport. Se for sinalizada, registre como falha crítica. Verifique também a auditoria de CSS em busca de declarações de font-size em unidades px que apareçam nos avisos de boas práticas do axe.
2. Verifique a meta tag de viewport no código-fonte. Abra o DevTools (F12), vá até a aba Elements e pesquise por meta name='viewport'. Leia com atenção o atributo content. Se ele contiver user-scalable=no, user-scalable=0 ou maximum-scale=1 (ou qualquer valor menor que 2), isso é uma falha direta de 1.4.4.
3. Defina o zoom do navegador em 200%. No Chrome ou Firefox, pressione Ctrl + Mais (Windows/Linux) ou Cmd + Mais (macOS) repetidamente até o indicador de zoom do navegador mostrar 200%. Alternativamente, vá em Ver > Aumentar Zoom. No Safari para macOS, use Ver > Aumentar Zoom. Não use o escalonamento de exibição em nível de sistema operacional para este teste — use especificamente o zoom do navegador.
4. Role por todas as seções da página com zoom de 200%. Role sistematicamente de cima para baixo. Procure por: texto que é cortado ou ocultado por seu contêiner, texto que transborda sua caixa e se sobrepõe a conteúdo adjacente, rótulos de formulário que desaparecem atrás de seus campos de entrada, botões cujo texto é truncado, menus suspensos que se estendem para fora da tela e não podem ser rolados para ficar visíveis e diálogos modais que excedem a janela de visualização e não podem ser rolados.
5. Teste toda a funcionalidade interativa com zoom de 200%. Ative todos os menus de navegação, abra todos os modais, envie formulários, dispare tooltips e popovers e interaja com quaisquer carrosséis ou acordeões. Verifique se todos permanecem totalmente operáveis — não apenas visualmente presentes.
6. Teste com NVDA + Firefox (Windows). Ative o NVDA e abra o Firefox com zoom de 200%. Navegue usando a tecla Tab e as setas. Confirme que elementos focáveis recebem foco, que os indicadores de foco são visíveis (sobreposição com WCAG 2.4.7, mas útil de verificar) e que a ordem de leitura corresponde à ordem visual no tamanho ampliado.
7. Teste com VoiceOver + Safari (macOS/iOS). Ative o VoiceOver. No iOS, vá em Ajustes > Acessibilidade > Tamanho da Tela e do Texto e ative Texto Maior. Navegue pela mesma página e verifique a integridade do conteúdo. Use também o gesto de pinça para zoom para confirmar que ele não está bloqueado.
8. Teste a configuração de tamanho mínimo de fonte do navegador. No Firefox, vá em Settings > General > Fonts and Colors e defina o tamanho mínimo de fonte como 24px. Recarregue a página e verifique se todo o texto atende a esse mínimo e se o layout não quebra. Isso testa um vetor diferente do mesmo critério.
9. Teste com JAWS + Chrome (Windows). Abra a página no Chrome com zoom de 200% e o JAWS ativo. Use os comandos de leitura do JAWS (Insert + Seta para Baixo para ler a partir do cursor) para confirmar que todo o conteúdo de texto é anunciado e que nenhum conteúdo é ignorado por estar oculto devido a corte por overflow.

Como Corrigir

Meta tag de viewport bloqueando zoom — Incorreto

<!-- ERRADO: user-scalable=no impede o gesto de pinça para zoom em dispositivos móveis,
     violando diretamente a WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>

Meta tag de viewport bloqueando zoom — Correto

<!-- CORRETO: Remova user-scalable=no e não limite maximum-scale abaixo de 2.
     Permitir zoom de pelo menos 2 (200%) satisfaz a WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>

Tamanhos de fonte fixos em pixels — Incorreto

<!-- ERRADO: font-size em px ignora a preferência de tamanho de fonte da pessoa usuária no navegador.
     Se a pessoa definir um padrão maior, valores em px substituem essa preferência. -->
<style>
  body {
    font-size: 14px;
  }
  h1 {
    font-size: 24px;
  }
  .caption {
    font-size: 11px;
  }
</style>
<p>Your appointment is confirmed.</p>

Tamanhos de fonte fixos em pixels — Correto

<!-- CORRETO: Use unidades rem relativas ao tamanho de fonte raiz (tipicamente 16px padrão do navegador).
     1rem = 16px por padrão, mas escala com a preferência da pessoa usuária.
     Definir font-size em :root em % em vez de px também respeita as configurações da pessoa usuária. -->
<style>
  :root {
    font-size: 100%; /* herda o padrão do navegador, tipicamente 16px */
  }
  body {
    font-size: 0.875rem; /* ~14px no padrão, mas escala com a preferência da pessoa usuária */
  }
  h1 {
    font-size: 1.5rem; /* ~24px no padrão */
  }
  .caption {
    font-size: 0.75rem; /* ~12px no padrão — ainda escalonável */
  }
</style>
<p>Your appointment is confirmed.</p>

Contêineres de altura fixa que cortam texto — Incorreto

<!-- ERRADO: Uma altura fixa com overflow:hidden cortará texto ampliado.
     Com zoom de 200%, o texto cresce, mas a caixa não, ocultando conteúdo. -->
<style>
  .card {
    height: 120px;
    overflow: hidden;
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Contêineres de altura fixa que cortam texto — Correto

<!-- CORRETO: Use min-height em vez de height para que o contêiner cresça
     com o conteúdo quando o texto for ampliado. -->
<style>
  .card {
    min-height: 7.5rem; /* define um mínimo, mas permite crescimento */
    overflow: visible; /* ou remova overflow:hidden completamente */
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Texto incorporado em imagens — Incorreto

<!-- ERRADO: Uma imagem de banner contendo texto não pode ser redimensionada pelo navegador.
     Mesmo com texto alternativo, o texto visual é inacessível em níveis altos de zoom. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>

Texto incorporado em imagens — Correto

<!-- CORRETO: Use texto HTML real sobre uma imagem de fundo para que o navegador
     possa redimensioná-lo. A imagem é um fundo decorativo; o texto é HTML vivo. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
  <p class='promo-text'>50% İndirim &mdash; Sadece Bu Hafta Sonu</p>
</div>
<!-- O CSS define a imagem de fundo em .promo-banner, enquanto .promo-text
     usa font-size em rem e mantém contraste seguro em relação ao fundo. -->

Erros Comuns

• Adicionar user-scalable=no à meta tag de viewport para evitar que o layout "quebre" em dispositivos móveis — isso é uma violação direta e testável de 1.4.4 e nunca deve ser usado. Corrija o layout em vez de suprimir a capacidade de zoom da pessoa usuária.
• Definir maximum-scale=1.0 ou qualquer valor abaixo de 2.0 — mesmo sem user-scalable=no, limitar o zoom a 1.0 ou 1.5 impede que as pessoas alcancem 200% e falha no critério.
• Usar event listeners em JavaScript para chamar event.preventDefault() em gestos de pinça para zoom ou eventos de roda do mouse — bloquear o zoom nativo programaticamente é funcionalmente equivalente à abordagem da meta tag de viewport e falha no mesmo critério.
• Definir font-size em pixels no elemento <html> ou <body> e depois usar unidades em para todo o resto — se o tamanho de fonte raiz estiver fixo em px, todos os descendentes em em/rem também ficam efetivamente fixos e não responderão à preferência de tamanho de fonte da pessoa usuária no navegador.
• Usar height em vez de min-height em componentes de cartão, barras laterais ou corpos de modais — com zoom de 200%, texto ampliado transborda caixas de altura fixa e é cortado por overflow: hidden, ocultando conteúdo crítico.
• Colocar texto importante exclusivamente dentro de elementos <canvas> — texto renderizado em canvas é um bitmap rasterizado e não pode ser escalonado pelos mecanismos de redimensionamento de texto ou zoom do navegador. Qualquer texto significativo que a pessoa usuária precise ler deve estar disponível como texto HTML real ou, no mínimo, como texto alternativo acessível.
• Usar elementos SVG <text> com coordenadas absolutas e sem escalonamento por viewBox — texto em SVG pode ser escalonável quando o SVG usa um viewBox e é dimensionado com unidades relativas, mas texto em SVG com atributos fixos x, y, font-size definidos em pixels dentro de um SVG com width e height fixos não redimensiona com o zoom do navegador em todos os navegadores.
• Pressupor que o zoom do navegador lida automaticamente com o critério e pular o teste manual — o zoom do navegador escala a página inteira, incluindo imagens e layout, mas texto que já era pequeno demais, cortado ou sobreposto em 100% se torna um problema ainda maior em 200%. A verificação manual no nível de zoom é sempre necessária.
• Esquecer de testar widgets incorporados de terceiros — widgets de chat, iframes de pagamento, banners de consentimento de cookies e sobreposições de analytics são frequentemente desenvolvidos por terceiros usando tamanhos fixos em px e podem bloquear o zoom. Mesmo que o código seja de terceiros, o critério se aplica à página inteira conforme entregue à pessoa usuária.
• Corrigir o layout de desktop para zoom, mas negligenciar o breakpoint móvel — muitas equipes testam o zoom em desktop e declaram sucesso, mas viewports móveis com zoom de 200% apresentam um conjunto separado de desafios de layout, especialmente para menus de navegação, cabeçalhos fixos e barras de navegação inferiores que dependem de alturas fixas em pixels.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece requisitos obrigatórios de acessibilidade web e móvel para um conjunto definido de organizações que operam na Turquia. A circular faz referência a normas de acessibilidade reconhecidas internacionalmente — alinhando, na prática, os requisitos turcos com a WCAG 2.1 e a WCAG 2.2 Nível AA como referência para conformidade.

WCAG 1.4.4 Redimensionar Texto é um critério de Nível AA, e a conformidade em Nível AA é o limiar exigido para obter o Selo de Acessibilidade (Erişilebilirlik Logosu) emitido pelo Ministério da Família e dos Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı). O Selo de Acessibilidade é ao mesmo tempo um sinal de confiança pública e um ponto de controle regulatório — organizações sujeitas à circular que desejam exibir o selo ou demonstrar conformidade a auditoras e auditores devem satisfazer todos os critérios de Nível AA, incluindo 1.4.4.

As categorias de entidades abrangidas pela Circular Presidencial 2025/10 incluem: instituições e órgãos públicos em todos os níveis de governo; plataformas de e-commerce e marketplaces online; bancos e prestadores de serviços financeiros regulados pela Agência de Regulação e Supervisão Bancária (BDDK); hospitais, centros de saúde e outras organizações de saúde com serviços digitais voltados a pacientes; operadoras de telecomunicações com 200.000 ou mais assinantes; agências de viagem e plataformas de viagem online; empresas privadas de transporte que oferecem serviços digitais de emissão de bilhetes ou reservas; e escolas privadas e instituições de ensino autorizadas pelo Ministério da Educação Nacional (Millî Eğitim Bakanlığı, MoNE).

Para cada um desses tipos de entidade, a implicação prática de 1.4.4 é significativa. O portal de internet banking de um banco que bloqueia o gesto de pinça para zoom em dispositivos móveis não é apenas uma falha de usabilidade — é uma não conformidade regulatória que pode resultar em achados de auditoria ou exclusão do programa do Selo de Acessibilidade. Um sistema de agendamento de consultas de um hospital que usa tamanhos de fonte fixos em pixels dentro de contêineres que cortam conteúdo deixa de atender pacientes com baixa visão e, ao mesmo tempo, falha em suas obrigações sob a circular. A plataforma de matrícula de uma escola privada que incorpora texto em imagens em vez de usar texto HTML escalonável é igualmente não conforme.

As organizações devem tratar a WCAG 1.4.4 não como um item técnico estreito de checklist, mas como uma expectativa básica de respeito às pessoas com deficiências visuais — uma expectativa sobre a qual a legislação turca, as melhores práticas internacionais e a usabilidade básica convergem. O SDK de overlay da Accsible oferece suporte à conformidade com redimensionamento de texto ao fornecer controles configuráveis de escalonamento de fonte que permitem que as pessoas usuárias aumentem o tamanho do texto independentemente do zoom do navegador, oferecendo uma camada adicional de acomodação além dos requisitos básicos que os próprios sites devem implementar.