WCAG 2.5.8: Zielgröße (Minimum)

WCAG 2.5.8 verlangt, dass interaktive Ziele wie Schaltflächen und Links eine Mindestgröße von 24×24 CSS-Pixeln haben oder dass um kleinere Ziele herum ausreichend Abstand vorhanden ist, damit Nutzerinnen und Nutzer mit motorischen Beeinträchtigungen sie zuverlässig aktivieren können. Wird dieses Kriterium nicht erfüllt, führt dies zu unbeabsichtigten Aktivierungen und Frustration bei allen, die einen Zeiger nicht präzise steuern können.

Was diese Regel bedeutet

WCAG 2.5.8 Target Size (Minimum) ist ein Erfolgskriterium der Stufe AA, das in WCAG 2.2 eingeführt wurde. Es besagt, dass die Größe des Ziels für Zeigereingaben mindestens 24×24 CSS-Pixel betragen muss, mit einer wichtigen Ausnahme: Wenn das Ziel selbst kleiner als 24×24 CSS-Pixel ist, muss ausreichend Abstand darum herum vorhanden sein, sodass die Gesamtfläche – einschließlich des Abstands – in jede Richtung die Schwelle von 24×24 erreicht. Anders ausgedrückt: Der Begrenzungsrahmen (Bounding Box) des Ziels plus angrenzender Leerraum, der frei von anderen Zielen ist, müssen zusammen horizontal 24 CSS-Pixel und vertikal 24 CSS-Pixel erreichen.

Das Kriterium gilt für jedes Element, das ein Zeigerereignis empfangen kann: Links (<a>), Buttons (<button>), Checkboxen, Radiobuttons, Select-Steuerelemente, Slider, benutzerdefinierte Widgets mit Pointer-Event-Listenern und jedes Element, dem eine ARIA-Rolle zugewiesen wurde, die Interaktivität impliziert. Es gilt nicht für nicht-interaktive Elemente wie dekorative Bilder oder statischen Text, selbst wenn diese zufällig groß sind.

Ein Ziel besteht dieses Kriterium, wenn mindestens eine der folgenden Bedingungen erfüllt ist:

Die gerenderte Größe des Ziels beträgt in beiden Dimensionen mindestens 24×24 CSS-Pixel.
Das Ziel ist in einer oder beiden Dimensionen kleiner als 24 CSS-Pixel, aber der Abstand zwischen der Kante des Ziels und dem nächstgelegenen interaktiven Element ist groß genug, sodass die kombinierte Fläche aus Ziel plus Abstand mindestens 24×24 CSS-Pixel beträgt.
Das Ziel ist ein Inline-Element innerhalb eines Satzes oder Textblocks, das ausdrücklich ausgenommen ist, weil ein Umfließen solcher Ziele den Lesefluss stören würde.
Die visuelle Größe des Ziels wird vollständig durch das Standard-User-Agent-Stylesheet des Browsers bestimmt und wurde vom Autor nicht verändert – dies ist die Ausnahme für native Steuerelemente.
Es existiert eine nicht-interaktive Darstellung derselben Information und das kleine Ziel ist lediglich eine Alternative, nicht die einzige Aktivierungsmöglichkeit.

Ein Ziel verfehlt das Kriterium, wenn es kleiner als 24×24 CSS-Pixel ist und nicht genügend Abstand vorhanden ist, um dies auszugleichen, und keine der oben genannten Ausnahmen greift. Häufige reale Fehler sind kleine, reine Icon-Buttons (z. B. ein 16×16-Schließen-Icon in einem Modal), eng gepackte Navigationslinks mit minimalem Padding und Social-Share-Icon-Reihen, bei denen jedes Icon mit 20×20 Pixeln und nur 2px Abstand dazwischen gerendert wird.

Es ist wichtig zu beachten, dass WCAG 2.5.8 eine Mindestanforderung ist. Das zugehörige AAA-Kriterium 2.5.5 Target Size (Enhanced) verlangt mindestens 44×44 CSS-Pixel ohne Ausnahme für Abstände, und viele Usability-Richtlinien empfehlen 44–48 CSS-Pixel als komfortables Touch-Ziel. Die Erfüllung von 2.5.8 ist die Untergrenze, nicht die Obergrenze.

Warum das wichtig ist

Motorische Beeinträchtigungen beeinflussen die Zeigerpräzision auf vielfältige Weise. Menschen mit Parkinson, essenziellem Tremor, Zerebralparese, Multipler Sklerose, schlaganfallbedingter Hemiplegie oder wiederholten Belastungsverletzungen können den Zeiger möglicherweise nicht zuverlässig auf einem kleinen Ziel platzieren. Ältere Erwachsene erleben ebenfalls einen natürlichen Rückgang der Feinmotorik: Etwa 15% der Menschen über 65 berichten von erheblichen Schwierigkeiten bei der Nutzung einer Maus oder eines Touchscreens. Über klinische Erkrankungen hinaus haben auch situativ beeinträchtigte Nutzer – etwa jemand, der ein Smartphone mit einer Hand in einem fahrenden Bus hält, oder jemand, dessen Finger im Verhältnis zu einem kleinen Telefonbildschirm groß ist – Probleme mit winzigen Zielen.

Laut Weltgesundheitsorganisation leben weltweit über 1,3 Milliarden Menschen mit irgendeiner Form von Behinderung, und motorische Beeinträchtigungen gehören zu den häufigsten Kategorien. Wenn interaktive Elemente zu klein oder zu dicht beieinander sind, erleben diese Nutzer versehentliche Aktivierungen, verfehlte Taps und wiederholte Fehler, die eine Website faktisch unbenutzbar machen. Die Frustration verstärkt sich auf Touch-Geräten, bei denen es keinen Hover-Zustand gibt, um die Cursorposition vor dem Klick zu bestätigen.

Betrachten wir ein konkretes Szenario: Eine türkische E‑Commerce-Website für Elektronik zeigt oben auf jeder Produktseite eine Reihe von fünf Social-Share-Icons, jeweils 18×18 Pixel mit 3px Abstand dazwischen. Eine Nutzerin mit essenziellem Tremor versucht, ein Produkt über WhatsApp zu teilen, tippt aber wiederholt auf das falsche Icon und löst unerwünschte Facebook-Shares aus. Sie kann diese Shares nicht schnell rückgängig machen, und die Aufgabe wird so fehleranfällig, dass sie sie ganz abbricht. Wenn jedes Icon auf 24×24 CSS-Pixel vergrößert oder Padding hinzugefügt würde, sodass die klickbare Fläche 24×24 erreicht, ließe sich das Problem lösen, ohne das visuelle Design wesentlich zu verändern.

Über Barrierefreiheit hinaus korreliert eine angemessene Zielgröße mit höheren Conversion-Raten, niedrigeren Absprungraten und besseren Core-Web-Vitals-Werten in Bezug auf Interaktionsbereitschaft. Mobile-first-Indexierung durch Suchmaschinen bevorzugt zudem Seiten mit guter Touch-Bedienbarkeit, sodass die Zielgröße ein Faktor ist, der Barrierefreiheit und SEO verbindet.

Wie man testet

Automatischer Scan mit axe DevTools: Installieren Sie die Browser-Erweiterung axe DevTools. Öffnen Sie die zu testende Seite. Aktivieren Sie im axe-DevTools-Panel die experimentellen Regeln, bevor Sie den Scan ausführen (suchen Sie nach dem Regel-Tag-Filter und fügen Sie experimental hinzu). Filtern Sie nach Abschluss des Scans die Ergebnisse nach der Regel-ID target-size. Notieren Sie für jedes markierte Element die gemeldeten Abmessungen. Bestätigen Sie den Befund manuell, bevor Sie ihn als bestätigten Fehler protokollieren, da experimentelle Regeln eine höhere Rate an Fehlalarmen aufweisen.
Automatischer Scan mit Lighthouse: Führen Sie in Chrome DevTools oder über die CLI ein Lighthouse-Accessibility-Audit aus. Lighthouse enthält ein Tap-Targets-Audit, das nach Zielen sucht, die kleiner als 48×48 CSS-Pixel sind und nicht genügend Abstand haben – beachten Sie, dass dies eine strengere Schwelle als WCAG 2.5.8 ist, sodass Lighthouse-Fehler eine Obermenge der WCAG-Fehler darstellen. Prüfen Sie die im Bericht markierten Elemente und gleichen Sie sie mit der 24×24-WCAG-Schwelle ab, um zu bestimmen, welche tatsächliche AA-Fehler und welche Best-Practice-Empfehlungen sind.
Manuelle Messung mit Browser-DevTools: Öffnen Sie DevTools und inspizieren Sie jedes interaktive Element. Prüfen Sie im Reiter „Computed“ width und height. Wenn einer der Werte unter 24px liegt, wechseln Sie zur Box-Model-Ansicht und prüfen Sie padding. Wenn das Padding das Ziel auf 24×24 bringt, besteht es. Wenn nicht, messen Sie den Abstand zum nächstgelegenen interaktiven Element mithilfe des Begrenzungsrechtecks des Elements: Führen Sie im Konsolenfenster document.querySelector('your-selector').getBoundingClientRect() aus und vergleichen Sie die Koordinaten benachbarter Elemente. Wenn der kombinierte Abstand in jeder Dimension die effektiv erreichbare Fläche auf 24px bringt, besteht das Ziel.
Touch-Simulation: Aktivieren Sie in Chrome DevTools die Geräteemulation und wechseln Sie zu einem touch-optimierten Geräteprofil. Versuchen Sie, auf jedes kleine interaktive Element zu tippen. Notieren Sie alle Fälle, in denen es schwierig ist, das gewünschte Element zu aktivieren oder in denen versehentlich benachbarte Elemente ausgelöst werden.
Tastatur- und Screenreader-Tests (zur Einordnung): Obwohl WCAG 2.5.8 speziell ein Zeigerkriterium ist, hilft die Bestätigung, dass kleine Ziele auch sichtbare Fokusindikatoren haben und per Tastatur erreichbar sind, kombinierte Probleme zu identifizieren. Verwenden Sie NVDA mit Firefox oder JAWS mit Chrome, um interaktive Elemente zu navigieren und zu bestätigen, dass sie unabhängig von ihrer Größe erreichbar und aktivierbar sind.
Tests auf realen Geräten: Testen Sie auf einem physischen Mobilgerät – idealerweise sowohl auf einem Android-Gerät mit großem Bildschirm als auch auf einem kleineren iOS-Gerät –, um sicherzustellen, dass Ziele, die auf dem Desktop bestehen, auch bei mobilen Viewport-Größen bestehen, da CSS-Pixeldichte und Zoomverhalten die wahrgenommene Zielgröße beeinflussen können.

Wie man es behebt

Kleiner reiner Icon-Button – falsch

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

Kleiner reiner Icon-Button – richtig

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

Eng gepackte Navigationslinks – falsch

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

Eng gepackte Navigationslinks – richtig

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

Checkbox mit winziger Trefferfläche – falsch

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

Checkbox mit zugehörigem Label – richtig

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

Social-Share-Icon-Reihe – falsch

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

Social-Share-Icon-Reihe – richtig

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

Häufige Fehler

Setzen von width und height auf das Icon innerhalb eines Buttons statt auf den Button selbst: Entwickler begrenzen häufig das SVG oder Bild auf 16–20px, vergessen aber, dass das <button>-Element min-width: 24px; min-height: 24px und entsprechendes Padding benötigt, um ein ausreichendes Tap-Ziel zu schaffen.
Entfernen des Standard-Paddings des Browsers von Buttons und Inputs mit padding: 0 oder einem globalen Reset: CSS-Resets, die das Padding von Formularelementen auf null setzen, entfernen den Puffer, der native Steuerelemente in einer brauchbaren Größe hält. Fügen Sie nach einem Reset immer explizit Padding wieder hinzu.
Verlassen auf line-height allein, um die Link-Höhe zu erhöhen, ohne display: block oder display: inline-block: Inline-Elemente reagieren nicht auf height oder vertikales Padding wie Block-Elemente, sodass ein Link optisch höher erscheinen kann, während seine tatsächlich klickbare Bounding Box klein bleibt.
Verwendung von pointer-events: none auf einem Wrapper und Anbringen von Click-Handlern an einem winzigen inneren Element: Dies macht jegliches Padding oder jede Mindestgröße des Wrappers wirkungslos und reduziert das effektive Ziel auf die gerenderte Größe des inneren Elements.
Anwenden von overflow: hidden auf einen Button-Container, der das Padding des Buttons abschneidet: Die visuelle Klickfläche wird auf die Grenzen des Containers beschnitten, wodurch das effektive Ziel kleiner ist, als es die Dimensionen des Buttons vermuten lassen.
Vergessen, CSS-Transforms wie scale() zu berücksichtigen: Ein Button, der visuell mit transform: scale(0.7) verkleinert wird, behält in den meisten Browsern seine ursprüngliche Bounding Box für Zeigerereignisse, aber dieses Verhalten ist inkonsistent und unzuverlässig – dimensionieren Sie Ziele immer in ihrer endgültigen Darstellungsgröße.
Die Annahme, dass ein großes <label> eine winzige <input> kompensiert, wenn Label und Input nicht programmatisch verknüpft sind: Wenn das <label> kein for verwendet, das der id des Inputs entspricht, oder wenn der Input nicht im Label verschachtelt ist, aktiviert ein Klick auf den Label-Text den Input nicht, sodass nur die kleine Zielgröße des Inputs selbst funktioniert.
Kein Testen bei den Viewport-Größen, in denen die Ziele tatsächlich gerendert werden: Ein Button, der auf dem Desktop 32×32 CSS-Pixel groß ist, kann auf einem schmalen mobilen Viewport aufgrund von fluidem Scaling oder viewport-relativen Einheiten (vw, vmin) mit 22×22 CSS-Pixeln gerendert werden, was einen Fehler erzeugt, der nur auf Mobilgeräten auftritt.
Die WCAG-2.5.8-Ausnahme für Inline-Textlinks zu großzügig auslegen: Die Ausnahme gilt nur für Links, die wirklich inline in einem Textlauf stehen (z. B. ein Hyperlink innerhalb eines Absatzes). Eigenständige Links, die wie Text gestaltet sind – etwa ein „Passwort vergessen?“-Link unter einem Formular – sind keine Inline-Links und müssen die 24×24-Schwelle erfüllen.
Kein Audit von Drittanbieter-Widgets und eingebetteten Komponenten: Cookie-Banner, Chat-Widgets und Analytics-Overlays enthalten häufig winzige Buttons (Akzeptieren, Schließen, Minimieren), die von externen Skripten eingefügt werden. Diese sind dennoch Teil der Barrierefreiheit der Seite und müssen WCAG 2.5.8 erfüllen, auch wenn der Code nicht im eigenen Haus erstellt wurde.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Barrierefreiheitsanforderungen für eine breite Palette von digitalen Dienstanbietern fest, die in der Türkei tätig sind. Die Verfügung verweist ausdrücklich auf WCAG 2.2 als technischen Standard, und Konformität auf Stufe AA ist erforderlich, um sich für das vom Ministerium für Familie und Sozialdienste (Aile ve Sosyal Hizmetler Bakanlığı) vergebene Erişilebilirlik Logosu (Barrierefreiheitslogo) zu qualifizieren. Da WCAG 2.5.8 ein Kriterium der Stufe AA in WCAG 2.2 ist, fällt es direkt in den Geltungsbereich dieses verbindlichen Rahmens.

Zu den von der Verfügung erfassten Organisationstypen gehören öffentliche Institutionen und Regierungsbehörden auf zentraler und lokaler Ebene, Banken und Finanzdienstleister, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten, E‑Commerce-Plattformen, Reisebüros, private Transportunternehmen und Privatschulen, die vom Ministerium für Nationale Bildung (Milli Eğitim Bakanlığı) zugelassen sind. Für all diese Organisationen ist die Einhaltung von WCAG 2.5.8 nicht nur eine Best-Practice-Empfehlung – sie ist eine regulatorische Verpflichtung, die mit der Berechtigung zur Anzeige des Barrierefreiheitslogos und dem Nachweis der rechtlichen Konformität bei Audits verknüpft ist.

Praktisch bedeutet dies, dass die mobil-optimierte Webanwendung einer türkischen Bank sicherstellen muss, dass ihre Buttons zur Überweisungsbestätigung, Eingabefelder für Einmalpasswörter und Navigationselemente alle die Mindestzielgröße von 24×24 CSS-Pixeln erfüllen. Ebenso muss eine E‑Commerce-Website sicherstellen, dass ihre „In den Warenkorb“-Buttons, Mengenauswahlen und Filtersteuerelemente auf allen Geräteprofilen ausreichend groß sind. Gesundheitsportale müssen Terminbuchungs-Kalender prüfen, die berüchtigt für kleine Datumsfelder sind, und diese Felder entweder vergrößern oder ausreichende Abstände vorsehen. Self-Service-Portale von Telekommunikationsanbietern müssen prüfen, ob ihre Kontoverwaltungslinks und Umschaltsteuerelemente in Datentarif-Auswahlen die Schwelle erfüllen.

Die Nichteinhaltung der Verfügung kann zu Verwaltungssanktionen führen und eine Organisation daran hindern, das Barrierefreiheitslogo anzuzeigen, das von türkischen Verbraucherinnen und Verbrauchern zunehmend als Vertrauenssignal genutzt wird. Über Sanktionen hinaus setzt die Nichteinhaltung Organisationen Beschwerden bei den zuständigen Aufsichtsbehörden aus. Angesichts der Tatsache, dass die Türkei eine wachsende Bevölkerung älterer Menschen hat – das Türkische Statistische Institut prognostiziert, dass Menschen ab 65 Jahren bis 2040 16,3% der Bevölkerung ausmachen werden – wird die praktische Auswirkung kleiner Ziele im Laufe der Zeit nur zunehmen, sodass frühzeitige Konformität sowohl eine ethische Priorität als auch eine sinnvolle langfristige Geschäftsstrategie ist.