axessia.eu

O erro mais comum na navegação apenas com teclado: o que dá errado e como evitá-lo?

Muitos websites funcionam perfeitamente com um rato, mas travam assim que alguém usa apenas o teclado. É aqui que as coisas geralmente correm mal e como o pode detetar.

O que dá errado na navegação apenas com teclado

O erro mais comum na navegação apenas com teclado é que os componentes interativos são visíveis, mas não são acessíveis com a tecla Tab. Pense num menu que abre apenas com um clique do rato, um botão que não recebe foco, ou uma janela de diálogo que não pode fechar sem usar o rato. Para pessoas que não conseguem usar um rato devido a limitações motoras, ou que utilizam um leitor de ecrã que depende de navegação por teclado, isto significa que partes do website simplesmente não são utilizáveis.

A causa quase sempre está em componentes personalizados: um desenvolvedor constrói um elegante menu suspenso, um seletor de data personalizado ou um filtro expansível com HTML e JavaScript próprios, mas esquece-se do suporte de teclado que um botão ou ligação HTML padrão oferece gratuitamente. O elemento parece bem e funciona com o rato, por isso ninguém repara durante os testes que a tecla Tab simplesmente o ignora.

Por que isto é frequentemente ignorado

Este erro é persistente porque não é visível a olho nu. Quem clica num website de comércio eletrónico com um rato não vê qualquer problema. Só quando deixa o rato de lado e navega pela página apenas com Tab, Shift+Tab, Enter e as teclas de seta, fica claro onde a navegação se interrompe. Como este teste raramente faz parte do processo padrão de entrega, o problema frequentemente passa despercebido durante anos — até que um visitante ou uma autoridade de supervisão o encontre.

Uma segunda razão é que muitas destas falhas ocorrem precisamente nos locais mais visíveis durante a utilização: o passo de compra, o ecrã de início de sessão, um filtro de pesquisa. São precisamente estas partes que frequentemente são construídas separadamente do resto do website, com componentes próprios que nem sempre recebem o mesmo cuidado que a navegação principal.

Como detetar isto por si próprio

Uma verificação inicial simples é deixar o rato de lado e navegar através de um fluxo de página apenas com teclado. Observe três aspetos: cada elemento clicável é acessível através de Tab, é claro a todo o momento qual elemento tem foco, e cada componente que abre — um menu, um filtro, uma janela de diálogo — pode também fechar-se novamente sem o rato. Se o foco ficar preso numa janela de diálogo, saltar para um local inesperado ou desaparecer completamente, isso é um sinal de que há trabalho a fazer.

Uma análise automatizada pode detetar alguns destes problemas, por exemplo indicadores de foco ausentes ou componentes sem acesso por teclado que tecnicamente são identificáveis no código-fonte. No entanto, se um menu suspenso também funciona de forma lógica e previsível, é algo que uma análise automatizada não pode avaliar completamente — isto continua a ser essencialmente um teste realizado por humanos. Aliás, isto aplica-se a mais requisitos WCAG, e sempre o mencionamos no relatório. inicie a análise rápida gratuita das suas páginas principais para ver que parte deste tipo de problemas já vem à luz automaticamente.

Como evitar isto

A solução geralmente não está em tecnologia adicional acrescentada ao website, mas no uso correto dos componentes existentes. Um botão ou ligação HTML padrão é naturalmente acessível com Tab e pode ser utilizado com Enter; quem em vez disso torna um pedaço de texto ou uma imagem clicável com JavaScript tem de adicionar esse suporte de teclado por si próprio. Para componentes personalizados como menus, filtros e janelas de diálogo, deve haver um acordo claro com o desenvolvedor: cada componente deve poder ser aberto, utilizado e fechado com o teclado, e o foco deve permanecer visível e previsível.

O que não ajuda aqui é um widget de acessibilidade que afirma corrigir esse tipo de deficiências com um script solto. Tal sobreposição não altera o código subjacente e, portanto, não altera a usabilidade real; a lei exige um website acessível, não uma camada adicional. Deliberadamente não vendemos esse tipo de widgets.

Deseja saber quais partes do seu website ou aplicativo contêm esse tipo de problemas estruturais e qual é o seu peso na lista de prioridades do seu plano de melhoria? Na base de conhecimento organizada por tópico você lê sobre cada tipo de deficiência o que está em jogo, e como funciona exatamente a nossa avaliação você vê qual parte é avaliada automaticamente e qual parte requer atenção manual.

Tem ainda dúvidas sobre o que está ou não abrangido por este requisito, ou sobre o resto do marco de avaliação? As respostas às perguntas frequentes já esclarecem a maioria delas.

A verificação rápida gratuita da axessia.eu oferece imediatamente uma indicação se esse tipo de problemas de teclado ocorrem no seu site, sem que você precise de uma conta.

Este artigo é informação geral e não constitui aconselhamento jurídico.