WCAG 2.1.1: Teclado

O Que Esta Regra Significa

WCAG 2.1.1 (Keyboard) determina que toda funcionalidade em uma página da web ou aplicação deve ser operável usando uma interface de teclado. Isso significa que, se um usuário pode clicar em um botão, arrastar um item, passar o mouse para revelar um menu ou interagir com qualquer outro elemento usando um mouse, ele deve ser capaz de realizar exatamente a mesma ação usando apenas entradas de teclado — normalmente as teclas Tab, Shift+Tab, Enter, Space e as setas.

O critério se aplica a todos os elementos interativos: links, botões, controles de formulário, widgets personalizados, diálogos modais, menus suspensos, acordeões, carrosséis, seletores de data, interfaces de arrastar e soltar, interações baseadas em canvas e qualquer outro componente que responda à entrada do usuário. Se o conteúdo exigir que o usuário execute um traçado de desenho (em que o próprio traçado é a entrada, não apenas o ponto final), essa é a única exceção formalmente reconhecida nas WCAG. Fora dessa exceção restrita, toda outra funcionalidade deve ser acessível por teclado.

Um aprovado significa que um usuário que utiliza apenas o teclado pode alcançar todos os elementos interativos via navegação com Tab ou teclas de seta, ativá-los com Enter ou Space e concluir a ação pretendida sem precisar de um mouse em nenhuma etapa. Uma falha ocorre quando qualquer uma das seguintes situações se aplica: um elemento interativo não recebe foco; o foco é recebido, mas o elemento não pode ser ativado; uma função é acionada exclusivamente por um evento de mouse como onmouseover ou ondblclick sem equivalente de teclado; ou um contêiner rolável não é alcançável por teclado, prendendo o conteúdo dentro dele.

É importante distinguir WCAG 2.1.1 de WCAG 2.1.2 (No Keyboard Trap). O critério 2.1.1 garante que usuários de teclado possam chegar a e usar tudo; o critério 2.1.2 garante que usuários de teclado nunca fiquem presos dentro de um componente. Ambos devem ser atendidos para conformidade completa de Nível A.

Por Que Isso Importa

A acessibilidade por teclado não é uma preocupação de nicho. Estima-se que 1 em cada 4 adultos nos Estados Unidos viva com algum tipo de deficiência, e deficiências motoras — incluindo condições como doença de Parkinson, esclerose múltipla, lesões na medula espinhal, lesão por esforço repetitivo (LER), diferenças de membros e tremores — frequentemente impedem usuários de operar um mouse padrão ou tela sensível ao toque. Esses usuários dependem inteiramente de teclados, controles por interruptor, dispositivos de sopro e sucção, apontadores de cabeça ou outras tecnologias assistivas que, em última instância, emulam a entrada de teclado no nível do sistema operacional.

Pessoas cegas e com baixa visão que dependem de leitores de tela como NVDA, JAWS ou VoiceOver navegam inteiramente via teclado. Se um elemento não for alcançável por teclado, o leitor de tela nunca o anunciará, tornando o conteúdo completamente invisível para esse usuário. De acordo com a Organização Mundial da Saúde, pelo menos 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual de perto ou de longe.

Considere um cenário concreto: uma pessoa com artrite reumatoide avançada em ambas as mãos visita uma página de checkout de e-commerce. O seletor de método de pagamento personalizado do site é implementado como uma série de elementos <div> estilizados que respondem apenas a cliques de mouse. A pessoa pode usar Tab para chegar ao contêiner, mas nenhuma opção individual recebe foco e pressionar Enter não faz nada. Ela não consegue concluir a compra. Isso não é um pequeno inconveniente — é uma exclusão completa de uma transação comercial e representa tanto um risco legal quanto um cenário significativo de perda de receita para o negócio.

Além da deficiência, a acessibilidade por teclado beneficia usuários avançados que preferem atalhos de teclado pela rapidez, usuários em ambientes corporativos ou governamentais onde o uso de mouse é restrito por política e usuários com dispositivos de entrada não padrão. Ela também se correlaciona positivamente com estruturas HTML limpas e semânticas que mecanismos de busca interpretam de forma mais confiável, contribuindo para melhor desempenho de SEO e maior capacidade de manutenção do código a longo prazo.

Regras Relacionadas do Axe-core

• scrollable-region-focusable: Esta regra verifica se qualquer elemento que tenha conteúdo com overflow (ou seja, seja rolável) é alcançável via teclado. Quando um contêiner tem propriedades CSS como overflow: auto ou overflow: scroll, usuários videntes que usam mouse podem rolá-lo com a roda do mouse ou trackpad. Usuários de teclado, porém, devem conseguir usar Tab para entrar no contêiner ou usar as teclas de seta para rolá-lo. A regra sinaliza regiões roláveis que não têm atributo tabindex e nenhum elemento filho naturalmente focável, o que significa que um usuário que utiliza apenas o teclado não teria como acessar o conteúdo que transborda. A detecção automatizada é confiável aqui porque o axe pode inspecionar os estilos computados e a árvore DOM para identificar elementos com overflow rolável que não têm capacidade de foco por teclado.
• server-side-image-map: Esta regra sinaliza o uso de mapas de imagem do lado do servidor — elementos HTML <img> com o atributo ismap. Mapas de imagem do lado do servidor enviam as coordenadas de pixel de um clique de mouse para o servidor para determinar qual link foi ativado. Como a ação depende inteiramente de coordenadas de pixel derivadas de um dispositivo apontador, não existe mecanismo equivalente de teclado. Diferentemente de mapas de imagem do lado do cliente (que usam elementos <map> e <area> e podem ser tornados acessíveis por teclado), mapas de imagem do lado do servidor são fundamentalmente incompatíveis com navegação apenas por teclado. O axe sinaliza qualquer elemento <img ismap> como uma falha de acessibilidade de teclado. A verificação manual deve confirmar se o mapa de imagem é a única forma de acessar a navegação ou funcionalidade subjacente.

É fundamental entender que ferramentas automatizadas como axe-core só conseguem detectar um subconjunto das falhas de acessibilidade de teclado. Muitas violações exigem testes manuais porque envolvem listeners de eventos JavaScript personalizados, gerenciamento dinâmico de foco ou padrões de interação complexos que a análise estática não consegue avaliar completamente. Por exemplo, um botão implementado como um <div> com um listener de evento click pode receber foco via tabindex='0', mas falhar em responder a pressionamentos das teclas Enter ou Space — uma falha que o axe nem sempre consegue detectar sem executar a interação.

Como Testar

1. Varredura automatizada com axe DevTools ou Lighthouse: Instale a extensão de navegador axe DevTools para Chrome ou Firefox. Navegue até a página em teste e execute uma varredura de página inteira. Filtre os resultados para regras marcadas com wcag2a e keyboard. Procure especificamente por violações de scrollable-region-focusable e server-side-image-map. No Lighthouse (Chrome DevTools), execute uma auditoria de Acessibilidade e revise a categoria "Keyboard". Observe que essas ferramentas vão evidenciar falhas estruturais óbvias, mas não detectarão todos os problemas em widgets personalizados.
2. Teste manual de navegação por teclado: Desconecte ou deixe de lado completamente o mouse. A partir da barra de endereços do navegador, pressione Tab repetidamente para avançar por todos os elementos focáveis na página. Pressione Shift+Tab para voltar. Para cada elemento interativo — links, botões, campos de entrada, dropdowns personalizados, modais, sliders — verifique se: (a) ele recebe um indicador de foco visível; (b) pressionar Enter ou Space o ativa como esperado; (c) qualquer diálogo ou painel resultante também pode ser navegado e fechado pelo teclado. Use as teclas de seta dentro de widgets que implementam padrões compostos (menus, listas de abas, grupos de rádio, listboxes).
3. Teste com leitor de tela + teclado usando NVDA e Firefox: Inicie o NVDA (gratuito, Windows) e abra o Firefox. Use o Modo de Navegação do NVDA (teclas de seta) para ler a página e identificar todos os elementos interativos. Alterne para o Modo de Foco (Insert+Space ou automático em campos de formulário) para interagir com os controles. Verifique se widgets personalizados anunciam seu papel, estado e nome, e se toda a funcionalidade pode ser concluída sem mouse. Teste quaisquer contêineres roláveis tentando usar Tab para entrar neles e usar as teclas de seta para rolar.
4. Teste com leitor de tela usando VoiceOver e Safari (macOS/iOS): Ative o VoiceOver (Command+F5 no macOS). Use VO+seta para a direita para navegar linearmente pela página. Use Tab para se mover entre elementos interativos. Confirme se regiões roláveis são alcançáveis e se nenhuma funcionalidade exige gesto de deslizar ou interação por ponteiro sem uma alternativa acessível por teclado.
5. Teste com JAWS e Chrome: Com o JAWS em execução, abra o Chrome e navegue até a página. Use o Cursor Virtual do JAWS para percorrer o conteúdo e a tecla Tab para se mover entre elementos interativos. Teste especificamente quaisquer widgets JavaScript personalizados — acordeões, carrosséis, diálogos modais, caixas de seleção personalizadas — usando Tab para chegar até eles e tentando operá-los completamente via teclado. Registre qualquer elemento que receba foco, mas não possa ser ativado, ou qualquer funcionalidade que só seja alcançável via hover do mouse.
6. Teste específico de regiões roláveis: Identifique todos os contêineres na página com barras de rolagem visíveis ou que contenham mais conteúdo do que sua área visível. Tente usar Tab para entrar em cada contêiner. Se Tab não mover o foco para dentro do contêiner e não houver elementos filhos focáveis, o contêiner provavelmente é uma falha de acessibilidade de teclado. Tente pressionar as teclas de seta enquanto o contêiner ou um elemento próximo estiver com foco para ver se a rolagem é possível.

Como Corrigir

Cenário 1: Contêiner Rolável — Incorreto

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Cenário 1: Contêiner Rolável — Correto

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Cenário 2: Mapa de Imagem do Lado do Servidor — Incorreto

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

Cenário 2: Mapa de Imagem do Lado do Servidor — Correto

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

Cenário 3: Widget Personalizado Usando Apenas Eventos de Mouse — Incorreto

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

Cenário 3: Widget Personalizado Usando Apenas Eventos de Mouse — Correto

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

Cenário 4: Menu Dropdown Somente em Hover — Incorreto

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Cenário 4: Menu Dropdown Somente em Hover — Correto

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Erros Comuns

• Usar onclick como único manipulador de evento em um elemento não nativo sem adicionar um manipulador correspondente onkeydown ou onkeyup — cliques de mouse acionam onclick, mas a ativação por teclado em um <div> ou <span> não.
• Adicionar tabindex='0' a um elemento interativo personalizado, mas esquecer de adicionar role='button' (ou papel apropriado), o que significa que leitores de tela não comunicam a finalidade do elemento ao usuário.
• Construir navegação em dropdown que depende exclusivamente da pseudo-classe CSS :hover sem um toggle de teclado acionado por JavaScript, tornando submenus invisíveis e inalcançáveis para usuários de teclado.
• Implementar interfaces de arrastar e soltar — listas ordenáveis, quadros kanban, áreas de upload de arquivos — sem um mecanismo alternativo acessível por teclado, como comandos de movimentação acionados por teclado ou um controle separado de reordenação.
• Criar contêineres roláveis (como caixas de termos de serviço, janelas de chat ou tabelas de dados dentro de wrappers de altura fixa) sem tabindex='0', impedindo usuários de teclado de rolar para ver todo o conteúdo.
• Usar <img ismap> para componentes de navegação herdados de bases de código legadas sem substituí-los por mapas de imagem do lado do cliente ou links de navegação padrão.
• Aplicar tabindex='-1' a elementos interativos para removê-los da ordem natural de Tab sem fornecer uma estratégia programática de gerenciamento de foco, resultando em controles permanentemente inalcançáveis por teclado.
• Acionar funcionalidade exclusivamente em eventos mouseenter, mouseleave ou mousemove (tooltips, pré-visualizações, menus de contexto) sem alternativas equivalentes de eventos focus, blur ou de teclado.
• Pressupor que um diálogo modal gerencia o foco automaticamente — falhando em mover o foco para dentro do diálogo quando ele é aberto e falhando em devolver o foco ao elemento acionador quando ele é fechado, deixando usuários de teclado desorientados na página.
• Definir pointer-events: none em CSS em um elemento que deveria ser acessível por teclado, o que, embora não afete diretamente o comportamento do teclado, costuma ser combinado com padrões de JavaScript que também bloqueiam a interação por teclado.

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 na web alinhados com WCAG 2.1 Nível AA. WCAG 2.1.1 (Keyboard) é um critério de Nível A, o que o coloca na camada de mais alta prioridade de conformidade exigida. A conformidade de Nível A é o mínimo absoluto — se um site falha em critérios de Nível A, ele é considerado não acessível, independentemente de quaisquer outras melhorias realizadas.

De acordo com a circular, os prazos de conformidade são diferenciados por tipo de entidade: instituições públicas e órgãos governamentais devem alcançar conformidade dentro de um ano a partir da data de publicação da circular, enquanto entidades do setor privado abrangidas pela regulamentação têm dois anos para se adequar.

As entidades abrangidas pela Circular Presidencial 2025/10 incluem uma ampla seção dos serviços digitais turcos: plataformas de e-commerce, instituições públicas e ministérios, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200,000 ou mais assinantes, agências de viagem licenciadas, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE).

Para todas essas entidades, não satisfazer WCAG 2.1.1 significa que usuários dependentes de teclado — incluindo cidadãos com deficiências motoras, pessoas idosas e usuários de leitores de tela — não conseguem acessar seus serviços digitais centrais. Isso é uma violação regulatória direta. Em termos práticos, um site de e-commerce em que o fluxo de checkout não pode ser concluído por teclado, ou um portal de pacientes de hospital em que o agendamento de consultas exige interação com mouse, estaria em descumprimento dos requisitos da circular.

Organizações sujeitas à circular devem realizar uma auditoria de acessibilidade por teclado como primeiro passo em seu programa de correção de acessibilidade. Como falhas de WCAG 2.1.1 são frequentemente arquiteturais — enraizadas na escolha de elementos HTML, padrões de vinculação de eventos e padrões de componentes de frameworks — corrigi-las pode exigir mudanças em nível de código, e não apenas ajustes de configuração. O SDK de overlay da Accsible pode ajudar a evidenciar e corrigir lacunas comuns de acessibilidade de teclado na camada de JavaScript, mas as equipes também devem buscar correções estruturais em seu código-fonte para alcançar uma conformidade robusta e auditável que satisfaça a revisão regulatória.