Critérios de Sucesso WCAG · Level AAA

WCAG 2.4.13: Aparência do Foco

A WCAG 2.4.13 exige que os indicadores de foco do teclado atendam a requisitos mínimos de tamanho e contraste para que os usuários possam ver claramente qual elemento está em foco. Esse critério garante que pessoas que dependem de teclados ou de tecnologias assistivas possam navegar pelas interfaces sem perder a noção de sua posição atual.

O que Esta Regra Significa

WCAG 2.4.13 Focus Appearance é um critério de Nível AAA introduzido no WCAG 2.2 que define requisitos precisos e mensuráveis para a aparência visual dos indicadores de foco de teclado. Enquanto o critério de nível inferior 2.4.11 (Focus Not Obscured, Nível AA) garante que o elemento em foco não esteja totalmente oculto, e 2.4.7 (Focus Visible, Nível AA) exige apenas que exista algum indicador de foco, 2.4.13 vai além ao definir quão visível esse indicador deve ser.

Para atender a este critério, o indicador de foco do teclado deve satisfazer todas as seguintes condições:

  • Área mínima: O indicador de foco deve ter uma área de pelo menos o perímetro do componente sem foco multiplicado por 2 pixels CSS. Em termos práticos, para um botão retangular típico, isso significa que o contorno de foco deve ter uma área igual ou maior que o perímetro do botão vezes 2px — um anel de foco com pelo menos 2px de espessura em toda a borda se qualifica.
  • Taxa de contraste do indicador de foco: Os pixels que formam o indicador de foco devem ter uma taxa de contraste de pelo menos 3:1 entre seus estados com foco e sem foco. Portanto, se um botão tem um fundo branco em seu estado padrão, o anel de foco desenhado ao seu redor deve contrastar pelo menos 3:1 em relação a esse fundo branco.
  • Sem redução de contraste para o conteúdo interno: O indicador de foco não deve reduzir o contraste do texto ou de outro conteúdo dentro do componente em foco para abaixo de 4.5:1 (para texto abaixo de 18pt / 14pt em negrito) ou 3:1 (para texto grande e conteúdo não textual).

Todas as três condições devem ser atendidas simultaneamente para que um componente seja aprovado. Um indicador de foco grande o suficiente, mas com contraste insuficiente, falha. Da mesma forma, um indicador de alto contraste que seja pequeno demais também falha.

A especificação WCAG define uma exceção notável: se o indicador de foco padrão do navegador (o padrão do user-agent) atender aos requisitos, o autor não precisa adicionar um estilo personalizado. No entanto, os padrões dos navegadores variam significativamente — navegadores baseados em Chromium geralmente fornecem um contorno azul, enquanto o Safari pode renderizar um anel que carece de contraste suficiente em certos esquemas de cores. Os autores devem verificar se o indicador padrão atende ao limite ou fornecer um estilo personalizado robusto.

O critério se aplica a todos os componentes interativos e focáveis: links, botões, campos de formulário, menus select, caixas de seleção, botões de opção, componentes de widget personalizados construídos com papéis ARIA e qualquer elemento tornado focável via tabindex. Ele também se aplica a indicadores de foco criados puramente por CSS em pseudo-elementos ou por alterações de classe controladas por JavaScript.

Por Que Isso Importa

A visibilidade do foco é uma pista de navegação crítica para uma ampla gama de usuários. Quando os indicadores de foco são finos, de baixo contraste ou totalmente ausentes, esses usuários perdem sua orientação espacial dentro de uma página — eles não conseguem dizer onde estão ou para onde podem ir em seguida.

Usuários que utilizam apenas teclado — incluindo pessoas com deficiências motoras como tremores, paralisia ou lesões por esforço repetitivo — dependem inteiramente do teclado para navegar. Para esses usuários, um indicador de foco invisível ou quase invisível não é apenas um inconveniente; ele torna toda a interface inutilizável. De acordo com a Organização Mundial da Saúde, aproximadamente 1,3 bilhão de pessoas vivem com algum tipo de deficiência, e deficiências motoras representam uma das maiores categorias entre as pessoas que evitam ou não podem usar um mouse.

Usuários com baixa visão que usam software de ampliação, mas não um leitor de tela completo, também dependem do anel de foco para se orientar. Em níveis de zoom altos, um contorno padrão de 1px pode ser recortado pela janela de visualização ou simplesmente invisível contra um fundo de cor semelhante. Esses usuários frequentemente navegam pelo teclado justamente porque a mira precisa do mouse é difícil em alta ampliação.

Deficiências cognitivas e relacionadas à atenção, como TDAH, transtornos de ansiedade e lesões cerebrais traumáticas, podem dificultar o acompanhamento de informações visuais em uma página. Um indicador de foco altamente visível e claramente diferenciado reduz a carga cognitiva da navegação ao fornecer uma âncora inconfundível para a posição atual do usuário.

Deficiências situacionais também importam: uma pessoa desenvolvedora testando em um laptop com brilho baixo ao ar livre, ou uma pessoa idosa com declínio de sensibilidade ao contraste relacionado à idade, pode ter dificuldade com anéis de foco finos ou de baixo contraste mesmo sem um diagnóstico clínico.

Considere um cenário do mundo real: o formulário online de um banco para transferência de fundos contém dez campos de entrada e quatro botões de ação. Uma pessoa com doença de Parkinson percorre o formulário usando o teclado. Se o indicador de foco for um contorno pontilhado padrão de 1px em cinza claro sobre um fundo branco, a pessoa não consegue acompanhar de forma confiável qual campo está editando no momento. Ela pode enviar acidentalmente uma transferência para a conta errada porque não conseguiu ver que o foco havia passado do campo do destinatário. Um contorno de foco robusto e de alto contraste teria evitado isso completamente.

Além da acessibilidade, um indicador de foco claro é uma melhoria de usabilidade para todos os usuários. Usuários avançados que frequentemente navegam por formulários e menus via teclado — um padrão comum entre desenvolvedores, profissionais de digitação de dados e usuários de leitores de tela — se beneficiam de uma orientação rápida e confiável. Há também um sinal indireto de SEO: sites com forte acessibilidade tendem a ter taxas de rejeição mais baixas e maior conclusão de tarefas, ambos correlacionados com fatores de ranqueamento positivos.

Regras Relacionadas do Axe-core

WCAG 2.4.13 exige testes manuais porque ferramentas automatizadas não conseguem avaliar totalmente o tamanho e o contraste de um indicador de foco em todos os possíveis contextos de renderização de navegador. O axe-core não possui uma única regra automatizada que sinalize falhas de 2.4.13 diretamente. As razões são técnicas:

  • Por que a automação é insuficiente: Calcular a área exata em pixels de um indicador de foco exige simular o foco de teclado em cada elemento interativo, medir a geometria do contorno renderizado (que depende do navegador, SO, nível de zoom e CSS), calcular a taxa de contraste dos pixels do indicador em relação aos seus vizinhos e verificar se nenhum deles viola o requisito de contraste do conteúdo interno. Nenhum mecanismo de acessibilidade automatizado atual executa de forma confiável todas essas etapas em todos os componentes. O axe-core pode sinalizar a ausência de qualquer estilo de foco (relacionado a 2.4.7), mas não pode medir se o estilo que está presente atende aos limites de área e contraste de 2.4.13.
  • Cobertura parcial por meio de regras relacionadas a foco: A regra focus-visible do axe-core verifica se os elementos têm algum indicador de foco visível. Se um elemento tiver outline: none ou outline: 0 sem nenhum indicador visual alternativo, essa regra o sinalizará. No entanto, passar nessa regra não garante conformidade com 2.4.13 — um elemento pode ter um contorno tecnicamente visível que ainda seja fino demais ou com contraste muito baixo.
  • Teste manual é o método autoritativo: Testadores devem inspecionar visualmente cada componente interativo em estado de foco, medir ou estimar as dimensões do contorno e verificar as taxas de contraste usando um analisador de contraste de cores. É por isso que o WCAG lista 2.4.13 como um critério de teste apenas manual para fins do axe-core.

Como Testar

  1. Varredura automatizada (sinal parcial apenas): Execute o axe DevTools ou o Lighthouse na página. Procure por quaisquer falhas relacionadas a focus-visible ou focus-order-semantics. Embora essas não sinalizem diretamente violações de 2.4.13, elas podem revelar elementos em que o estilo de foco foi totalmente suprimido, o que é uma falha prévia. No Chrome DevTools, abra o painel Accessibility e use o modo de inspeção "Tab" para percorrer os elementos focáveis.
  2. Teste visual de navegação por teclado: Desconecte ou deixe de lado o mouse. Pressione Tab para percorrer todos os elementos interativos da página. Para cada elemento em foco, inspecione visualmente o indicador de foco. Pergunte: Há um anel claramente visível ou outro indicador? Ele parece ter pelo menos 2px de espessura? Ele contrasta fortemente com o fundo ao redor? Anote quaisquer elementos em que você hesite ou tenha dificuldade para ver onde está o foco.
  3. Medição de contraste: Use o WebAIM Contrast Checker ou a ferramenta de desktop Colour Contrast Analyser. Com o foco em um componente, faça uma captura de tela. Amostre a cor dos pixels do indicador de foco e a cor do fundo imediatamente adjacente a ele. Verifique se a taxa de contraste é de pelo menos 3:1.
  4. Medição de dimensões: Use as DevTools do navegador (Chrome ou Firefox). Selecione um elemento em foco e inspecione seus estilos computados. Verifique outline-width, outline-offset e qualquer box-shadow usado como anel de foco. Multiplique o perímetro do elemento (2 × largura + 2 × altura) por 2px para calcular a área mínima. Verifique se a área renderizada do indicador atende ou excede esse valor.
  5. Teste com leitor de tela + teclado (NVDA + Firefox): Abra a página no Firefox com o NVDA em execução. Navegue usando Tab e as setas. Confirme se o indicador visual de foco se move em sincronia com o foco anunciado pelo NVDA. Preste atenção especial a widgets personalizados (carrosséis, modais, acordeões) em que o gerenciamento de foco pode ser controlado por JavaScript.
  6. VoiceOver + Safari (macOS/iOS): Ative o VoiceOver com Command + F5. Use Tab para navegar pelos elementos interativos. Verifique se o cursor do VoiceOver (a caixa de contorno preta) não substitui um indicador de foco CSS adequado — a própria página deve fornecer um de forma independente.
  7. Teste em modo de alto contraste: No Windows, ative o modo de Alto Contraste (Configurações → Facilidade de Acesso → Alto Contraste). Recarregue a página e repita o teste de navegação por teclado. Alguns estilos de foco em CSS são substituídos pelo sistema operacional no modo de alto contraste; verifique se ainda aparece um indicador visível. Use a media query CSS forced-colors: active para ajustar estilos condicionalmente, se necessário.

Como Corrigir

Contorno padrão do navegador removido — Incorreto

<!-- Muitas folhas de estilo suprimem globalmente o contorno de foco padrão -->
<style>
  * {
    outline: none; /* Remove TODOS os indicadores de foco em todo o site */
  }
  a:focus, button:focus {
    outline: 0; /* Remoção redundante; nenhuma substituição fornecida */
  }
</style>
<button>Submit Payment</button>

Contorno padrão do navegador removido — Correto

<!-- Remova o padrão apenas ao fornecer um indicador personalizado superior -->
<style>
  /* Suprima o contorno padrão apenas quando :focus-visible se aplicar, então forneça uma substituição forte */
  :focus-visible {
    outline: 3px solid #0057b8; /* 3px garante que o requisito de área seja atendido para elementos típicos */
    outline-offset: 2px;       /* O deslocamento separa o indicador da borda do elemento para maior clareza */
  }
  /* Respeite forced-colors (Alto Contraste do Windows) usando palavras-chave do sistema */
  @media (forced-colors: active) {
    :focus-visible {
      outline: 3px solid ButtonText;
    }
  }
</style>
<button>Submit Payment</button>

Anel de foco de baixo contraste em fundo colorido — Incorreto

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus {
    outline: 2px solid #3399ff; /* Contorno azul claro em fundo azul escuro: taxa de contraste ~1.4:1 — falha */
  }
</style>
<button class='cta-button'>Book Now</button>

Anel de foco de baixo contraste em fundo colorido — Correto

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus-visible {
    /* O contorno branco contrasta fortemente com o botão azul escuro (contraste ~8:1) */
    outline: 3px solid #ffffff;
    outline-offset: 2px;
    /* Uma sombra de caixa escura atrás do anel branco garante contraste contra fundos de página claros */
    box-shadow: 0 0 0 5px #0057b8;
  }
</style>
<button class='cta-button'>Book Now</button>

Widget interativo personalizado baseado em div sem estilo de foco — Incorreto

<style>
  .tab-item { cursor: pointer; padding: 12px 20px; }
  /* Nenhum estilo :focus ou :focus-visible definido para a aba personalizada */
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Widget interativo personalizado baseado em div sem estilo de foco — Correto

<style>
  .tab-item {
    cursor: pointer;
    padding: 12px 20px;
    border-radius: 4px;
  }
  /* Estilo explícito :focus-visible — outline-width 3px com deslocamento atende ao limite de área */
  .tab-item:focus-visible {
    outline: 3px solid #d4550a; /* Contraste 3:1+ em relação ao fundo branco */
    outline-offset: 3px;
  }
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Box-shadow fino usado como indicador de foco — Incorreto

<style>
  .form-input:focus {
    outline: none;
    /* Spread de box-shadow de 1px: provavelmente pequeno demais em área para a maioria dos tamanhos de input */
    box-shadow: 0 0 0 1px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Box-shadow fino usado como indicador de foco — Correto

<style>
  .form-input:focus-visible {
    outline: none;
    /*
      Spread de 3px fornece área suficiente ao redor de um input típico de 300px de largura.
      #005fcc em fundo branco gera contraste de ~5.9:1 — atende tanto 2.4.13 (3:1) quanto 1.4.3 (4.5:1).
    */
    box-shadow: 0 0 0 3px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Erros Comuns

  • Usar outline: none em um reset de CSS sem fornecer qualquer indicador de foco substituto. Muitos resets de CSS populares (versões mais antigas do Normalize.css, resets personalizados) removem contornos de forma abrangente. Sempre associe a remoção a uma substituição :focus-visible que atenda aos requisitos de tamanho e contraste.
  • Fornecer um estilo de foco apenas para :focus mas não para :focus-visible, causando anéis de foco em botões ao clique do mouse que irritam usuários videntes que usam mouse — levando desenvolvedores a removê-los completamente em vez de usar a pseudo-classe correta.
  • Escolher uma cor de anel de foco que corresponda de perto à cor de fundo do componente. Por exemplo, um anel azul claro #99ccff em um fundo branco #ffffff tem uma taxa de contraste de aproximadamente 1.5:1, muito abaixo do exigido 3:1.
  • Usar outline-width: 1px em componentes pequenos, como botões de ícone ou caixas de seleção. Um anel de 1px ao redor de um ícone de 24×24px tem uma área de aproximadamente 96 pixels quadrados, mas a área mínima exigida para um elemento de 24×24 é (24+24+24+24) × 2 = 192 pixels quadrados — exatamente 2px de espessura. Um contorno de 1px falha nesse cálculo.
  • Esquecer de testar a aparência do foco em widgets ARIA personalizados, como role='combobox', role='listbox' ou role='slider'. Esses componentes frequentemente têm foco gerenciado por JavaScript que ignora pseudo-classes CSS nativas, a menos que sejam tratados explicitamente.
  • Aplicar um estilo de foco apenas às tags a e button enquanto negligencia input, select, textarea e qualquer elemento com tabindex='0'.
  • Substituir estilos de foco profundamente em uma biblioteca de componentes ou widget de terceiros sem perceber que a substituição remove o indicador visível. Culpados comuns incluem kits de UI como o Bootstrap 4 (que define box-shadow como um brilho sutil) que podem não atender ao limite de 2.4.13.
  • Não testar a aparência do foco no modo de Alto Contraste do Windows. Algumas técnicas de outline e box-shadow em CSS são renderizadas de forma invisível no modo de Alto Contraste. Use o bloco @media (forced-colors: active) para garantir um fallback visível baseado em cores do sistema.
  • Usar outline-offset com um valor negativo muito grande para mover o contorno para dentro da borda do elemento. Isso pode fazer com que o indicador se sobreponha ao fundo do elemento, reduzindo o contraste efetivo para abaixo de 3:1.
  • Assumir que o indicador de foco em um contêiner pai é suficiente para elementos interativos filhos. Cada elemento focável deve atender ao critério de forma independente; uma linha destacada em uma tabela não satisfaz o requisito para um link em uma célula dentro dessa linha.

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 amplo conjunto de entidades que operam na Turquia. A circular adota o WCAG 2.2 como seu padrão técnico de referência e exige conformidade em Nível AA para as entidades abrangidas. WCAG 2.4.13 Focus Appearance é um critério de Nível AAA e, portanto, não é diretamente exigido pela circular para conformidade padrão.

No entanto, o escopo da circular é amplo. As entidades abrangidas incluem instituições públicas e órgãos governamentais, bancos e prestadores de serviços financeiros, hospitais e organizações de saúde, operadoras 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 (MoNE). Para todas essas organizações, demonstrar conformidade em Nível AAA em critérios aplicáveis — incluindo 2.4.13 — sinaliza um compromisso com acessibilidade de ponta que excede a base legal.

Existem razões práticas e de reputação para que entidades turcas abrangidas implementem voluntariamente 2.4.13. Bancos e prestadores de serviços financeiros, em particular, atendem clientes com deficiências motoras que dependem da navegação por teclado para transações seguras. O portal de internet banking de um banco turco que atenda a 2.4.13 não apenas excede os requisitos regulatórios, mas também reduz o risco de erro do usuário e demonstra responsabilidade social corporativa. Da mesma forma, hospitais e portais de saúde em que pacientes marcam consultas ou acessam prontuários devem garantir que todos os usuários — incluindo pacientes idosos com controle motor fino reduzido ou baixa visão — possam navegar por essas interfaces com confiança.

Operadoras de telecomunicações com grandes bases de assinantes estão entre os serviços digitais de maior tráfego na Turquia. Seus portais de clientes e aplicativos de autoatendimento alcançam milhões de usuários, incluindo uma proporção significativa de pessoas idosas e usuários com deficiência. Implementar voluntariamente 2.4.13 em todas essas plataformas garante acesso equitativo para todos os assinantes e posiciona a operadora de forma favorável em qualquer futuro endurecimento regulatório que possa estender a conformidade obrigatória a critérios AAA.

Para organizações que buscam alcançar conformidade total com WCAG 2.2 AAA — seja por exigências de contratação, exportação para mercados da UE sujeitos ao European Accessibility Act ou políticas internas de acessibilidade — implementar 2.4.13 é um componente necessário. O SDK de overlay da Accsible fornece recursos configuráveis de aprimoramento de foco que podem ajudar organizações a exibir indicadores de foco fortes e conformes em suas interfaces, complementando as correções de CSS em nível de autoria descritas neste artigo.