WCAG 2.5.8: Tamanho do Alvo (Mínimo)

O Que Esta Regra Significa

WCAG 2.5.8 Tamanho do Alvo (Mínimo) é um critério de sucesso de Nível AA introduzido no WCAG 2.2. Ele estabelece que o tamanho do alvo para entradas de ponteiro deve ser de pelo menos 24×24 pixels CSS, com uma exceção importante: se o próprio alvo for menor que 24×24 pixels CSS, então deve haver espaçamento de offset suficiente ao seu redor para que a área total — incluindo o espaçamento — atinja o limite de 24×24 em todas as direções. Em outras palavras, a caixa delimitadora do alvo mais qualquer espaço em branco adjacente que esteja livre de outros alvos deve, em conjunto, alcançar 24 pixels CSS horizontalmente e 24 pixels CSS verticalmente.

O critério se aplica a qualquer elemento que possa receber um evento de ponteiro: links (<a>), botões (<button>), caixas de seleção, botões de opção, controles select, controles deslizantes, widgets personalizados com listeners de eventos de ponteiro e qualquer elemento ao qual seja atribuído um papel ARIA que implique interatividade. Ele não se aplica a elementos não interativos, como imagens decorativas ou texto estático, mesmo que sejam grandes.

Um alvo atende a este critério quando pelo menos uma das seguintes condições é verdadeira:

• O tamanho renderizado do alvo é de pelo menos 24×24 pixels CSS em ambas as dimensões.
• O alvo é menor que 24 pixels CSS em uma ou ambas as dimensões, mas o offset entre a borda do alvo e o elemento interativo adjacente mais próximo é grande o suficiente para que a área combinada alvo-mais-offset seja de pelo menos 24×24 pixels CSS.
• O alvo é um elemento inline dentro de uma frase ou bloco de texto, o que é explicitamente excluído porque o reflow desses alvos prejudicaria a leitura.
• O tamanho visual do alvo é determinado inteiramente pela folha de estilos padrão do user agent do navegador e o autor não o modificou — esta é a exceção de controle nativo.
• Existe uma apresentação não interativa da mesma informação e o alvo pequeno é simplesmente uma alternativa, não o único meio de ativação.

Um alvo falha quando é menor que 24×24 pixels CSS e não há espaçamento de offset suficiente para compensar, e nenhuma das exceções acima se aplica. Falhas comuns no mundo real incluem pequenos botões apenas com ícone (como um ícone de fechar 16×16 em um modal), links de navegação muito próximos com padding mínimo e linhas de ícones de compartilhamento social em que cada ícone é renderizado a 20×20 pixels com apenas 2px de margem entre eles.

Vale notar que WCAG 2.5.8 é um requisito mínimo. O critério AAA relacionado 2.5.5 Tamanho do Alvo (Aprimorado) exige pelo menos 44×44 pixels CSS sem exceção de espaçamento de offset, e muitas diretrizes de usabilidade recomendam 44–48 pixels CSS como um alvo de toque confortável. Atender ao 2.5.8 é o piso, não o teto.

Por Que Isso Importa

Deficiências motoras afetam a precisão do ponteiro de uma grande variedade de maneiras. Pessoas com doença de Parkinson, tremor essencial, paralisia cerebral, esclerose múltipla, hemiplegia relacionada a AVC ou lesões por esforço repetitivo podem ser incapazes de posicionar um ponteiro de forma confiável em um alvo pequeno. Pessoas idosas também experimentam um declínio natural no controle motor fino: aproximadamente 15% das pessoas com mais de 65 anos relatam dificuldade significativa em usar um mouse ou tela sensível ao toque. Além de condições clínicas, até mesmo usuários com limitações situacionais — alguém segurando um smartphone com uma mão em um ônibus em movimento, ou alguém cujo dedo é grande em relação a uma tela de telefone pequena — têm dificuldade com alvos minúsculos.

De acordo com a Organização Mundial da Saúde, mais de 1,3 bilhão de pessoas em todo o mundo vivem com algum tipo de deficiência, e a deficiência motora está entre as categorias mais comuns. Quando elementos interativos são muito pequenos ou muito próximos uns dos outros, esses usuários experimentam ativações acidentais, toques perdidos e erros repetidos que tornam um site efetivamente inutilizável. A frustração é agravada em dispositivos de toque, onde não há estado de hover para confirmar a posição do cursor antes de confirmar um clique.

Considere um cenário concreto: um site de comércio eletrônico turco que vende eletrônicos exibe uma linha de cinco ícones de compartilhamento social no topo de cada página de produto, cada um com 18×18 pixels e 3px de espaço entre eles. Uma mulher com tremor essencial tentando compartilhar um produto no WhatsApp toca repetidamente no ícone errado, acionando compartilhamentos indesejados no Facebook. Não há como ela desfazer esses compartilhamentos rapidamente, e a tarefa se torna tão propensa a erros que ela a abandona completamente. Aumentar cada ícone para 24×24 pixels CSS, ou adicionar padding para que a área clicável atinja 24×24, resolveria o problema sem alterar significativamente o design visual.

Além da acessibilidade, um dimensionamento adequado de alvos se correlaciona com taxas de conversão mais altas, taxas de rejeição mais baixas e melhores pontuações de Core Web Vitals relacionadas à prontidão de interação. A indexação mobile-first pelos mecanismos de busca também favorece páginas que oferecem boa usabilidade de toque, tornando o dimensionamento de alvos um fator que cruza acessibilidade e SEO.

Regras Relacionadas do Axe-core

• target-size (experimental): Esta regra verifica se elementos interativos têm um tamanho renderizado de pelo menos 24×24 pixels CSS ou, para elementos menores, se existe espaçamento de offset suficiente para que a área total alcançável atenda ao limite. A regra consulta as dimensões computadas e os retângulos delimitadores de elementos focáveis e interativos por ponteiro e sinaliza qualquer um que falhe no teste de tamanho-ou-offset. Como atualmente está marcada como experimental, ela não está incluída no conjunto de regras padrão do axe-core e deve ser explicitamente habilitada com runOnly: { type: 'tag', values: ['wcag22aa', 'experimental'] } ou habilitando regras experimentais no axe DevTools. A regra pode produzir falsos positivos para links de texto inline e controles nativos que os navegadores dimensionam de forma diferente entre plataformas, portanto, a revisão manual é sempre recomendada após uma varredura automatizada. Ela não consegue detectar de forma confiável aprovações baseadas em espaçamento quando layouts CSS complexos, transforms ou contextos de empilhamento de z-index sobrepostos estão envolvidos, razão pela qual a inspeção manual de estilos computados no DevTools continua essencial.

Como o tamanho do alvo depende da renderização visual, CSS computado, dimensões da viewport e da proximidade de elementos interativos vizinhos, ferramentas automatizadas podem sinalizar falhas óbvias, mas não podem substituir o julgamento humano. Uma ferramenta pode medir a caixa delimitadora de um botão, mas determinar se o offset entre dois alvos adjacentes está realmente livre de outros elementos interativos — especialmente em interfaces dinâmicas ou acionadas por JavaScript — exige verificação manual.

Como Testar

1. Varredura automatizada com axe DevTools: Instale a extensão de navegador axe DevTools. Abra a página em teste. No painel do axe DevTools, habilite regras experimentais antes de executar a varredura (procure o filtro de tag de regra e adicione experimental). Após a conclusão da varredura, filtre os resultados pelo ID da regra target-size. Para cada elemento sinalizado, observe as dimensões relatadas. Verifique a constatação manualmente antes de registrá-la como falha confirmada, porque regras experimentais têm uma taxa mais alta de falsos positivos.
2. Varredura automatizada com Lighthouse: Execute uma auditoria de acessibilidade do Lighthouse no Chrome DevTools ou via CLI. O Lighthouse inclui uma auditoria de tap-targets que verifica alvos menores que 48×48 pixels CSS com espaçamento insuficiente — observe que isso usa um limite mais rigoroso do que o WCAG 2.5.8, portanto, as falhas do Lighthouse são um superconjunto das falhas do WCAG. Revise os elementos sinalizados no relatório e faça referência cruzada com o limite de 24×24 do WCAG para determinar quais constituem falhas reais de Nível AA versus recomendações de boas práticas.
3. Medição manual com DevTools do navegador: Abra o DevTools e inspecione cada elemento interativo. No painel Computed, verifique width e height. Se qualquer um estiver abaixo de 24px, mude para a visualização Box Model e verifique o padding. Se o padding levar o alvo a 24×24, ele passa. Caso contrário, meça o espaço até o elemento interativo adjacente mais próximo usando o retângulo delimitador do elemento: execute document.querySelector('your-selector').getBoundingClientRect() no console e compare as coordenadas dos elementos vizinhos. Se o espaço combinado em cada dimensão levar a área alcançável efetiva a 24px, ele passa.
4. Simulação de toque: No Chrome DevTools, habilite a emulação de dispositivo e mude para um perfil de dispositivo otimizado para toque. Tente tocar em cada pequeno elemento interativo. Observe quaisquer instâncias em que ativar o elemento pretendido seja difícil ou em que elementos adjacentes sejam acionados acidentalmente.
5. Teste com teclado e leitor de tela (para contexto): Embora o WCAG 2.5.8 seja especificamente um critério de ponteiro, confirmar que alvos pequenos também têm indicadores de foco visíveis e são alcançáveis por teclado ajuda a identificar problemas compostos. Use NVDA com Firefox ou JAWS com Chrome para navegar pelos elementos interativos e confirmar que eles são alcançáveis e ativáveis independentemente do tamanho.
6. Teste em dispositivo real: Teste em um dispositivo móvel físico — idealmente tanto em um Android de tela grande quanto em um dispositivo iOS menor — para confirmar que alvos que passam no desktop também passam em tamanhos de viewport móveis, já que a densidade de pixels CSS e o comportamento de zoom podem afetar o tamanho percebido do alvo.

Como Corrigir

Botão pequeno apenas com ícone — Incorreto

<!-- Close button is only 16x16 CSS pixels, no padding, adjacent to other controls -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    width: 16px;
    height: 16px;
    padding: 0;
    border: none;
    background: none;
    cursor: pointer;
  }
</style>

Botão pequeno apenas com ícone — Correto

<!-- Adding padding increases the interactive area to 24x24 CSS pixels
     while the visual icon remains 16x16. The min-width/min-height
     ensures the target meets the WCAG 2.5.8 threshold. -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    min-width: 24px;
    min-height: 24px;
    padding: 4px;
    border: none;
    background: none;
    cursor: pointer;
    display: inline-flex;
    align-items: center;
    justify-content: center;
  }
</style>

Links de navegação muito próximos — Incorreto

<!-- Each link renders at roughly 20px tall with 1px margin,
     leaving insufficient offset spacing between targets -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list li { margin: 1px 0; }
  .nav-list a { font-size: 12px; line-height: 1.4; display: block; }
</style>

Links de navegação muito próximos — Correto

<!-- Padding on each anchor ensures the target area is at least 24px tall.
     The gap between items is now large enough to satisfy the offset rule
     even if the text itself is smaller than 24px. -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list { list-style: none; padding: 0; margin: 0; }
  .nav-list a {
    display: block;
    padding: 6px 8px; /* vertical padding brings block height to >= 24px */
    font-size: 14px;
    line-height: 1.4;
    text-decoration: none;
  }
</style>

Caixa de seleção com área de clique minúscula — Incorreto

<!-- The default checkbox is visually 13px on many browsers and has no
     associated label providing additional target area -->
<input type='checkbox' id='agree'>
<span>I agree to the terms</span>

Caixa de seleção com label associado — Correto

<!-- Wrapping the input in a <label> makes the entire label text also
     a valid pointer target. The label's line-height and padding ensure
     the combined hit area easily exceeds 24x24 CSS pixels.
     The input itself is given min-width/min-height as a fallback. -->
<label class='checkbox-label'>
  <input type='checkbox' id='agree' class='checkbox-input'>
  I agree to the terms
</label>

<style>
  .checkbox-label {
    display: inline-flex;
    align-items: center;
    gap: 8px;
    padding: 4px 0;
    cursor: pointer;
    min-height: 24px;
  }
  .checkbox-input {
    min-width: 24px;
    min-height: 24px;
    cursor: pointer;
  }
</style>

Linha de ícones de compartilhamento social — Incorreto

<!-- Each icon is 18x18px with only 2px gap; the combined
     reachable area for each icon is only 20px, below the 24px threshold -->
<div class='share-row'>
  <a href='#' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 2px; }
  .share-row a { display: inline-block; line-height: 1; }
</style>

Linha de ícones de compartilhamento social — Correto

<!-- Each anchor now has min-width and min-height of 24px via padding,
     and the gap between anchors is at least 3px so the offset rule is
     satisfied independently even without the padding. -->
<div class='share-row'>
  <a href='#' class='share-link' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' class='share-link' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 6px; }
  .share-link {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: 24px;
    min-height: 24px;
    padding: 3px;
  }
</style>

Erros Comuns

• Definir width e height no ícone dentro de um botão em vez de no próprio botão: Desenvolvedores frequentemente limitam o SVG ou a imagem a 16–20px, mas esquecem que o elemento <button> precisa de min-width: 24px; min-height: 24px e padding apropriado para criar um alvo de toque adequado.
• Remover o padding padrão do navegador de botões e inputs com padding: 0 ou um reset global: Resets de CSS que zeram o padding em elementos de formulário eliminam o buffer que mantém os controles nativos em um tamanho utilizável. Sempre readicione padding explícito após um reset.
• Confiar apenas em line-height para aumentar a altura do link sem display: block ou display: inline-block: Elementos inline não respondem a height ou padding vertical da mesma forma que elementos de bloco, então um link pode parecer visualmente mais alto enquanto sua caixa delimitadora clicável permanece pequena.
• Usar pointer-events: none em um wrapper e anexar handlers de clique a um pequeno elemento interno: Isso anula qualquer padding ou tamanho mínimo aplicado ao wrapper, reduzindo o alvo efetivo ao tamanho renderizado do elemento interno.
• Aplicar overflow: hidden a um contêiner de botão que recorta o padding do botão: A área visual de clique é recortada aos limites do contêiner, tornando o alvo efetivo menor do que as próprias dimensões do botão sugerem.
• Esquecer de levar em conta transforms CSS como scale(): Um botão reduzido visualmente via transform: scale(0.7) ainda tem sua caixa delimitadora original para eventos de ponteiro na maioria dos navegadores, mas esse comportamento é inconsistente e não confiável — sempre dimensione os alvos na sua escala final renderizada.
• Presumir que um <label> grande compensa um <input> minúsculo quando o label e o input não estão associados programaticamente: Se o <label> não usa for correspondendo ao id do input, ou se o input não está envolvido dentro do label, clicar no texto do label não ativa o input, então apenas a pequena área de alvo do próprio input é funcional.
• Não testar nos tamanhos de viewport em que os alvos são realmente renderizados: Um botão que tem 32×32 pixels CSS no desktop pode ser renderizado a 22×22 pixels CSS em uma viewport móvel estreita devido a escalonamento fluido ou unidades relativas à viewport (vw, vmin), criando uma falha que só aparece no mobile.
• Tratar a exceção do WCAG 2.5.8 para links de texto inline de forma muito ampla: A exceção se aplica apenas a links que são genuinamente inline dentro de um trecho de texto (por exemplo, um hyperlink dentro de um parágrafo). Links isolados estilizados para parecer texto — como um link "Esqueceu a senha?" abaixo de um formulário — não são links inline e devem atender ao limite de 24×24.
• Não auditar widgets de terceiros e componentes incorporados: Banners de consentimento de cookies, widgets de chat e overlays de analytics frequentemente incluem pequenos botões (aceitar, fechar, minimizar) injetados por scripts externos. Eles ainda fazem parte da postura de acessibilidade da página e devem cumprir o WCAG 2.5.8, mesmo que o código não seja desenvolvido internamente.

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 de acessibilidade vinculativos para uma ampla gama de prestadores de serviços digitais que operam na Turquia. A Circular faz referência explícita ao WCAG 2.2 como o padrão técnico, e a conformidade de Nível AA é exigida para se qualificar para o Erişilebilirlik Logosu (Logotipo de Acessibilidade) emitido pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı). Como o WCAG 2.5.8 é um critério de Nível AA no WCAG 2.2, ele se enquadra diretamente no escopo deste quadro obrigatório.

Os tipos de entidades abrangidos pela Circular incluem instituições públicas e órgãos governamentais em níveis central e local, bancos e empresas de serviços financeiros, hospitais e prestadores de cuidados de saúde privados, operadoras de telecomunicações com 200.000 ou mais assinantes, plataformas de comércio eletrônico, agências de viagens, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (Milli Eğitim Bakanlığı). Para todas essas organizações, a conformidade com o WCAG 2.5.8 não é apenas uma recomendação de boa prática — é uma obrigação regulatória vinculada à capacidade de exibir o Logotipo de Acessibilidade e de demonstrar conformidade legal durante auditorias.

Em termos práticos, isso significa que a aplicação web responsiva de um banco turco deve garantir que seus botões de confirmação de transferência, campos de entrada de senhas de uso único e controles de navegação atendam todos ao tamanho mínimo de alvo de 24×24 pixels CSS. Da mesma forma, um site de comércio eletrônico deve verificar se seus botões de adicionar ao carrinho, seletores de quantidade e controles de filtro são dimensionados adequadamente em todos os perfis de dispositivo. Portais de saúde devem auditar calendários de marcação de consultas, que são notoriamente conhecidos por células de data pequenas, e ou expandir essas células ou fornecer espaçamento de offset suficiente. Portais de autoatendimento de telecomunicações devem verificar se seus links de gerenciamento de conta e controles de alternância em seletores de planos de dados atendem ao limite.

O não cumprimento da Circular pode resultar em sanções administrativas e pode impedir que uma organização exiba o Logotipo de Acessibilidade, que é cada vez mais usado como um sinal de confiança pelos consumidores turcos. Além das penalidades, a não conformidade expõe as organizações a reclamações apresentadas aos órgãos de supervisão relevantes. Considerando que a Turquia tem uma população crescente de pessoas idosas — o Instituto de Estatística Turco projeta que pessoas com 65 anos ou mais representarão 16,3% da população até 2040 — o impacto prático de alvos pequenos só aumentará com o tempo, tornando a conformidade antecipada tanto uma prioridade ética quanto uma estratégia de negócios sólida a longo prazo.