Touch Target Größe: WCAG, iOS, Android und Tailwind

Frag nach der minimalen Touch Target Größe und du bekommst vier Zahlen: 24, 28, 44 und 48. Sie stammen aus verschiedenen Dokumenten und nutzen verschiedene Einheiten, und zwei davon sind Untergrenzen, die niemand als Designziel nehmen sollte. Dieses Tutorial ordnet, was WCAG 2.2, Apple und Android verlangen, wählt eine Zahl für eine React-Web-App und baut sie in Tailwind CSS v4.1: Buttons, Icon-Buttons und Checkboxen, die auf dem Smartphone 44px große Taps annehmen, während der Desktop seine Controls mit 32px und 40px behält. Am Ende steht ein Playwright-Test, der fehlschlägt, sobald ein Ziel schrumpft.

Wie groß muss ein Touch Target mindestens sein?

Die minimale Touch Target Größe (auf Englisch „minimum touch target size“) liegt bei 24 mal 24 CSS-Pixeln für WCAG 2.2 Stufe AA, bei 44 mal 44 für WCAG Stufe AAA und für Apples Standard-Control auf iOS, und bei 48 mal 48 dp für Material und Android. Der Rest jedes Dokuments dreht sich um Ausnahmen und Abstände:

Die Einheiten liegen näher beieinander, als es aussieht. Mit dem Viewport width=device-width, den der Next.js App Router standardmäßig setzt, ist ein CSS-Pixel auf dem iPhone ein Punkt und auf Android ein dp. 44px in deinem CSS sind also Apples 44 pt, und 48px sind die 48 dp von Material.

Zwei Details zählen mehr als die Zahlen. WCAG misst die Fläche, die den Tap annimmt; die Definition spricht vom Bereich der Anzeige, der eine Pointer-Aktion entgegennimmt. Padding zählt also mit, und ein kleines Icon kann trotzdem bestehen. Außerdem gilt WCAG für jeden Pointer, auch für die Maus, also betrifft die Untergrenze von 24px auch dein Desktop-Layout.

Was verlangt WCAG 2.2 für Touch Targets?

Damit ein Touch Target WCAG 2.2 auf Stufe AA erfüllt, muss es mindestens 24 mal 24 CSS-Pixel groß sein, außer eine von fünf Ausnahmen greift. Die Spezifikation (opens in a new tab) zählt sie auf:

• Abstand. Ein zu kleines Ziel besteht, wenn ein Kreis mit 24px Durchmesser, zentriert auf seiner Bounding Box, kein anderes Ziel und keinen Kreis eines anderen zu kleinen Ziels schneidet. In der Praxis heißt das: Die Mittelpunkte zu kleiner Ziele brauchen mindestens 24px Abstand voneinander und mindestens 12px zum Rand jedes anderen Ziels.
• Gegenstück. Ein anderes Control auf derselben Seite tut dasselbe und erfüllt die Größe.
• Inline. Das Ziel steht in einem Satz, etwa ein Link in einem Absatz.
• User-Agent-Control. Der Browser bestimmt die Größe des Controls, und du hast es nicht umgestylt.
• Unverzichtbar. Genau diese Darstellung ist unverzichtbar oder rechtlich vorgeschrieben.

Stufe AAA (2.5.5) verlangt 44 mal 44 mit denselben Ausnahmen, nur ohne die Abstandsregel. Die WCAG-Definition eines Ziels enthält einen Hinweis, der für die Techniken weiter unten wichtig ist: Wo sich Ziele überlappen, zählt die Überlappung nicht zu ihrer Größe, außer sie lösen dieselbe Aktion aus oder öffnen dieselbe Seite.

Behandle AA als Untergrenze für Audits. AA lässt ein 24px großes Icon durch, und Apple und Google verlangen auf Touch etwa das Doppelte.

Welche Touch Target Größe empfehlen iOS und Android?

Apple nennt 44 mal 44 Punkte als Standardgröße für Controls auf iOS und iPadOS und 28 mal 28 Punkte als Minimum. Googles Android-Leitfaden verlangt 48 mal 48 dp mit mindestens 8 dp zwischen den Zielen, was laut Google etwa 9 mm entspricht.

Apple rät außerdem, den Abstand zwischen Controls genauso ernst zu nehmen wie ihre Größe, und schlägt etwa 12 Punkte Padding um Controls mit Rahmen vor und etwa 24 um Controls ohne Rahmen. Natives Android nimmt dir einen Teil der Arbeit ab: Die Compose-Referenz (opens in a new tab) bezeichnet 48 dp als die von Material empfohlene Mindestgröße und erklärt, dass das System Touch Targets auf der Eingabeebene vergrößert. Im Web baust du diese Fläche selbst, in CSS.

Welche Größe sollte eine React-Web-App nutzen?

Nimm 44px auf groben Pointern, halte 8px zwischen benachbarten Zielen, geh für keinen Pointer unter 24px und gib der Hauptaktion eines Smartphone-Screens 48px. Ein 44px Touch Target erfüllt WCAG AAA und Apples Standard mit einer einzigen Zahl. Wenn deine Analytics zeigen, dass die meisten deiner Nutzer Android verwenden, tausch 44 gegen 48: pointer-coarse:h-12 auf Buttons und 48px im Utility hit-area weiter unten.

Am Desktop schießen Teams übers Ziel hinaus. Apples eigener Standard für ein macOS-Control sind 28 Punkte, und 44px große Controls überall lassen ein Einstellungsformular oder eine Tabellen-Toolbar wie einen Kiosk aussehen. Richte die Größe nach dem Eingabegerät statt nach der Bildschirmbreite.

Wie erreichst du 44px auf Touch, ohne den Desktop aufzublähen?

Schalte die Größen über die Pointer Coarse Media Query, @media (pointer: coarse), die greift, wenn der primäre Pointer ein Finger ist. Tailwind CSS v4.1 hat sie als Variante pointer-coarse (opens in a new tab) eingeführt. Ein Breakpoint nach Bildschirmbreite liegt hier gleich doppelt falsch: Ein iPad im Querformat ist breiter als lg und bekommt Controls in Mausgröße, und ein schmales Desktop-Fenster bekommt Controls in Daumengröße.

Es gibt drei Techniken, hier nach Priorität geordnet.

Das Control wachsen lassen, wenn das Layout Platz hat

Ein Text-Button verträgt 4 Pixel mehr Höhe. Das ist die Größen-Map des Buttons in Wingo UI:

// components/ui/button.tsx (Auszug): 32 / 40 / 48px
const SIZES: Record<ButtonSize, string> = {
  sm: "h-8 gap-1.5 px-3 text-[13px] pointer-coarse:after:absolute pointer-coarse:after:inset-x-0 pointer-coarse:after:-inset-y-1.5",
  md: "h-10 gap-2 px-4 text-sm pointer-coarse:h-11",
  lg: "h-12 gap-2 px-5 text-[15px]",
  "icon-sm": "size-8 pointer-coarse:after:absolute pointer-coarse:after:-inset-1.5",
  icon: "size-10 pointer-coarse:size-11",
  "icon-lg": "size-12",
};

Das Standard-md ist mit der Maus 40px hoch und unter dem Finger 44px, und dasselbe gilt für die quadratische Größe icon. lg ist überall 48px, was zu einem Submit-Button über die volle Breite unten auf einem Smartphone-Screen passt. Weil die Klasse eine Media Query ist, stimmt das serverseitig gerenderte HTML schon beim ersten Paint.

Eine unsichtbare Trefferfläche ergänzen, wenn das Control klein aussehen muss

Ein 32px großes Icon in einer Toolbar soll 32px bleiben. Gib ihm ein Pseudo-Element, das auf Touch über seine Ränder hinausragt: (44 - 32) / 2 = 6px auf jeder Seite, also -inset-1.5. Genau das tun sm und icon-sm oben; sm erweitert nur vertikal, weil ein Text-Button meist ohnehin breiter als 44px ist. In Tailwind v4 setzt die Variante after: das content für dich, und der Button ist schon relative (sein ::before trägt die Hover-Tönung).

Für deine eigenen Komponenten erledigt ein einziges Utility die Rechnung für jede Größe:

/* app/globals.css */
/* eine 44px große Trefferfläche um jedes kleinere Control; das Control muss positioniert sein */
@utility hit-area {
  &::after {
    content: "";
    position: absolute;
    inset-block: min(0px, calc((100% - 44px) / 2));
    inset-inline: min(0px, calc((100% - 44px) / 2));
  }
}

import { X } from "lucide-react";

export function DismissButton({ onDismiss }: { onDismiss: () => void }) {
  return (
    <button
      type="button"
      aria-label="Schließen"
      onClick={onDismiss}
      className="relative grid size-7 touch-manipulation place-items-center rounded-full [-webkit-tap-highlight-color:transparent] pointer-coarse:hit-area"
    >
      <X className="size-4" />
    </button>
  );
}

Die Prozente beziehen sich auf das Control selbst, und min(0px, ...) verkleinert nie ein Control, das schon groß genug ist. Wir haben es in Chromium gemessen: Ein 16px und ein 32px großer Button nehmen beide Taps auf genau 44 mal 44 an, ein Button mit 80 mal 32 auf 80 mal 44, und ein 60px großer Button behält seine 60px.

Trefferflächen scheitern auf drei Arten, und alle bleiben unsichtbar, bis jemand danebentippt:

1. Abschneiden. overflow-hidden auf dem Control schneidet sein eigenes ::after ab, und ein Vorfahr mit overflow-hidden schneidet es an seinem Rand ab. Leg das Abschneiden stattdessen auf eine innere Ebene. Der Haptic Button schneidet seinen Ripple und die Füllung beim Halten auf einer inneren Ebene ab, damit der Button selbst seine 44px Fläche behält.
2. Überlappung. Zwei 32px große Icons mit 4px Abstand haben 44px große Flächen, die sich um 8px überlappen. Das spätere Icon im DOM gewinnt jeden Tap in der Überlappung, und WCAG rechnet sie keinem der beiden an. Halte die Mittelpunkte auf Touch 44px auseinander: gap-1 pointer-coarse:gap-3 für 32px große Icons.
3. Keine Positionierung. Ohne relative auf dem Control richtet sich das ::after nach dem nächsten positionierten Vorfahren, und dieser ganze Vorfahr wird zu einem unsichtbaren Ziel für dieses eine Control.

Das Label zum Ziel machen

Bei Checkboxen, Radios und Switches darf das Kästchen 16 bis 20px groß bleiben, wenn die ganze Zeile den Tap annimmt. Die Checkbox rendert die Zeile als ein einziges <label>. Auf einem groben Pointer ist die Zeile mindestens 44px hoch (pointer-coarse:min-h-11) und nimmt die volle Breite ein, und in einer Gruppe fällt der Abstand zwischen den Zeilen auf null, während das Padding in jede Zeile wandert. Ein Tap zwischen zwei Optionen landet so immer auf einer davon. Ein Kästchen ohne Label, etwa in einer Tabellenzelle, bekommt stattdessen die ::after-Behandlung: Die Checkbox ergänzt 14px auf jeder Seite ihrer 16px und 18px großen Kästchen und 12px um das 20px große.

Dieselbe Idee funktioniert mit einem nativen Input. min-h-6 hält die Zeile für die Maus auf der Untergrenze von 24px:

export function ReleaseEmails() {
  return (
    <label className="flex min-h-6 w-fit cursor-pointer touch-manipulation items-center gap-3 text-sm pointer-coarse:min-h-11 pointer-coarse:w-full">
      <input type="checkbox" name="releases" className="size-4" />
      Schick mir eine E-Mail, wenn eine neue Version erscheint
    </label>
  );
}

Solltest du pointer: coarse oder any-pointer: coarse nutzen?

Nimm in den meisten Apps pointer: coarse für Größen. Die Query beschreibt die primäre Eingabe, also greift sie auf Smartphone und Tablet, aber nicht auf dem Laptop. any-pointer: coarse (opens in a new tab) greift, wenn mindestens ein angeschlossenes Eingabegerät grob ist, und MDN weist darauf hin, dass mehrere Werte gleichzeitig zutreffen können. Ein Laptop mit Touchscreen hat meist einen feinen primären Pointer, also greift dort any-pointer: coarse, aber nicht pointer: coarse.

Wähl any-pointer, wenn Touch eine häufige zweite Eingabe ist, etwa bei Convertibles und All-in-One-PCs mit Touchscreen; der Preis sind größere Controls, während jemand das Trackpad nutzt. Damit diese Entscheidung an einer Stelle bleibt, gib ihr einen Namen:

/* app/globals.css: jede touch:*-Klasse folgt dieser einen Zeile */
@custom-variant touch (@media (pointer: coarse));
/* stattdessen Laptops mit Touchscreen einschließen: */
/* @custom-variant touch (@media (any-pointer: coarse)); */

Dann schreibst du touch:h-11 und touch:hit-area und änderst die Definition später in einer Zeile. Wingo UI nutzt pointer: coarse; der Hook useMediaQuery exportiert sie als TOUCH_QUERY, damit Komponenten und App-Code dasselbe unter Touch verstehen.

Wann solltest du Touch-Geräte in React erkennen?

Erkenne Touch in React nur für Verhalten, nie für Größen. Der Server kennt den Pointer nicht, also gibt useIsTouch() auf dem Server und während der Hydration false zurück. Eine Größe, die der Hook wählt, rendert zuerst Desktop-Controls und springt dann auf Smartphones; die CSS-Variante stimmt ab dem ersten Paint. Der Guide zu Mobile-first React-Komponenten behandelt dieselbe Trennung fürs Layout, und das Tutorial zum SSR-sicheren React use mobile Hook erklärt, warum diese Hooks auf dem Server false liefern.

Nutze ihn in Effects und Event-Handlern. Autofokus ist der klassische Fall, denn ein fokussiertes Eingabefeld öffnet auf dem Smartphone die Tastatur über den halben Screen. Dieses Snippet nutzt den kostenlosen Hook, installiert mit npx wingo-ui@latest add use-media-query:

"use client";

import { useEffect, useRef } from "react";
import { matchesMedia, TOUCH_QUERY } from "@/hooks/use-media-query";

export function ClientSearch() {
  const ref = useRef<HTMLInputElement>(null);

  // auf Touch würde der Fokus die Tastatur öffnen, bevor jemand danach gefragt hat
  useEffect(() => {
    if (!matchesMedia(TOUCH_QUERY)) ref.current?.focus();
  }, []);

  return (
    <input
      ref={ref}
      type="search"
      name="q"
      placeholder="Kunden suchen"
      className="h-10 w-full rounded-[10px] border border-border bg-transparent px-3 text-base pointer-coarse:h-11 sm:text-sm"
    />
  );
}

Für Entscheidungen pro Interaktion liest du event.pointerType statt einer Media Query, weil ein Laptop mit Touchscreen beide Arten von Events senden kann. Der Haptic Button spielt sein haptisches Ticken nur bei Touch und Stift ab; ein Mausklick vibriert nie.

Wie testest du Touch Targets?

Lass axe für die Untergrenze von 24px laufen und einen Hit-Test bei 44px mit Touch-Emulation, und probier den Screen dann auf einem echten Smartphone mit dem Daumen aus.

Die Regel target-size von axe-core prüft WCAG 2.5.8. In axe-core 4.13 ist sie standardmäßig aus und läuft, wenn du das Tag wcag22aa anforderst, zum Beispiel new AxeBuilder({ page }).withTags(["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"]) mit @axe-core/playwright. Sie prüft die AA-Untergrenze, also besteht ein 32px großer Icon-Button ohne Trefferfläche.

Für 44px prüfst du, was der Browser tatsächlich trifft. In Chromium sorgt hasTouch: true in Playwright dafür, dass (pointer: coarse) greift und (hover: hover) nicht mehr, also wirken deine pointer-coarse:-Klassen. document.elementFromPoint an den Ecken eines 44px Quadrats um jedes Control findet dann alle drei Fehler von oben, weil der Hit-Test ::after einbezieht, Overflow-Clipping beachtet und von zwei überlappenden Zielen das oberste liefert:

// e2e/touch-targets.spec.ts
import { expect, test } from "@playwright/test";

const MIN = 44;
const CONTROLS =
  'button, a[href], input:not([type="hidden"]), select, textarea, summary, [role="button"], [role="checkbox"], [role="switch"], [role="tab"]';

// hasTouch lässt (pointer: coarse) greifen, also wirken die pointer-coarse:-Styles
test.use({ viewport: { width: 390, height: 844 }, hasTouch: true, isMobile: true });

test("jedes Control nimmt auf Touch 44px große Taps an", async ({ page }) => {
  // eine beliebige Seite deiner App; eine relative URL braucht baseURL in playwright.config.ts
  await page.goto("/settings");
  const misses = await page.evaluate(
    ({ selector, min }) => {
      const half = min / 2 - 1;
      const found: string[] = [];
      for (const el of document.querySelectorAll<HTMLElement>(selector)) {
        // Links im Fließtext sind ausgenommen (die Inline-Ausnahme)
        if (el.matches("a") && el.closest("p, label")) continue;
        if (el.closest("[aria-hidden='true'], [inert]")) continue;
        // ein Control in einem <label> ist so groß wie das Label
        const target = el.closest("label") ?? el;
        target.scrollIntoView({ block: "center" });
        const box = target.getBoundingClientRect();
        if (!box.width || !box.height) continue;
        const x = box.left + box.width / 2;
        const y = box.top + box.height / 2;
        const corners = [[-half, -half], [half, -half], [-half, half], [half, half]];
        // der Hit-Test sieht ::after-Trefferflächen, Overflow-Clipping und überlappende Nachbarn
        const ok = corners.every(([dx, dy]) => target.contains(document.elementFromPoint(x + dx, y + dy)));
        if (!ok) found.push(`${Math.round(box.width)}x${Math.round(box.height)} ${el.outerHTML.slice(0, 80)}`);
      }
      return found;
    },
    { selector: CONTROLS, min: MIN },
  );
  expect(misses).toEqual([]);
});

Mit Playwright 1.63 bestehen die Checkbox-Demo und der Button in icon-sm, während ein nackter 32px großer Button und einer in einem Wrapper mit overflow-hidden beide gemeldet werden.

Die Emulation beweist das CSS. Sie beweist nicht, dass das Layout mit einer Hand funktioniert, also teste zum Schluss auf einem Smartphone: Greif mit der Hand, die es hält, nach den oberen Ecken, und tippe auf die Controls, die du nah beieinander platziert hast.

Wo fängst du an?

Installier den kostenlosen Button mit npx wingo-ui@latest add button und öffne deine App auf dem Smartphone: Jeder md-Button ist dort 44px hoch und mit der Maus 40px, und die kleinen Größen bringen ihre eigene Trefferfläche mit. Ergänze die Checkbox für Formulare und kopier das Utility hit-area für alles, was du selbst gebaut hast. Der Haptic Button, mit derselben Größen-Map plus Feedback beim Drücken und Halten zum Bestätigen, gehört zu Wingo UI Pro. Für die übrigen Regeln fürs Smartphone, von Bottom Sheets bis zu Safe Areas, sieh dir Mobile UI mit React an.

Häufige Fragen

Wie groß muss ein Touch Target nach WCAG 2.2 mindestens sein?

Stufe AA (SC 2.5.8) verlangt 24 mal 24 CSS-Pixel, mit Ausnahmen für kleine Ziele mit genug Abstand, Links in einem Satz, nicht umgestylte Browser-Controls, Controls mit einem Gegenstück an anderer Stelle der Seite und unverzichtbare Darstellungen. Stufe AAA (SC 2.5.5) verlangt 44 mal 44 CSS-Pixel.

Wie groß sollte ein Touch Target auf iOS sein?

Stand Oktober 2026 nennen Apples Human Interface Guidelines 44 mal 44 Punkte als Standardgröße für Controls auf iOS und iPadOS und 28 mal 28 Punkte als Minimum. In einem mobilen Browser mit dem Viewport width=device-width ist ein CSS-Pixel ein Punkt, also entsprechen 44px in CSS Apples 44 pt.

Reicht ein 44px Touch Target für Android?

Es erfüllt WCAG AAA und Apples Standard, liegt aber 4px unter der Empfehlung für Android. Googles Android-Leitfaden zur Barrierefreiheit verlangt 48 mal 48 dp mit 8 dp Abstand zwischen Zielen, und ein dp ist im mobilen Browser ein CSS-Pixel. Wenn die meisten deiner Nutzer Android verwenden, nimm 48px auf groben Pointern.

Zählt eine unsichtbare Trefferfläche zur Touch Target Größe?

Ja. WCAG misst den Bereich, der Pointer-Eingaben annimmt, also zählen Padding und eine Trefferfläche aus einem Pseudo-Element. Sie zählt nicht mehr, wo ein Vorfahr mit overflow-hidden sie abschneidet oder wo sie einen Nachbarn mit einer anderen Aktion überlappt.

Was ist die Media Query pointer coarse?

@media (pointer: coarse) greift, wenn das primäre Zeigegerät ungenau ist, etwa ein Finger auf einem Touchscreen. Tailwind CSS ab v4.1 liefert sie als Variante pointer-coarse; any-pointer: coarse greift, wenn irgendein angeschlossenes Eingabegerät grob ist, und das schließt einen Laptop mit Touchscreen ein.

Erreichen die Komponenten von Wingo UI 44px auf Touchscreens?

Button, Checkbox und Haptic Button tun es. Mittlere Buttons wachsen unter pointer: coarse von 40 auf 44px, kleine behalten ihr Aussehen und bekommen eine 44px große Trefferfläche, und Checkbox-Zeilen sind mindestens 44px hoch, mit der ganzen Zeile als Ziel. Button und Checkbox sind kostenlos; der Haptic Button gehört zu Pro.