Die Größe des Touch-Ziels.
WCAG 2.2 verlangt für Touch-Ziele auf Stufe AA mindestens 24×24 CSS-Pixel, auf Stufe AAA mindestens 44×44 CSS-Pixel.
Die Touch-Zielgröße ist eine der konkretesten numerischen Regeln, die WCAG 2.2 gebracht hat, und eine der in mobilen Oberflächen am häufigsten gebrochenen Klauseln. Die Regel wirkt einfach — das Ziel vergrößern —, aber in der Praxis werden zwei Punkte verwechselt: welche Stufe welche Zahl verlangt, und welche Situationen unter die Ausnahmen fallen. Beides zu verwechseln führt zu unnötiger Arbeit oder zum Übersehen eines echten Verstoßes.
Zwei Kriterien, zwei Zahlen
Die Quelle der Verwirrung: Zwei getrennte Kriterien verlangen zwei getrennte Zahlen. 2.5.5 „Zielgröße (Erweitert)“ existiert seit WCAG 2.1 und verlangt 44×44 CSS-Pixel — aber auf Stufe AAA. 2.5.8 „Zielgröße (Minimum)“ kam mit WCAG 2.2, liegt auf AA und verlangt 24×24. Für AA genügt also 24; wer 44 anstrebt, sammelt auch AAA ein.
In der Praxis empfehlen die meisten Designleitfäden einen Wert um 44 Pixel, und der Grund ist nicht WCAG, sondern Ergonomie: Die Kontaktfläche einer erwachsenen Fingerkuppe auf dem Bildschirm hat ungefähr diese Größe. 24 ist also eine Basis für die Konformität; 44 ein Ziel, das mit echten Fingern gut funktioniert. Beides widerspricht sich nicht — das eine ist die gesetzliche Mindestschwelle, das andere ein Gebrauchstauglichkeitsziel.
Auf dieser Website wurde das Ziel auf ≥44 Pixel gesetzt, und die Prüfsuite misst jedes berührbare Element. Die Entscheidung war eine Gebrauchstauglichkeits-, keine Konformitätsentscheidung — erfüllt aber als Nebenprodukt auch das AAA-Kriterium 2.5.5. So ist es bei den meisten Barrierefreiheitsposten: Die richtig getroffene Entwurfsentscheidung bringt das Kriterium von selbst mit.
Die Ausnahmen: nicht jedes kleine Ziel ist ein Verstoß
Die Ausnahmeliste von 2.5.8 macht die Regel realistisch, und wer sie nicht kennt, arbeitet unnötig. In fünf Situationen ist ein kleines Ziel legitim und braucht keine Korrektur.
- Abstand (Spacing) — auch ein kleines Ziel ist konform, wenn ein 24×24-Kreis um es kein anderes Ziel berührt. Abstand zwischen Icons zu legen wirkt wie das Vergrößern der Icons.
- Im Fließtext (Inline) — ein Link innerhalb eines Textblocks ist ausgenommen. Einen Link im Satz auf 24 Pixel Höhe zu heben würde den Text zerstören.
- Gleichwertige Alternative — existiert auf derselben Seite ein anderes, ausreichend großes Ziel mit derselben Funktion, ist das kleine konform.
- Browser-Steuerung — bestimmt der Browser die Größe und hat der Autor sie nicht geändert, greift die Ausnahme.
- Wesentlich (Essential) — wenn die Kleinheit des Ziels für die Information selbst zwingend ist. Eine Ortsmarkierung auf der Karte oder eine Cursorposition im Texteditor.
Die Abstandsausnahme ist praktisch die nützlichste, weil sie am wenigsten ins Design eingreift. 20-Pixel-Icons einer Werkzeugleiste auf 24 zu vergrößern kann das Layout brechen; ein paar Pixel Abstand dazwischen meist nicht — und es erfüllt das Kriterium. Gemessen wird nicht das Icon selbst, sondern die berührbare Fläche darum.
Die Wesentlichkeitsausnahme wird am meisten missbraucht. „Unser Design verlangt es“ ist keine wesentliche Begründung; wesentlich sind die Fälle, in denen das Vergrößern die Information verfälschen würde. Nadeln auf einer Karte sind wirklich wesentlich, weil sie Orte repräsentieren; kleine Icons in einem Menü nicht.
Gemessen wird nicht die visuelle Größe
Der häufigste Messfehler ist, das Icon selbst zu messen. Das Kriterium betrifft die BERÜHRBARE Fläche — den Kasten, der das Klickereignis des Elements fängt. Ein 16-Pixel-Icon kann ein 44-Pixel-Ziel sein, wenn Innenabstand darum liegt; das Icon ist klein, aber das Ziel groß, und das Kriterium erfüllt.
Auch das Umgekehrte gilt und ist gefährlicher: Ein visuell groß wirkender Button ist in Wahrheit ein kleines Ziel, wenn das Klickereignis nur am Text darin hängt. Der Nutzer berührt den Rand des Buttons, nichts geschieht, und er versteht nicht warum. Dieser Fehler wird im Browser-Inspektor am Elementkasten leicht gefangen.
Auch die Einheit wird verwechselt: Die Regel spricht in CSS-Pixeln, nicht in Gerätepixeln. Auf einem hochdichten Bildschirm sind 24 CSS-Pixel physisch weit mehr Gerätepixel; zu messen ist die vom Browser gemeldete CSS-Größe. Pixel auf einem Bildschirmfoto zu zählen täuscht.
Gemessen wird nicht die Größe des Icons, sondern die Fläche, die der Finger berühren kann.
Wo es bricht
Auf echten Websites bricht dieses Kriterium an einigen typischen Stellen immer wieder, und alle hängen am mobilen Layout. Am Desktop ausreichend große Ziele fallen im auf Mobil verengten Raster unter die Schwelle — und niemand bemerkt es, weil am Desktop getestet wird.
- Schließen-Buttons (×) — die kleinen Kreuze in den Ecken von Ebenen und Benachrichtigungen. Das am häufigsten gebrochene Muster.
- Social-Media-Icon-Reihen — kleine, nebeneinander gereihte Icons im Footer; klein und zugleich dicht beieinander.
- Seitennummerierung — auf schmalen Bildschirmen verengte Seitenzahlen.
- Aktions-Icons in Tabellen — löschen, bearbeiten, herunterladen. Sie schrumpfen mit der Zeilenhöhe.
- Checkboxen und Radiobuttons — eigens gestaltete fallen oft auf 16–18 Pixel; das Etikett mit-klickbar zu machen löst es.
- Der Sprachumschalter — zweibuchstabige Kürzel (TR, EN, DE) erzeugen naturgemäß kleine Ziele.
Der letzte Punkt bekam auf dieser Website besondere Aufmerksamkeit, denn die Website ist dreisprachig und der Sprachumschalter steht auf jeder Seite. Ein zweibuchstabiges Etikett in ein 44-Pixel-Ziel zu verwandeln geschah mit Innenabstand, ohne visuelle Vergrößerung — und die Suite misst es bei jedem Lauf, auch im mobilen Umbruch.
Als allgemeine Regel: Alle berührbaren Elemente einmal im mobilen Umbruch zu durchmustern fängt fast alle Fehler dieses Kriteriums. Gemustert wird im Browser-Inspektor an den Elementkästen — nach der gemeldeten Größe, nicht nach Augenmaß.
Es gilt auch am Desktop
Obwohl das Kriterium „Touch-Ziel“ genannt wird, spricht der WCAG-Text nicht nur von Touchscreens; er umfasst alle Zeigereingaben. Es gilt also auch für Desktop-Oberflächen, und dort ist die Begründung eine andere: nicht Fingerdicke, sondern Zeigepräzision. Für Nutzer mit Tremor, eingeschränkter Armbewegung oder Kopf-/Blicksteuerung ist ein kleines Ziel mit der Maus so schwer zu treffen wie auf Touch.
Kleine Ziele sind deshalb auch im Desktop-Design ein Fehler, und dort brechen am häufigsten Tabellen und Werkzeugleisten. Mit gestauchter Zeilenhöhe schrumpfen die Bearbeiten- und Löschen-Icons am Zeilenende; ein sechzehn Pixel großes Papierkorb-Icon wirkt elegant, ist aber schwer zu treffen — und ein Fehlgriff kann eine unumkehrbare Operation auslösen.
Eine praktische Regel: Die Größe eines Ziels sollte umgekehrt proportional zur Folge des Verfehlens sein. Einen Link zu verfehlen ist harmlos, der Nutzer versucht es erneut. Einen Löschen-Button versehentlich zu treffen kostet Daten. Zerstörerische Operationen verdienen Ziele, die groß und von ihren Nachbarn entfernt sind — dort ist das Minimum des Kriteriums kein Boden, sondern ein Ausgangspunkt.
Wie gemessen wird
Gemessen wird im Browser-Inspektor, und Augenmaß genügt kategorisch nicht. Ist ein Element gewählt, zeigt der Inspektor das Box-Modell; der zu prüfende Wert ist die Gesamtbreite und -höhe einschließlich Innenabstand. Nicht die Eigengröße des Icons — die Größe des ereignisfangenden Kastens.
- Öffnen Sie den Browser-Inspektor, wählen Sie das berührbare Element und prüfen Sie die Gesamtgröße im Box-Modell. Unter 24×24: prüfen, ob eine Ausnahme greift.
- Messen Sie den mobilen Umbruch gesondert — am Desktop ausreichende Ziele können sich auf schmalen Bildschirmen verengen. Wer am Desktop testet, sieht den Fehler nicht.
- Messen Sie auch den Abstand — ist das Ziel klein: Fasst der Raum darum einen 24×24-Kreis, ohne ein Nachbarziel zu berühren?
- Automatisieren Sie — ein kurzes Skript, das berührbare Elemente durchmustert und ihre Größen berichtet, ersetzt die Handdurchsicht und läuft bei jedem Deployment.
Der letzte Punkt ist der Ansatz dieser Website. Die Suite misst die berührbaren Elemente im Desktop- und im mobilen Umbruch und leuchtet rot, wenn ein Ziel unter 44 Pixel fällt. Einmal von Hand gemessen besteht es und bricht mit der nächsten Komponente lautlos; der Wächter macht den Bruch im Moment des Deployments sichtbar.