Je sluit het venster. Waar gaat je toetsenbordfocus daarna heen?

Een dialoogvenster kan er keurig uitzien en toch een gebruiker laten verdwalen. Je opent “Project bewerken”, verandert een naam en drukt op Opslaan. Het venster verdwijnt. De volgende Tab brengt je ineens naar de navigatie bovenaan. Met een muis herstel je dat misschien zonder nadenken. Met alleen een toetsenbord moet je opnieuw uitzoeken waar je was.

De terugweg verdient daarom een eigen ontwerpbeslissing. Niet pas wanneer iemand een bug meldt, maar zodra je bepaalt wat Opslaan, Annuleren en Sluiten doen. Hieronder werken we een fictief projectoverzicht uit. Het is een ontwerp- en testaanpak, geen claim dat een bepaalde app of componentbibliotheek dit al correct uitvoert.

De basis uit het W3C-patroon

Het WAI-ARIA Authoring Practices-patroon beschrijft dat focus een modale dialoog binnengaat en dat Tab en Shift+Tab binnen die dialoog blijven. Escape sluit het venster. Na sluiten gaat focus gewoonlijk terug naar het element dat het opende. Bestaat dat niet meer, dan is een ander logisch vervolgpunt nodig. Het patroon noemt ook een uitzondering wanneer de afgeronde taak direct naar een volgende stap leidt. Een zichtbare sluitknop hoort bereikbaar te zijn. Dit patroon is een bouwrichtlijn; het volgen ervan alleen bewijst geen volledige toegankelijkheid.

Begin met een simpele bewerking

SITUATIE
Een fictieve lijst toont project Atlas. De knop “Atlas bewerken” opent een dialoog met een naamveld en de knoppen Annuleren en Opslaan.

VERWACHTE ROUTE
Openen: focus komt op een passend element binnen het venster. Annuleren: focus keert terug naar “Atlas bewerken”. Opslaan: de lijst toont de aangepaste naam, focus keert terug naar de bijbehorende bewerkknop. De volgende Tab gaat verder vanaf die positie, niet vanaf de paginatop.

Leg niet alleen een selector zoals “de eerste bewerkknop” vast. In een lijst met twintig projecten is dat de verkeerde context. Je wilt onthouden welke concrete knop deze dialoog opende en bij sluiten controleren of die nog bestaat en bruikbaar is. Als de lijst na opslaan opnieuw wordt opgebouwd, kan hetzelfde project een nieuw element krijgen. Ontwerp ook voor die situatie een terugvindbare bestemming.

Verwijderen verandert de terugweg

Stel dat de dialoog juist dient om Atlas te verwijderen. Na bevestiging verdwijnen de rij én de oorspronkelijke knop. Focus terugsturen naar die verwijderde knop kan dan niet. Kies vooraf een alternatief dat de gebruiker helpt verder te werken: bijvoorbeeld de equivalente actie in de volgende rij. Was Atlas de laatste rij, dan kan de vorige rij passend zijn. Is de lijst leeg, dan kan “Nieuw project” een logisch vervolg zijn. Dit zijn ontwerpkeuzes voor dit voorbeeld, geen universele W3C-voorschriften.

1. Schrijf per afsluitroute op wat er verandert: alleen het venster, ook de rij, de sortering of zelfs de hele pagina.
2. Kies de normale terugkeerplek en één expliciete fallback wanneer die plek niet meer beschikbaar is.
3. Laat de ontwikkelaar na de bijgewerkte weergave focussen op een bestaand, zichtbaar en bruikbaar element. Een verwijzing naar een oud element is niet voldoende.
4. Test de route met de eerste, middelste en laatste rij. Test ook de overgang naar een lege lijst.
5. Controleer of de zichtbare focusmarkering de gekozen bestemming duidelijk maakt. De technische focuspositie en wat iemand op het scherm ziet moeten overeenkomen.

Test ook een mislukte opslag

Een foutmelding is geen succesvolle afsluiting. Als een opslag mislukt, moet de interface helder maken wat er aan de hand is en welke handeling nog mogelijk is. Controleer dat focus niet al naar de achtergrond verhuist terwijl het venster openblijft. Controleer vervolgens de herstelroute: gegevens aanpassen, opnieuw proberen, annuleren en opnieuw openen. Gebruik testgegevens en een veilige testomgeving, zeker wanneer de handeling records verwijdert.

Een tweede dialoog boven de eerste maakt de keten langer. Sluit je de bovenste, dan hoort je vervolgpunt bij de nog openstaande dialoog, niet meteen bij de pagina erachter. Test dit afzonderlijk in de echte component. Ook scrollpositie telt mee: als de lijst verspringt en de focus buiten beeld belandt, is de route voor de gebruiker nog steeds onduidelijk.

Een korte testkaart voor je team

• Open de dialoog zonder muis en noteer waar focus begint.
• Loop met Tab en Shift+Tab door de inhoud; je mag niet ongemerkt op achtergrondacties belanden.
• Sluit via Annuleren, de sluitknop en Escape. Controleer elke route afzonderlijk.
• Sla een wijziging op en controleer de eerstvolgende Tab.
• Verwijder een testitem en controleer de gekozen fallback, inclusief een lege lijst.
• Herhaal met een schermlezer en de browsers die je ondersteunt; een visuele check alleen is niet genoeg.

Noteer per fout de beginactie, afsluitactie, verwachte bestemming en werkelijke bestemming. “Focus werkt niet” geeft een ontwikkelaar weinig houvast. “Na verwijderen van de laatste rij belandt Tab op de browserbalk in plaats van Nieuw project” maakt het probleem reproduceerbaar. Zo wordt de terugweg een concreet onderdeel van je acceptatiecriteria in plaats van een detail dat tussen ontwerp en oplevering verdwijnt.