Touch-Ziele: Mindestgrößen für Buttons auf dem Smartphone

Stell dir die Parkschein-App einer mittelgroßen Stadt vor. Jemand steht neben dem Auto, in der einen Hand eine Einkaufstasche, in der anderen das Smartphone. Die Parkdauer stellt man mit zwei kleinen Symbolen ein, „Minus“ und „Plus“, jeweils 20 Pixel groß und direkt nebeneinander. Wer 90 Minuten will, muss sechsmal auf „Plus“ tippen und landet zweimal versehentlich auf „Minus“. Oben rechts in der Ecke sitzt ein winziges „X“, das ein Hinweisfenster schließen soll und erst beim dritten Versuch reagiert. Und die Leiste am unteren Rand drängt sechs Symbole so dicht aneinander, dass der Daumen regelmäßig das falsche erwischt.

Keines dieser Probleme hat mit Farben, Texten oder dem Ablauf zu tun. Es geht um etwas sehr Handfestes: Die Flächen, die Menschen treffen sollen, sind zu klein oder liegen zu dicht beieinander. Fachleute sprechen von Touch-Zielen (englisch „touch targets“ oder „tap targets“).

Dieser Artikel klärt, wie groß Touch-Ziele sein sollten, woher die bekannten Zahlen 44, 48 und 24 kommen, warum die sichtbare Größe nicht dasselbe ist wie die Fläche, die auf Berührung reagiert, und was an der viel zitierten „Daumenzone“ wirklich dran ist. Die Parkschein-App dient dabei als durchgehendes Beispiel. Sie ist erfunden, aber typisch.

Warum Größe zählt: Fitts’ Law

Dass große, nahe Ziele leichter zu treffen sind als kleine, ferne, klingt banal. Der Psychologe Paul Fitts hat diesen Zusammenhang 1954 aber genau vermessen. Seine Versuchspersonen tippten mit einem Stift abwechselnd auf zwei Metallplatten, deren Breite und Abstand Fitts variierte. Daraus leitete er ab, dass die Zeit für eine Zielbewegung vom Verhältnis zwischen Entfernung und Zielbreite abhängt. Diese Regel ist heute als Fitts’ Law bekannt.

Fitts beschrieb die Schwierigkeit einer Bewegung mit einem Index, der logarithmisch mit dem Verhältnis von Entfernung zu Zielbreite wächst: ID = log2(2D / W). D steht für die Distanz, W für die Breite des Ziels. Die praktische Folge: Wird ein Ziel kleiner, steigt die Schwierigkeit, und Menschen brauchen entweder länger oder treffen öfter daneben.

Auf Touchscreens kommt ein Problem hinzu, das es mit der Maus nicht gibt. Der Finger ist viel größer als ein Mauszeiger und verdeckt genau die Stelle, die er treffen soll. Das W3C formuliert es in den Erläuterungen zu den Zielgrößen sinngemäß so: Touch ist ein grobes Eingabeverfahren, und der Finger versperrt in der Regel die Sicht.

Wie groß ein Ziel für den Daumen mindestens sein sollte, untersuchten Pekka Parhi, Amy Karlson und Benjamin Bederson 2006. Ihre Testpersonen bedienten ein Gerät mit einer Hand und nur mit dem Daumen. Das Ergebnis: Für einzelne Tipps wie einen Button oder eine Checkbox hielten sie 9,2 Millimeter für ausreichend, für Folgen von Tipps wie beim Texteingeben 9,6 Millimeter. Diese Größen reichen laut den Autoren aus, ohne Leistung oder Zufriedenheit zu beeinträchtigen. Die Zahlen sind rund 20 Jahre alt und stammen von kleineren Touchscreen-Geräten, sie geben aber eine brauchbare Größenordnung: knapp ein Zentimeter.

Die Zahlen im Überblick

Wer nach Mindestgrößen sucht, stößt auf drei Quellen: Apple, Google und die Web Content Accessibility Guidelines (WCAG). Sie nennen unterschiedliche Werte, weil sie unterschiedliche Fragen beantworten.

Apple: 44 × 44 Punkt

Apples Human Interface Guidelines (HIG) sind eindeutig: Als allgemeine Regel braucht ein Button eine Trefferfläche von mindestens 44 × 44 Punkt, in visionOS 60 × 60 Punkt. Ein Punkt (pt) ist eine geräteunabhängige Einheit, die je nach Bildschirm auf mehrere physische Pixel abgebildet wird.

Interessant ist ein Detail aus dem Kapitel zur Barrierefreiheit. Dort führt Apple für iOS und iPadOS 44 × 44 Punkt als Standardgröße für Bedienelemente und 28 × 28 Punkt als Minimum. Die 44 sind also das, was Apple empfiehlt, die 28 die Untergrenze für Fälle, in denen es eng wird.

Google: 48 × 48 dp

Google empfiehlt für Android und Material Design Touch-Ziele von mindestens 48 × 48 dp, getrennt durch mindestens 8 dp Abstand. Auch dp (density-independent pixels) ist eine geräteunabhängige Einheit. Laut Google entspricht ein Ziel von 48 × 48 dp unabhängig von der Bildschirmgröße etwa 9 Millimetern. Damit liegt Google sehr nah an den Werten von Parhi und seinem Team.

WCAG 2.2: 24 × 24 CSS-Pixel als Minimum

Die WCAG 2.2 sind seit Oktober 2023 eine Empfehlung des W3C. Sie enthalten zwei Erfolgskriterien zur Zielgröße:

2.5.8 Target Size (Minimum), Stufe AA: Ziele für Zeigereingaben sind mindestens 24 × 24 CSS-Pixel groß. Es gibt Ausnahmen, zu denen wir gleich kommen.
2.5.5 Target Size (Enhanced), Stufe AAA: Ziele sind mindestens 44 × 44 CSS-Pixel groß, ebenfalls mit Ausnahmen.

Die 24 Pixel sind also kein Designziel, sondern eine Untergrenze. Das W3C schreibt selbst, dass das Kriterium eine Mindestgröße definiert und, wo diese nicht erreichbar ist, einen Mindestabstand. Für wichtige Bedienelemente empfiehlt es, das strengere Kriterium 2.5.5 anzustreben.

Für Projekte in Deutschland ist das nicht nur Theorie. Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act um, und für die technische Umsetzung ist die europäische Norm EN 301 549 maßgeblich. Ihre bisherige Version 3.2.1 verweist auf WCAG 2.1, in der es 2.5.8 noch nicht gab. Am 2. September 2026 ist die Version 4.1.1 erschienen, die auf WCAG 2.2 Stufe AA aufbaut. Rechtlich zählt sie, sobald sie im Amtsblatt der EU veröffentlicht ist, was für Ende 2026 erwartet wird. Für Websites und Apps, die unter das BFSG fallen, wird 2.5.8 damit zum Maßstab. Mehr zum Gesetz liest du im Artikel BFSG in der Praxis.

Was die Einheiten bedeuten

Punkt, dp und CSS-Pixel sind alle geräteunabhängige Einheiten. Sie sollen dafür sorgen, dass ein Button auf einem hochauflösenden Display nicht winzig wird. Auf einer mobilen Website mit korrekt gesetztem Viewport entsprechen 48 CSS-Pixel laut Googles Leitfaden auf web.dev etwa 9 Millimetern. Grob lassen sich die Werte also vergleichen.

Exakt ist das nicht. Die physische Größe hängt vom Gerät ab, und der UX-Forscher Steven Hoober hält Standards, die in Pixeln statt in physischen Maßen angegeben sind, grundsätzlich für unzuverlässig. Er schreibt auch, die Zielgrößen von Apple und Google wirkten eher an Plattform-Konventionen orientiert als an menschlichen Faktoren. Das macht sie nicht falsch, es heißt nur: Die Zahlen sind sinnvolle Faustregeln, keine Naturkonstanten.

Für die Praxis reicht eine einfache Einordnung:

24 × 24: die Untergrenze nach WCAG 2.2 AA. Darunter wird es für viele Menschen schwierig, und sobald die neue EN 301 549 gilt, auch rechtlich heikel.
44 × 44 bzw. 48 × 48: das, was Apple und Google für Touch empfehlen und was WCAG 2.5.5 auf Stufe AAA verlangt. Das ist der richtige Zielwert für Bedienelemente auf dem Smartphone.

Sichtbare Größe ist nicht gleich Trefferfläche

Ein Missverständnis hält sich hartnäckig: Ein 48-dp-Ziel muss nicht wie ein 48-dp-Button aussehen. Die WCAG definieren ein Ziel als den Bereich der Anzeige, der eine Zeigeraktion annimmt. Entscheidend ist also die Fläche, die reagiert, nicht die, die man sieht.

Google beschreibt das am Beispiel eines Symbols: Ein Icon von 24 × 24 dp kann mit umgebendem Innenabstand eine Trefferfläche von 48 × 48 dp bilden. Material-Komponenten wie Checkbox oder Switch fügen diesen Abstand in Jetpack Compose automatisch hinzu. Für eigene Elemente gibt es unter Android den sogenannten TouchDelegate, mit dem ein übergeordnetes Element Berührungen für ein kleineres annimmt. Apple formuliert es für Bildbuttons unter macOS ganz direkt: Die Kanten eines Buttons bestimmen seine klickbare Fläche, auch wenn sie nicht sichtbar sind.

Im Web funktioniert das genauso. Ein Symbol bleibt optisch 24 Pixel groß, der umgebende button bekommt genug Innenabstand oder eine Mindestgröße. Bei Formularen hilft HTML von sich aus: Wer ein label korrekt mit einer Checkbox verknüpft, macht den ganzen Text antippbar. MDN beschreibt diese größere Trefferfläche ausdrücklich als Vorteil für Touch-Bedienung.

Zwei Grenzen gibt es. Erstens dürfen sich unsichtbare Trefferflächen nicht überlappen. Die WCAG zählen überlappende Bereiche nicht zur Zielgröße, und Google weist darauf hin, dass sich manche eng stehenden Elemente nicht vergrößern lassen, ohne dass sich die Flächen überschneiden. Zweitens muss das Ziel als Ziel erkennbar bleiben. Eine riesige unsichtbare Fläche um ein kaum sichtbares Symbol hilft wenig, wenn niemand weiß, dass man dort tippen kann.

In der Parkschein-App bedeutet das:

Vorher: „Minus“ und „Plus“ als 20 Pixel große Symbole ohne Innenabstand, direkt nebeneinander. Das „X“ im Hinweisfenster: 16 Pixel, ganz in der Ecke.
Nachher: Beide Stellknöpfe sind 48 × 48 dp groß und sichtbar als Buttons gestaltet, mit dem Wert zwischen ihnen. Das „X“ bleibt optisch klein, hat aber eine Trefferfläche von 48 × 48 dp und rückt etwas vom Rand weg. Zusätzlich gibt es Schnellwahlen für 30, 60 und 120 Minuten.

Abstand: der unterschätzte Teil

Größe allein reicht nicht. Die Nielsen Norman Group bringt es auf eine einfache Reihenfolge: Ziele müssen zuerst groß genug sein und dann auch genug Abstand haben. Apple sieht das ähnlich und nennt Abstände zwischen Bedienelementen genauso wichtig wie ihre Größe. Als Faustregel empfiehlt Apple etwa 12 Punkt Innenabstand um Elemente mit sichtbarer Fläche (Apple spricht von „bezel“) und etwa 24 Punkt um die sichtbaren Kanten von Elementen ohne eine solche Fläche. Google empfiehlt mindestens 8 dp zwischen Touch-Zielen.

Die WCAG machen Abstand sogar zu einem Weg, das Kriterium 2.5.8 zu erfüllen. Ist ein Ziel kleiner als 24 × 24 CSS-Pixel, zeichnet man gedanklich einen Kreis mit 24 Pixel Durchmesser um seine Mitte. Schneidet dieser Kreis kein anderes Ziel und keinen Kreis eines anderen kleinen Ziels, ist das Kriterium erfüllt. Ein 16 Pixel großes Symbol mit genug Luft rundherum kann also konform sein. Das W3C empfiehlt trotzdem, unabhängig vom Abstand mindestens die Mindestgröße einzuhalten.

Abstand ist besonders dort wichtig, wo ein Fehlgriff teuer ist. Steven Hoober rät, gefährliche oder unzusammenhängende Aktionen weit entfernt von anderen zu platzieren, damit versehentliche Tipps weniger Folgen haben. „Parkvorgang beenden“ gehört also nicht direkt neben „Parkzeit verlängern“.

Die Daumenzone: was Steven Hoober wirklich herausgefunden hat

Kaum ein Thema rund um Touch-Ziele wird so oft vereinfacht wie die „Daumenzone“: eine Grafik mit grünem, gelbem und rotem Bereich, die zeigt, wohin der Daumen bequem reicht. Sie geht auf Arbeiten von Steven Hoober zurück, und es lohnt sich, genau hinzusehen, was er gefunden hat und was nicht.

2013 veröffentlichte Hoober im Magazin UXmatters eine Beobachtungsstudie. Er hatte über zwei Monate 1.333 Beobachtungen von Menschen gesammelt, die in der Öffentlichkeit ihr Smartphone nutzten, auf der Straße, an Haltestellen, in Cafés und Zügen. In 780 Fällen tippten die Menschen auf den Bildschirm. Davon hielten 49 Prozent das Gerät in einer Hand, 36 Prozent hielten es in einer Hand und bedienten es mit der anderen, 15 Prozent nutzten beide Hände.

Schon damals betonte Hoober die Grenzen: Menschen wechseln ihren Griff sehr oft, manchmal alle paar Sekunden. Es gab keine demografischen Daten, Geräte wurden nicht erfasst, Tablets fehlten, und beobachtet wurden meist nur die ersten Sekunden einer Nutzung. Die Bereiche für die Daumenreichweite bezeichnete er als grobe Annäherung, die je nach Person, Griff und Gerät schwankt.

2017 legte Hoober nach, gestützt auf weitere Beobachtungen, eine Auswertung von Forschungsliteratur und unter anderem eine Studie mit über 120 Millionen erfassten Berührungen. Seine Kernaussagen:

Menschen halten ihr Smartphone auf viele verschiedene Arten und wechseln den Griff häufig, oft ohne es zu merken.
Die verbreiteten Grafiken zur Daumenreichweite nennt er „bekannt, aber falsch“. Wie weit der Daumen reicht, hängt vom Griff ab, und Menschen passen ihren Griff an.
Menschen schauen und tippen bevorzugt in die Mitte des Bildschirms.
Die Treffgenauigkeit hängt von der Position ab: In der Mitte reichen Ziele ab etwa 7 Millimetern, in den Ecken braucht es rund 12 Millimeter. Diese Werte decken laut Hoober 95 Prozent der beobachteten Tipps ab, nicht alle.

Daraus leitet er eine Empfehlung ab: Hauptinhalte in die Mitte, sekundäre Aktionen an den oberen und unteren Rand, seltene Funktionen in Menüs in den Ecken.

Was das nicht bedeutet: dass es eine feste Zone gibt, in die alle wichtigen Elemente gehören, oder dass Elemente oben auf dem Bildschirm grundsätzlich unerreichbar sind. Die ehrliche Lesart ist bescheidener. Ziele am Rand und in den Ecken brauchen mehr Fläche als Ziele in der Mitte, und du solltest nicht davon ausgehen, dass Menschen dein Produkt immer auf dieselbe Weise halten.

In der Parkschein-App wandert deshalb der wichtigste Button, „Parkschein lösen“, als breiter Button in den unteren Bereich des Inhalts, nicht weil dort eine magische Zone liegt, sondern weil er so groß und klar abgesetzt ist, dass er sich in jedem Griff gut treffen lässt.

Sonderfälle

Links im Fließtext

Ein Link mitten in einem Satz kann nicht 44 Pixel hoch sein, ohne den Text zu zerreißen. Die WCAG nehmen solche Ziele deshalb ausdrücklich aus: Ein Ziel in einem Satz oder eines, dessen Größe durch die Zeilenhöhe des umgebenden Textes begrenzt ist, muss die Mindestgröße nicht erfüllen. Das W3C begründet das damit, dass sich bei responsivem Text nicht vorhersagen lässt, wo ein Link landet.

Die Ausnahme ist aber keine Einladung zur Nachlässigkeit. Eine großzügige Zeilenhöhe, klar erkennbare Links und keine zwei kurzen Links direkt nebeneinander helfen trotzdem. Wichtig: Die Ausnahme gilt nur für Links in Sätzen. Eine Reihe wie „Impressum | Datenschutz | AGB“ im Footer ist kein Fließtext und muss die Anforderungen erfüllen.

Dichte Werkzeugleisten

Editoren, Kartenansichten oder Bildbearbeitung brauchen oft viele Werkzeuge auf wenig Platz. Hier helfen drei Wege. Erstens der Abstand: Kleinere Symbole mit genug Luft können WCAG 2.5.8 über die Abstandsregel erfüllen. Zweitens die Auswahl: Seltene Werkzeuge wandern in ein Überlaufmenü, das selbst ein ausreichend großes Ziel ist. Drittens eine Alternative: Die WCAG lassen kleinere Ziele zu, wenn dieselbe Funktion über ein anderes, ausreichend großes Bedienelement auf derselben Seite erreichbar ist.

Wichtig ist auch der Kontext. Google weist darauf hin, dass Ziele für präzise Eingaben mit Maus oder Trackpad kleiner sein können. Eine dichte Werkzeugleiste in einer Desktop-Anwendung ist also etwas anderes als dieselbe Leiste auf dem Smartphone.

In der Parkschein-App:

Vorher: Sechs Symbole in der unteren Leiste, jeweils 32 Pixel breit, ohne Beschriftung und ohne Abstand.
Nachher: Vier beschriftete Einträge („Parken“, „Verlauf“, „Fahrzeuge“, „Mehr“), jeder mindestens 48 dp hoch und gleichmäßig über die Breite verteilt. Hilfe und Einstellungen liegen unter „Mehr“.

Kalender, Tabellen und Auswahllisten

Datumsauswahlen sind ein Klassiker für zu kleine Ziele: sieben Spalten auf schmalem Bildschirm, jede Zahl ein eigenes Ziel. Hier lohnt es sich, die ganze Zelle antippbar zu machen statt nur die Ziffer, und bei Bedarf eine Texteingabe als Alternative anzubieten. Ähnliches gilt für Listen und Tabellen: Wenn eine ganze Zeile zu einer Detailansicht führt, sollte auch die ganze Zeile reagieren.

Elemente des Browsers oder Systems

Native Bedienelemente, deren Größe der Browser bestimmt und die du nicht veränderst, fallen laut WCAG nicht unter 2.5.8. Eine unveränderte Checkbox ist also formal in Ordnung. Für Menschen ist sie trotzdem klein, und mit einem verknüpften Label lässt sich die Trefferfläche ohne Aufwand vergrößern.

So prüfst du Touch-Ziele

Am zuverlässigsten werden Touch-Ziele dort geregelt, wo Komponenten entstehen. Wenn Buttons, Icon-Buttons und Listeneinträge im Design System eine Mindestgröße mitbringen, muss niemand bei jedem Screen neu messen. Wie das mit wenig Aufwand gelingt, zeigt der Artikel Design Systems für kleine Teams.

Darüber hinaus helfen einfache Prüfungen:

Im Entwurf: Trefferflächen als eigene, halbtransparente Ebene einzeichnen. So siehst du sofort, wo sie zu klein sind oder sich überlappen.
Im Browser: Mit den Entwicklungswerkzeugen die tatsächliche Größe von Links und Buttons messen, einschließlich Innenabstand.
Unter Android: Google empfiehlt den Accessibility Scanner für manuelle Tests auf dem Gerät. Er erkennt einen TouchDelegate allerdings erst ab Android 10.
Auf echten Geräten: Die App mit einer Hand bedienen, im Gehen, mit dem Daumen. Fehltipps zählen.
Mit Menschen: Im Usability-Test auf versehentliche Tipps, wiederholte Versuche und Korrekturen achten. Besonders aufschlussreich sind Tests mit älteren Menschen oder Menschen mit motorischen Einschränkungen.

Weitere Werkzeuge und Methoden beschreibt der Artikel Accessibility-Prüfung: Werkzeuge und Methoden.

Grenzen und Fallstricke

Größer ist nicht immer besser. Ziele können so groß werden, dass kaum noch Inhalt auf den Bildschirm passt und Menschen mehr scrollen müssen. Das Ziel sind ausreichend große Ziele, nicht möglichst große.

Die Mindestgröße ist keine Designentscheidung. Wer überall exakt 24 × 24 Pixel baut, weil das „WCAG-konform“ ist, liegt deutlich unter dem, was Apple, Google und die Forschung für Touch empfehlen. Das W3C empfiehlt für häufig genutzte, schwer rückgängig zu machende oder schwer erreichbare Bedienelemente ausdrücklich größere Ziele.

Zahlen ersetzen keinen Test. Die Werte aus Richtlinien und Studien sind Durchschnittswerte. Menschen mit Tremor, mit großen Händen oder mit Handschuhen im Winter brauchen mehr Spielraum. Wie viel, zeigt nur der Test mit den Menschen, die das Produkt tatsächlich nutzen. Warum Barrierefreiheit weit über solche Einzelregeln hinausgeht, beschreibt der Artikel Warum Barrierefreiheit mehr als Kontrast und Größe ist.

Daumenzonen sind keine Bauvorschrift. Wer alle Bedienelemente nach unten schiebt, weil eine Grafik das nahelegt, ignoriert, wie unterschiedlich Menschen ihr Gerät halten. Hoober selbst hält solche Grafiken inzwischen für falsch.

Fazit

Wie groß Buttons auf dem Smartphone sein müssen, lässt sich erstaunlich klar beantworten. Rechtlich und nach WCAG 2.2 AA liegt die Untergrenze bei 24 × 24 CSS-Pixeln oder ausreichend Abstand. Für eine gute Bedienung mit dem Finger solltest du dich an 44 × 44 Punkt (Apple) beziehungsweise 48 × 48 dp (Google) orientieren, was ungefähr einem Zentimeter entspricht. Die Forschung von Fitts bis Parhi stützt diese Größenordnung.

Wichtiger als die genaue Zahl sind drei Prinzipien: Die Trefferfläche zählt, nicht die sichtbare Größe. Abstand ist genauso wichtig wie Größe. Und Ränder und Ecken brauchen mehr Spielraum als die Mitte. Die Parkschein-App aus dem Beispiel hat nach der Überarbeitung größere Stellknöpfe, eine Schnellwahl, ein „X“ mit ausreichender Trefferfläche und eine aufgeräumte Navigationsleiste. Optisch hat sich wenig verändert. Aber niemand muss mehr dreimal tippen, um einen Parkschein zu lösen.

Checkliste

Alle Touch-Ziele sind mindestens 24 × 24 CSS-Pixel groß oder haben ausreichend Abstand (WCAG 2.5.8).
Wichtige Bedienelemente erreichen 44 × 44 pt beziehungsweise 48 × 48 dp.
Kleine Symbole haben eine größere, unsichtbare Trefferfläche durch Innenabstand.
Trefferflächen überlappen sich nicht.
Zwischen Zielen liegen mindestens 8 dp, gefährliche Aktionen stehen abseits.
Ziele am Rand und in den Ecken sind großzügiger bemessen als in der Mitte.
Labels von Checkboxen und Radiobuttons sind verknüpft und antippbar.
Links außerhalb von Fließtext, etwa im Footer, erfüllen die Mindestgröße.
Dichte Werkzeugleisten sind reduziert oder haben eine Alternative.
Mindestgrößen sind im Design System hinterlegt.
Die Bedienung ist auf echten Geräten mit einer Hand getestet.

Touch-Ziele: Wie groß Buttons auf dem Smartphone sein müssen