Der Entwurf der WCAG 2.1 enthielt das neue Erfolgskriterium Target Size (Größe von Schaltflächen / Links), das nun doch nicht Eingang in die Candidate Recommendation der WCAG 2.1 gefunden hat. Warum wurde diese Anforderung nicht Teil des überarbeiteten Standards?

In der nun veröffentlichten WCAG 2.1 Candidate Recommendation ist die lange heiß umstrittene Anforderung Target Size nur noch auf Konformitätsebene AAA enthalten, das heißt, dass es bis auf Weiteres keine verpflichtende gesetzlichen Vorgabe mit Verweis auf die europäische Norm EN 301 549 geben wird, wie groß Tasten, Navigationselemente und Links sein sollten.

Es hatte sich als schwierig erwiesen, für die unterschiedlichen Arten von "Targets" – Elemente in Navigationsmenüs, Formularelemente, Links, usw. – eine bestimmte Größe verbindlich festzulegen, selbst nachdem Ausnahmen für Fließtextlinks und nur schwer stylebare native HTML-Elemente wie Checkboxen oder Radiobuttons hinzugenommen worden waren.

Target size für Mausbedienung und Touchbedienung

Ein grundsätzliches Problem war dabei auch, zwischen der Mausbedienung mit dem feineren Cursor (Mauszeiger) und der Touchbedienung (die größere Targets braucht, schon weil der Finger die Sicht verdeckt) zu unterscheiden, gerade weil Hybridgeräte beide Eingaben zulassen und es immer mehr Gerätetypen gibt, die sich nicht klar der Desktopwelt bzw. der Welt der "Mobilgeräte" zuordnen lassen.

Vor- und Nachteile großer Targets

Die grundsätzliche Vorteile großer Targets sind aus Sicht von Nutzern mit motorischen Einschränkungen, aber auch aus Sicht sehbehinderter Nutzer, klar. Andererseits haben größere Targets aber auch Nachteile, da mit ihnen nun deutlich weniger Inhalt auf den sichtbaren Ausschnitt des Bildschirms passt. Nutzer müssen also scrollen, oder Webdesigner müssen Inhalte auf mehr Ansichten aufteilen bzw. in Ausklappelementen oder Menüs 'verstecken'. Das wiederum hat auch Usability-Nachteile. Die "Gesamtschau" - das schnelle Überblicken der Inhalte - leidet darunter.

Die Suche nach soliden Vorgaben

Eine weitere Schwierigkeit war die Festlegung einer bestimmten Größe. Google empfiehlt in den Accessibility-Richtlinien für Material Design  48 x 48 CSS Pixel, Apple in den Human Interface Guidelines für iOS 44 x 44px. Die Nutzerstudien gingen aber von einem Bedarf von 100 x 100 CSS-Pixeln aus, eine für die meisten Angebote ohne wesentliche Änderungen kaum erfülllbare Anforderung.

Neue Barrieren durch große Targets?

Aber auch eine durchgehende Vorgabe von mindestens 44 x 44 CSS-Pixeln ist nicht einfach zu erfüllen, selbst wenn man Fließtextlinks ausnimmt. Bei dynamischen Ausklappnavigationen zum Beispiel verringert sich deutlich die Anzahl der Listenelemente von Untermenüs, die noch auf dem Bildschirm (bzw. im Viewport) sichtbar sind. Wenn man dorthin scrollen wollte, schließt sich das Menü wieder. Für sehbehinderte Nutzer, die mit Vergrößerungssoftware arbeiten, verschärft sich das Problem. Es entstehen also durch die größeren Targets auch neue Barrieren (oder man müsste die Anzahl der Menüpunkte reduzieren, was ein erheblicher Eingriff in die Struktur eines Angebots ist).

Keine Einigung – bislang

Der Kompromissvorschlag einer Größe von 44 x 22 CSS-Pixeln, die es erlauben würde, bei Ausklapplisten mit einer geringeren Höhe auszukommen, war dann in der Working Group stets umstritten. Für diesen Wert gab es keine Anhaltspunkte in Empfehlungen und keine empirische Deckung durch Studien mit Nutzern – es war einfach ein Kompromisswert, aus der Not geboren. Andere Ansätze versuchten bis zuletzt, die 44 Pixel auf einer Dimension des Targets vorzugeben und die andere Dimension etwa über die Höhe des Standardtextgröße zu definieren.

Letztlich fand sich dann unter dem gegebenen Zeitdruck keine Mehrheit für eine bestimtme Festlegung der Targetgröße auf Konformitätslevel AA. Das Thema wird sicherlich bei der Entwicklung der nächsten WCAG-Version (sei es WCAG 2.2 oder der große neue Wurf mit dem Arbeitstitel Silver) wieder aufgenommen werden.