Zu klein zum Treffen: Wenn Buttons und Links mobile Nutzer ausbremsen

Ein kleines „X“ schließt das Cookie-Banner. Eine schmale Lupe öffnet die Suche. In der mobilen Navigation liegen Links dicht nebeneinander. Auf dem Desktop wirkt alles ordentlich – auf dem Smartphone braucht es drei Versuche.

Das ist kein rein optisches Detail. Kleine oder eng platzierte Ziele führen zu Fehlklicks, erschweren die Bedienung bei eingeschränkter Feinmotorik und beschädigen genau die Nutzerwege, die Anfragen, Käufe oder Registrierungen erzeugen sollen.

WCAG 2.2 hat deshalb das Erfolgskriterium 2.5.8 „Target Size (Minimum)“ auf Level AA ergänzt. Vereinfacht gesagt sollen Pointer-Ziele mindestens 24 × 24 CSS-Pixel groß sein oder ausreichend Abstand zu benachbarten Zielen haben. Es gibt definierte Ausnahmen, etwa für Links innerhalb von Fließtext oder durch den Browser vorgegebene Controls.

Die operative Frage lautet aber nicht nur: Erfüllt das Element rechnerisch 24 × 24 Pixel?

Sie lautet: Kann eine echte Person es auf einem kleinen, bewegten Bildschirm zuverlässig treffen, ohne versehentlich etwas anderes auszulösen?

Wo kleine Ziele besonders teuer werden

Mobile Navigation

Hamburger-Menü, Untermenü-Pfeile, Sprachumschalter und Konto-Icons liegen häufig in einer schmalen Kopfzeile. Ist nur das sichtbare Icon klickbar, nicht aber die umgebende Fläche, wirkt das Ziel deutlich kleiner als erwartet.

Typische Folgen:

• Das Menü öffnet nicht beim ersten Versuch.
• Statt des Pfeils wird der benachbarte Link aktiviert.
• Untermenüs schließen sich beim Korrigieren.
• Nutzer verlassen die Seite, bevor sie das gewünschte Angebot finden.

Formulare

Checkboxen für Datenschutz, Newsletter oder AGB werden oft visuell verkleinert. Der Text steht direkt daneben, ist aber nicht mit dem Eingabeelement verbunden. Dann muss exakt das winzige Kästchen getroffen werden.

Auch kleine Kalender-Icons, Passwort-Sichtbarkeitsschalter oder Entfernen-Buttons bei Uploads werden schnell zu Hürden.

Cookie- und Consent-Banner

Ein dominanter Zustimmungsbutton und ein winziger Ablehnen-Link sind nicht nur ein Gestaltungsproblem. Die tatsächliche Bedienbarkeit der Optionen muss vergleichbar geprüft werden. Besonders kritisch sind kleine Schließen-Symbole, eng gesetzte Toggle-Schalter oder Links, die erst nach mehreren Ebenen erreichbar sind.

Slider, Carousels und Karten

Pfeile, Punkte-Navigation und Kartenmarker sind häufig dekorativ fein, aber praktisch schwer zu treffen. Dragging allein ist ebenfalls problematisch: WCAG 2.2 fordert für Funktionen mit Ziehbewegungen grundsätzlich eine Alternative mit einem einzelnen Pointer, sofern das Ziehen nicht wesentlich ist.

Tabellen und Admin-Oberflächen

Bearbeiten, Löschen, Duplizieren und Mehr-Menüs werden gern als dicht gepackte Icon-Reihe dargestellt. Ein Fehlklick kann hier nicht nur nerven, sondern Daten verändern.

Sieben Red Flags im schnellen Audit

1. Nur die sichtbare Grafik ist klickbar.
   Das Icon ist 16 Pixel groß und der umgebende Button hat keine zusätzliche Fläche.

2. Ziele liegen ohne Abstand nebeneinander.
   Zwei kleine Icons teilen sich praktisch dieselbe Trefferzone.

3. Labels sind nicht klickbar.
   Checkbox oder Radio-Button muss punktgenau getroffen werden.

4. Hover verdeckt das Problem.
   Auf dem Desktop erscheint eine großzügige Fläche, die tatsächliche aktive Region bleibt aber klein.

5. Overlays verdecken Ziele.
   Sticky Header, Chat-Widgets oder Cookie-Banner liegen über Navigation und Formularaktionen.

6. Zoom verschärft die Enge.
   Bei 200 Prozent Zoom brechen Controls um, überlagern sich oder werden abgeschnitten.

7. Kritische Aktionen sehen wie Textlinks aus.
   „Ablehnen“, „Zurück“, „Entfernen“ oder „Abbrechen“ sind klein, schwach kontrastiert und dicht an anderen Aktionen platziert.

So prüfen Sie Zielgrößen sinnvoll

1. Nicht nur messen, sondern den echten Hit-Bereich prüfen

In den DevTools lässt sich die Box eines Elements untersuchen. Entscheidend ist die aktive Fläche des Links oder Buttons, nicht die Größe des SVG oder Textzeichens.

Ein 16-Pixel-Icon kann in einem 44-Pixel-Button liegen und hervorragend bedienbar sein. Ein 24-Pixel-Icon kann dagegen exakt 24 Pixel groß und direkt neben einem zweiten Ziel platziert sein – formal näher am Minimum, praktisch aber fragil.

2. Repräsentative Seitentypen testen

Prüfen Sie mindestens:

• Hauptnavigation und Untermenüs
• Suchfunktion
• Kontakt- und Checkout-Formulare
• Cookie- und Consent-Dialoge
• Login und Passwort-Reset
• Karten, Slider und Galerien
• Tabellen, Filter und Dashboards
• eingebettete Termin- oder Chat-Widgets

3. Mit realistischen Bedingungen testen

Ein Desktop-Mauszeiger ist nicht genug. Testen Sie:

• schmale mobile Viewports
• Touch-Eingabe
• 200 bis 400 Prozent Zoom
• Gerätesimulation und echte Geräte
• Bedienung mit einer Hand
• größere Systemschrift
• Tastatur und sichtbaren Fokus

Die beste Prüfung ist nicht, ob Sie das Ziel konzentriert treffen können. Sie ist, ob es auch bei Bewegung, Ermüdung, Tremor oder eingeschränkter Sicht zuverlässig funktioniert.

4. Abstände und Ausnahmen dokumentieren

WCAG 2.2 erlaubt bei kleineren Zielen unter anderem eine Abstandsregel. Diese sollte nicht als Einladung verstanden werden, ganze Interfaces aus Mini-Links zu bauen.

Dokumentieren Sie bei bewusst kleinen Zielen:

• warum die Ausnahme greift,
• welche benachbarten Ziele existieren,
• wie der Abstand berechnet wurde,
• ob eine gleichwertige größere Alternative vorhanden ist,
• wie die Bedienung im realen Layout getestet wurde.

5. Das Design-System korrigieren

Einzelfixes helfen kurzfristig. Nachhaltiger sind zentrale Regeln:

• Mindesthöhe und -breite für Buttons und Icon-Buttons
• ausreichendes Padding
• klickbare Labels
• definierte Abstände zwischen Aktionen
• responsive Varianten für dichte Toolbars
• sichtbare Fokuszustände
• keine kritische Funktion nur per Dragging
• Tests für Overlay- und Sticky-Situationen

So wird die Verbesserung bei neuen Komponenten automatisch mitgeliefert.

Was Website-Pflichtencheck prüfen würde

Ein technischer und visueller Target-Size-Check betrachtet nicht nur einzelne Pixelwerte. Geprüft werden können:

• tatsächliche Hit-Bereiche von Links, Buttons und Icons
• Abstände zu benachbarten Zielen
• mobile Navigation und Untermenüs
• Formulare, Checkboxen und Upload-Aktionen
• Consent-Banner und Schließen-Controls
• Slider, Karten und Drag-Interaktionen
• Zoom, Reflow und größere Schrift
• Überlagerungen durch Sticky Header, Chat und Overlays
• Tastaturfokus und alternative Bedienwege
• zentrale Regeln im Design-System
• automatisierbare Regressionstests und manuelle Ausnahmen

Das Ergebnis sollte priorisieren, wo kleine Ziele nur unbequem sind und wo sie echte Abschlüsse verhindern oder Fehlaktionen auslösen.

Große Touch-Ziele machen ein Interface nicht automatisch klobig. Gute Gestaltung trennt visuelle Größe und aktive Fläche: Ein Icon darf fein aussehen, während der Button darum großzügig und zuverlässig bedienbar bleibt.

Wenn eine wichtige Aktion nur funktioniert, wenn jemand ruhig, präzise und mit perfekter Sicht tippt, ist sie nicht robust gestaltet.

Hinweis: Dieser Beitrag ist eine technische Übersicht und keine Rechtsberatung.