O recurso "ponto de partida da navegação sequencial com foco" define onde começamos a procurar elementos com foco para a navegação sequencial com foco ([Tab] ou [Shift-Tab]) quando não há uma área em foco. Ele é especialmente útil para recursos de acessibilidade, como "links de pular" e gerenciamento de foco no documento.
O HTML oferece muito suporte integrado para lidar com interações do teclado, o que significa que é muito fácil escrever páginas que podem ser usadas pelo teclado, seja porque uma deficiência motora impede o uso de um mouse ou porque é mais eficiente tirar as mãos do teclado para economizar preciosos milissegundos.
O processamento do teclado gira em torno do foco, que determina para onde os eventos do teclado vão na página. Até agora, houve algumas situações em que precisamos fazer um trabalho extra para que as coisas funcionassem bem para os usuários de teclado. O método focus() permite gerenciar o foco escolhendo seletivamente um elemento para focar em resposta a uma ação do usuário. No entanto, essa prática recomendada tem muitas armadilhas e exige algumas gambiarras JavaScript complicadas para fornecer uma experiência de referência.
Essa técnica não vai desaparecer tão cedo, mas no Chrome 50 ela será necessária em menos casos devido ao ponto de início da navegação de foco sequencial. Com essa mudança, as páginas bem elaboradas vão ficar automaticamente mais acessíveis sem a necessidade de gerenciamento manual extra do foco. Vamos conferir um exemplo.
Link em uma página
Sites com muito texto geralmente têm links internos na mesma página para ajudar os usuários a acessar rapidamente seções importantes.
<!-- Table of Contents -->
<a href="#recipes">Recipes</a>
<a href="#ingredients">Ingredients</a>
<!-- Recipes Section -->
<h2 id="recipes">Recipes</h1>
<h3>Vegemite Cheesecake</h3>
<p>
Vegemite cheesecake is delicious. We promise.
<a href="cheesecake.html">Read More</a>
</p>
Se eu fosse um usuário de teclado (e um glutão por comidas australianas), minha próxima série de ações seria mais ou menos assim:
- Pressione
Tabduas vezes para focar o link "Receitas" - Pressione
Enterpara acessar a seção "Receitas" - Pressione
Tabnovamente para focar o link "Leia mais"
Vamos conferir isso em ação usando o Chrome 49.
Ah, isso não saiu como planejado, não é?
Em vez de focar o link "Leia mais", pressionar Tab pela última vez moveu o foco para o próximo item na tabela de conteúdos. Isso ocorre porque o desenvolvedor não definiu tabindex="-1" no cabeçalho para torná-lo focalizável. Portanto, clicar na âncora com o nome #recipes não moveu o foco. É um erro sutil e não é um problema se você usa um mouse. Mas pode ser um problema muito grande se você for um usuário de teclado ou de dispositivo de troca. Considere a quantidade de links cruzados em uma página típica da Wikipédia? Seria frustrante ter que alternar constantemente entre todas essas âncoras.
Vamos conferir a mesma experiência usando o Chrome 50.
Uau, isso é exatamente o que queríamos, e o melhor de tudo é que não precisamos mudar nosso código. O navegador acabou de descobrir onde o foco deveria ir com base no local em que estávamos no documento.
Como funciona?
Antes da implementação do ponto de partida do foco, ele sempre se movia do elemento em foco anterior ou da parte de cima da página. Isso significa que escolher o que será focado em seguida pode envolver mover o foco para algo que não deveria ser focado, como um elemento de contêiner ou um título. Isso causa todo tipo de estranheza, incluindo a exibição de um anel de foco se você clicar em um elemento.
O ponto de início do foco, como o nome sugere, fornece um mecanismo para sugerir onde começar a procurar o próximo elemento com foco quando pressionamos Tab ou Shift-Tab.
Ele pode ser definido de várias maneiras:
Se algo tiver foco, ele também será o ponto de início da navegação de foco, assim como antes.
Além disso, como antes, se nada mais definir o ponto de início da navegação de foco, ele será o document atual ou, se disponível e compatível, o dialog ativo.
Se navegarmos para um fragmento de página como no exemplo acima, isso vai definir o ponto de início do foco.
Além disso, se clicarmos em qualquer elemento na página, mesmo que ele não seja focado, isso vai definir o ponto de início da navegação de foco.
Por fim, se o elemento que era o ponto de início do foco for removido do DOM, o elemento pai se torna o ponto de início do foco. Chega de distrações!
Outros casos de uso
Além do exemplo acima, há muitos outros cenários em que esse recurso pode ser útil.
Como ocultar elementos
Pode haver momentos em que um usuário vai se concentrar em um item que precisa ser definido como visibility: hidden ou display: none. Um exemplo disso são os itens clicáveis em um carrossel. Nas versões anteriores do Chrome, ocultar o item focado dessa maneira redefinia o foco para o ponto de partida padrão, transformando o carrossel mencionado em uma armadilha para usuários com deficiência motora. Com o ponto de partida do foco sequencial, isso não acontece mais. Se um elemento for oculto por um dos métodos acima, pressionar a tecla Tab simplesmente move para o próximo item com foco.
Ignorar os links
Os links de salto são âncoras invisíveis que só podem ser acessados pelo teclado. Eles permitem que os usuários "pulem" elementos de navegação para acessar diretamente o conteúdo de uma página e podem ser extremamente benéficos para usuários de teclado e de dispositivos com chave. Conforme explicado no site da WebAIM
Muitos sites populares implementam links de pular, mas você pode nunca ter notado.
Como os links de pular são âncoras nomeadas, eles funcionam da mesma forma que nosso exemplo de sumário original.
Restrições e suporte
No momento, o ponto de partida da navegação de foco sequencial só é compatível com o Chrome 50, o Firefox e o Opera. Até que o recurso seja compatível com todos os navegadores, ainda será necessário adicionar tabindex="-1" (e remover o contorno de foco) aos destinos de âncora nomeados.
Demonstração
O ponto de partida da navegação de foco sequencial é uma ótima adição ao conjunto de primitivas de acessibilidade do navegador. É fácil de entender e permite remover o código do aplicativo, melhorando a experiência dos usuários. Vitória dupla! Confira a demonstração para conhecer melhor esse recurso.