WCAG 2.5.5: Tamanho do Alvo (Aprimorado)

O Que Esta Regra Significa

WCAG 2.5.5 Target Size (Enhanced) é um critério de Nível AAA sob a WCAG 2.2 que define um tamanho mínimo rigoroso para elementos interativos. Especificamente, exige que o tamanho do alvo — a área clicável ou tocável de qualquer componente da interface do usuário — seja de pelo menos 44 por 44 pixels CSS em largura e altura. Isso se aplica a todas as interações baseadas em ponteiro, incluindo cliques de mouse, toques em tela sensível ao toque e entrada por caneta.

É importante entender o que exatamente constitui o "alvo" neste contexto. O alvo é toda a área ativável do controle, não apenas sua representação visual. Um ícone pequeno pode ter visualmente 16×16 pixels, mas se o espaçamento ao redor expandir a região clicável para 44×44 pixels, o critério ainda pode ser atendido. Isso significa que desenvolvedores podem usar padding de forma estratégica para cumprir o requisito sem alterar dramaticamente o design visual.

O critério define um aprovado como qualquer elemento interativo cuja área de alvo meça pelo menos 44×44 pixels CSS. Uma falha ocorre quando a área ativável de um elemento interativo fica abaixo desse limite em qualquer dimensão — por exemplo, um link que tenha 44 pixels de largura, mas apenas 20 pixels de altura ainda falharia.

A WCAG 2.5.5 fornece várias exceções oficiais em que o requisito de 44×44 não se aplica. São elas:

• Espaçamento: Alvos subdimensionados são aceitáveis se houver espaçamento de afastamento suficiente separando-os de todos os outros alvos. O alvo deve ser posicionado de forma que, se um círculo de 44×44 pixels CSS fosse centralizado nele, esse círculo não interceptaria nenhum outro alvo nem a caixa delimitadora do círculo de 44×44 de qualquer outro alvo. Essa exceção impede que a regra exija mudanças de layout quando controles adjacentes são inerentemente pequenos, mas bem separados.
• Equivalente: Um controle alternativo na mesma página executa a mesma função e atende ao requisito de tamanho mínimo.
• Em linha: O alvo está em uma frase ou seu tamanho é de outra forma limitado pela altura da linha do texto que não é alvo. Hiperlinks dentro de um parágrafo de texto corrido, por exemplo, são isentos porque redimensioná-los interromperia o fluxo do texto.
• Controle do agente do usuário: O tamanho é determinado inteiramente pelo navegador ou sistema operacional e não pode ser alterado pelo autor. Controles de formulário nativos do navegador em seu estado sem estilo podem se enquadrar nessa categoria.
• Essencial: Uma apresentação específica do alvo é essencial para a informação que está sendo transmitida. Esta é uma exceção restrita para casos em que alterar o tamanho do alvo mudaria fundamentalmente o significado ou a funcionalidade.

Este critério foi introduzido na WCAG 2.2 e substitui a orientação anterior, menos rigorosa, sobre alvos de ponteiro. Seu critério complementar, WCAG 2.5.8 Target Size (Minimum) no Nível AA, define um patamar mais baixo de 24×24 pixels CSS com um cálculo baseado em espaçamento, mas o 2.5.5 continua sendo o padrão ouro para acessibilidade aprimorada.

Por Que Isso Importa

Deficiências motoras e de destreza afetam uma parcela substancial da população global. De acordo com a Organização Mundial da Saúde, aproximadamente 1,3 bilhão de pessoas — ou 16% da população mundial — vivem com algum tipo de deficiência significativa, sendo as condições motoras e musculoesqueléticas algumas das mais prevalentes. Condições como doença de Parkinson, tremor essencial, paralisia cerebral, esclerose múltipla, hemiplegia relacionada a AVC e lesões por esforço repetitivo reduzem a capacidade de uma pessoa de realizar movimentos precisos com o ponteiro. Em dispositivos móveis, mesmo usuários sem deficiências podem ter dificuldades com alvos pequenos ao usar luvas, quando suas mãos estão molhadas ou simplesmente ao usar o telefone com uma só mão.

Considere um cenário concreto do mundo real: uma pessoa com artrite reumatoide está navegando em uma plataforma de e-commerce turca em um tablet com tela sensível ao toque para comprar medicamentos. O fluxo de checkout inclui pequenos botões de opção (radio buttons), menus suspensos estreitos e um botão "Confirmar Pedido" de 24×18 pixels. Cada toque errado seleciona a opção errada ou não faz nada, forçando o usuário a tentar várias vezes. A frustração não é apenas inconveniente — pode levá-lo a abandonar a compra completamente, transformando uma falha de acessibilidade em perda direta de receita para o negócio.

Além das deficiências motoras, alvos com tamanho adequado beneficiam uma ampla gama de usuários. Pessoas idosas comumente apresentam redução do controle motor fino e acuidade visual diminuída simultaneamente, tornando alvos pequenos duplamente difíceis. Usuários com deficiências cognitivas podem levar mais tempo para posicionar um ponteiro e têm maior probabilidade de acionar controles adjacentes se os alvos estiverem muito próximos. Mesmo usuários videntes e sem deficiências se beneficiam de alvos maiores em dispositivos móveis — uma verdade que tem orientado convenções de design em grandes empresas de tecnologia há anos. As Human Interface Guidelines da Apple recomendam um alvo mínimo de toque de 44×44 pontos, e as diretrizes do Material Design do Google recomendam pelo menos 48×48 pixels independentes de densidade pelos mesmos motivos.

Do ponto de vista de SEO e usabilidade, a métrica "Interaction to Next Paint" (INP) do Core Web Vitals do Google recompensa interfaces em que as interações do usuário são registradas de forma rápida e correta. Toques errados causados por alvos subdimensionados aumentam as taxas de falha de interação, aumentam o tempo na tarefa e elevam as taxas de rejeição — todos sinais que podem afetar indiretamente o ranqueamento em buscas. Melhorias de acessibilidade no nível do ponteiro, portanto, têm consequências de negócio mensuráveis além da conformidade.

Regras Relacionadas do Axe-core

A WCAG 2.5.5 exige testes manuais. Não há uma regra totalmente automatizada no axe-core que sinalize de forma confiável todas as violações de tamanho de alvo para este critério aprimorado. A razão pela qual ferramentas automatizadas têm dificuldade aqui é multifacetada: o tamanho efetivo do alvo depende do layout CSS computado, incluindo padding, margin e dimensões de pseudo-elementos que variam por viewport, proporção de pixels do dispositivo e renderização dinâmica. Além disso, a exceção de espaçamento exige o cálculo do afastamento geométrico entre alvos adjacentes — um cálculo que requer toda a árvore de layout renderizada e uma análise de proximidade que ferramentas automatizadas de parsing do DOM não conseguem executar com precisão em todos os casos. Ademais, determinar se um elemento se qualifica para a exceção "em linha" ou "equivalente" exige entendimento semântico e contextual que está além das capacidades de mecanismos de regras automatizadas.

• target-size (axe-core experimental): O axe-core inclui uma regra experimental chamada target-size que verifica elementos interativos em relação ao limite de Nível AA da WCAG 2.5.8 de 24×24 pixels CSS com afastamentos de espaçamento. Embora essa regra possa revelar algumas violações menores, ela não aplica o limite mais rigoroso de 44×44 exigido pelo 2.5.5 e pode deixar de detectar violações em que padding ou pseudo-elementos afetam a área de clique renderizada de maneiras que o snapshot do DOM não captura. Trate quaisquer resultados dessa regra como um ponto de partida, não como uma auditoria completa.
• Inspeção visual manual: Como nenhuma regra automatizada cobre totalmente o 2.5.5, testadores devem inspecionar visualmente e medir alvos interativos usando as ferramentas de desenvolvedor do navegador, réguas de pixels CSS ou extensões de navegador de acessibilidade. Isso inclui verificar se o padding está incluído na área de clique e se as exceções de espaçamento são realmente atendidas — não apenas presumidas.

Como Testar

1. Execute uma varredura automatizada como linha de base: Abra o axe DevTools ou o Lighthouse nas DevTools do Chrome na página em teste. No axe DevTools, filtre os resultados por "target-size" se disponível sob regras experimentais. Observe quaisquer elementos sinalizados, mas entenda que essa varredura não detectará todas as violações do 2.5.5 e pode referenciar o limite 2.5.8 em vez de 44×44 pixels. Use a auditoria de acessibilidade do Lighthouse para procurar avisos relacionados a alvos de ponteiro.
2. Meça os tamanhos dos alvos com as DevTools do navegador: Abra as DevTools do Chrome ou Firefox e use o painel Elements para inspecionar cada elemento interativo — botões, links, campos de formulário, caixas de seleção, botões de opção, controles personalizados e controles apenas com ícone. No painel de estilos Computed, verifique a largura e a altura renderizadas. Lembre-se de que o padding é incluído no alvo de clique para elementos de nível de bloco, mas pode não ser para elementos em linha. Verifique se a área de clique computada é de pelo menos 44×44 pixels CSS.
3. Use as ferramentas de acessibilidade integradas do navegador: Nas DevTools do Chrome, abra a aba Rendering e ative "Emulate a focused page" ou use a Accessibility Tree para inspecionar elementos. No Firefox, use o Accessibility Inspector para identificar elementos interativos e cruzar suas dimensões de caixa delimitadora.
4. Teste em dispositivos touch reais: Conecte um dispositivo físico iOS e teste com o VoiceOver ativado (pressione o botão lateral três vezes para ativar). Navegue tocando e use o rotor para se mover entre elementos interativos. Tente ativar alvos pequenos e observe com que frequência elementos adjacentes são acionados acidentalmente. Repita em um dispositivo Android usando o TalkBack (deslize para a direita para navegar, toque duas vezes para ativar). Preste atenção especial a widgets personalizados construídos a partir de elementos <div> ou <span>.
5. Teste manualmente as exceções de espaçamento: Para qualquer alvo menor que 44×44 pixels que alegue a exceção de espaçamento, desenhe uma caixa delimitadora imaginária de 44×44 pixels centralizada nesse alvo e confirme visualmente que nenhum outro elemento interativo cai dentro dessa caixa. Extensões de navegador ou ferramentas de sobreposição que desenham caixas delimitadoras podem ajudar aqui.
6. Verificação com teclado e leitor de tela: Teste com NVDA + Firefox e JAWS + Chrome, percorrendo todos os elementos interativos com a tecla Tab. Embora o foco do teclado não teste diretamente o tamanho do alvo de ponteiro, ele ajuda a identificar se todos os controles são alcançáveis e confirma o inventário de elementos com o qual você irá cruzar os tamanhos de ponteiro. O VoiceOver + Safari no macOS pode ser usado para verificar se controles personalizados se anunciam corretamente e têm áreas de ativação adequadas quando clicados com o ponteiro.
7. Teste em múltiplos tamanhos de viewport: Os tamanhos dos alvos podem variar entre layouts de desktop e mobile. Teste em larguras de viewport de 320px, 768px e 1280px para confirmar que designs responsivos mantêm o mínimo de 44×44 em todos os breakpoints, particularmente em menus hambúrguer, carrosséis e colunas de ações em tabelas de dados.

Como Corrigir

Botão apenas com ícone com tamanho insuficiente — Incorreto

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

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

Botão apenas com ícone com tamanho insuficiente — Correto

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Caixa de seleção personalizada construída a partir de uma div — Incorreto

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

Caixa de seleção personalizada construída a partir de uma div — Correto

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Links de navegação em uma barra de ferramentas com espaçamento apertado — Incorreto

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Links de navegação em uma barra de ferramentas com espaçamento apertado — Correto

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Erros Comuns

• Presumir que a caixa delimitadora visual é igual à área de clique: Definir width: 44px; height: 44px na imagem do ícone dentro de um botão não torna o botão 44×44 — apenas adicionar essas dimensões ou padding equivalente ao próprio elemento <button> cria a área de clique correta.
• Usar padding: 0 para redefinir estilos do navegador sem um tamanho mínimo compensatório: Resets de CSS frequentemente removem todo o padding de botões e campos de entrada. Após um reset, sempre reaplique padding suficiente ou valores explícitos de min-width e min-height para restaurar a área de ativação.
• Confiar apenas em line-height para aumentar a altura do alvo: Aumentar o line-height afeta o espaçamento do texto, mas nem sempre expande a área clicável de um link ou botão. Use padding-top e padding-bottom em vez disso.
• Colocar vários pequenos botões de ícone lado a lado sem espaçamento suficiente: Uma fileira de ícones de compartilhamento em redes sociais de 24×24 com apenas 2px de margem falha tanto no requisito de tamanho quanto na exceção de espaçamento, já que os círculos de 44px centralizados em cada ícone se sobreporiam aos vizinhos.
• Aplicar incorretamente a exceção de texto em linha a links de navegação: A exceção se aplica a links dentro de uma frase ou parágrafo de texto corrido. Menus de navegação, barras de ferramentas e listas de links não são texto em linha e não se qualificam para essa exceção, mesmo que usem display: inline.
• Criar controles personalizados com role='button' em um <span> e esquecer de dimensionar o span: Leitores de tela anunciarão o span como um botão, mas seu tamanho renderizado padrão será determinado apenas pelo conteúdo de texto, que normalmente fica muito abaixo de 44×44 pixels. Sempre adicione display: inline-flex, min-width, min-height e padding.
• Não testar em dispositivos touch reais no tamanho real de viewport: Medir pixels nas DevTools de desktop não é suficiente. A densidade de pixels CSS e o comportamento de detecção de toque em nível de sistema operacional podem diferir entre ambientes simulados e dispositivos físicos.
• Ignorar controles renderizados dinamicamente: Tooltips, células de dias em datepickers, itens de sugestão em autocomplete e botões de fechar em modais são frequentemente injetados por bibliotecas JavaScript com tamanhos pequenos codificados. Audite a saída de widgets de terceiros e sobrescreva seus estilos se necessário.
• Alegar a exceção de espaçamento sem medi-la: A exceção de espaçamento é geométrica e precisa. Presumir visualmente que os controles parecem suficientemente afastados não é suficiente — o teste do círculo de 44px deve ser aplicado a cada alvo subdimensionado para confirmar que não há sobreposição.
• Esquecer de verificar após mudanças de breakpoint responsivo: Um botão que é 44×44 no desktop pode encolher para 30×30 em um viewport mobile de 375px devido a larguras em porcentagem ou encolhimento por flexbox. Sempre reteste os tamanhos dos alvos em cada breakpoint principal.

Relação com as Regulamentações de Acessibilidade da Turquia

O Decreto Presidencial nº 2025/10 da Turquia, publicado no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece requisitos obrigatórios de acessibilidade web e mobile com base no padrão WCAG 2.2. O decreto se aplica a um conjunto definido de entidades que operam na Turquia e estabelece obrigações legais de conformidade com níveis específicos da WCAG.

Os tipos de entidades abrangidas pelo decreto incluem: instituições e órgãos públicos em nível de governo central e local; bancos e instituições financeiras regulados pela Banking Regulation and Supervision Agency (BDDK); hospitais e prestadores de serviços de saúde, tanto públicos quanto privados; operadoras de telecomunicações com 200.000 ou mais assinantes; plataformas de e-commerce acima de limites especificados de receita ou transações; agências de viagem que operam serviços de reserva online; empresas de transporte privado que oferecem emissão de bilhetes ou reserva digital; e escolas privadas e instituições de ensino autorizadas pelo Ministry of National Education (MoNE).

WCAG 2.5.5 Target Size (Enhanced) é um critério de Nível AAA e não está entre os requisitos mínimos obrigatórios estabelecidos pelo decreto, que se concentra principalmente na conformidade com os Níveis A e AA. No entanto, o decreto incentiva explicitamente as entidades abrangidas — particularmente aquelas que atendem ao público, pacientes de saúde e estudantes — a buscar a conformidade AAA sempre que viável, reconhecendo que ela representa a prática de acessibilidade de melhor nível.

Para organizações na Turquia, implementar a WCAG 2.5.5 tem valor estratégico particular em vários contextos. Portais governamentais que atendem cidadãos idosos, sistemas de agendamento de saúde usados por pacientes com condições crônicas e aplicativos bancários acessados por pessoas com deficiências motoras se beneficiam substancialmente de tamanhos de alvo de 44×44 pixels. A Turquia tem uma população que envelhece rapidamente, e o Turkish Statistical Institute (TÜİK) projeta que cidadãos com 65 anos ou mais constituirão mais de 16% da população até 2040 — um grupo demográfico para o qual o tamanho do alvo de ponteiro é um fator crítico de usabilidade.

Mesmo quando o Nível AAA não é legalmente obrigatório, organizações que voluntariamente atendem à WCAG 2.5.5 demonstram um compromisso que pode reduzir o risco de litígios, fortalecer a elegibilidade em licitações públicas que exigem documentação de acessibilidade e melhorar métricas de satisfação do usuário em mercados competitivos como e-commerce e fintech. O SDK da Accsible fornece recursos configuráveis de aprimoramento de alvos de toque que podem ajudar organizações a cumprir ou se aproximar desse critério, e a documentação desses esforços pode compor parte de um Accessibility Conformance Report (ACR) ou submissão de VPAT exigida por processos de compras institucionais.