O recurso "Ponto de partida da navegação com foco sequencial" define onde começamos a pesquisar elementos focalizáveis para a navegação de foco sequencial ([Tab] ou [Shift-Tab]) quando não há uma área focalizada. Esse recurso é especialmente útil para recursos de acessibilidade como "pular links" e gerenciamento do foco no documento.
O HTML nos fornece muito suporte integrado para lidar com interações de teclado, o que significa que é muito fácil escrever páginas que podem ser usadas por meio do teclado, não importa se uma deficiência motora nos impede de usar um mouse ou se somos tão eficientes removendo nossas mãos do teclado desperdiçam milissegundos preciosos.
O manuseio do teclado gira em torno do foco, que determina onde os eventos do teclado serão colocados na página. Há algumas situações em que, até agora, foi necessário fazer um trabalho extra para que tudo funcionasse bem com 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 apresenta muitos problemas e exige alguns recursos complexos de invasão de JavaScript para fornecer uma experiência básica.
Embora essa técnica não seja totalmente desativada em breve, no Chrome 50 ela será necessária em menos casos graças ao ponto de partida da navegação com foco sequencial. Com essa mudança, páginas mais escritas automaticamente ficarão mais acessíveis sem a necessidade de gerenciamento manual extra. Vamos conferir um exemplo.
Link em uma página
Sites com muito texto geralmente se interligam 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 gostasse de comidas australianas), minha próxima série de ações seria algo assim:
- Pressione
Tabduas vezes para focar o link "Recipes" - Pressione
Enterpara pular para a seção "Recipes" - Pressione
Tabnovamente para focar o link "Ler mais"
Vamos conferir isso em ação no Chrome 49.
Bem, isso não correu muito de acordo com o planejado?
Em vez de focar no link "Ler mais", pressionar Tab pela última vez mudou o foco para o próximo item no índice. Isso ocorre porque o desenvolvedor não definiu tabindex="-1" no cabeçalho para torná-lo focalizável. Portanto, clicar na âncora #recipes não moveu o foco. É um erro sutil, e não é um grande problema se você for usuário de mouse. Mas isso é potencialmente um grande problema se você usa teclado ou usa outro dispositivo. Considera a quantidade de interligações em uma página típica da Wikipédia. Seria frustrante ter que navegar constantemente por todas essas âncoras!
Agora, vamos conferir a mesma experiência com o Chrome 50.
Isso era exatamente o que queríamos e, o melhor de tudo, não precisamos alterar nosso código. O navegador apenas entendeu onde o foco deve ir com base no ponto em que estávamos no documento.
Como funciona?
Antes da implementação do ponto de partida do foco, o foco sempre se deslocaria do elemento anterior ou do topo da página. Isso significa que escolher o que será focado em seguida pode envolver mudar o foco para algo que não deveria ser focalizável, como um elemento de contêiner ou um título. Isso causa vários tipos de estrangulamento, inclusive mostrar um anel de foco se você clicar em um elemento desse tipo.
O ponto inicial de foco, como o nome sugere, oferece um mecanismo para sugerir onde começar a procurar o próximo elemento focalizável quando pressionamos Tab ou Shift-Tab.
Isso pode ser definido de várias maneiras:
se algo estiver em foco, também será o ponto inicial da navegação de foco, como antes.
Além disso, assim como antes, se nada mais tiver definido o ponto inicial da navegação de foco, esse vai ser o document atual ou, se disponível e com suporte, o dialog ativo no momento.
Se navegarmos para um fragmento de página, como no exemplo acima, isso definirá o ponto inicial de foco.
Além disso, se clicarmos em qualquer elemento na página, independente de ser focalizável, isso definirá o ponto inicial de navegação de foco.
Por fim, se o elemento que era o ponto inicial de foco for removido do DOM, o pai se tornará o ponto inicial de foco. Chega de mirar na manga!
Outros casos de uso
Além do exemplo acima, há muitos outros cenários em que esse recurso pode ser útil.
Ocultando elementos
Pode haver momentos em que o foco do usuário é um item que precisa ser definido como visibility: hidden ou display: none. Um exemplo disso seriam itens clicáveis em um carrossel. Em versões anteriores do Chrome, ocultar o item em foco dessa forma redefine o foco de volta ao ponto de partida padrão, transformando o carrossel mencionado acima em uma armadilha desagradável para usuários com deficiências motoras. Com o ponto de partida do foco sequencial, esse não é mais o caso. Se um elemento estiver oculto por qualquer um dos métodos acima, pressionar a tecla Tab simplesmente avançará para o próximo item focalizável.
Ignorar os links
Links de salto são âncoras invisíveis que só podem ser acessadas pelo teclado. Eles permitem que os usuários “pule” elementos de navegação para ir direto ao conteúdo de uma página, e podem ser extremamente benéficos para usuários de teclado e de outro dispositivo. Conforme explicado no site WebAIM
Muitos sites populares implementam links de salto, mas talvez você nunca os tenha notado.
Como os links de salto são chamados de âncoras, eles funcionam da mesma maneira que o exemplo original do índice.
Ressalvas e suporte
No momento, o ponto de partida da navegação com foco sequencial é compatível apenas no Chrome 50, Firefox e Opera. Até que ele seja compatível com todos os navegadores, ainda será necessário adicionar tabindex="-1" (e remover o contorno do foco) aos seus destinos fixos nomeados.
Demonstração
O ponto de partida da navegação com foco sequencial é uma ótima adição ao conjunto de primitivas de acessibilidade do navegador. É fácil de se esconder e, na verdade, ele nos permite remover o código do aplicativo e, ao mesmo tempo, melhorar a experiência para os usuários. Vitória dupla! Confira a demonstração para explorar esse recurso em mais detalhes.