Verwijder hoofdpijn uit focusmanagement

De functie 'startpunt voor sequentiële focusnavigatie' definieert waar we beginnen te zoeken naar focusbare elementen voor sequentiële focusnavigatie ([Tab] of [Shift-Tab]) wanneer er geen focusgebied is. Het is vooral handig voor toegankelijkheidsfuncties zoals 'links overslaan' en het beheren van de focus in het document.

HTML biedt ons veel ingebouwde ondersteuning voor het omgaan met toetsenbordinteracties, wat betekent dat het vrij eenvoudig is om pagina's te schrijven die via het toetsenbord kunnen worden gebruikt - of we nu door een motorische beperking geen muis kunnen gebruiken, of dat we gewoon zo efficiënt zijn als we onze handen van het toetsenbord halen, verspillen we kostbare milliseconden.

De toetsenbordbediening draait om focus, die bepaalt waar toetsenbordgebeurtenissen op de pagina terechtkomen. Er zijn een paar situaties waarin we tot nu toe wat extra werk moesten doen om het goed te laten werken voor toetsenbordgebruikers. Met de focus() methode kunnen we de focus beheren door selectief een element te kiezen waarop we ons willen concentreren als reactie op een gebruikersactie. Deze best practice kent echter veel valkuilen en vereist een aantal lastige JavaScript-hacks om een ​​basiservaring te bieden.

Hoewel deze techniek niet snel volledig zal verdwijnen, zal deze in Chrome 50 in minder gevallen nodig zijn dankzij het Sequential Focus Navigation Start Point. Met deze wijziging worden goed geschreven pagina's automatisch toegankelijker zonder dat er extra handmatig focusbeheer nodig is. Laten we eens kijken naar een voorbeeld.

Sites met veel tekst zijn vaak onderling gekoppeld binnen dezelfde pagina, zodat gebruikers snel naar belangrijke secties kunnen gaan.

<!-- 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>

Als ik een toetsenbordgebruiker was (en een veelvraat van Australisch eten), zou mijn volgende reeks acties ongeveer als volgt gaan:

  • Druk tweemaal op Tab om de link Recepten scherp te stellen
  • Druk op Enter om naar het gedeelte Recepten te gaan
  • Druk nogmaals op Tab om de link Meer lezen scherp te stellen

Laten we dat eens in actie zien met Chrome 49.

Oh. Nou, dat ging niet helemaal volgens plan, toch?

In plaats van de link Meer lezen te focussen, verplaatste het drukken op Tab voor de laatste keer de focus naar het volgende item in de inhoudsopgave. Dit komt omdat de ontwikkelaar tabindex="-1" niet in de header heeft ingesteld om deze focusseerbaar te maken. Dus klikken op de #recipes met de naam anker verplaatste de focus niet. Het is een subtiele fout, en geen probleem als je een muisgebruiker bent. Maar het is potentieel een heel groot probleem als u een toetsenbord- of switch-apparaatgebruiker bent. Denk eens aan de hoeveelheid interlinks op een typische Wikipedia-pagina? Het zou frustrerend zijn om voortdurend heen en weer te moeten bladeren door al die ankers!

Laten we eens kijken naar dezelfde ervaring nu met Chrome 50.

Wauw, dat is precies wat we wilden, en het beste van alles: we hoefden onze code niet te veranderen. De browser heeft zojuist ontdekt waar de focus naartoe moet gaan op basis van waar we ons in het document bevonden.

Hoe werkt het?

Voorafgaand aan de implementatie van het focus-startpunt verplaatste de focus zich altijd van het vorige gefocuste element of naar de bovenkant van de pagina. Dit betekent dat het kiezen van wat vervolgens wordt gefocust, kan inhouden dat de focus wordt verplaatst naar iets dat niet echt focusbaar zou moeten zijn, zoals een containerelement of een kop. Dit veroorzaakt allerlei vreemde dingen, waaronder het tonen van een focusring als je toevallig op zo'n element klikt.

Het focusstartpunt biedt, zoals de naam al doet vermoeden, een mechanisme om aan te geven waar we moeten beginnen met zoeken naar het volgende focusbare element wanneer we Tab of Shift-Tab drukken.

Het kan op een aantal manieren worden ingesteld: Als iets focus heeft, is dit ook het startpunt van de focusnavigatie, net als voorheen. Als niets anders het focusnavigatiestartpunt heeft ingesteld, zal dit, net als voorheen, het huidige document zijn of, indien beschikbaar en ondersteund, het momenteel actieve dialog . Als we naar een paginafragment navigeren zoals in het bovenstaande voorbeeld, wordt nu het focusstartpunt ingesteld. Als we op een element op de pagina klikken, ongeacht of het focusbaar is, wordt nu het focusnavigatiestartpunt ingesteld. Als ten slotte het element dat het focusstartpunt was, uit de DOM wordt verwijderd, wordt het bovenliggende element het focusstartpunt. Geen focus-whack-a-mole meer!

Andere gebruiksscenario's

Naast het bovenstaande voorbeeld zijn er nog veel meer scenario's waarin deze functie van pas kan komen.

Elementen verbergen

Het kan voorkomen dat een gebruiker zich concentreert op een item dat moet worden ingesteld op visibility: hidden of display: none . Een voorbeeld hiervan zijn klikbare items binnen een carrousel. In eerdere versies van Chrome zou het op deze manier verbergen van het momenteel gefocuste item de focus terugzetten naar het standaard startpunt, waardoor de bovengenoemde carrousel een vervelende valstrik werd voor gebruikers met een motorische beperking. Met het uitgangspunt voor sequentiële focus is dit niet langer het geval. Als een element via een van de bovenstaande methoden verborgen is, gaat het indrukken van de Tab toets eenvoudigweg naar het volgende focusbare item.

Skiplinks zijn onzichtbare ankers die alleen via het toetsenbord te bereiken zijn. Ze stellen gebruikers in staat navigatie-elementen te “overslaan” om direct naar de inhoud van een pagina te gaan, en ze kunnen uiterst nuttig zijn voor gebruikers van toetsenborden en andere apparaten. Zoals uitgelegd op de WebAIM-site

Veel populaire websites implementeren links overslaan, ook al heb je ze misschien nog nooit opgemerkt.

Een skip-link op GitHub.com

Omdat skip-links ankers worden genoemd, werken ze op dezelfde manier als ons oorspronkelijke voorbeeld van de inhoudsopgave.

Waarschuwingen en ondersteuning

Het startpunt voor sequentiële focusnavigatie wordt momenteel alleen ondersteund in Chrome 50, Firefox en Opera. Totdat het in alle browsers wordt ondersteund, moet u nog steeds tabindex="-1" toevoegen (en de focusomtrek verwijderen) aan uw benoemde ankerdoelen.

Demo

Het startpunt voor sequentiële focusnavigatie is een geweldige aanvulling op de set toegankelijkheidsprimitieven van de browser. Het is gemakkelijk te groken en laat ons feitelijk code uit onze applicatie verwijderen terwijl we de ervaring voor onze gebruikers verbeteren. Dubbele overwinning! Bekijk de demo om deze functie dieper te verkennen.