WCAG 2.5.8: Doelgrootte (minimum)

Wat Deze Regel Betekent

WCAG 2.5.8 Target Size (Minimum) is een succescriterium op niveau AA dat is geïntroduceerd in WCAG 2.2. Het stelt dat de grootte van het doelwit voor pointer‑invoer minimaal 24×24 CSS‑pixels moet zijn, met één belangrijke uitzondering: als het doelwit zelf kleiner is dan 24×24 CSS‑pixels, dan moet er voldoende offset‑ruimte omheen zijn zodat het totale gebied — inclusief de ruimte — in elke richting aan de drempel van 24×24 voldoet. Met andere woorden: de begrenzingskader (bounding box) van het doelwit plus aangrenzende witruimte die vrij is van andere doelwitten moeten samen horizontaal 24 CSS‑pixels en verticaal 24 CSS‑pixels bereiken.

Het criterium is van toepassing op elk element dat een pointer‑event kan ontvangen: links (<a>), knoppen (<button>), selectievakjes, keuzerondjes, select‑besturingselementen, sliders, aangepaste widgets met pointer‑event‑listeners en elk element dat een ARIA‑rol krijgt die interactiviteit impliceert. Het is niet van toepassing op niet‑interactieve elementen zoals decoratieve afbeeldingen of statische tekst, zelfs niet als die toevallig groot zijn.

Een doelwit voldoet aan dit criterium wanneer ten minste één van de volgende punten waar is:

• De gerenderde grootte van het doelwit is in beide dimensies minimaal 24×24 CSS‑pixels.
• Het doelwit is kleiner dan 24 CSS‑pixels in één of beide dimensies, maar de afstand tussen de rand van het doelwit en het dichtstbijzijnde aangrenzende interactieve element is groot genoeg zodat het gecombineerde gebied van doelwit plus offset minimaal 24×24 CSS‑pixels is.
• Het doelwit is een inline element binnen een zin of tekstblok, wat expliciet is uitgesloten omdat het herflowen van zulke doelwitten het lezen zou verstoren.
• De visuele grootte van het doelwit wordt volledig bepaald door de standaard user‑agent‑stylesheet van de browser en de auteur heeft die niet aangepast — dit is de uitzondering voor native besturingselementen.
• Er bestaat een niet‑interactieve presentatie van dezelfde informatie en het kleine doelwit is slechts een alternatief, niet de enige manier om de actie uit te voeren.

Een doelwit voldoet niet wanneer het kleiner is dan 24×24 CSS‑pixels en er niet genoeg offset‑ruimte is om dat te compenseren, en geen van de bovenstaande uitzonderingen van toepassing is. Veelvoorkomende fouten in de praktijk zijn kleine knoppen die alleen uit een pictogram bestaan (zoals een 16×16 sluit‑icoon in een modal), dicht op elkaar gepakte navigatielinks met minimale padding, en rijen met social‑share‑iconen waarbij elk icoon op 20×20 pixels wordt gerenderd met slechts 2px marge ertussen.

Het is belangrijk om op te merken dat WCAG 2.5.8 een minimumvereiste is. Het verwante AAA‑criterium 2.5.5 Target Size (Enhanced) vereist minimaal 44×44 CSS‑pixels zonder uitzondering voor offset‑ruimte, en veel usability‑richtlijnen bevelen 44–48 CSS‑pixels aan als een comfortabele touch‑target. Voldoen aan 2.5.8 is de ondergrens, niet de bovengrens.

Waarom Het Belangrijk Is

Motorische beperkingen beïnvloeden de precisie van pointer‑gebruik op uiteenlopende manieren. Mensen met de ziekte van Parkinson, essentiële tremor, cerebrale parese, multiple sclerose, hemiplegie als gevolg van een beroerte of RSI‑klachten kunnen een pointer mogelijk niet betrouwbaar op een klein doelwit laten landen. Oudere volwassenen ervaren ook een natuurlijke afname van de fijne motoriek: ongeveer 15% van de mensen boven de 65 rapporteert aanzienlijke moeite met het gebruik van een muis of touchscreen. Buiten klinische aandoeningen hebben zelfs situationeel beperkte gebruikers — iemand die een smartphone met één hand vasthoudt in een rijdende bus, of iemand van wie de vinger groot is ten opzichte van een klein telefoonscherm — moeite met piepkleine doelwitten.

Volgens de Wereldgezondheidsorganisatie leven wereldwijd meer dan 1,3 miljard mensen met een of andere vorm van beperking, en motorische beperkingen behoren tot de meest voorkomende categorieën. Wanneer interactieve elementen te klein of te dicht op elkaar staan, ervaren deze gebruikers onbedoelde activaties, gemiste tikken en herhaalde fouten die een site in de praktijk onbruikbaar maken. De frustratie wordt versterkt op touch‑apparaten waar geen hover‑toestand bestaat om de cursorpositie te bevestigen voordat er wordt geklikt.

Beschouw een concreet scenario: een Turkse e‑commerce‑site die elektronica verkoopt toont bovenaan elke productpagina een rij van vijf social‑share‑iconen, elk 18×18 pixels met 3px ruimte ertussen. Een gebruiker met essentiële tremor die een product naar WhatsApp wil delen, tikt herhaaldelijk op het verkeerde icoon, waardoor ongewenste Facebook‑shares worden geactiveerd. Zij kan deze shares niet snel ongedaan maken en de taak wordt zo foutgevoelig dat ze die helemaal opgeeft. Het vergroten van elk icoon naar 24×24 CSS‑pixels, of het toevoegen van padding zodat het klikbare gebied 24×24 bereikt, zou het probleem oplossen zonder het visuele ontwerp significant te veranderen.

Los van toegankelijkheid hangt een adequate doelwitgrootte samen met hogere conversieratio’s, lagere bounce‑ratio’s en betere Core Web Vitals‑scores die te maken hebben met interactiegereedheid. Mobile‑first‑indexering door zoekmachines geeft bovendien de voorkeur aan pagina’s met goede touch‑bruikbaarheid, waardoor doelwitgrootte een factor wordt op het snijvlak van toegankelijkheid en SEO.

Gerelateerde Axe-core Regels

• target-size (experimental): Deze regel controleert of interactieve elementen een gerenderde grootte hebben van minimaal 24×24 CSS‑pixels of, voor kleinere elementen, of er voldoende offset‑ruimte bestaat zodat het totale bereikbare gebied aan de drempel voldoet. De regel bevraagt de berekende afmetingen en begrenzingsrechthoeken van focusbare en pointer‑interactieve elementen en markeert alle elementen die niet slagen voor de size‑of‑offset‑test. Omdat deze momenteel als experimental is gemarkeerd, is hij niet opgenomen in de standaardregels van axe‑core en moet hij expliciet worden ingeschakeld met runOnly: { type: 'tag', values: ['wcag22aa', 'experimental'] } of door experimentele regels in axe DevTools te activeren. De regel kan false positives opleveren voor inline tekstlinks en native besturingselementen die browsers per platform anders dimensioneren, dus handmatige controle wordt altijd aanbevolen na een geautomatiseerde scan. Hij kan niet betrouwbaar detecteren of er sprake is van een pass op basis van ruimte wanneer complexe CSS‑layouts, transforms of overlappende z‑index‑stapels betrokken zijn, wat de reden is dat handmatige inspectie van berekende stijlen in DevTools essentieel blijft.

Omdat doelwitgrootte afhangt van visuele rendering, berekende CSS, viewport‑afmetingen en de nabijheid van omliggende interactieve elementen, kunnen geautomatiseerde tools duidelijke fouten signaleren maar menselijke beoordeling niet vervangen. Een tool kan de bounding box van een knop meten, maar bepalen of de offset tussen twee aangrenzende doelwitten echt vrij is van andere interactieve elementen — zeker in dynamische of door JavaScript aangestuurde interfaces — vereist handmatige verificatie.

Hoe te Testen

1. Geautomatiseerde scan met axe DevTools: Installeer de axe DevTools‑browserextensie. Open de te testen pagina. Schakel in het axe DevTools‑paneel experimentele regels in voordat je de scan uitvoert (zoek naar de filter voor regel‑tags en voeg experimental toe). Filter na voltooiing van de scan de resultaten op de regel‑ID target-size. Noteer voor elk gemarkeerd element de gerapporteerde afmetingen. Bevestig de bevinding handmatig voordat je die als een definitieve fout registreert, omdat experimentele regels een hogere kans op false positives hebben.
2. Geautomatiseerde scan met Lighthouse: Voer een Lighthouse‑toegankelijkheidsaudit uit in Chrome DevTools of via de CLI. Lighthouse bevat een tap‑targets‑audit die controleert op doelwitten kleiner dan 48×48 CSS‑pixels met onvoldoende ruimte — let op dat dit een strengere drempel is dan WCAG 2.5.8, dus Lighthouse‑fouten zijn een superset van WCAG‑fouten. Bekijk de gemarkeerde elementen in het rapport en vergelijk ze met de WCAG‑drempel van 24×24 om te bepalen welke daadwerkelijke AA‑fouten zijn en welke best‑practice‑aanbevelingen.
3. Handmatige meting met browser DevTools: Open DevTools en inspecteer elk interactief element. Controleer in het Computed‑paneel width en height. Als een van beide onder 24px ligt, schakel dan over naar de Box Model‑weergave en controleer padding. Als padding het doelwit naar 24×24 brengt, voldoet het. Zo niet, meet dan de afstand tot het dichtstbijzijnde aangrenzende interactieve element met behulp van de begrenzingsrechthoek van het element: voer document.querySelector('your-selector').getBoundingClientRect() uit in de console en vergelijk de coördinaten van omliggende elementen. Als de gecombineerde ruimte in elke dimensie het effectief bereikbare gebied naar 24px brengt, voldoet het.
4. Touch‑simulatie: Schakel in Chrome DevTools apparaat‑emulatie in en kies een touch‑geoptimaliseerd apparaatprofiel. Probeer op elk klein interactief element te tikken. Noteer alle gevallen waarin het moeilijk is om het bedoelde element te activeren of waarin per ongeluk aangrenzende elementen worden geactiveerd.
5. Toetsenbord‑ en schermlezer‑testen (voor context): Hoewel WCAG 2.5.8 specifiek een pointer‑criterium is, helpt het bevestigen dat kleine doelwitten ook zichtbare focusindicatoren hebben en met het toetsenbord bereikbaar zijn om gecombineerde problemen te identificeren. Gebruik NVDA met Firefox of JAWS met Chrome om door interactieve elementen te navigeren en te bevestigen dat ze bereikbaar en activeerbaar zijn ongeacht hun grootte.
6. Testen op echte apparaten: Test op een fysiek mobiel apparaat — idealiter zowel een Android‑apparaat met groot scherm als een kleiner iOS‑apparaat — om te bevestigen dat doelwitten die op desktop voldoen ook voldoen bij mobiele viewport‑groottes, aangezien CSS‑pixeldichtheid en zoomgedrag de waargenomen doelwitgrootte kunnen beïnvloeden.

Hoe te Oplossen

Kleine knop met alleen pictogram — Onjuist

<!-- Close button is only 16x16 CSS pixels, no padding, adjacent to other controls -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    width: 16px;
    height: 16px;
    padding: 0;
    border: none;
    background: none;
    cursor: pointer;
  }
</style>

Kleine knop met alleen pictogram — Juist

<!-- Adding padding increases the interactive area to 24x24 CSS pixels
     while the visual icon remains 16x16. The min-width/min-height
     ensures the target meets the WCAG 2.5.8 threshold. -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    min-width: 24px;
    min-height: 24px;
    padding: 4px;
    border: none;
    background: none;
    cursor: pointer;
    display: inline-flex;
    align-items: center;
    justify-content: center;
  }
</style>

Dicht op elkaar gepakte navigatielinks — Onjuist

<!-- Each link renders at roughly 20px tall with 1px margin,
     leaving insufficient offset spacing between targets -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list li { margin: 1px 0; }
  .nav-list a { font-size: 12px; line-height: 1.4; display: block; }
</style>

Dicht op elkaar gepakte navigatielinks — Juist

<!-- Padding on each anchor ensures the target area is at least 24px tall.
     The gap between items is now large enough to satisfy the offset rule
     even if the text itself is smaller than 24px. -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list { list-style: none; padding: 0; margin: 0; }
  .nav-list a {
    display: block;
    padding: 6px 8px; /* vertical padding brings block height to >= 24px */
    font-size: 14px;
    line-height: 1.4;
    text-decoration: none;
  }
</style>

Selectievakje met piepklein klikgebied — Onjuist

<!-- The default checkbox is visually 13px on many browsers and has no
     associated label providing additional target area -->
<input type='checkbox' id='agree'>
<span>I agree to the terms</span>

Selectievakje met gekoppeld label — Juist

<!-- Wrapping the input in a <label> makes the entire label text also
     a valid pointer target. The label's line-height and padding ensure
     the combined hit area easily exceeds 24x24 CSS pixels.
     The input itself is given min-width/min-height as a fallback. -->
<label class='checkbox-label'>
  <input type='checkbox' id='agree' class='checkbox-input'>
  I agree to the terms
</label>

<style>
  .checkbox-label {
    display: inline-flex;
    align-items: center;
    gap: 8px;
    padding: 4px 0;
    cursor: pointer;
    min-height: 24px;
  }
  .checkbox-input {
    min-width: 24px;
    min-height: 24px;
    cursor: pointer;
  }
</style>

Rij met social‑share‑iconen — Onjuist

<!-- Each icon is 18x18px with only 2px gap; the combined
     reachable area for each icon is only 20px, below the 24px threshold -->
<div class='share-row'>
  <a href='#' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 2px; }
  .share-row a { display: inline-block; line-height: 1; }
</style>

Rij met social‑share‑iconen — Juist

<!-- Each anchor now has min-width and min-height of 24px via padding,
     and the gap between anchors is at least 3px so the offset rule is
     satisfied independently even without the padding. -->
<div class='share-row'>
  <a href='#' class='share-link' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' class='share-link' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 6px; }
  .share-link {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: 24px;
    min-height: 24px;
    padding: 3px;
  }
</style>

Veelvoorkomende Fouten

• width en height instellen op het pictogram binnen een knop in plaats van op de knop zelf: Ontwikkelaars beperken vaak de SVG of afbeelding tot 16–20px maar vergeten dat het <button>‑element min-width: 24px; min-height: 24px en passende padding nodig heeft om een voldoende groot tap‑doelwit te creëren.
• Standaard browser‑padding verwijderen van knoppen en invoervelden met padding: 0 of een globale reset: CSS‑resets die padding op formulierelementen op nul zetten, verwijderen de buffer die native besturingselementen op een bruikbare grootte houdt. Voeg na een reset altijd expliciet padding opnieuw toe.
• Alleen vertrouwen op line-height om de linkhoogte te vergroten zonder display: block of display: inline-block: Inline elementen reageren niet op height of verticale padding zoals block‑elementen dat doen, waardoor een link er visueel hoger uit kan zien terwijl de daadwerkelijke klikbare bounding box klein blijft.
• pointer-events: none gebruiken op een wrapper en click‑handlers koppelen aan een piepklein binnenste element: Dit maakt elke padding of min‑grootte op de wrapper ongedaan en reduceert het effectieve doelwit tot de gerenderde grootte van het binnenste element.
• overflow: hidden toepassen op een knopcontainer die de padding van de knop afknipt: Het visuele klikgebied wordt beperkt tot de grenzen van de container, waardoor het effectieve doelwit kleiner wordt dan de afmetingen van de knop doen vermoeden.
• Vergeten rekening te houden met CSS‑transforms zoals scale(): Een knop die visueel wordt verkleind via transform: scale(0.7) behoudt in de meeste browsers zijn oorspronkelijke bounding box voor pointer‑events, maar dit gedrag is inconsistent en onbetrouwbaar — zorg er altijd voor dat doelwitten op hun uiteindelijke gerenderde schaal groot genoeg zijn.
• Aannemen dat een groot <label> een piepkleine <input> compenseert wanneer label en input niet programmatisch gekoppeld zijn: Als het <label> geen for gebruikt dat overeenkomt met de id van de input, of als de input niet binnen het label is gewrapt, activeert klikken op de labeltekst de input niet en is alleen het kleine doelwitgebied van de input functioneel.
• Niet testen op de viewport‑groottes waarop doelwitten daadwerkelijk worden gerenderd: Een knop die op desktop 32×32 CSS‑pixels is, kan op een smalle mobiele viewport op 22×22 CSS‑pixels worden gerenderd door vloeiende schaal of viewport‑relatieve eenheden (vw, vmin), waardoor een fout ontstaat die alleen op mobiel zichtbaar is.
• De WCAG 2.5.8‑uitzondering voor inline tekstlinks te ruim interpreteren: De uitzondering geldt alleen voor links die echt inline staan binnen een tekstregel (bijv. een hyperlink in een alinea). Losstaande links die eruitzien als tekst — zoals een link “Wachtwoord vergeten?” onder een formulier — zijn geen inline links en moeten aan de drempel van 24×24 voldoen.
• Verzuimen om third‑party‑widgets en ingesloten componenten te auditen: Cookie‑toestemmingsbanners, chat‑widgets en analytics‑overlays bevatten vaak piepkleine knoppen (accepteren, sluiten, minimaliseren) die door externe scripts worden geïnjecteerd. Deze maken nog steeds deel uit van het toegankelijkheidsprofiel van de pagina en moeten voldoen aan WCAG 2.5.8, ook als de code niet in‑house is ontwikkeld.

Relatie met de Turkse Toegankelijkheidsregelgeving

De Turkse Presidentiële Circulaire 2025/10, gepubliceerd in Staatsblad nr. 32933 op 21 juni 2025, stelt bindende toegankelijkheidseisen vast voor een brede groep digitale dienstverleners die in Turkije actief zijn. De Circulaire verwijst expliciet naar WCAG 2.2 als technische standaard, en conformiteit op niveau AA is vereist om in aanmerking te komen voor het Erişilebilirlik Logosu (Toegankelijkheidslogo) dat wordt uitgegeven door het Ministerie van Gezin en Sociale Diensten (Aile ve Sosyal Hizmetler Bakanlığı). Omdat WCAG 2.5.8 een criterium op niveau AA is in WCAG 2.2, valt het rechtstreeks binnen de reikwijdte van dit verplichte kader.

De entiteitstypen die onder de Circulaire vallen, omvatten overheidsinstellingen en ‑organen op centraal en lokaal niveau, banken en financiële dienstverleners, ziekenhuizen en particuliere zorgaanbieders, telecomoperators met 200.000 of meer abonnees, e‑commerce‑platforms, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (Milli Eğitim Bakanlığı). Voor al deze organisaties is naleving van WCAG 2.5.8 niet slechts een best‑practice‑aanbeveling — het is een wettelijke verplichting die is gekoppeld aan de mogelijkheid om het Toegankelijkheidslogo te tonen en om tijdens audits juridische conformiteit aan te tonen.

In praktische termen betekent dit dat de mobiel‑responsieve webapplicatie van een Turkse bank ervoor moet zorgen dat de knoppen voor het bevestigen van overboekingen, invoervelden voor eenmalige wachtwoorden en navigatie‑besturingselementen allemaal voldoen aan de minimale doelwitgrootte van 24×24 CSS‑pixels. Evenzo moet een e‑commerce‑site verifiëren dat de knoppen “toevoegen aan winkelwagen”, hoeveelheidselectoren en filterbesturingselementen op alle apparaatprofielen voldoende groot zijn. Zorgportalen moeten afspraak‑kalenders auditen, die berucht zijn om hun kleine datumcellen, en deze cellen vergroten of voldoende offset‑ruimte bieden. Self‑service‑portalen van telecombedrijven moeten controleren of hun accountbeheerlinks en toggle‑besturingselementen in data‑bundel‑selectoren aan de drempel voldoen.

Niet‑naleving van de Circulaire kan leiden tot administratieve sancties en kan een organisatie beletten het Toegankelijkheidslogo te tonen, dat door Turkse consumenten in toenemende mate als vertrouwenssignaal wordt gebruikt. Los van sancties stelt niet‑naleving organisaties bloot aan klachten bij de relevante toezichthoudende instanties. Gezien het feit dat Turkije een groeiende populatie oudere volwassenen heeft — het Turkse Statistische Instituut voorspelt dat mensen van 65 jaar en ouder in 2040 16,3% van de bevolking zullen uitmaken — zal de praktische impact van kleine doelwitten alleen maar toenemen, waardoor vroege naleving zowel een ethische prioriteit als een verstandige langetermijnbedrijfsstrategie is.