Oliver Vaupel

Shift Left – Barrierefreiheit fängt schon beim Design an

Summary

Nur, was vorher barrierefrei gedacht war, kann hinterher auch barrierefrei umgesetzt werden. Der Aufwand für eine barrierefreie Website verringert sich erheblich, wenn die Seite mit Barrierefreiheit im Sinn konzipiert und gestaltet wurde. Die Hauptlast für die barrierefreie Umsetzung in die Umsetzungsphase zu legen, führt zu unnötigen Schleifen und Verzögerungen.

Die neue Verantwortung von Designer*Innen

Ich bin der festen Überzeugung, dass digitale Barrierefreiheit gekommen ist, um zu bleiben. Eigentlich müsste sie ja schon längst da sein, wenn es nach dem Gesetz und den Richtlinien der EU ginge … aber das ist eine andere Geschichte.

Mit dem Barrierefreiheitsstärkungsgesetz wird das Thema jedenfalls endlich auch in der Wirtschaft ankommen. Briefings und Aufträge werden mit dieser Anforderung ausgeschrieben werden – Agenturen und Software-Unternehmen werden reagieren müssen.

Die Frage ist, sind sie vorbereitet? Und wo integrieren sie das Thema in den hektischen Arbeitsalltag und die knappen Ressourcen? Der erste Reflex sagt einem da natürlich: am Ende. Es passt irgendwie zur Qualitätssicherung und die findet auch leider immer noch oft am Ende eines Projektes statt – agile Projektentwicklung hin oder her.

Dabei wäre es gerade beim Thema Barrierefreiheit so wichtig, es von Anfang an in die Planung mit einzubeziehen. Vom ersten Entwurf bis hin zur Abnahme der Website sollte das Thema immer schon mit am Tisch sitzen. Am Besten durch einen Menschen mit Behinderung – was aber in vielen Firmen nicht geht, da viel zu wenig Menschen mit Behinderung mit Web-Design ihr Geld verdienen. Mindestens aber sollten in Barrierefreiheit geschulte Software-Architekt*Innen, UX-Designer*Innen und Web-Entwickler*Innen an diesen Projekten ihr Wissen mit einbringen.

Laut der Umfrage „State-of-the-Frontend“ von „The Software House“ 2022 geben immer noch über die Hälfte der Front-End-Entwickler*Innen an, nie, selten oder manchmal Barrierefreiheit zu beachten. Das klingt nicht danach, als wäre das Thema bekannt und bestens in den Workflow integriert. Es ist also mindestens riskant, anzunehmen, dass Design-Mockups und Prototypen wie selbstverständlich in der Entwicklung zu barrierefreien Websites werden. Designer*Innen müssen einfach mit- und vor allem voraus denken. Aber wie?

Shift left – Barrierefreiheit schon im Design mitdenken

Das „Shift left“-Prinzip – Deutsch „nach links verschieben“ – ist in der Softwareentwicklung schon seit längerem ein Thema. Dabei wird von einem eher linearen Produktionsprozess ausgegangen, mit Konzeption am Anfang und Umsetzung sowie Tests am Ende. Es sind sich alle einig, dass Änderungen in diesem Prozess um so teurer werden, je weiter am Ende – auf einer linearen Achse also rechts – eines Prozesses sie anfallen. Auf Barrierefreiheit und die dafür anfallenden Aufwände bezogen heisst das ebenso: je weiter hinten/rechts im Prozess sie angegangen werden, desto aufwändiger ist die Umsetzung. Je weiter vorne/links sie schon mit einbezogen werden, desto weniger Aufwände und Kosten fallen an.

Barrierefreiheit als Chance für Designer*Innen

Für dieses Mitdenken müssen Designer*Innen natürlich erst mal wissen, worauf sie achten müssen. Und es müssen Ängste abgebaut werden. Manche fürchten den Verlust von Gestaltungsfreiheit und die Beachtung von noch mehr Regeln. Aber es steckt darin auch eine Chance. Viel zu oft wird nämlich UX/UI-Design immer noch und vor allem ästhetisch beurteilt. Usability und Barrierefreiheit bieten da ganz neue Begründungen und Argumente für Designentscheidungen und geben diesen in den Augen von Stakeholdern eine ganz neue Relevanz. Die Frage, ob ein Button runde oder eckige Kanten hat, ist dann wirklich fast schon egal.

Designentscheidungen sichtbar machen

Bis jetzt ist es oft so, dass wir Designer*Innen davon ausgehen, dass unsere Mockups alle Informationen enthalten, die für die Web-Entwicklung nötig sind, daraus eine Website zu bauen. Tatsächlich aber vergessen wir oft, dass viele unserer Entscheidungen gar nicht sichtbar sind oder jedenfalls nicht so eindeutig, wie benötigt, um daraus klare Programmierungsentscheidungen abzuleiten. Viele – vor allem für die Barrierefreiheit wichtige – Details fehlen oder sind mitgedacht aber nicht dokumentiert und müssen dann nachgefragt oder nachgearbeitet werden.

Einige dieser „unsichtbaren“ bzw. oft fehlenden Entscheidungen habe ich hier anhand von vier Beispielen aufgeführt. Sie alle können durch besser ausgebildete Designer*Innen und Designer schon getroffen und dokumentiert werden und damit Projekte erheblich beschleunigen.

Farb-Kontrast

Der Klassiker unter den Barrierefreiheit-Regeln, die das Design betreffen: Das Erfolgskriterium 1.4.3 der Web Content Accessibility Guidelines (WCAG 2.1.) Die Vermeidung dieser Barriere liegt natürlich in der Verantwortung des/der Designer*in. Sie ist bereits gut dokumentiert und es gibt zahlreiche Tools und Farbpaletten dazu im Web:

Links zu Farb-Kontrast-Tools:

Die Überprüfung aller Texte, Schaltflächen und States auf den Mindestkontrastwert gehört zu jedem Designjob dazu und darf in keinem Designsystem fehlen.

Nicht so eindeutig dem Design zuzuordnen, aber ebenso wichtig, sind die folgenden Bereiche. Je früher hier gute Entscheidungen getroffen werden, desto barrierefreier die Umsetzung im Code.

Die Reihenfolge der Elemente

Ein(e) Web-Entwickler*In muss aus dem Desgin-Mockup eine HTML-Struktur bauen. Dazu werden die Elemente in eine bestimmte lineare Reihenfolge gebracht. Das ist recht einfach, wenn alle Elemente untereinander folgen. Aber was ist mit Seiten-Navigationen in Seitenleisten, Content-Slidern, komplexen Layouts mit sich überlagernden Inhaltsebenen. Über die Reihenfolge der Elemente auf einer Website nachzudenken, bedeutet auch, die eigene Arbeit zu hinterfragen und zu überprüfen. Das Ergebnis kann dann zum Beispiel über kleine Anmerkungen mit Nummern an den jeweiligen Elementen dokumentiert werden, die die gewünschte Reihenfolge festlegen. Anhand dieser Information kann mit der Entwicklung über Machbarkeit und Alternativen diskutiert werden. Wichtig für die Barrierefreiheit ist bei dieser Reihenfolge immer, dass die sichtbare Reihenfolge nicht oder nur begründet von der Reihenfolge im Code der Seite abweicht. Hier auf unnötige Komplexität zu verzichten heisst, Inhalte für viele Menschen sehr viel besser bedienbar zu machen.

Gruppieren der Inhalte in Bereiche

Semantisches HTML ist eine der Kernforderung der Barrierefreiheit. Und auch hier können Designer*Innen schon vorausdenken. Eine der wichtigsten Eigenschaften des semantischen HTML sind die Landmark-Regions. Landmark – Deutsch Landmarken – sind schon von weitem zu sehende Erkennungszeichen in der Landschaft, an denen sich Menschen orientieren können. Genauso etwas gibt es auch im Web. Sie heißen <header>, <main>, <footer>, <nav>, <aside> etc. Mit ihrer Hilfe können sich zum Beispiel blinde Menschen auf einer Seite orientieren. Assistenztechnologien wie Screen-Reader erkennen diese Landmarks und können sie direkt ansteuern. Dazu ist es aber wichtig, sich im Design schon Gedanken zu machen, welcher Inhalt in welchen Landmarks enthalten sein soll. Eine der Grundregeln der Barrierefreiheit lautet: Es gibt keine Inhalte ausserhalb einer dieser Regionen. Wir können unsere Ordnerstruktur in der Layer-Palette der Design-Datei nach diesen Landmarks strukturieren, so dass Entwickler*Innen sehen und einordnen können, welche Inhalt in welche HTML-Regions eingebaut werden sollen. Oder wir kennzeichnen im Design-Canvas diese Bereiche auf Extra-Layern, die wir über das Design legen. So vermeiden wir sogenanntes „Guess-Work“ bei Entwickler*Innen, die diese Entscheidungen dann neben ihren eigentlichen Aufgaben auch noch „eben“ treffen müssen. Quasi als Nebeneffekt macht man sich dadurch noch einmal Gedanken über die Informationsarchitektur des Designs und kann damit besser begründete Designentscheidungen treffen.

Die Benennung bestimmter Abschnitte der Website

Wir haben schon Landmarks kennengelernt, aber wir können noch weiter gehen. Das <main>-Element enthält den Hauptinhalt der jeweiligen Seite. Aber auch der gliedert sich in mehrere Unterbereiche, die wir mit der <section> oder <article> passend auszeichnen können. Was aber beinhalten die verschiedenen Unterbereiche? Wie können wir „Blogbeiträge“ von „Call-to-Actions“ unterscheiden? Uns sehenden Menschen fällt das nicht schwer, wir erkennen den unterschiedlichen Aufbau und die Muster oder die optischen Trenner zwischen den Abschnitten. Blinde Menschen und Menschen mit Sehbehinderung, die eine starke Vergößerung nutzen, erkennen diese Muster nicht. Für sie ist in der Übersicht der Seite der Hauptinhalt nichts weiter als eine Abfolge von Abschnitten (sections, articles, asides). Barrierefreies Design gibt diesen Abschnitten Namen – zum Beispiel, indem sie jedem Abschnitt eine Überschrift gibt. Selbst wenn – wie oft gewünscht – die Überschrift weggelassen werden soll, da sie redundant erscheint (man „sieht“ ja, dass es sich um die drei neuesten Blogartikel handelt), muss sie dennoch als Name des Abschnitts erhalten bleiben. Durch entsprechende Hinweise im Design – sei es in der Ordnerbezeichnung des Layer-Menüs oder als Anmerkung im Design – können sie bereits festgelegt und dokumentiert- und damit nicht vergessen werden bei der Umsetzung der Seite in HTML und CSS.

Der Zustand verschiedener interaktiver Elemente

Aus irgendeinem Grund wird der Status interaktiver Elemente im Design immer noch viel zu häufig nur beispielhaft anhand eines Hover-Effektes gestaltet. Die Simulation dieses – eigentlich langsam aussterbenden Effekts aus der Desktop-Zeit – wird dann auch noch besonders gerne von UI-Software wie Figma, Sketch und Adobe-XD als tolles Feature angeboten und gerne bei Präsentationen zur Demonstration der Interaktivität genutzt. Dabei sind die anderen States – Tastatur-Fokus und Aktiv-Status – viel wichtiger für die Barrierefreiheit. Der Tastatur-Fokus zeigt an, welches Element auf der Seite gerade mit der Tastatur angesteuert worden ist. Der Aktiv-Status gibt an, ob ein interaktives Element gerade aktiviert ist – eine wichtige Information, denn wenn ich zum Beispiel mit meiner Maus oder meinem Finger nicht so genau navigieren kann, weil meine Hand stark zittert, dann kann ich so erkennen, ob ich den richtigen Button getroffen habe. Falls nicht, kann ich im gedrückten/geklickten Zustand noch schnell die Hand/den Zeiger wegbewegen und mich korrigieren. Zu einem richtig guten Design-Entwurf gehört daher die Ausarbeitung aller Zustände von interaktiven Flächen – natürlich mit ausreichend Kontrast.

Diese Liste der Dinge, die Designer*Innen schon im Design-Entwurf bestimmen und weitergeben können, ist natürlich bei weitem nicht vollständig und kann beliebig erweitert werden. Je besser das UI-Design eines Projektes dokumentiert und ausgearbeitet ist, desto schneller und problemloser lässt es sich barrierefrei umsetzen.

Wie kann ich diese Dokumentation möglichst effizient erledigen?

Natürlich kann sich ein Design-Team sein eigenes Dokumentations-Framework basteln, das wird aber nur in größeren Unternehmen gehen. In letzter Zeit gibt es daher immer mehr Hilfsmittel in Form von zum Beispiel frei verfügbaren Templates für Figma oder sogar Plugins für alle großen UI-Software-Plattformen, die die Überprüfung und die Dokumentation der Barrierefreiheit im Design vereinfachen. Meine kleine Recherche hier zeigt einige dieser Helfer, aber du findest mit Sicherheit noch mehr.

Plugins:

Templates

„Axe for Designers“ habe ich bereits getestet. Es ist noch in der Beta und nicht perfekt, aber es bietet wertvolle Erleichterungen wie eine Textkontrast-Prüfung mit Alternativvorschlägen und sogar schon einen ersten automatisierten Tests. Allerdings muss dazu die Datei nach bestimmten Voraussetzungen gebaut sein, sonst sind die Ergebnisse falsch positiv und geben damit eine Barrierefreiheit vor, die nicht vorhanden ist. Darauf möchte ich in einem meiner nächsten Blogbeiträge eingehen, den ihr demnächst auf netz-rebellen.de findet.

Ich gebe auch Trainings und Workshops speziell für UX/UI-Designer*Innen zu Barrierefreiheit. Wir lernen und üben in kleinen Gruppen das Detailwissen für Design mit Barrierefreiheit im Sinn. Ich freue mich, euch dort zu sehen! Anmeldungen auch unter netz-rebellen.de