WCAG 2.1.3: Teclado (Sem Exceção)

O Que Esta Regra Significa

WCAG 2.1.3 — Teclado (Sem Exceção) é um critério de sucesso de Nível AAA sob as WCAG 2.1 e 2.2 que estende a WCAG 2.1.1 (Teclado, Nível A) ao remover todas as exceções. Especificamente, afirma: Toda a funcionalidade do conteúdo é operável por meio de uma interface de teclado sem exigir tempos específicos para pressionamentos individuais de teclas. A distinção crítica em relação a 2.1.1 é a ausência da cláusula de exceção que isenta funcionalidades em que a função subjacente exige uma entrada que depende do trajeto do movimento do usuário, não apenas dos pontos finais.

De acordo com 2.1.1, desenvolvedores podem legitimamente excluir de suporte por teclado recursos como telas de desenho à mão livre, ferramentas de pintura baseadas em gestos ou interfaces de arrastar sensíveis ao trajeto, porque o trajeto exato do ponteiro do usuário determina o resultado. A WCAG 2.1.3 elimina completamente essa exceção. Sob este critério, toda e qualquer função—incluindo desenho, arrastar, gestos dependentes de trajeto e qualquer interação que historicamente tenha dependido de movimento do ponteiro—deve ser acessível por teclado. Isso significa que os desenvolvedores devem fornecer mecanismos alternativos de teclado (por exemplo, uma barra de ferramentas acessível com ferramentas de formas, modos de desenho controlados por teclado ou alternativas de entrada baseadas em formulários) mesmo para tarefas à mão livre ou dependentes de trajeto.

Uma aprovação exige que toda operação na página possa ser iniciada, navegada e concluída usando apenas o teclado. Isso inclui gerenciamento de foco, diálogos modais, reordenação por arrastar e soltar, controles deslizantes personalizados, ferramentas de desenho em canvas, interações com mapas, navegação em carrosséis e controles de reprodução de vídeo. Não deve haver armadilha de teclado (também coberta por 2.1.2), nenhuma função que só possa ser acionada por clique, hover ou gestos baseados em toque sem um caminho equivalente por teclado, e nenhuma dependência de trajetos do ponteiro do mouse.

Uma falha ocorre quando qualquer funcionalidade—independentemente de quão específica ou secundária possa parecer—não pode ser alcançada ou concluída apenas por teclado. Como este critério não tem exceções, mesmo uma única função não acessível por teclado constitui uma falha completa, tornando-o um dos padrões mais exigentes nas WCAG.

Por Que Isso Importa

A acessibilidade por teclado é fundamental para pessoas com deficiências motoras que não podem usar um dispositivo apontador. Pessoas com condições como doença de Parkinson, tetraplegia, paralisia cerebral, lesões por esforço repetitivo ou diferenças de membros muitas vezes dependem exclusivamente de um teclado físico, um dispositivo de varredura, um controlador de sopro e sucção ou tecnologia de rastreamento ocular que emula a entrada de teclado. De acordo com a Organização Mundial da Saúde, aproximadamente 1,3 bilhão de pessoas no mundo vivem com algum tipo de deficiência significativa, e deficiências motoras ou físicas representam uma parcela substancial dessa população. Só na Turquia, dados do Instituto de Estatística da Turquia (TÜİK) indicam que mais de 8,5 milhões de pessoas relatam pelo menos uma forma de limitação funcional.

Além da deficiência motora, a acessibilidade por teclado beneficia pessoas cegas e com baixa visão que navegam com leitores de tela como NVDA, JAWS ou VoiceOver—todos os quais dependem de comandos de teclado para percorrer e interagir com conteúdo web. Pessoas com condições fotossensíveis podem evitar telas sensíveis ao toque, e pessoas com deficiências cognitivas muitas vezes se beneficiam da navegação previsível e linear que a interação por teclado proporciona.

Considere um cenário concreto do mundo real: uma plataforma de design gráfico que oferece uma ferramenta de desenho vetorial à mão livre. Sob a WCAG 2.1.1, isso poderia ser isento porque o trajeto do ponteiro define a forma. Sob a WCAG 2.1.3, a plataforma deve fornecer uma alternativa—talvez uma biblioteca de formas, uma série de pontos de ancoragem controlados por teclado ou um editor de caminhos SVG baseado em texto—para que uma pessoa com deficiência motora ainda possa criar arte vetorial sem um mouse. Deixar de fazer isso exclui um segmento significativo de profissionais criativos que dependem de acesso apenas por teclado.

Do ponto de vista de usabilidade e SEO, interfaces devidamente acessíveis por teclado normalmente apresentam um gerenciamento de foco mais limpo, uma ordem de tabulação mais lógica e hierarquias de DOM bem estruturadas—tudo isso contribui para melhor rastreabilidade e uma experiência de usuário de maior qualidade para todos, incluindo usuários avançados que preferem atalhos de teclado pela rapidez.

Regras Relacionadas do Axe-core

WCAG 2.1.3 exige testes manuais. Ao contrário de muitos critérios das WCAG, ferramentas automatizadas não conseguem detectar de forma confiável violações deste critério porque:

• A detecção de funcionalidade dependente de trajeto está além da análise estática: Axe-core e Lighthouse inspecionam o DOM em busca de padrões estruturais—tabindex ausente, atributos role ausentes ou gerenciamento de foco quebrado—mas não conseguem simular uma pessoa tentando cada função em uma página e determinar se existe uma alternativa por teclado. Um elemento canvas pode estar presente no DOM sem atributos ARIA, mas uma barra de ferramentas acessível por teclado nas proximidades pode satisfazer totalmente a 2.1.3. Por outro lado, um botão aparentemente normal pode acionar uma ação JavaScript que, por sua vez, lança um widget apenas para mouse, que ferramentas automatizadas nunca sinalizariam. A equivalência lógica de alternativas de teclado a trajetos dirigidos por mouse exige julgamento humano.
• Não há regra dedicada do axe-core que mapeie para 2.1.3: As regras do axe mais próximas—como scrollable-region-focusable (que verifica se regiões de conteúdo roláveis podem receber foco de teclado) e tabindex (que sinaliza valores positivos de tabindex que prejudicam a ordem natural de foco)—tratam de preocupações relacionadas, porém mais estreitas, sob 2.1.1 e 2.4.3. Elas não avaliam e não podem avaliar se toda funcionalidade, incluindo operações sensíveis a trajeto, tem um equivalente por teclado.
• Auditorias de widgets interativos exigem interação em tempo de execução: Componentes personalizados de arrastar e soltar, editores baseados em canvas e carrosséis dirigidos por gestos só revelam sua inacessibilidade por teclado quando uma pessoa avaliadora realmente tenta usá-los sem mouse. A varredura estática do DOM pelo axe-core não pode acionar listeners de eventos, observar perda de foco durante operações assíncronas ou avaliar se uma operação de arrastar pode ser concluída por meio de teclas de seta e Enter/Barra de Espaço.
• O que observar durante a auditoria manual: Pessoas testadoras devem procurar especificamente elementos canvas usados para desenho ou interação, listas de arrastar e soltar ou áreas de upload de arquivos, controles personalizados de mapas ou visualizações de dados, controles deslizantes baseados em tempo e qualquer componente que responda a eventos mousemove, pointermove ou gestos de toque sem handlers de eventos de teclado correspondentes.

Como Testar

1. Execute uma varredura automatizada de linha de base: Use axe DevTools (extensão de navegador ou CLI) ou Google Lighthouse na sua página para identificar falhas de acessibilidade por teclado mais óbvias—elementos sem foco, armadilhas de teclado ou elementos com pointer-events: none que deveriam ser interativos. Embora essas ferramentas não detectem violações de 2.1.3 diretamente, elas revelam problemas relacionados e estabelecem uma linha de base limpa antes do início dos testes manuais.
2. Catalogar toda a funcionalidade interativa: Antes de testar, crie um inventário completo de cada componente interativo na página: botões, links, formulários, modais, acordeões, carrosséis, mapas, ferramentas de canvas, áreas de arrastar e soltar, dropdowns personalizados, seletores de data, players de vídeo e qualquer widget que responda a eventos de mouse ou toque. Esse inventário se torna sua lista de verificação de testes.
3. Teste de navegação apenas por teclado: Desconecte ou desative seu mouse. Use Tab e Shift+Tab para mover o foco, Enter e Barra de Espaço para ativar controles, teclas de seta para widgets compostos (menus, controles deslizantes, abas, grupos de rádio) e Escape para fechar diálogos. Tente concluir cada função da sua lista de inventário. Anote qualquer função que você não consiga iniciar, concluir ou sair usando apenas o teclado.
4. Teste com leitor de tela usando NVDA + Firefox: Inicie o NVDA (Windows) com Firefox. Navegue usando o cursor virtual (H para títulos, B para botões, F para campos de formulário, Tab para elementos interativos). Tente cada função. Ouça o papel (role), nome e estado anunciados. Identifique qualquer região interativa que seja inalcançável ou que não produza anúncio audível.
5. Teste com leitor de tela usando JAWS + Chrome: Use JAWS no Windows com Chrome. Use o cursor virtual do JAWS e o Modo de Formulários (alternar com Enter). Verifique se toda a funcionalidade pode ser operada e se o foco é gerenciado corretamente após cada interação—especialmente depois que diálogos modais são abertos ou conteúdo AJAX é carregado.
6. Teste com leitor de tela usando VoiceOver + Safari (macOS/iOS): Ative o VoiceOver (Command + F5 no macOS). Use Control + Option + Seta para navegar. No iOS, use gestos de deslizar. Confirme que todas as funções são alcançáveis e operáveis. Preste atenção especial a widgets personalizados baseados em toque que podem não ter equivalentes por teclado na versão para desktop.
7. Auditoria de funcionalidade dependente de trajeto: Para qualquer canvas de desenho, interação com mapa ou componente dirigido por gestos, verifique se existe um mecanismo alternativo por teclado. Tente criar uma forma, reordenar um item de lista ou mover um mapa usando apenas controles de teclado. Se não existir um caminho por teclado, isso é uma falha direta de 2.1.3.
8. Verificação de visibilidade do foco: Ao navegar apenas com teclado, confirme que o foco está sempre visível na tela e ordenado de forma lógica. Foco invisível ou foco que salta para locais inesperados é uma falha de usabilidade e provavelmente também viola 2.4.7 e 2.4.3.

Como Corrigir

Ferramenta de Desenho em Canvas — Incorreto

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Ferramenta de Desenho em Canvas — Correto

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Reordenar Lista por Arrastar e Soltar — Incorreto

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Reordenar Lista por Arrastar e Soltar — Correto

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Controles de Mapa Interativo — Incorreto

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Controles de Mapa Interativo — Correto

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Erros Comuns

• Presumir que a exceção de trajeto da WCAG 2.1.1 ainda se aplica: Desenvolvedores familiarizados com o Nível A às vezes constroem ferramentas de desenho à mão livre ou baseadas em gestos sem alternativas por teclado, sem perceber que 2.1.3 remove explicitamente essa exceção. Toda função, incluindo as sensíveis a trajeto, deve ter um equivalente por teclado neste nível.
• Anexar apenas handlers onclick e onmousedown a elementos interativos personalizados: Widgets personalizados construídos com elementos <div> ou <span> que só escutam eventos de mouse são completamente inalcançáveis por teclado. Sempre adicione handlers onkeydown ou onkeyup juntamente com listeners de eventos de mouse e garanta que o elemento tenha tabindex='0' e um papel ARIA apropriado.
• Usar tabindex='-1' em elementos que deveriam estar na ordem de tabulação: Definir tabindex='-1' remove um elemento da ordem sequencial de tabulação. Isso é apropriado apenas para elementos gerenciados programaticamente (por exemplo, dentro de um widget composto usando roving tabindex). Aplicá-lo a controles interativos independentes os torna inacessíveis por teclado.
• Implementar arrastar e soltar sem um mecanismo de reordenação baseado em teclado: Bibliotecas como SortableJS ou implementações personalizadas de arrastar muitas vezes não fornecem uma alternativa por teclado prontamente. Desenvolvedores devem implementar o padrão ARIA de arrastar e soltar ou fornecer reordenação com teclas de seta para cima/baixo para que a reordenação de listas seja totalmente operável por teclado.
• Confiar em CSS :hover para revelar controles interativos: Submenus de dropdown, botões de ação baseados em tooltip ou controles revelados que aparecem apenas no hover são inacessíveis a pessoas que usam teclado, a menos que estados :focus e :focus-within também sejam tratados. Uma pessoa que usa teclado nunca pode fazer hover, então conteúdo apenas em hover fica efetivamente oculto para ela.
• Não gerenciar o foco após mudanças dinâmicas de conteúdo: Quando um modal é aberto, um alerta inline aparece ou um widget carregado via AJAX substitui conteúdo existente, o foco deve ser movido programaticamente para o novo conteúdo usando element.focus(). Deixar de fazer isso deixa pessoas que usam teclado presas na posição em que acionaram a mudança, sem consciência de que existe novo conteúdo.
• Construir controles deslizantes personalizados apenas com onmousemove: Controles deslizantes do tipo faixa construídos a partir de elementos <div> que rastreiam a posição do mouse para mudanças de valor também devem implementar o tratamento das teclas ArrowLeft, ArrowRight, Home e End conforme o padrão ARIA de slider, e expor o valor atual via aria-valuenow, aria-valuemin e aria-valuemax.
• Colocar o foco do teclado dentro de iframes sem fornecer uma saída: Iframes incorporados—especialmente aqueles que contêm widgets de terceiros como mapas, formulários de pagamento ou ferramentas de chat—podem prender o foco do teclado se o conteúdo incorporado em si não for acessível por teclado e não suportar a tecla Escape para devolver o foco ao documento pai.
• Omitir suporte por teclado em visualizações de dados baseadas em canvas: Gráficos e diagramas renderizados em <canvas> são invisíveis para o teclado e leitores de tela, a menos que uma alternativa acessível (uma tabela de dados, um equivalente em SVG com ARIA ou pontos de dados navegáveis por teclado) seja fornecida junto ao elemento canvas.
• Testar acessibilidade por teclado apenas com Tab e Enter, ignorando padrões de teclas de widgets compostos: Muitos padrões de widgets ARIA—menus, árvores, grades, painéis de abas, listboxes—exigem navegação por teclas de seta dentro do widget, com apenas um único ponto de tabulação para todo o componente (roving tabindex). Testar apenas Tab e Enter não revelará falhas nesses padrões compostos e dará uma falsa sensação de conformidade.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial de número 32933 em 21 de junho de 2025, estabelece uma estrutura abrangente de acessibilidade web e móvel para uma ampla gama de entidades públicas e privadas que operam na Turquia. A circular exige conformidade com padrões alinhados às WCAG 2.1 e 2.2, obrigando as organizações abrangidas a garantir que seus serviços digitais sejam perceptíveis, operáveis, compreensíveis e robustos para todas as pessoas usuárias, incluindo aquelas com deficiência.

As entidades abrangidas por este regulamento incluem instituições e agências públicas em todos os níveis de governo, plataformas de e-commerce, bancos e prestadores de serviços financeiros, hospitais e instituições de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagens, empresas de transporte privado e escolas privadas que operam sob autorização do Ministério da Educação Nacional (MoNE). Para essas organizações, a conformidade com critérios de sucesso de Nível A e Nível AA é o mínimo legal.

WCAG 2.1.3 — Teclado (Sem Exceção) é um critério de Nível AAA e, portanto, não é explicitamente exigido como requisito legal básico sob a circular. No entanto, o espírito do regulamento—garantir acesso digital equitativo para os milhões de usuários com deficiência na Turquia—está fortemente alinhado com a intenção deste critério. Organizações em setores abrangidos que oferecem serviços especializados a pessoas com deficiências motoras, ou que operam portais governamentais usados por cidadãos que dependem de tecnologia assistiva, são fortemente aconselhadas a buscar conformidade AAA para acesso por teclado.

Alcançar conformidade com a WCAG 2.1.3 sinaliza um compromisso de acessibilidade de melhor nível, que vai além dos mínimos regulatórios. Para organizações turcas que buscam atender à base de usuários mais ampla possível, demonstrar responsabilidade social ou participar de mercados digitais da União Europeia onde padrões de acessibilidade mais elevados podem se aplicar, implementar operabilidade completa por teclado sem exceções é tanto uma vantagem competitiva quanto ética. À medida que o cenário regulatório da Turquia evolui e os mecanismos de fiscalização amadurecem, as primeiras adotantes de critérios de nível AAA como 2.1.3 estarão bem posicionadas para atender a qualquer endurecimento regulatório futuro sem remediações custosas.