Über den Autor:
Detlef Beyer
Size matters
Die Web Content Accessibility Guidelines (WCAG) enthalten mit dem Erfolgskriterium (SC) 1.4.4 öffnet sich in einem neuen Tab einen Abschnitt „Resize Text“ (Stufe AA). Eine kurze Erklärung zu SC 1.4.4 liest sich so: „Mit Ausnahme von Untertiteln und Bildern eines Textes, kann Text ohne Einsatz von Hilfsmitteln wie einer Bildschirmlupe um bis zu 200 Prozent vergrößert werden, ohne dass dabei Inhalt oder Funktionalität verloren geht“. Dazu muss man parallel das Erfolgskriterium 1.4.10 öffnet sich in einem neuen Tab (Stufe AA) betrachten. Hier dreht es sich darum, dass „Inhalte ohne Informations- oder Funktionsverlust dargestellt werden können, ohne dass dafür ein Scrollen in zwei Dimensionen erforderlich ist“ (auf Ausnahmen wie Karten und Diagramme gehe ich jetzt nicht ein).
Zoomen oder nur den Text vergrößern?
Bei der Gestaltung und späteren Umsetzung ist es wichtig daran zu denken, dass manche Menschen die Größe des Inhalts ändern müssen, um ihn problemlos lesen zu können. Spannend ist an dieser Stelle die Diskussion, ob sich SC 1.4.4 auf ein Zoom des kompletten Bildschirminhalts oder auf eine Vergrößerung vom Text allein bezieht. In den Erklärungen zu SC 1.4.4 öffnet sich in einem neuen Tab findet sich die Passage „Zum Beispiel können Wörter zu breit sein, um in den verfügbaren horizontalen Raum zu passen, was dazu führt, dass sie abgeschnitten werden; Layout-Einschränkungen können dazu führen, dass sich Text mit anderen Inhalten überschneidet, wenn er größer skaliert wird“. Bis ungefähr in das Jahr 2008/9 vergrößerten die Browser ausschließlich den Text – das würde ich als „Resize Text“ beschreiben. Wenn ich jetzt in einem beliebigen Browser die Darstellung vergrößere, betrifft das den gesamten Bildschirm – allerdings in einem gleichbleibend großen Fenster. Diese Funktion würde ich mit „Zoomen“ bezeichnen. Auf einem Smartphone benutzt man die „Pinch“ Geste (zwei Finger auseinander ziehen) für das Zoomen und nimmt die Einstellungen für eine Veränderung der Schriftgröße (bei iOS wäre das Einstellungen > Bedienungshilfen > Anzeige und Textgröße > Größerer Text).
Technische Umsetzung
Technisch ist die reine Veränderung der Schriftgröße in der Umsetzung meist anspruchsvoller als ein Vergrößern des gesamten Layouts. Bei Apple nennt sich die Technologie „Dynamic Type öffnet sich in einem neuen Tab„. Unter Android öffnet sich in einem neuen Tab wird es etwas komplizierter. Für iOS sagt die Statistik aus, dass immerhin 30% der iPhones auf eine größere Schriftgröße eingestellt wurden. Es ist folglich eine gute Idee, wenn eine Anwendung Dynamic Type unterstützt. Für eine Website müssen relative Einheiten wie em oder rem für responsives Design verwenden werden. Bei absoluten Einheiten könnte es passieren, dass nach dem Vergrößern eine horizontale und vertikale Scrollbar erscheint, was gegen WCAG SC 1.4.10 verstoßen würde.
Wat mutt, dat mutt
Jetzt ist die Einhaltung von SC 1.4.4 ab 2025 in der EU vorgeschrieben und da macht es dann einen erheblichen Unterschied, ob wir über Zoom oder Text Resize sprechen. Wenn ich weiter in den Erklärungen zu 1.4.4 als Beispiel lesen kann: „Ein sehbehinderter Benutzer vergrößert den Text auf einer Webseite in einem Browser von 1 em auf 1,2 ems.“, dann zielt das für mich auf ein Text-Resize und nicht auf ein Vergrößern der gesamten Seite. Das Barrierefreiheitsstärkungsgesetz (BFSG) schließt Apps auf Smartphone ausdrücklich ein. Hier spielt die getrennte Einstellung der Textgröße eine noch wichtigere Rolle. Auch die (auf der WCAG aufbauende) Europäische Norm EN 301 549 öffnet sich in einem neuen Tab kennt unter 11.1.4.4 das Thema „Resize text“. Hier findet sich „This success criterion is about the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200 % (zoom or otherwise) without loss of content or functionality„. Etwas quer schießt die Technik G142 öffnet sich in einem neuen Tab zum Erfolgskriterium 1.4.4. Hier findet sich die Erklärung, dass „Inhalte einheitlich skaliert werden können, indem eine Webtechnologie verwendet wird, die von Benutzeragenten unterstützt wird, die die Textgröße über ein Zoom-Tool ändern“. Also doch Zoom und nicht Text Resize? Meine Interpretation ist, unter Berücksichtigung der Anforderungen aus 14.10, dass beide Funktionalitäten für eine barrierefreie Umsetzung nach WCAG 2.1 erfüllt sein müssen.
Das hört sich alles nach Rosinenpicken an. Ist aber ein wunderbares Beispiel dafür, dass im Bereich der digitalen Barrierefreiheit viele Dinge nicht einfach mit ja oder nein zu beantworten sind. Da die Auslegung durchaus rechtliche Folgen haben kann, ist dies keine belanglose Diskussion. Das Thema zieht sich schon lange durch viele Diskussionen. Man kann hier sehr schön sehen, dass sich neue Technologien schneller entwickeln, als Normen und Gesetze geschrieben werden. Die WCAG 1.0 wurden 1999 veröffentlicht, 2014 wurden die WCAG 2.0 (Stufe A und AA) in der EN 301 549 referenziert (die letzte Version dieser Norm stammt aus 2021), 2018 ist WCAG 2.1 verabschiedet worden und die WCAG 2.2 erschienen Ende 2023 (mit 9 Änderungen gegenüber der 2.1). Klarer sind die Aussagen an dieser Stelle bis heute nicht.
Dein Kommentar
Mehr zu diesem Thema
Werkzeuge
Ganz einfach – Overlays für die Barrierefreiheit
So ganz einfach ist es dann doch nicht. Das Einbinden eines Overlays ist für die Barrierefreiheit einer Website in der Regel keine gute Idee.
Gesetze und Verordnungen
Übersicht Marktüberwachungsbehörden BFSG
Das Barrierefreiheitsstärkungsgesetz schreibt schwungvoll, dass eine Marktüberwachungsbehörde die Überwachung einer barrierefreien, digitalen Welt übernehmen wird. Nur: bisher gibt keine „Marktüberwachungsbehörde“ mit dieser Schwerpunktsetzung.
Werkzeuge
Braille – Lesen mit den Fingerspitzen!
Eine kleine Übersicht über Braille und wie die Ausgabe funktioniert. Dazu unser Braille Generator zum Ausprobieren.