Wcag 2.2: focus visible en focus appearance — praktijkgids (24 augustus 2025)

Focus visible en focus appearance volgens WCAG 2.2

Focusindicatoren bepalen of toetsenbordgebruikers en mensen met motorische of visuele beperkingen kunnen navigeren. WCAG 2.2 voegt expliciete eisen rond de zichtbaarheid en verschijning van focus toe (zie onder meer succescriteria 2.4.11 en 2.4.12) en vraagt dat focus niet alleen met kleur wordt aangegeven en dat de indicator voldoende contrast en grootte heeft.

Deze korte gids richt zich op praktische implementatie en teststappen voor designers, developers en redacties. Gebruik semantische HTML als eerste keuze; voeg ARIA alleen toe als er geen semantische oplossing is. Gebruik tooling zoals axe, Lighthouse en pa11y als aanvulling op handmatige toetsen, niet als vervanging.

Praktische teststappen

Tab door alle interactieve elementen; controleer dat focus zichtbaar blijft en niet verdwijnt bij dynamische updates; controleer dat focus niet alleen uit kleur bestaat; controleer contrast van de focusindicator met aangrenzende kleuren; test met :focus en :focus-visible en met schermvergroting en hoge-contrastinstellingen.

Concrete implementaties voor developers

Gebruik standaard focusstijlen van browsers tenzij je ze verbetert. Verwijder nooit outlines zonder een goede vervanging. Geef prioriteit aan semantische elementen (button, a, input). Als je custom components bouwt, zorg dat ze keyboard-focus, aria-focussable waar relevant en focusbeheer correct ondersteunen.

Voor moderne browsers is :focus-visible handig om onnodige focusringen bij muisinteractie te voorkomen. Combineer dit met een duidelijke focusstijl die zichtbaar is bij toetsenbordnavigatie.

Voorbeeld CSS: duidelijke focusstijl

Voorbeeld met outline en outline-offset; vervang kleuren door je designtokens.

/* Duidelijke focusstijl - gebruik semantische elementen */:focus{outline:3px solid #034ea2;outline-offset:3px}/* Gebruik :focus-visible om muisklikken niet te benadrukken */:focus:not(:focus-visible){outline: none;}/* Alternatief met box-shadow voor afgeronde elementen */button:focus{box-shadow:0 0 0 3px rgba(3,78,162,0.25);}

Accessible patterns voor custom components

Als je custom controls maakt, zorg dat ze tabindex, role en keyboard events adequaat ondersteunen en dat focus zichtbaar is wanneer het element focus krijgt via scripting of keyboard. Probeer semantische elementen te wrappen in custom styling in plaats van elementen te vervangen door divs met click handlers.

HTML-voorbeeld: knop met semantiek

Gebruik native elementen waar mogelijk. Als je een div als knop gebruikt, voeg minimaal role en tabindex toe en manage key handlers.

<button class="btn">Opslaan</button>/* Slecht: div als knop */<div role="button" tabindex="0">Opslaan</div>

Tips voor designers

Ontwerp focusindicatoren in de componentbibliotheek en documenteer kleur, dikte en afstand tot content. Zorg dat focusindicatoren niet samensmelten met achtergrondpatronen en test ernstige cornercases zoals overlappende componenten en modals.

  • Maak focus zichtbaar op alle interactieve toestanden (focus, focus-visible).
  • Documenteer focus in design tokens en componentspecs.
  • Werk samen met developers op responsive en zoom-scenarios.

Mini-checklist developers

Gebruik deze stappen tijdens code-review en testing.

  • Tabben door de pagina: is elke interactieve control bereikbaar?
  • Is de focusindicator zichtbaar en persistent bij keyboard focus?
  • Verwijder je geen browser-outline zonder vervanging?
  • Is de indicator niet alleen kleurafhankelijk?
  • Werkt :focus-visible en is er een fallback voor browsers zonder ondersteuning (bijv. focus-visible polyfill)?

Checklist redacties en contentteams

Redacties kunnen onbedoeld focusproblemen introduceren door inline script of linkstructuren. Let op dynamische content en bewerkbare velden.

  • Zijn links en knoppen semantisch correct (a, button)?
  • Voegt content scripts toe die focus verplaatsen of verbergen?
  • Controleer alt-teksten en labels die relevant zijn voor focusable widgets.

Testtools en handmatige checks

Gebruik axe, Lighthouse en pa11y om regressies te vinden, maar voer altijd handmatige toetsen uit: tab-navigatie, toetsenbord-only scenario’s en visuele inspectie bij hoge zoom en thema’s met laag contrast. Raadpleeg de WCAG 2.2-succescriteria (zoals 2.4.11 en 2.4.12) voor formele eisen en teststappen.

Handige teststappen samengevat

Tab door de site; test met schermvergroting; schakel muis uit of gebruik enkel toetsenbord; controleer focus onder modals, dialogs en dynamische updates; meet contrast van focusindicatoren waar nodig.

ARIA en focus

Gebruik ARIA alleen als semantische HTML niet volstaat. ARIA kan focusgedrag zichtbaar maken of ondersteunen, maar lost geen styling- of contrastproblemen op. Vermijd tabindex>0 en beheers programmatic focus zorgvuldig om verwarring te voorkomen.

Voor complexe widgets implementeer aria-activedescendant, roletype en focusbeheer volgens WAI-ARIA authoring practices wanneer native elementen niet toepasbaar zijn.

trefwoorden: wcag 2.2, focus visible, focus appearance, toegankelijkheid, focus-styles, :focus-visible, semantische html

Previous Post Next Post

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *