WCAG 2.5.5: Doelgrootte (Uitgebreid)

Wat Deze Regel Betekent

WCAG 2.5.5 Target Size (Enhanced) is een criterium op Niveau AAA onder WCAG 2.2 dat een strikte minimale grootte vastlegt voor interactieve elementen. Concreet vereist het dat de grootte van het doel — het klikbare of tikbare gebied van een gebruikersinterfacecomponent — minimaal 44 bij 44 CSS-pixels is in zowel breedte als hoogte. Dit geldt voor alle pointer-gebaseerde interacties, waaronder muiskliks, aanrakingen op een touchscreen en invoer met een stylus.

Het is belangrijk te begrijpen wat precies het "doel" vormt in deze context. Het doel is het volledige activeerbare gebied van de bediening, niet alleen de visuele weergave. Een klein pictogram kan visueel 16×16 pixels zijn, maar als de omliggende padding het klikbare gebied uitbreidt tot 44×44 pixels, kan nog steeds aan het criterium worden voldaan. Dit betekent dat ontwikkelaars padding strategisch kunnen gebruiken om aan de eis te voldoen zonder het visuele ontwerp drastisch te wijzigen.

Het criterium definieert een pass als elk interactief element waarvan het doelgebied ten minste 44×44 CSS-pixels meet. Een fail treedt op wanneer het activeerbare gebied van een interactief element onder deze drempel valt in een van beide dimensies — bijvoorbeeld, een link die 44 pixels breed maar slechts 20 pixels hoog is, zou nog steeds falen.

WCAG 2.5.5 biedt verschillende officiële uitzonderingen waarbij de eis van 44×44 niet van toepassing is. Dit zijn:

• Spacing: Te kleine doelen zijn acceptabel als voldoende offsetruimte ze scheidt van alle andere doelen. Het doel moet zo gepositioneerd zijn dat, als er een cirkel van 44×44 CSS-pixels op wordt gecentreerd, die cirkel geen ander doel of de begrenzingsbox van de 44×44-cirkel van een ander doel snijdt. Deze uitzondering voorkomt dat de regel lay-outwijzigingen vereist wanneer aangrenzende bedieningselementen van nature klein maar goed gescheiden zijn.
• Equivalent: Een alternatieve bediening op dezelfde pagina voert dezelfde functie uit en voldoet aan de minimale grootte-eis.
• Inline: Het doel bevindt zich in een zin of de grootte ervan wordt anderszins beperkt door de regelhoogte (line-height) van niet-doeltekst. Hyperlinks binnen een alinea lopende tekst zijn bijvoorbeeld uitgezonderd omdat het vergroten ervan de tekststroom zou verstoren.
• User agent control: De grootte wordt volledig bepaald door de browser of het besturingssysteem en kan niet door de auteur worden gewijzigd. In hun ongestylede staat kunnen native browser-formulierelementen in deze categorie vallen.
• Essential: Een bepaalde presentatie van het doel is essentieel voor de over te brengen informatie. Dit is een beperkte uitzondering voor gevallen waarin het wijzigen van de doelgrootte de betekenis of functionaliteit fundamenteel zou veranderen.

Dit criterium is geïntroduceerd in WCAG 2.2 en vervangt de eerdere, minder strikte richtlijnen voor pointerdoelen. Het bijbehorende criterium, WCAG 2.5.8 Target Size (Minimum) op Niveau AA, stelt een lagere grens van 24×24 CSS-pixels met een op spacing gebaseerde berekening, maar 2.5.5 blijft de gouden standaard voor verbeterde toegankelijkheid.

Waarom Het Belangrijk Is

Motorische en vaardigheidsbeperkingen treffen een aanzienlijk deel van de wereldbevolking. Volgens de Wereldgezondheidsorganisatie leven ongeveer 1,3 miljard mensen — ofwel 16% van de wereldbevolking — met een vorm van significante beperking, waarbij motorische en musculoskeletale aandoeningen tot de meest voorkomende behoren. Aandoeningen zoals de ziekte van Parkinson, essentiële tremor, cerebrale parese, multiple sclerose, hemiplegie als gevolg van een beroerte en RSI verminderen allemaal het vermogen van een persoon om precieze pointerbewegingen uit te voeren. Op mobiele apparaten kunnen zelfs gebruikers zonder beperkingen moeite hebben met kleine doelen wanneer ze handschoenen dragen, wanneer hun handen nat zijn, of simpelweg wanneer ze een telefoon met één hand gebruiken.

Beschouw een concreet scenario uit de echte wereld: een persoon met reumatoïde artritis bladert op een touchscreen-tablet door een Turkse e-commerceplatform om medicatie te kopen. De checkout-flow bevat kleine keuzerondjes, smalle dropdownmenu’s en een "Bestelling bevestigen"-knop van 24×18 pixels. Elke mis-tik selecteert ofwel de verkeerde optie of doet niets, waardoor de gebruiker meerdere keren moet proberen. De frustratie is niet slechts onhandig — het kan ertoe leiden dat de aankoop volledig wordt afgebroken, waardoor een toegankelijkheidsfout direct omzetverlies voor het bedrijf wordt.

Naast motorische beperkingen komen voldoende grote doelen een brede groep gebruikers ten goede. Oudere volwassenen ervaren vaak tegelijkertijd een verminderd fijne motoriek en afnemende gezichtsscherpte, waardoor kleine doelen dubbel zo moeilijk worden. Gebruikers met cognitieve beperkingen kunnen meer tijd nodig hebben om een pointer te positioneren en hebben meer kans om aangrenzende bedieningselementen te activeren als doelen dicht op elkaar staan. Zelfs ziende, valide gebruikers profiteren van grotere doelen op mobiele apparaten — een waarheid die al jaren ontwerpconventies bij grote technologiebedrijven aanstuurt. De Human Interface Guidelines van Apple bevelen een minimale tikdoelgrootte van 44×44 punten aan, en de Material Design-richtlijnen van Google bevelen minstens 48×48 density-independent pixels aan om dezelfde redenen.

Vanuit SEO- en bruikbaarheidsperspectief beloont Google's Core Web Vitals-metric "Interaction to Next Paint" (INP) interfaces waarbij gebruikersinteracties snel en correct worden geregistreerd. Mis-tikken door te kleine doelen verhogen de interactiefoutpercentages, verlengen de taakduur en verhogen de bounce rates — allemaal signalen die de zoekrangschikking indirect kunnen beïnvloeden. Toegankelijkheidsverbeteringen op het niveau van pointerdoelen hebben daarom meetbare zakelijke gevolgen die verder gaan dan naleving.

Gerelateerde Axe-core-regels

WCAG 2.5.5 vereist handmatige tests. Er is geen volledig geautomatiseerde axe-core-regel die betrouwbaar alle schendingen van doelgrootte voor dit verbeterde criterium markeert. De reden dat geautomatiseerde tools hier moeite mee hebben is veelzijdig: de effectieve doelgrootte hangt af van de berekende CSS-layout, inclusief padding, margin en pseudo-elementafmetingen die variëren per viewport, device pixel ratio en dynamische rendering. Daarnaast vereist de spacing-uitzondering het berekenen van de geometrische offset tussen aangrenzende doelen — een berekening die de volledige gerenderde lay-outboom en nabijheidsanalyse vereist, iets wat geautomatiseerde DOM-parsingtools niet in alle gevallen nauwkeurig kunnen uitvoeren. Bovendien vereist de vraag of een element in aanmerking komt voor de "inline"- of "equivalent"-uitzondering semantisch en contextueel begrip dat buiten het bereik van geautomatiseerde regelengines ligt.

• target-size (axe-core experimental): Axe-core bevat een experimentele regel genaamd target-size die interactieve elementen toetst aan de WCAG 2.5.8 Niveau AA-drempel van 24×24 CSS-pixels met spacing-offsets. Hoewel deze regel sommige kleinere overtredingen kan aan het licht brengen, handhaaft hij niet de strengere 44×44-drempel die door 2.5.5 wordt vereist, en hij kan overtredingen missen waarbij padding of pseudo-elementen het gerenderde hitgebied beïnvloeden op manieren die de DOM-snapshot niet vastlegt. Behandel alle resultaten van deze regel als een startpunt, niet als een volledige audit.
• Handmatige visuele inspectie: Omdat geen enkele geautomatiseerde regel 2.5.5 volledig dekt, moeten testers interactieve doelen visueel inspecteren en meten met behulp van browserontwikkeltools, CSS-pixel-linialen of toegankelijkheidsbrowserextensies. Dit omvat het controleren dat padding is opgenomen in het hitgebied en dat aan spacing-uitzonderingen daadwerkelijk wordt voldaan — niet alleen verondersteld.

Hoe te Testen

1. Voer een geautomatiseerde scan uit als basislijn: Open axe DevTools of Lighthouse in Chrome DevTools op de te testen pagina. Filter in axe DevTools de resultaten op "target-size" indien beschikbaar onder experimentele regels. Noteer alle gemarkeerde elementen, maar begrijp dat deze scan niet alle 2.5.5-overtredingen zal detecteren en mogelijk verwijst naar de 2.5.8-drempel in plaats van 44×44 pixels. Gebruik de toegankelijkheidsaudit van Lighthouse om te zoeken naar gerelateerde waarschuwingen over pointerdoelen.
2. Meet doelgroottes met browser DevTools: Open Chrome of Firefox DevTools en gebruik het Elements-paneel om elk interactief element te inspecteren — knoppen, links, formuliervelden, selectievakjes, keuzerondjes, aangepaste bedieningselementen en alleen-pictogramknoppen. Controleer in het paneel Computed styles de gerenderde breedte en hoogte. Onthoud dat padding is inbegrepen in het klikdoel voor block-level elementen, maar mogelijk niet voor inline-elementen. Verifieer dat het berekende hitgebied minimaal 44×44 CSS-pixels is.
3. Gebruik de ingebouwde toegankelijkheidstools van de browser: Open in Chrome DevTools het tabblad Rendering en schakel "Emulate a focused page" in of gebruik de Accessibility Tree om elementen te inspecteren. Gebruik voor Firefox de Accessibility Inspector om interactieve elementen te identificeren en hun begrenzingsboxafmetingen te controleren.
4. Test op echte touch-apparaten: Verbind een fysiek iOS-apparaat en test met VoiceOver ingeschakeld (druk driemaal op de zijknop om te activeren). Navigeer door te tikken en gebruik de rotor om tussen interactieve elementen te bewegen. Probeer kleine doelen te activeren en noteer hoe vaak per ongeluk aangrenzende elementen worden geactiveerd. Herhaal dit op een Android-apparaat met TalkBack (veeg naar rechts om te navigeren, dubbel tik om te activeren). Let in het bijzonder op aangepaste widgets die zijn opgebouwd uit <div>- of <span>-elementen.
5. Test spacing-uitzonderingen handmatig: Teken voor elk doel kleiner dan 44×44 pixels dat aanspraak maakt op de spacing-uitzondering een denkbeeldige begrenzingsbox van 44×44 pixels gecentreerd op dat doel en controleer visueel dat geen enkel ander interactief element binnen die box valt. Browserextensies of overlaytools die begrenzingsboxen tekenen, kunnen hierbij helpen.
6. Toets met toetsenbord en schermlezer: Test met NVDA + Firefox en JAWS + Chrome door met Tab langs alle interactieve elementen te gaan. Hoewel toetsenbordfocus de pointerdoelgrootte niet direct test, helpt het te identificeren of alle bedieningselementen bereikbaar zijn en bevestigt het de lijst met elementen waarmee je de pointergroottes kruislings controleert. VoiceOver + Safari op macOS kan worden gebruikt om te verifiëren dat aangepaste bedieningselementen zichzelf correct aankondigen en voldoende activatiegebieden hebben wanneer erop wordt geklikt met een pointer.
7. Test bij meerdere viewportgroottes: Doelgroottes kunnen variëren tussen desktop- en mobiele layouts. Test bij viewportbreedtes van 320px, 768px en 1280px om te bevestigen dat responsive ontwerpen de minimumgrootte van 44×44 op alle breakpoints behouden, met name in hamburgermenu’s, carrousels en actiekolommen in datatabellen.

Hoe te Oplossen

Alleen-pictogramknop met onvoldoende grootte — Onjuist

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

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

Alleen-pictogramknop met onvoldoende grootte — Correct

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Aangepast selectievakje opgebouwd uit een div — Onjuist

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

Aangepast selectievakje opgebouwd uit een div — Correct

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Navigatielinks in een toolbar met krappe spacing — Onjuist

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Navigatielinks in een toolbar met krappe spacing — Correct

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Veelvoorkomende Fouten

• Aannemen dat de visuele begrenzingsbox gelijk is aan het hitgebied: width: 44px; height: 44px instellen op het pictogramafbeeldingselement binnen een knop maakt de knop niet 44×44 — alleen het toepassen van die afmetingen of equivalente padding op het <button>-element zelf creëert het juiste hitgebied.
• padding: 0 gebruiken om browserstijlen te resetten zonder compenserende minimumgrootte: CSS-resets verwijderen vaak alle padding van knoppen en invoervelden. Breng na een reset altijd voldoende padding of expliciete waarden voor min-width en min-height opnieuw aan om het activatiegebied te herstellen.
• Alleen vertrouwen op line-height om de doelhoogte te vergroten: Het verhogen van line-height beïnvloedt de tekstafstand, maar vergroot niet altijd het klikbare gebied van een anker of knop. Gebruik in plaats daarvan padding-top en padding-bottom.
• Meerdere kleine pictogramknoppen naast elkaar plaatsen zonder voldoende spacing: Een rij socialmedia-deelpictogrammen van 24×24 met slechts 2px marge voldoet niet aan de grootte-eis en ook niet aan de spacing-uitzondering, omdat de 44px-cirkels die op elk pictogram zijn gecentreerd elkaar zouden overlappen.
• De inline-tekstuizondering verkeerd toepassen op navigatielinks: De uitzondering geldt voor links binnen een zin of alinea lopende tekst. Navigatiemenu’s, toolbars en lijsten met links zijn geen inline tekst en komen niet in aanmerking voor deze uitzondering, zelfs niet als ze display: inline gebruiken.
• Aangepaste bedieningselementen bouwen met role='button' op een <span> en vergeten de span te dimensioneren: Schermlezers kondigen de span aan als een knop, maar de standaard gerenderde grootte wordt alleen bepaald door de tekstinhoud, die doorgaans ver onder 44×44 pixels ligt. Voeg altijd display: inline-flex, min-width, min-height en padding toe.
• Niet testen op echte touch-apparaten bij de daadwerkelijke viewportgrootte: Pixels meten in desktop DevTools is niet voldoende. De dichtheid van CSS-pixels en het hit-testgedrag van touchdoelen op OS-niveau kunnen verschillen tussen gesimuleerde en fysieke apparaatomgevingen.
• Dynamisch gerenderde bedieningselementen over het hoofd zien: Tooltips, dagcellen in datepickers, items in autosuggestielijsten en modale sluitknoppen worden vaak geïnjecteerd door JavaScript-bibliotheken met hardgecodeerde kleine groottes. Controleer de output van widgets van derden en overschrijf hun stijlen indien nodig.
• Aanspraak maken op de spacing-uitzondering zonder deze te meten: De spacing-uitzondering is geometrisch en precies. Visueel aannemen dat bedieningselementen ver genoeg uit elkaar lijken te staan is niet voldoende — de 44px-cirkeltest moet op elk te klein doel worden toegepast om te bevestigen dat er geen overlap is.
• Vergeten te verifiëren na wijzigingen in responsive breakpoints: Een knop die 44×44 is op desktop kan ineenkrimpen tot 30×30 op een mobiele viewport van 375px door percentagebreedtes of flexbox-shrinking. Test doelgroottes altijd opnieuw op elk belangrijk breakpoint.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular No. 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte toegankelijkheidseisen voor web en mobiel vast op basis van de WCAG 2.2-standaard. De circulaire is van toepassing op een gedefinieerde set entiteiten die in Turkije actief zijn en legt wettelijke verplichtingen op voor conformiteit met specifieke WCAG-niveaus.

De onder de circulaire vallende entiteitstypen omvatten: publieke instellingen en agentschappen op zowel centraal als lokaal overheidsniveau; banken en financiële instellingen die worden gereguleerd door de Banking Regulation and Supervision Agency (BDDK); ziekenhuizen en zorgaanbieders, zowel publiek als privaat; telecommunicatie-operators met 200.000 of meer abonnees; e-commerceplatforms boven gespecificeerde omzet- of transactiedrempels; reisagentschappen die online boekingsdiensten aanbieden; particuliere vervoersbedrijven die digitale ticketing of reservering aanbieden; en particuliere scholen en onderwijsinstellingen die zijn gemachtigd door het Ministry of National Education (MoNE).

WCAG 2.5.5 Target Size (Enhanced) is een Niveau AAA-criterium en behoort niet tot de minimale verplichte eisen die door de circulaire zijn vastgesteld, die zich primair richt op conformiteit met Niveau A en AA. De circulaire moedigt de betrokken entiteiten echter expliciet aan — met name degenen die het publiek, zorgpatiënten en studenten bedienen — om waar mogelijk AAA-conformiteit na te streven, in de erkenning dat dit de best mogelijke toegankelijkheidspraktijk vertegenwoordigt.

Voor organisaties in Turkije heeft de implementatie van WCAG 2.5.5 bijzondere strategische waarde in verschillende contexten. Overheidsportalen voor oudere burgers, systemen voor het plannen van zorgafspraken die worden gebruikt door patiënten met chronische aandoeningen, en bankapplicaties die worden gebruikt door mensen met motorische beperkingen profiteren allemaal aanzienlijk van doelgroottes van 44×44 pixels. Turkije heeft een snel vergrijzende bevolking, en het Turkse Statistische Instituut (TÜİK) voorspelt dat burgers van 65 jaar en ouder tegen 2040 meer dan 16% van de bevolking zullen uitmaken — een demografische groep voor wie de grootte van pointerdoelen een cruciale bruikbaarheidsfactor is.

Zelfs waar AAA niet wettelijk verplicht is, tonen organisaties die vrijwillig voldoen aan WCAG 2.5.5 een betrokkenheid die het risico op rechtszaken kan verminderen, de geschiktheid voor aanbestedingen van overheidsopdrachten kan versterken wanneer toegankelijkheidsdocumentatie vereist is, en de gebruikerstevredenheidsmetrics kan verbeteren in concurrerende markten zoals e-commerce en fintech. De SDK van Accsible biedt configureerbare functies voor het verbeteren van touchdoelen die organisaties kunnen helpen dit criterium te halen of te benaderen, en documentatie van dergelijke inspanningen kan deel uitmaken van een Accessibility Conformance Report (ACR) of VPAT-indiening die vereist is door institutionele aanbestedingsprocessen.