Optimiert eure Designs mit Barrierefreiheits-Anmerkungen

Barrierefreiheit ist ein Gemeinschaftsprojekt. Damit eine Website für alle Nutzer:innen gut bedienbar ist, sollte Accessibility im gesamten Entwicklungsprozess berücksichtigt werden. Wie können Designer:innen am besten dazu beitragen?

Als Web-Entwickler und Requirements Engineer arbeite ich eng mit UI/UX-Designer:innen zusammen. Auf Basis der Anforderungen erarbeiten sie Entwürfe und Prototypen für die Benutzeroberfläche, die Entwickler:innen später implementieren. Diese Arbeit ist oft sehr visuell dominiert: Welche Farben kommen zum Einsatz? Wie berücksichtigen wir die Corporate Identity des Kunden optimal?

Zwei Mitarbeiterinnen eines Blumengeschäfts betrachten das Tablet vor ihnen auf dem Tisch. Foto: © Amina Filkins / pexels.com

Bei Barrierefreiheit denken Designer:innen daher oft an die Verwendung von Farbe und ausreichende Kontrastverhältnisse. Doch Designs können noch mehr: Barrierefreiheits-Anmerkungen vermitteln wichtige Informationen über die Struktur und Semantik der Website.

Das A11y Annotation Kit für Figma

Es gibt verschiedene Programme zum Erstellen von Prototypen. Meine Kolleg:innen arbeiten gerne mit Figma, einer kollaborativen Plattform für UI/UX Design.

Um dort Überlegungen zur Barrierefreiheit zu dokumentieren, können Designer:innen selbst passende Elemente definieren oder mit fertigen Bibliotheken wie dem A11y Annotation Kit arbeiten. Dieses bietet eine breite Palette an Tools, um semantische Informationen im Design auszuzeichnen. Sehen wir uns ein paar davon näher an.

Überschriften auszeichnen

Sehende Nutzer:innen scannen meist instinktiv eine Website nach Überschriften, um das zu finden, wonach sie suchen. Auch für blinde und sehbeeinträchtigte Nutzer:innen sind Überschriften von zentraler Bedeutung: Laut der letzten Umfrage von WebAIM sagen 9 von 10 Screenreader-Nutzer:innen, dass sinnvoll eingesetzte Überschriften-Ebenen für sie sehr oder eher nützlich seien.

Überschriften müssen semantisch korrekt ausgezeichnet werden, damit Screenreader sie als Überschrift ankündigen können. Bei Websites passiert das mit den HTML-Tags h1 bis h6. Nutzer:innen können dann etwa mit Tastaturkürzel von Überschrift zu Überschrift springen und sich somit schnell einen Überblick verschaffen.

Designer:innen sollten sich daher möglichst früh überlegen, wie der Inhalt einer Seite sinnvoll mit Überschriften strukturiert werden kann. Im finalen Design sollten alle Überschriften sowie ihre Ebene (1 bis 6) markiert sein. Hier ein Beispiel:

Ein Design mit zwei Überschriften, die als h2 und h3 markiert sind. Screenshot: © Alexander Lehner

Zwei Fragen werden euch dabei ständig begleiten: Was macht eine Überschrift zur Überschrift? Welche Überschriften-Hierarchie ist sinnvoll? Um euch das Leben etwas zu erleichtern, hier ein paar Tipps:

  • Überschriften strukturieren den Inhalt der Seite: Eine Überschrift leitet einen neuen Inhaltsabschnitt ein und sollte diesen beschreiben. Große Schrift, Fettdruck oder eine eigene Zeile machen einen Text nicht automatisch zur Überschrift!
  • Überspringt niemals eine Überschriften-Ebene! Die wichtigste Überschrift sollte als h1ausgezeichnet werden, danach folgt h2, h3, usw. Überschriften mit gleichem oder höherem Rang beginnen einen neuen Abschnitt. Überschriften mit niedrigerem Rang beginnen neue Unterabschnitte.
  • Styling und Semantik trennen: Die visuelle Darstellung einer Überschrift sollte niemals darüber entscheiden, welche Überschriften-Ebene verwendet wird! Mein Tipp: Definiert eigene Überschriften-Klassen wie heading-sm, heading-md, heading-lg, usw. Somit könnt ihr Überschriften unabhängig von ihrer Position in der Hierarchie stylen.
  • In manchen Fällen kann auch eine visuell verborgene Überschrift Sinn machen, um die Seitenstruktur zu verbessern.
  • Seid kreativ! Eine perfekte Überschriften-Struktur ist harte Arbeit. Macht einen Entwurf. Holt euch Feedback von außen. Verfeinert eure Designs schrittweise. Es ist noch kein Meister vom Himmel gefallen 😉

Alternativtext für Bilder

Fehlende oder schlechte Alternativtexte zählen zu den häufigsten Barrieren auf Websites. Laut der Studie WebAIM Million 2023 weisen über ein Drittel der Bilder auf beliebten Websites einen fehlenden, fragwürdigen oder sich wiederholenden Alternativtext auf.

Design-Prototypen sollten daher Alternativtexte für Bildinhalte definieren, so dass visuell vermittelte Informationen auch für Screenreader-Nutzer:innen zugänglich sind. Hierbei solltet ihr folgende Punkte beachten:

  • Funktionale Bilder: Wenn ein Button oder Link nur ein Bild oder Icon enthält, dann muss der Alternativtext den Zweck des Elements beschreiben.
  • Informative Bilder: Das sind Bilder, die relevante Informationen vermitteln. Hier sollte das Design einen konkreten Alternativtext vorgeben oder zumindest definieren, dass ein sinnvoller Alternativtext definiert werden muss.
  • Dekorative Bilder: Wenn Bilder nur die Seite aufhübschen sollen, dann müssen sie vor assistiven Technologien verborgen werden. Die Barrierefreiheits-Anmerkung kann dies mit alt="" darstellen.

Ein Design mit mehreren Bildern, für die Alternativtexte definiert sind. Screenshot: © Alexander Lehner

Weitere Infos sowie einige Negativbeispiele findet ihr in meinem Artikel „Ein Bild sagt mehr als tausend Worte – außer du bist blind!“.

Button oder Link?

Links sind unterstrichen. Buttons sind klickbare Boxen. Oder? 🤔

Visuell sind Links und Buttons oft nicht klar voneinander zu unterscheiden. In manchen Designs sehen Links wie klassische Buttons aus, und umgekehrt. Für sehende Nutzer:innen ist das meistens kein Problem: Hauptsache sie verstehen, dass es sich um interaktive Elemente handelt.

Für assistive Technologien ist die semantische Rolle der Elemente jedoch besonders wichtig. Je nachdem, ob der Screenreader ein Element als Link oder Button ankündigt, erwarten Nutzer:innen ein anderes Verhalten:

  • Links führen zu einer neuen Ressource, z.B. einer anderen Website oder einem anderen Abschnitt auf derselben Seite. Man verlässt den aktuellen Kontext.
  • Buttons lösen hingegen eine Aktion im selben Kontext aus, z.B. ein Popup-Menü oder das Abspielen eines Videos.

Das heißt: Das Aussehen ist zweitrangig. Die Funktion des Elements ist entscheidend. Ich empfehle euch den Artikel „Links vs. Buttons in Modern Web Applications“, der noch tiefer in das Thema eintaucht.

Also liebe Designer: Markiert Links und Buttons entsprechend ihrer Funktion. Und erklärt am besten in der Legende des Designs, dass Entwicklerinnen dafür native Elemente verwenden sollten. Also a für Links und button für Buttons. Eure Nutzer:innen werden es euch danken! 🤩

Erstellt am