Die universelle Gestaltung von grafischen Benutzer-Oberflächen ist eine gute Idee. Dabei versucht man, generelle Gestaltungs-Prinzipien so anzuwenden, dass die Inhalte für die größtmögliche Zahl an Personen bestmöglich zugänglich sind. Das mag tatsächlich oft funktionieren. Aber was ist mit den 10 Prozent der Menschen, für die das schlecht und die weiteren 10 Prozent, für die das gar nicht funktioniert? Bevor jemand fragt, das sind Erfahrungswerte, keine harten Statistiken.
Universelles Design keine universelle Lösung
Es gibt mehrere Kern-Probleme, die mit dem universellen Design aus meiner Sicht nicht gelöst werden können.
- Bestimmte Gestaltungs-Prinzipien können die Attraktivität der GUI verringern. Zum Beispiel brauchen Sehbehinderte in der Regel gute Kontraste und größere Schrift. Für Sehbehinderte sind auch klare Begrenzungsrahmen oder Farb-Unterschiede zwischen den einzelnen Arealen einer Website hilfreich, weil man bei großen Zoom oft nicht weiß, wo man sich befindet. Die WCAG-Vorgaben reichen für stark Sehbehinderte nicht aus und werden ohnehin selten flächendeckend erfüllt. Attraktivität sollte nicht der leitende Faktor sein, aber seien wir mal ehrlich: Weder Kunden noch Gestalterinnen lassen sich darauf immer ein.
- Der gesamte Bereich kognitive Behinderungen und Neuro-Diversität ist meines Erachtens mit universellen Gestaltungs-Prinzipien nicht abzudecken. Das liegt daran, dass die Bedarfe dieser Gruppen 1. sehr individuell sind und sich 2. auch gegenseitig widersprechen können. Person X reagiert auf die Farbe Rot, Person Y auf die Farbe Grün – es ist aber kaum zu vermeiden, diese oder andere Farben (oder andere Aspekte der Gestaltung wie Helligkeits-Unterschiede, Flackern in Videos etc.) vollständig zu vermeiden. Das wäre die Quadratur des Kreises.
- Ein aus meiner Sicht super-wichtiges Thema ist die Vereinfachung von GUIs und Texten. Es gibt zu wenige Inhalte in verständlicher Sprache und die meisten Website-GUIs sind für digitale Natives ausgelegt. Die automatisierte Vereinfachung von Texten ist bereits möglich (ja, ChatGPT darf hier nicht fehlen), die von GUIs wird vielleicht irgendwann möglich sein. Aber auch der Bedarf an Vereinfachung ist individuell.
- Die Regelwerke wie etwa die Anforderungen der EN 301549 mit mehr als 100 Anforderungen für native Apps und so weiter sind heute bereits nur für Expertinnen verständlich und reichen dennoch nicht aus. Wenn die Anforderungen noch Neuro-Diversität einschließen (was aus meiner Sicht wie oben gesagt nicht flächendeckend möglich ist), wären die Regelwerke kaum noch anwendbar. Sie wären zu komplex, es gäbe zuviel Spielraum für Interpretationen und dadurch unendlich viele Diskussionen.
Das sind nur offenkundige Beispiele. Es gibt noch viel mehr Herausforderungen, die von der WCAG und gängigen Best Practices nicht abgedeckt werden. Oder die mit vernünftigem Aufwand nicht umgesetzt werden können. Ich bevorzuge zum Beispiel hellen Text auf dunklem Grund und habe mit Ausnahmen immer die Farb-Invertierung auf allen Geräten aktiviert. Leider kommen mir aber Websites unter, die ihrerseits bereits hellen Text auf dunklem Grund haben, also von meiner Vor-Einstellung in dunklen Text auf hellen Grund invertiert werden. Benutzer-definierte Einstellungen, welche das komplette Layout überschreiben sind schon seit dem Internet Explorer 6 möglich, zerstören aber das Layout der GUI, dessen Wahrnehmung ab und zu für mich wichtig sein kann.
Ein anderes einfaches Beispiel ist der Tastatur-Fokus. In der WCAG 2.2 gibt es jetzt klare Hinweise darauf, wie kontrastreich und breit die Fokus-Outline sein soll. Meines Erachtens wäre es aber wesentlich sinnvoller, dass clientseitig zu machen: Der Mindest-Fokus der WCAG 2.2 wird für viele Leute nicht ausreichend sein. Es wäre außerdem auch client-seitig möglich, den Fokus ggf. zu verstärken, wenn er die Mindest-Kontrast-Vorgaben nicht erfüllt, zum Beispiel, wenn der Fokus auf Elementen mit einem Hintergrund-Bild liegt. Beim Edge-Browser zum Beispiel kann man einen verstärkten Tastatur-Fokus voreinstellen.
Gerade im visuellen Bereich fallen mir sehr viele Beispiele ein: Beispielsweise sind die Eingabefelder von Formularen oft schwer zu erkennen, was manchmal an der browser-eigenen Darstellung solcher UI-Elemente liegt. Oft kommt es vor, dass Verantwortliche die Defizite der Browser-Darstellung beheben müssen, was Extra-Aufwand macht.
Zur Übernahme von Benutzerinnen-Einstellungen gibt es übrigens einen eigenen Prüfschritt 11.7 in der EN 301549.
Ein anderes Thema sind dynamisch eingeblendete Meldungen. Wenn Sehbehinderte mit starkem Zoom arbeiten, bekommen sie solche Meldungen nicht mit, weil sie meistens nicht dort auftauchen, wo sich der Sehbehinderte befindet. Meines Wissens ist es nur clientseitig möglich, den Viewport des Sehbehinderten zu ermitteln. Dann wäre es natürlich sinnvoll, dass die Meldungen dort auftauchen, wo er sich gerade visuell aufhält. In die gleiche Kategorie fällt die Anforderung, dass Sehbehinderte oft zwei Bereiche gleichzeitig überblicken müssen, die nicht innerhalb ihres Zoomports sind. Das Wechseln zwischen zwei Bereichen, die weit voneinander entfernt sind, ist enorm anstrengend. Ein Beispiel dafür ist eine komplexe Infografik, bei der die Bedeutung der Symbole in einer Legende erklärt werden.
Es ist also schlichtweg unmöglich, eine GUI zu basteln, die für alle funktioniert. Genauso unmöglich ist es, eine GUI anbieter-seitig in so vielen Varianten oder Anpassungen bereitzustellen, dass auch jedes Individuum damit zurechtkommt. Wir reden hier zwar über Probleme, die sehr individuell sind, von denen aber andererseits zahlreiche Individuen betroffen sind.
Für einen solchen Zweck wurden ursprünglich zahlreiche CSS Media Queries wie „Prefer reduced motion“, „Prefer high contrast und so weiterentwickelt. Leider habe ich keine Statistiken gefunden, aber zumindest von den Anbietern, die ich bisher geprüft habe, wurde nur Prefer reduced motion überhaupt eingesetzt und das sehr selten und oft falsch. Prefer reduced Motion heißt, dass bestehende Animationen gestoppt oder ausgeblendet werden, wenn die Nutzerin dass in ihrem Betriebssystem eingestellt hat. Das funktioniert aber nicht automatisch – wie viele Einsetzende zu glauben scheinen – sondern erfordert, dass die Animationen entsprechend mit CSS-Eigenschaften identifiziert werden können. Deswegen funktionieren auch die sogenannten Accessibility Overlays nicht, die ja häufig solche Ausblenden-Funktionen integriert haben. Das Overlay erkennt nicht automatisch, was Animation bzw. Bewegung ist und die Betreiber kriegen die Info, dass sie nur eine Zeile Code implementieren müssen und alles wird auf magische Weise barrierefrei. Die Overlay-Verkäufer sind die Alchemisten des 21. Jahrhunderts.
Ich denke, dass sich durch entsprechende Algorithmen solche Dinge besser und vor allem an die Herausforderungen der Person angepasst herausfiltern lassen. Sie kennen diese PowerPoint-Effekte, die beim ersten Mal nett aussehen und beim fünften Mal tierisch nerven? Wären Sie nicht dankbar, wenn Sie Ihrem Computer sagen könnten, dass er das bitte rausfiltern soll? Auf der Code-Basis von Websites sollte es heute schon möglich sein, solche Effekte zu filtern, ohne dass damit die Funktionalität der Anwendung eingeschränkt wird.
Personalisierung ist längst Standard
Während sich Web-Verantwortliche graue Haare wachsen lassen, weil Apps auf iOS, Android und in der Web-Version nicht exakt gleich aussehen, hat sich die Individualisierung schon lange durchgesetzt. Smartphones und Tablets gibt es in den verschiedensten Größen, es gibt riesige Smart-TVs, eInk-Reader verschiedener Größe, es gibt große Smart Watches, es gibt die sprechenden Assistenten, die Websites vorlesen können. Es gibt zahllose Erweiterungen für Browser, welche das Design oder die Lesbarkeit verbessern können.
Auf der Seite der Nutzenden werden zumindest auf dem Smartphone die benutzerdefinierten Einstellungen benutzt. Fast alle Betriebssysteme kannten einen Farb-Invertierung, bevor der Dark Mode zum Trend wurde.
Meines Erachtens liegt tatsächlich in diesen Benutzerinnen-Einstellungen die Zukunft. Das Betriebssystem wird so konfiguriert, dass es zu den eigenen Bedarfen passt und die Designs der GUI werden überschrieben. Oder es wird Browser-Erweiterungen geben, welche die Designs der GUI’s teilweise überschreiben. Die Reader-Optionen der Browser sind ein Vorgeschmack darauf.
Wird Barrierefreiheit dadurch überflüssig?
Nein, im Gegenteil: Es wird eher wichtiger. Wenn man die gleiche Energie in die Anpassbarkeit der GUIs stecken würde, die aktuell in das vermeintlich gleiche Layout auf allen Plattformen gesteckt wird, wären wir schon zwei Schritte weiter.
Damit Sehbehinderte zum Beispiel Begrenzungsrahmen oder Hintergrund-Farben einsetzen können, müssen die Tools natürlich erkennen, dass es sich um abgegrenzte Bereiche handelt. Das passiert durch semantische HTML-Container-Elemente wie nav, Content, footer und so weiter.
Es kann passieren und passiert auch, dass bestimmte Elemente bei Anpassungen verschwinden, etwa beim OS-eigenen Dark Mode. UI-Elemente könnten ihre Funktion vollständig einstellen, wenn ihre animierten Effekte blockiert werden – vieles ist denkbar.
Auch wenn individuelle Einstellungen vieles kompensieren können, alles können sie nicht. Sie sind eher als Ergänzung eines universellen Designs gedacht.
Abgesehen davon wird es, solange solche Einstellungen nicht auf breiter Front bekannt sind auch immer Personen geben, die diese Einstellungen nicht kennen. Auch sind zumindest die gängigen Betriebssysteme sehr unterschiedlich aufgestellt. iOS hat klar die Nase vorn, während Google und Windows hinterher trotten und weit von diesem Grad an Anpassbarkeit entfernt sind.