Touch-Target-Größe: Mobile Barrierefreiheit für Finger statt Mauszeiger

1. Warum Touch-Target-Größe eine eigene WCAG-Regel bekommen hat

Bis zur WCAG-Version 2.1 gab es keine verbindliche Mindestgröße für klickbare oder tippbare Elemente, obwohl mobile Endgeräte längst die Mehrheit des Web-Traffics ausmachten. Die Folge waren Interfaces, die am Desktop makellos aussahen und auf dem Smartphone zu einer Fehlbedienungs-Übung wurden: winzige Schließen-Icons in Overlays, dicht gedrängte Sterne-Bewertungen, Filter-Chips, die kaum breiter als der Finger selbst waren. Mit WCAG 2.5.5 in Version 2.1 und der präzisierten Nachfolgeregel 2.5.8 in Version 2.2 wurde daraus eine testbare, messbare Anforderung.

Der Hintergrund ist rein physiologisch. Studien zur Fingerspitzengröße belegen, dass die durchschnittliche Kontaktfläche eines Fingers auf einem Touchscreen deutlich größer ist als die visuell wahrgenommene Fingerspitze, und dass die Trefferquote bei Zielen unter 44 Pixeln Kantenlänge messbar sinkt. Menschen mit Tremor, eingeschränkter Feinmotorik durch Parkinson, Arthritis oder auch nur kalte Finger im Winter treffen kleine Targets noch unzuverlässiger. Touch-Target-Größe ist damit kein kosmetisches Detail, sondern eine der wenigen WCAG-Anforderungen, die sich direkt in Conversion-Verlust übersetzen lässt, wenn Nutzer den Kaufen-Button dreimal verfehlen.

2. WCAG 2.5.8 Target Size Minimum: die Pflichtregel auf AA-Niveau

WCAG 2.5.8 verlangt auf Konformitätsstufe AA eine Mindestgröße von 24 mal 24 CSS-Pixeln für jedes Ziel, das per Zeiger aktiviert werden kann, sofern es keine der definierten Ausnahmen greift. Ausnahmen bestehen etwa für Inline-Links in Fließtext, für Targets, deren Größe durch den User Agent bestimmt wird und nicht durch den Autor kontrollierbar ist, sowie für Fälle, in denen ein gleichwertiges, größeres Alternativ-Target auf derselben Seite existiert.

Wichtig für die technische Umsetzung: Die 24x24-Regel bezieht sich auf die tatsächliche interaktive Fläche, nicht auf das sichtbare Icon. Ein 16x16-Pixel-Icon in einem Button mit ausreichend Padding erfüllt die Regel, wenn die klickbare Fläche insgesamt 24x24 Pixel erreicht. Das lässt sich in CSS über Mindesthöhe und Mindestbreite in Kombination mit einem transparenten Hitbox-Vergrößerer sauber lösen, ohne das visuelle Design zu verändern.

/* Sichtbares Icon bleibt klein, klickbare Fläche erreicht 24x24px */
.icon-button {
  min-width: 24px;
  min-height: 24px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 4px;
}

/* Falls das Element aus Layout-Gründen nicht wachsen darf,
   die Hitbox per Pseudo-Element unsichtbar vergrößern */
.icon-button--fixed {
  position: relative;
}
.icon-button--fixed::before {
  content: "";
  position: absolute;
  inset: -6px; /* vergrößert 12x12px sichtbares Icon auf 24x24px Hitbox */
}

3. WCAG 2.5.5 Target Size Enhanced: 44x44px auf AAA-Niveau

WCAG 2.5.5 ist die ältere, strengere Schwester von 2.5.8 und gilt auf Konformitätsstufe AAA mit einer Mindestgröße von 44 mal 44 CSS-Pixeln. Die meisten Magento-Projekte zielen vertraglich auf AA ab, weshalb 2.5.5 formal nicht erfüllt sein muss. Trotzdem lohnt sich die 44-Pixel-Marke als praktische Zielgröße für alle primären Handlungsaufforderungen: Warenkorb-Button, Zur-Kasse-Button, Hauptnavigation im Mobile-Menü. Diese Elemente tragen den größten Anteil an der Conversion und profitieren am meisten von großzügigen Zielflächen.

Apple und Google haben diese Erkenntnis längst in ihre Plattform-Guidelines übernommen: Die Human Interface Guidelines von Apple empfehlen 44x44 Punkte, Googles Material Design empfiehlt 48x48 dp als Mindestgröße für touch-bedienbare Elemente. Wer sich an diesen etablierten Richtwerten orientiert statt am rechtlichen Minimum von 24 Pixeln, baut Interfaces, die nicht nur WCAG-konform sind, sondern sich auf echten Geräten spürbar besser bedienen lassen.

4. Abstand zwischen Targets: die unterschätzte zweite Hälfte der Regel

Eine Mindestgröße allein reicht nicht, wenn benachbarte Targets ohne Abstand aneinandergrenzen. WCAG 2.5.8 akzeptiert Targets unter 24 Pixeln nur dann als Ausnahme, wenn ausreichend Abstand zu den nächsten Targets besteht, konkret ein Kreis mit 24 Pixeln Durchmesser um den Mittelpunkt jedes Targets darf keinen anderen Zielbereich überlappen. In der Praxis bedeutet das: Eine Reihe von 20x20-Pixel-Icons ohne Zwischenraum verstößt gegen die Regel, selbst wenn jedes einzelne Icon für sich betrachtet fast groß genug wäre.

Typisch betroffen sind horizontale Icon-Leisten, etwa Social-Share-Buttons, Bild-Galerie-Thumbnails oder Paginierungs-Ziffern in einer Produktliste. Der Abstand muss nicht sichtbar sein, ein transparenter Rand um jedes Icon reicht aus, aber er muss in der interaktiven Fläche vorhanden sein. Gap-basierte Flexbox- oder Grid-Layouts lösen das zuverlässiger als margin-Werte, die bei responsivem Umbruch leicht kollabieren.

/* Icon-Leiste mit garantiertem Mindestabstand, kein Kollabieren
   des Abstands beim Umbruch dank gap statt margin */
.share-icons {
  display: flex;
  flex-wrap: wrap;
  gap: 12px; /* Abstand zwischen 24x24px-Targets, verhindert Überlappung */
}
.share-icons a {
  min-width: 24px;
  min-height: 24px;
}

5. Magento-Fehlerquelle 1: Mini-Cart-Icon und Header-Aktionen

Im Hyvä-Standard-Header sitzen Such-Icon, Konto-Icon, Wishlist-Icon und Mini-Cart oft dicht nebeneinander, gestaltet für eine kompakte Desktop-Optik. Auf mobilen Breakpoints wird derselbe Markup häufig unverändert übernommen, nur die Icon-Größe per Tailwind-Klasse verkleinert, etwa von h-6 w-6 auf h-5 w-5, ohne das Padding des umgebenden Buttons anzupassen. Das Ergebnis ist eine sichtbar kleine, aber vor allem eine klickbar zu kleine Fläche.

Der Fix ist unabhängig von der Icon-Größe: Der Button, nicht das SVG, muss die 24x24-Pixel-Mindestfläche garantieren. In Tailwind lässt sich das über eine feste min-h-6 min-w-6-Klasse plus ausreichend Padding erzwingen, unabhängig davon, wie klein das SVG-Icon selbst gestaltet ist.

<!-- Hyvä header.phtml: Mini-Cart-Icon mit garantierter Touch-Fläche -->
<button type="button"
        class="relative flex items-center justify-center
               min-h-[44px] min-w-[44px] p-2"
        aria-label="Warenkorb öffnen, <?= count($items) ?> Artikel">
  <svg class="h-5 w-5" aria-hidden="true"><!-- Cart-Icon --></svg>
  <span class="absolute -top-1 -right-1 ..."><?= count($items) ?></span>
</button>

6. Magento-Fehlerquelle 2: Filter-Chips und Sterne-Bewertungen

Layered-Navigation-Filter werden in vielen Themes als kompakte Chips gerendert, oft mit wenig Padding, damit möglichst viele Attributwerte pro Zeile sichtbar sind. Auf dem Smartphone führt das regelmäßig zu Chips, die zwar textlich lesbar, aber als Tippziel deutlich unter 24 Pixel Höhe liegen, besonders bei kurzen Werten wie Größenangaben (S, M, L) oder Farbpunkten.

Sterne-Bewertungen sind ein zweiter Klassiker: Fünf einzelne Sterne-Icons, jedes für sich als eigenes klickbares Element für eine Bewertungsabgabe gedacht, werden oft in einer Breite von 100 bis 120 Pixeln gerendert, was pro Stern nur 20 bis 24 Pixel ergibt, und das ohne Abstand zwischen den Sternen. Die Lösung ist in beiden Fällen dieselbe: Mindesthöhe pro Chip beziehungsweise Stern auf 24 Pixel anheben und einen Gap-Wert zwischen den Elementen einführen, notfalls auf Kosten der Zeilenanzahl pro Filterblock.

<!-- Layered-Navigation-Chip mit Mindesthöhe statt kompaktem Padding -->
<a href="?size=m"
   class="inline-flex items-center justify-center
          min-h-[24px] px-3 py-1.5 rounded-full border text-sm">
  M
</a>

<!-- Sterne-Bewertung: jedes Symbol als eigenes 24x24px-Target mit Gap -->
<div class="flex gap-1" role="radiogroup" aria-label="Bewertung abgeben">
  <button type="button" class="min-h-[24px] min-w-[24px]"
          role="radio" aria-checked="false" aria-label="1 Stern">★</button>
  <!-- ... vier weitere Sterne, identisches Muster -->
</div>

7. Touch-Target-Größe testen: DevTools, echte Geräte, Automatisierung

Die zuverlässigste Testmethode ist ein echtes Mobilgerät mit aktivierter Touch-Simulation, weil Desktop-Emulatoren die tatsächliche Fingerkontaktfläche nicht abbilden. Als schneller Zwischenschritt eignet sich die Chrome-DevTools-Funktion Inspect Element kombiniert mit dem Box-Modell-Overlay: Die berechnete Breite und Höhe eines Elements lässt sich direkt ablesen und mit der 24-Pixel-Marke vergleichen, ohne ein physisches Gerät zur Hand zu haben.

Für die Automatisierung bieten sich Lighthouse-Accessibility-Audits an, die Tap-Target-Größen als eigenen Prüfpunkt führen, sowie axe-core-Regeln, die zumindest offensichtliche Verstöße markieren, auch wenn axe-core den Abstand zwischen Targets bislang nicht vollständig prüfen kann. Ein manuelles Review mit dem Finger auf einem echten Smartphone bleibt deshalb Pflicht, gerade bei dicht gepackten Komponenten wie Filterleisten oder Bewertungssternen.

8. Ausnahmen und Grenzfälle richtig einordnen

Nicht jedes kleine Element verstößt automatisch gegen WCAG 2.5.8. Inline-Textlinks innerhalb eines Fließtext-Absatzes sind explizit ausgenommen, weil eine Vergrößerung der Zeilenhöhe für einzelne Links das gesamte Textlayout stören würde. Auch essenzielle, durch den Kontext vorgegebene Darstellungen sind ausgenommen, etwa ein Kalender-Widget, dessen Tagesziffern aus Platzgründen nicht auf 24 Pixel wachsen können, ohne die Monatsübersicht unbrauchbar zu machen.

Diese Ausnahmen dürfen aber nicht als Generalfreibrief für kompakte Interfaces missverstanden werden. Die Ausnahme für essenzielle Darstellungen gilt nur, wenn keine praktikable Alternative existiert, nicht schon dann, wenn eine größere Darstellung dem Designer weniger gefällt. Im Zweifel gilt: Wenn sich ein Kompaktlayout mit vertretbarem Aufwand auf 24 Pixel Mindestgröße umbauen lässt, ist die Ausnahme nicht anwendbar und die Umsetzung Pflicht.

9. Touch-Target-Größe im Designsystem dauerhaft verankern

Einzelne Fixes an Mini-Cart oder Filter-Chips lösen nur das aktuelle Symptom. Nachhaltiger ist es, Mindestgrößen als Token im Designsystem zu verankern, etwa eine Tailwind-Utility-Klasse touch-target, die 44 Pixel Mindesthöhe und -breite für alle interaktiven Basiskomponenten erzwingt, und diese Klasse in Component-Reviews verbindlich vorzuschreiben.

Figma- oder Sketch-Bibliotheken sollten ebenfalls mit 44x44-Pixel-Rahmen für Icon-Buttons arbeiten, damit die Anforderung schon im Entwurf sichtbar wird und nicht erst im fertigen Code auffällt. Wer die Regel früh im Designprozess verankert, spart sich später aufwendige Nacharbeiten an bereits ausgelieferten Komponenten.

/* Zentrale Utility-Klasse im Tailwind-Theme, verbindlich für
   alle Icon-Buttons und kompakten interaktiven Elemente */
@layer utilities {
  .touch-target {
    min-height: 44px;
    min-width: 44px;
  }
}

10. Zusammenfassung

11. FAQ: Touch-Target-Größe in Magento: Das Wichtigste auf einen Blick