Resposta rápida
A navegação por teclado é a capacidade de percorrer um sítio web e operar todas as suas partes utilizando apenas um teclado — sem rato, sem ecrã tátil, sem trackpad. Os elementos HTML nativos suportam-na automaticamente; os componentes construídos à medida têm de a reimplementar deliberadamente, e é daí que vem a maioria das falhas de acessibilidade por teclado.
O que é a navegação por teclado?
Um utilizador avança com Tab de ligação em ligação, de botão em botão e de campo em campo de um formulário, e depois ativa aquilo em que se encontra com Enter ou Space. Não se trata de um método de introdução de nicho sobreposto à interface "verdadeira". Todos os navegadores e todos os elementos HTML nativos já o suportam por predefinição.
Onde o suporte falha
Uma simples etiqueta <button> ou <a> é operável por teclado no momento em que existe, sem necessidade de código adicional. O suporte só falha quando uma equipa substitui esses elementos nativos por outros construídos à medida — uma <div> estilizada para parecer um botão, por exemplo — sem reconstruir o comportamento de teclado que a versão nativa lhes oferecia gratuitamente.
Porque é a navegação por teclado importante para a acessibilidade?
A base comum sob a tecnologia de apoio
A navegação por teclado é importante porque é o único método de introdução de que quase todas as tecnologias de apoio dependem, mesmo quando a pessoa que as utiliza não está conscientemente a premir Tab. Um utilizador de leitor de ecrã percorre a estrutura de uma página através de comandos de teclado. Um utilizador de acesso por comutador, alguém com uma deficiência motora que não consegue operar diretamente um teclado convencional, continua a depender de software que emula a introdução por teclado. Se um sítio só funcionar com rato, todos esses utilizadores ficam excluídos de uma só vez — porque o suporte de teclado é a base comum que sustenta várias tecnologias de apoio diferentes.
Um indicador do estado geral da acessibilidade
É também por isso que a acessibilidade por teclado funciona como um indicador fiável do estado geral de acessibilidade de um sítio. Uma página totalmente operável por teclado tem normalmente uma estrutura subjacente sólida: elementos numa ordem sensata, controlos nativos em vez de widgets à medida e estados de foco visíveis em vez de removidos por razões estéticas. Uma página que falha no acesso por teclado costuma ter cortado caminho na própria marcação, o que tende a prenunciar problemas também para os utilizadores de leitores de ecrã, uma vez que ambos assentam na mesma base estrutural.
Quem utiliza a navegação por teclado?
Grupos diferentes dependem dela por razões completamente distintas, e um sítio que contemple apenas um deles continuará a falhar para os restantes.
Pessoas com deficiência motora
Os pequenos alvos de clique e os gestos de arrastar de um rato podem ser genuinamente difíceis de operar com fiabilidade, mesmo quando, por comparação, as pressões discretas das teclas de um teclado são perfeitamente comportáveis. Para este grupo, o suporte de teclado é frequentemente o único método de introdução que realmente funciona.
Utilizadores de leitores de ecrã
A posição de um ponteiro no ecrã não tem qualquer relação com aquilo que o leitor de ecrã está a ler em voz alta nesse momento. Os comandos de teclado são a forma como um utilizador de leitor de ecrã conduz a sua própria navegação pela estrutura e pelo conteúdo da página.
Utilizadores exclusivos de teclado
Alguns utilizadores navegam exclusivamente por teclado por razões que nada têm que ver com deficiência: um trackpad avariado, um rato que deixou de funcionar ou simplesmente uma preferência de fluxo de trabalho — trata-se de um sítio funcionar como qualquer dispositivo de introdução convencional deve funcionar.
Utilizadores avançados
Programadores, redatores e outros utilizadores frequentes de computador navegam muitas vezes por teclado porque é mais rápido do que estar constantemente a pegar no rato. Um bom suporte de teclado acaba por recompensar este grupo com uma experiência mais rápida.
Pessoas com lesões temporárias
Um pulso partido, uma lesão na mão ou ter um bebé ao colo num dos braços podem tornar a utilização do rato dolorosa ou impossível durante algum tempo, sem que a pessoa se identifique de todo como tendo uma deficiência.
Como navegam os utilizadores num sítio web sem rato?
As teclas essenciais de movimento
Tab avança pelos elementos interativos — ligações, botões, campos de formulário — pela ordem em que surgem no HTML subjacente da página, e Shift+Tab inverte esse movimento. Enter ou Space ativam depois o elemento que detém o foco nesse momento, seja submeter um formulário, seguir uma ligação ou abrir um menu.
Teclas para situações mais específicas
As teclas de seta movem-se dentro de um único componente depois de este ter o foco — entre um conjunto de botões de opção, os itens de um menu ou o intervalo de um cursor deslizante — em vez de saltarem entre elementos distintos da página. Esc fecha o que estiver aberto, como um menu pendente ou uma caixa de diálogo. Home e End saltam para o início ou o fim de uma lista ou de uma página longa.
Onde a experiência falha
A experiência só falha quando os componentes construídos à medida de um sítio não implementam este conjunto completo de teclas — um menu pendente personalizado que responde ao clique mas ignora por completo as teclas de seta deixa um utilizador de teclado sem qualquer forma de selecionar uma opção depois de o ter aberto.
Que teclas do teclado são utilizadas na navegação?
Tab
Move o foco para o elemento interativo seguinte na ordem do código-fonte da página. É a tecla mais determinante de toda a navegação por teclado.
Shift + Tab
Inverte a direção de Tab. A sua principal utilidade prática é a recuperação — voltar a um campo que se ultrapassou sem ter de recomeçar do topo.
Enter
Ativa o elemento que tem o foco nesse momento. Num controlo construído à medida que funciona como botão, o suporte de Enter tem de ser acrescentado deliberadamente.
Space
Ativa botões e alterna caixas de verificação — mas também faz deslocar a área visível quando o foco não está num elemento interativo, razão pela qual as caixas de verificação personalizadas precisam de tratamento explícito de Space.
Teclas de seta
Navegam dentro de um único componente agrupado — opções de um grupo de botões de opção, separadores de uma lista de separadores, itens de um menu aberto — em vez de o fazerem entre elementos distintos da página.
Escape
Fecha uma sobreposição aberta e, num componente bem construído, devolve o foco ao elemento que a abriu.
Home / End
Movem o foco para o primeiro ou o último item de uma lista, de um conjunto de separadores ou de um documento longo — especialmente úteis em páginas com muitos dados, onde Tab por si só seria impraticável.
Como funciona o foco do teclado?
O que é afinal o foco
O foco do teclado é o conceito nativo do navegador de "que elemento está atualmente ativo" — aquele que receberá a próxima pressão de tecla e aquele que um contorno visível costuma destacar no ecrã. Só um elemento pode deter o foco de cada vez.
Como se move o foco
O foco move-se de duas formas: automaticamente, à medida que o utilizador prime Tab ao longo da página, ou programaticamente, quando o código o desloca deliberadamente — por exemplo, levando o foco para dentro de uma caixa de diálogo assim que esta abre, ou devolvendo-o ao botão de origem quando essa caixa fecha. É neste segundo tipo, o foco gerido, que a maioria dos componentes interativos à medida falha.
Quando o foco corre mal
O foco é também aquilo a que se refere uma "armadilha de teclado" quando corre mal no sentido inverso — um elemento que captura o foco e nunca o liberta, porque nenhuma combinação de teclas que o utilizador experimente consegue tirá-lo de lá.
O que é a ordem de tabulação e porque é importante?
O que segue a ordem de tabulação por predefinição
A ordem de tabulação é a sequência pela qual o foco se move à medida que o utilizador prime Tab repetidamente e, por predefinição, segue a ordem em que os elementos surgem no código-fonte HTML da página — e não a sua posição visual na página apresentada. Divergem quando se usa CSS para reposicionar visualmente um elemento sem o mover no código subjacente.
Quando a ordem de tabulação se afasta da ordem visual
O foco recai sobre um elemento que visualmente aparece noutro ponto da página, ou uma barra lateral codificada no início do HTML recebe o foco antes do conteúdo principal que um utilizador com visão leria primeiro. A solução não é um script que reordene o foco a posteriori; é manter a ordem do código-fonte HTML alinhada, à partida, com a ordem visual de leitura.
O papel de tabindex
Uma prática relacionada mas distinta é o atributo tabindex, que pode inserir um elemento na sequência de tabulação (tabindex="0") ou retirá-lo dela (tabindex="-1"). Usar um valor positivo de tabindex para forçar manualmente uma ordem específica é um atalho comum mas desaconselhado — cria uma segunda ordem concorrente que tem de ser mantida à mão.
Que elementos de um sítio web devem ser acessíveis por teclado?
Todos os elementos interativos têm de ser acessíveis por teclado, mas tipos de elementos diferentes esbarram em modos de falha específicos diferentes.
Links
Uma etiqueta <a> nativa com um href válido é automaticamente acessível por teclado. Uma ligação construída sem href fica totalmente fora da ordem de tabulação.
Buttons
Um <button> nativo trata do alcance por Tab e da ativação por Enter/Space sem código adicional. Um "botão" feito com uma <div> estilizada é invisível para Tab, a menos que seja reconstruído manualmente.
Forms
Dependem de uma ordem de tabulação lógica, de rótulos associados programaticamente aos respetivos campos e de mensagens de erro que um utilizador de teclado realmente encontre — e não apenas de um contorno vermelho em CSS.
Menus
Têm de abrir com Enter ou Space, permitir o movimento entre itens com as teclas de seta e fechar com Esc, devolvendo o foco ao elemento que os acionou. Um menu que só reage ao passar do rato não tem equivalente por teclado.
Dialogs
Tem de levar o foco para dentro de si ao abrir, manter o foco confinado ao seu próprio conteúdo enquanto está aberta e devolver o foco ao elemento que a acionou assim que fecha.
Acordeões
O controlo de expandir/recolher tem de ser um botão a sério, operável com Enter ou Space, com o seu estado de expansão exposto à tecnologia de apoio.
Tabs
Devem permitir que as teclas de seta se movam entre separadores e que Enter ou Space ativem o separador selecionado, à semelhança do padrão usado noutros componentes agrupados.
Componentes à medida
Um cursor deslizante, uma lista de arrastar e largar ou um seletor de datas feitos à medida não herdam nada do comportamento de teclado que um equivalente nativo oferece — cada parte tem de ser construída deliberadamente.
O que é uma armadilha de teclado?
Uma armadilha de teclado é um elemento que captura o foco e nunca deixa um utilizador de teclado voltar a tirá-lo de lá, independentemente da tecla ou combinação de teclas que experimente. É uma das falhas mais graves de acessibilidade por teclado porque não gera apenas atrito — detém o utilizador por completo, sem caminho em frente nem caminho de volta.
Onde surgem normalmente as armadilhas
As armadilhas de teclado aparecem mais frequentemente em widgets construídos à medida: uma caixa de diálogo que confina corretamente o foco enquanto está aberta, mas que nunca o liberta depois de fechada. Conteúdos incorporados de terceiros, como alguns leitores de vídeo ou iframes publicitários, também podem prender o foco se não tiverem sido construídos a pensar na saída por teclado. Um utilizador que se depare com uma armadilha não tem qualquer pista visual de que algo está mal — a página parece igual, mas Tab e Shift+Tab simplesmente deixam de funcionar.
Porque é que as WCAG a tratam como critério próprio
A armadilha de teclado é expressamente referida nas WCAG como critério de sucesso próprio, separado da operabilidade geral por teclado, precisamente por ser uma forma distinta e grave de um sítio falhar — não conseguir chegar a um elemento é uma barreira, mas não conseguir sair dele é um beco sem saída absoluto.
Como se pode testar a navegação por teclado?
Os testes vão desde uma verificação manual rápida até uma auditoria formal, e usar mais do que um método deteta classes diferentes de problemas.
Testes manuais com teclado
Desligue o rato e complete uma tarefa real usando apenas Tab, Shift+Tab, Enter, Space e as teclas de seta — atento a elementos inalcançáveis, ao desaparecimento do indicador de foco e a armadilhas de teclado.
Testes com leitor de ecrã
Revelam outra camada de problemas — um elemento pode ser alcançável por teclado e ainda assim estar mal rotulado, levando o leitor de ecrã a anunciar "botão" sem qualquer indicação do que faz.
Ferramentas de programador do navegador
Permitem inspecionar diretamente a árvore de acessibilidade — confirmando que elementos podem receber foco, qual o seu papel calculado e se os valores de tabindex estão definidos como pretendido.
Testes automatizados de acessibilidade
Conseguem sinalizar alguns problemas, como um valor positivo de tabindex, mas não conseguem verificar se a ordem de tabulação corresponde à ordem visual ou se uma caixa de diálogo confina e liberta o foco corretamente.
Auditorias de acessibilidade
Combinam tudo o anterior numa avaliação estruturada face a uma norma definida, geralmente as WCAG, produzindo uma lista priorizada de constatações a partir da qual planear a remediação.
Como definem as WCAG a acessibilidade por teclado?
| 2.1.1 Teclado | Exige que toda a funcionalidade seja operável através de uma interface de teclado, sem exigir uma temporização específica para cada pressão de tecla. Um requisito de Nível A — o patamar de base. |
|---|---|
| 2.1.2 Sem Armadilha de Teclado | Proíbe expressamente que o foco fique preso em qualquer componente e exige que, se um método de saída convencional não funcionar, o utilizador seja informado de uma forma alternativa de afastar o foco. |
| 2.4.3 Ordem de Foco | Exige que, quando uma página pode ser navegada sequencialmente, a ordem preserve o significado e a operabilidade — a versão normativa da discussão sobre ordem de tabulação feita acima. |
| 2.4.7 Foco Visível | Exige que qualquer interface operável por teclado tenha um indicador visível que mostre que elemento detém o foco — exatamente o que se perde quando uma equipa remove o contorno de foco predefinido por razões estéticas. |
Quais são as boas práticas de navegação por teclado?
Utilizar controlos HTML nativos
Um botão, uma ligação ou um menu de seleção nativos trazem de origem o alcance por teclado, a ativação e, muitas vezes, o comportamento das teclas de seta, sem código adicional.
Manter uma ordem de tabulação lógica
Mantenha a ordem do código-fonte HTML alinhada com a ordem visual de leitura, em vez de remendar a discrepância com valores de tabindex que têm de ser sincronizados à mão.
Fornecer indicadores de foco visíveis
Mantenha o contorno de foco predefinido ou substitua-o por um estilo personalizado igualmente visível — nunca o remova para ficar com um aspeto "mais limpo".
Evitar armadilhas de teclado
Qualquer componente que faça a gestão do seu próprio foco precisa de uma saída explícita e testada — Esc, um botão de fechar alcançável, ou ambos.
Suportar as interações de teclado convencionais
Siga os mesmos padrões que os utilizadores já esperam dos equivalentes nativos, em vez de inventar um padrão novo para um único componente.
Testar sem rato
Completar regularmente fluxos reais de utilização apenas com o teclado é a forma mais direta de apanhar estes problemas antes de chegarem a produção.
Perguntas frequentes
Não por predefinição, e não sem um esforço deliberado. Os elementos HTML nativos são automaticamente acessíveis por teclado, mas qualquer componente construído à medida — um menu pendente, um cursor deslizante, uma caixa de diálogo — só funciona sem rato se um programador tiver implementado explicitamente o alcance por Tab, o tratamento de teclas e a gestão do foco.
Tab move o foco do teclado para o elemento interativo seguinte na ordem do código-fonte da página, e Shift+Tab leva-o de volta ao anterior. Em conjunto, são a principal forma de um utilizador de teclado percorrer os elementos interativos de uma página, um de cada vez.
O foco do teclado é o conceito que o navegador tem de qual é o elemento atualmente ativo e que receberá a próxima pressão de tecla. Costuma ser assinalado por um contorno visível, e todos os comandos de teclado atuam sobre o elemento que o detém nesse momento.
Uma armadilha de teclado é um componente que captura o foco do teclado e nunca o liberta, deixando o utilizador sem forma de sair com Tab, faça o que fizer. É considerada uma das falhas mais graves de acessibilidade por teclado porque detém o utilizador por completo, em vez de apenas criar atrito.
WCAG's core keyboard requirements are Success Criterion 2.1.1, which requires all functionality to be operable by keyboard, and 2.1.2, which prohibits keyboard traps. Two related criteria — 2.4.3 (focus order) and 2.4.7 (focus visible) — round out the requirement.
O teste mais direto é completar uma tarefa real no sítio usando apenas Tab, Shift+Tab, Enter, Space e as teclas de seta, atento sobretudo a elementos inalcançáveis, indicadores de foco em falta e armadilhas de teclado. Os testes com leitor de ecrã, as ferramentas de programador do navegador e os analisadores automatizados detetam, cada um, uma fatia diferente e mais estreita dos problemas.
A maioria dos utilizadores de leitores de ecrã navega sobretudo por teclado, dado que a posição do ponteiro do rato no ecrã não tem qualquer relação com aquilo que o leitor de ecrã está a ler nesse momento. Alguns utilizadores de leitores de ecrã em dispositivos táteis recorrem antes a gestos de deslize, mas no computador os comandos de teclado são a norma.
