WCAG 2.5.5: Zielgröße (erweitert)

WCAG 2.5.5 verlangt, dass interaktive Ziele wie Schaltflächen und Links mindestens 44×44 CSS-Pixel groß sind, damit Menschen mit motorischen Beeinträchtigungen, Tremor oder eingeschränkter Geschicklichkeit Steuerelemente zuverlässig aktivieren können, ohne versehentlich benachbarte Elemente auszulösen.

Was diese Regel bedeutet

WCAG 2.5.5 Target Size (Enhanced) ist ein Kriterium der Stufe AAA unter WCAG 2.2, das eine strenge Mindestgröße für interaktive Elemente festlegt. Konkret verlangt es, dass die Größe des Ziels – der anklickbare oder antippbare Bereich einer beliebigen Benutzeroberflächenkomponente – in Breite und Höhe mindestens 44 mal 44 CSS-Pixel betragen muss. Dies gilt für alle zeigerbasierten Interaktionen, einschließlich Mausklicks, Touchscreen-Tipps und Stifteingaben.

Es ist wichtig zu verstehen, was in diesem Kontext genau das „Ziel“ darstellt. Das Ziel ist der gesamte aktivierbare Bereich des Steuerelements, nicht nur seine visuelle Darstellung. Ein kleines Symbol kann visuell 16×16 Pixel groß sein, aber wenn das umgebende Padding den anklickbaren Bereich auf 44×44 Pixel erweitert, kann das Kriterium dennoch erfüllt werden. Das bedeutet, dass Entwickler Padding strategisch einsetzen können, um die Anforderung zu erfüllen, ohne das visuelle Design drastisch zu verändern.

Das Kriterium definiert ein Bestehen als jedes interaktive Element, dessen Zielbereich mindestens 44×44 CSS-Pixel misst. Ein Nichtbestehen liegt vor, wenn der aktivierbare Bereich eines interaktiven Elements in einer der Dimensionen unter diese Schwelle fällt – zum Beispiel würde ein Link, der 44 Pixel breit, aber nur 20 Pixel hoch ist, dennoch durchfallen.

WCAG 2.5.5 sieht mehrere offizielle Ausnahmen vor, bei denen die Anforderung von 44×44 nicht gilt. Diese sind:

Abstand: Unterdimensionierte Ziele sind zulässig, wenn ein ausreichender Versatzabstand sie von allen anderen Zielen trennt. Das Ziel muss so positioniert sein, dass, wenn ein Kreis mit 44×44 CSS-Pixeln darauf zentriert würde, dieser Kreis kein anderes Ziel oder die Begrenzungsbox des 44×44-Kreises eines anderen Ziels schneidet. Diese Ausnahme verhindert, dass die Regel Layoutänderungen verlangt, wenn benachbarte Steuerelemente von Natur aus klein, aber gut getrennt sind.
Äquivalent: Ein alternatives Steuerelement auf derselben Seite erfüllt dieselbe Funktion und erfüllt die Mindestgrößenanforderung.
Inline: Das Ziel befindet sich in einem Satz oder seine Größe ist anderweitig durch die Zeilenhöhe von Nicht-Ziel-Text eingeschränkt. Hyperlinks innerhalb eines Absatzes von Fließtext sind beispielsweise ausgenommen, weil ihre Vergrößerung den Textfluss stören würde.
Steuerung durch User Agent: Die Größe wird vollständig durch den Browser oder das Betriebssystem bestimmt und kann vom Autor nicht verändert werden. Native Browser-Formularsteuerelemente in ihrem ungestylten Zustand können in diese Kategorie fallen.
Wesentlich: Eine bestimmte Darstellung des Ziels ist für die zu vermittelnden Informationen wesentlich. Dies ist eine enge Ausnahme für Fälle, in denen eine Änderung der Zielgröße die Bedeutung oder Funktionalität grundlegend verändern würde.

Dieses Kriterium wurde in WCAG 2.2 eingeführt und ersetzt die frühere, weniger strenge Anleitung zu Zeigerzielen. Sein Begleitkriterium, WCAG 2.5.8 Target Size (Minimum) auf Stufe AA, setzt eine niedrigere Schwelle von 24×24 CSS-Pixeln mit einer abstandsbezogenen Berechnung, aber 2.5.5 bleibt der Goldstandard für verbesserte Barrierefreiheit.

Warum es wichtig ist

Motorische und Geschicklichkeitsbeeinträchtigungen betreffen einen erheblichen Teil der Weltbevölkerung. Laut der Weltgesundheitsorganisation leben etwa 1,3 Milliarden Menschen – oder 16 % der Weltbevölkerung – mit einer Form einer erheblichen Behinderung, wobei motorische und muskuloskelettale Erkrankungen zu den häufigsten gehören. Erkrankungen wie Parkinson, essenzieller Tremor, Zerebralparese, Multiple Sklerose, Schlaganfall-bedingte Hemiplegie und Belastungsschäden (RSI) verringern alle die Fähigkeit einer Person, präzise Zeigerbewegungen auszuführen. Auf mobilen Geräten können selbst Nutzer ohne Behinderungen mit kleinen Zielen kämpfen – etwa beim Tragen von Handschuhen, bei nassen Händen oder wenn sie ein Telefon einhändig bedienen.

Betrachten wir ein konkretes Szenario aus der realen Welt: Eine Person mit rheumatoider Arthritis surft auf einem türkischen E-Commerce-Portal auf einem Touchscreen-Tablet, um Medikamente zu kaufen. Der Checkout-Prozess enthält kleine Optionsfelder (Radio Buttons), schmale Dropdown-Menüs und eine 24×18 Pixel große Schaltfläche „Bestellung bestätigen“. Jeder Fehl-Tipp wählt entweder die falsche Option aus oder bewirkt gar nichts, sodass der Nutzer mehrere Versuche benötigt. Die Frustration ist nicht nur eine Unannehmlichkeit – sie kann dazu führen, dass der Kauf vollständig abgebrochen wird, wodurch ein Barrierefreiheitsversagen direkt zu einem Umsatzverlust für das Unternehmen wird.

Über motorische Beeinträchtigungen hinaus profitieren viele Nutzer von ausreichend großen Zielen. Ältere Menschen haben häufig gleichzeitig eine verringerte Feinmotorik und eine eingeschränkte Sehschärfe, was kleine Ziele doppelt schwierig macht. Nutzer mit kognitiven Beeinträchtigungen benötigen möglicherweise länger, um einen Zeiger zu positionieren, und lösen eher benachbarte Steuerelemente aus, wenn Ziele dicht gedrängt sind. Selbst sehende, nicht behinderte Nutzer profitieren auf mobilen Geräten von größeren Zielen – eine Tatsache, die seit Jahren Designkonventionen bei großen Technologieunternehmen prägt. Die Human Interface Guidelines von Apple empfehlen ein minimales Tippziel von 44×44 Punkten, und Googles Material Design Guidelines empfehlen aus denselben Gründen mindestens 48×48 dichteunabhängige Pixel.

Aus SEO- und Usability-Perspektive belohnt Googles Core Web Vitals-Metrik „Interaction to Next Paint“ (INP) Oberflächen, bei denen Nutzerinteraktionen schnell und korrekt registriert werden. Fehl-Tipps aufgrund unterdimensionierter Ziele erhöhen die Interaktionsfehlerraten, verlängern die Bearbeitungszeit und steigern die Absprungraten – alles Signale, die das Suchranking indirekt beeinflussen können. Verbesserungen der Barrierefreiheit auf Zeigerebene haben daher messbare geschäftliche Auswirkungen über die reine Compliance hinaus.

Wie man testet

Führen Sie einen automatisierten Scan als Basis durch: Öffnen Sie axe DevTools oder Lighthouse in den Chrome DevTools auf der zu testenden Seite. Filtern Sie in axe DevTools die Ergebnisse nach „target-size“, falls unter experimentellen Regeln verfügbar. Notieren Sie alle markierten Elemente, verstehen Sie jedoch, dass dieser Scan nicht alle 2.5.5-Verstöße erfasst und sich möglicherweise auf die 2.5.8-Schwelle statt auf 44×44 Pixel bezieht. Verwenden Sie den Accessibility-Audit von Lighthouse, um nach verwandten Warnungen zu Zeigerzielen zu suchen.
Messen Sie Zielgrößen mit Browser DevTools: Öffnen Sie die DevTools von Chrome oder Firefox und verwenden Sie das Elements-Panel, um jedes interaktive Element zu inspizieren – Schaltflächen, Links, Formulareingaben, Kontrollkästchen, Optionsfelder, benutzerdefinierte Steuerelemente und reine Symbol-Steuerelemente. Überprüfen Sie im Panel „Computed styles“ die gerenderte Breite und Höhe. Denken Sie daran, dass Padding bei Block-Elementen in das Klickziel einbezogen wird, bei Inline-Elementen jedoch möglicherweise nicht. Verifizieren Sie, dass der berechnete Trefferbereich mindestens 44×44 CSS-Pixel beträgt.
Verwenden Sie die integrierten Barrierefreiheits-Tools des Browsers: Öffnen Sie in den Chrome DevTools den Tab „Rendering“ und aktivieren Sie „Emulate a focused page“ oder verwenden Sie den Accessibility Tree, um Elemente zu inspizieren. Verwenden Sie in Firefox den Accessibility Inspector, um interaktive Elemente zu identifizieren und ihre Begrenzungsbox-Dimensionen gegenzuprüfen.
Testen Sie auf realen Touch-Geräten: Verbinden Sie ein physisches iOS-Gerät und testen Sie mit aktiviertem VoiceOver (dreifaches Drücken der Seitentaste zum Aktivieren). Navigieren Sie durch Tippen und verwenden Sie den Rotor, um zwischen interaktiven Elementen zu wechseln. Versuchen Sie, kleine Ziele zu aktivieren, und notieren Sie, wie oft benachbarte Elemente versehentlich ausgelöst werden. Wiederholen Sie dies auf einem Android-Gerät mit TalkBack (nach rechts wischen zum Navigieren, doppelt tippen zum Aktivieren). Achten Sie besonders auf benutzerdefinierte Widgets, die aus <div>- oder <span>-Elementen aufgebaut sind.
Testen Sie Abstands-Ausnahmen manuell: Zeichnen Sie für jedes Ziel, das kleiner als 44×44 Pixel ist und die Abstands-Ausnahme beansprucht, eine imaginäre 44×44 Pixel große Begrenzungsbox, die auf dieses Ziel zentriert ist, und bestätigen Sie visuell, dass kein anderes interaktives Element in diese Box fällt. Browsererweiterungen oder Overlay-Tools, die Begrenzungsboxen zeichnen, können hierbei helfen.
Tastatur- und Screenreader-Überprüfung: Testen Sie mit NVDA + Firefox und JAWS + Chrome, indem Sie alle interaktiven Elemente mit der Tab-Taste durchlaufen. Während die Tastaturfokussierung die Zeigerzielgröße nicht direkt testet, hilft sie dabei zu erkennen, ob alle Steuerelemente erreichbar sind, und bestätigt das Element-Inventar, mit dem Sie die Zeigergrößen abgleichen. VoiceOver + Safari auf macOS kann verwendet werden, um zu verifizieren, dass benutzerdefinierte Steuerelemente korrekt angekündigt werden und über ausreichende Aktivierungsbereiche verfügen, wenn sie per Zeiger angeklickt werden.
Testen Sie bei mehreren Viewport-Größen: Zielgrößen können zwischen Desktop- und mobilen Layouts variieren. Testen Sie bei Viewport-Breiten von 320px, 768px und 1280px, um sicherzustellen, dass responsive Designs das Minimum von 44×44 an allen Breakpoints einhalten, insbesondere in Hamburger-Menüs, Karussells und Aktionsspalten in Datentabellen.

Wie man es behebt

Nur-Icon-Schaltfläche mit unzureichender Größe — Falsch

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 0;
  cursor: pointer;
}
</style>

Nur-Icon-Schaltfläche mit unzureichender Größe — Richtig

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Benutzerdefiniertes Kontrollkästchen aus einem div — Falsch

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

Benutzerdefiniertes Kontrollkästchen aus einem div — Richtig

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Navigationslinks in einer Toolbar mit engem Abstand — Falsch

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Navigationslinks in einer Toolbar mit engem Abstand — Richtig

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Häufige Fehler

Die Annahme, dass die visuelle Begrenzungsbox dem Trefferbereich entspricht: Das Setzen von width: 44px; height: 44px auf das Symbolbild innerhalb einer Schaltfläche macht die Schaltfläche nicht 44×44 groß – nur das Hinzufügen dieser Dimensionen oder eines entsprechenden Paddings zum <button>-Element selbst erzeugt den korrekten Trefferbereich.
Verwendung von padding: 0, um Browser-Styles zurückzusetzen, ohne eine ausgleichende Mindestgröße: CSS-Resets entfernen häufig sämtliches Padding von Schaltflächen und Eingabefeldern. Wenden Sie nach einem Reset immer ausreichend Padding oder explizite Werte für min-width und min-height an, um den Aktivierungsbereich wiederherzustellen.
Verlassen auf line-height allein, um die Zielhöhe zu erhöhen: Eine Erhöhung der line-height beeinflusst den Textabstand, vergrößert aber nicht immer den anklickbaren Bereich eines Ankers oder einer Schaltfläche. Verwenden Sie stattdessen padding-top und padding-bottom.
Mehrere kleine Symbolschaltflächen ohne ausreichenden Abstand nebeneinander platzieren: Eine Reihe von 24×24 Social-Media-Share-Symbolen mit nur 2px Rand verfehlt sowohl die Größenanforderung als auch die Abstands-Ausnahme, da sich die 44px-Kreise, die auf jedes Symbol zentriert sind, mit ihren Nachbarn überlappen würden.
Falsche Anwendung der Inline-Text-Ausnahme auf Navigationslinks: Die Ausnahme gilt für Links innerhalb eines Satzes oder Absatzes von Fließtext. Navigationsmenüs, Toolbars und Linklisten sind kein Inline-Text und qualifizieren sich nicht für diese Ausnahme, selbst wenn sie display: inline verwenden.
Erstellen benutzerdefinierter Steuerelemente mit role='button' auf einem <span> und Vergessen, das Span zu dimensionieren: Screenreader kündigen das Span als Schaltfläche an, aber seine standardmäßige gerenderte Größe wird nur durch seinen Textinhalt bestimmt, der typischerweise weit unter 44×44 Pixel liegt. Fügen Sie immer display: inline-flex, min-width, min-height und padding hinzu.
Nicht-Testen auf realen Touch-Geräten bei tatsächlicher Viewport-Größe: Das Messen von Pixeln in Desktop-DevTools ist nicht ausreichend. Die CSS-Pixeldichte und das Touch-Ziel-Hit-Testing-Verhalten auf Betriebssystemebene können sich zwischen simulierten und physischen Geräteumgebungen unterscheiden.
Übersehen dynamisch gerenderter Steuerelemente: Tooltips, Tageszellen in Datepickern, Autocomplete-Vorschlags-Elemente und Schließen-Schaltflächen in Modals werden häufig von JavaScript-Bibliotheken mit hart codierten kleinen Größen eingefügt. Prüfen Sie die Ausgabe von Widgets von Drittanbietern und überschreiben Sie deren Styles bei Bedarf.
Die Abstands-Ausnahme beanspruchen, ohne sie zu messen: Die Abstands-Ausnahme ist geometrisch und präzise. Die visuelle Annahme, dass Steuerelemente weit genug auseinander liegen, ist nicht ausreichend – der 44px-Kreis-Test muss auf jedes unterdimensionierte Ziel angewendet werden, um zu bestätigen, dass keine Überlappung besteht.
Vergessen, nach Änderungen an responsiven Breakpoints zu überprüfen: Eine Schaltfläche, die auf dem Desktop 44×44 groß ist, kann in einem 375px-Mobil-Viewport aufgrund von Prozentbreiten oder Flexbox-Schrumpfung auf 30×30 kollabieren. Testen Sie Zielgrößen immer erneut bei jedem wichtigen Breakpoint.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung Nr. 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web- und mobile Barrierefreiheit auf Grundlage des WCAG 2.2-Standards fest. Die Verfügung gilt für einen definierten Kreis von Einrichtungen, die in der Türkei tätig sind, und legt rechtliche Verpflichtungen zur Konformität mit bestimmten WCAG-Stufen fest.

Zu den von der Verfügung erfassten Einrichtungstypen gehören: öffentliche Institutionen und Behörden auf zentraler und lokaler Verwaltungsebene; Banken und Finanzinstitute, die von der Bankenaufsichts- und Regulierungsbehörde (BDDK) reguliert werden; Krankenhäuser und Gesundheitsdienstleister, sowohl öffentlich als auch privat; Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten; E-Commerce-Plattformen über bestimmten Umsatz- oder Transaktionsschwellen; Reisebüros, die Online-Buchungsdienste betreiben; private Transportunternehmen, die digitale Ticket- oder Reservierungsdienste anbieten; sowie Privatschulen und Bildungseinrichtungen, die vom Bildungsministerium (MoNE) autorisiert sind.

WCAG 2.5.5 Target Size (Enhanced) ist ein Kriterium der Stufe AAA und gehört nicht zu den minimalen verbindlichen Anforderungen, die durch die Verfügung festgelegt werden, die sich primär auf die Konformität mit den Stufen A und AA konzentriert. Die Verfügung ermutigt jedoch ausdrücklich die erfassten Einrichtungen – insbesondere solche, die der Öffentlichkeit, Patienten im Gesundheitswesen und Studierenden dienen – nachdrücklich, dort, wo es machbar ist, eine Konformität der Stufe AAA anzustreben, da diese den Best-in-Class-Standard für Barrierefreiheit darstellt.

Für Organisationen in der Türkei hat die Umsetzung von WCAG 2.5.5 in mehreren Kontexten besonderen strategischen Wert. Regierungsportale für ältere Bürger, Systeme zur Terminvergabe im Gesundheitswesen für Patienten mit chronischen Erkrankungen und Bankanwendungen, auf die Menschen mit motorischen Beeinträchtigungen zugreifen, profitieren alle erheblich von Zielgrößen von 44×44 Pixeln. Die Türkei hat eine schnell alternde Bevölkerung, und das Türkische Statistische Institut (TÜİK) prognostiziert, dass Bürger im Alter von 65 Jahren und älter bis 2040 über 16 % der Bevölkerung ausmachen werden – eine Bevölkerungsgruppe, für die die Größe von Zeigerzielen ein kritischer Usability-Faktor ist.

Auch wenn AAA nicht gesetzlich vorgeschrieben ist, zeigen Organisationen, die freiwillig WCAG 2.5.5 erfüllen, ein Engagement, das das Risiko von Rechtsstreitigkeiten verringern, die Eignung für Ausschreibungen der öffentlichen Hand stärken kann, die Barrierefreiheitsdokumentation verlangen, und die Nutzerzufriedenheit in wettbewerbsintensiven Märkten wie E-Commerce und Fintech verbessern kann. Das SDK von Accsible bietet konfigurierbare Funktionen zur Verbesserung von Touch-Zielen, die Organisationen helfen können, dieses Kriterium zu erfüllen oder sich ihm anzunähern, und die Dokumentation solcher Bemühungen kann Teil eines Accessibility Conformance Report (ACR) oder einer VPAT-Einreichung sein, die von institutionellen Beschaffungsprozessen verlangt wird.