Accessibility II - Ein Leitfaden für UX- / UI-Designer

Nachdem wir im ersten Teil unserer dreiteiligen Serie einen grundlegenden Einblick in Accessibility gegeben haben – mit besonderem Fokus auf dem Mehrwert für User:innen und für Kunden – geht's nun ans Eingemachte!

Im zweiten Beitrag wollen wir darauf eingehen, was eine a11y-konforme Website ausmacht und worauf alle Beteiligten bei der Entwicklung achten müssen. Der Praxis-Leitfaden richtet sich insbesondere an UX- und-UI-Designer:innen und Frontend-Entwickler:innen. Aber auch alle anderen Beteiligten, von Stakeholder bis Projektmanager, können hier ein paar Kniffe für den Projektalltag mitnehmen. Die Tipps und Tricks sind für uns eine wichtige Arbeitsgrundlage, um ein optimales Nutzungserlebnis, egal für wen und in welcher Situation, zu garantieren. Schreibt uns eine Email an info@sumcumo.com, falls ihr noch weitere Empfehlungen habt, wie ihr Accessibility in Projekten angeht.
Unser kleiner Leitfaden enthält alles rundum universelles Design, Nutzer-Zentrierung, Sprache und Medien, Kontraste, Bilder und Graphiken sowie Fonts und Typografie eingeht im Kontext von Accessibility.

Dieser Artikel ist ebenfalls bei produktbezogen als Gastbeitrag erschienen.

Universelles Design

Bei Accessibility und Design denken viele wahrscheinlich immer noch an Sonderlocken und eher unschöne Websites. Aber Design, Funktionalität und Accessibility gehen Hand in Hand. Wir etablieren in diesem Zusammenhang den Begriff "Universelles Design". Es soll in diesem Leitfaden explizit nicht darum gehen, Websites speziell für Menschen zu bauen, die auf Accessibility angewiesen sind, sondern um Websites, die universell, also für alle Menschen gleich funktionieren. Das ist aus Designerperspektive unglaublich spannend, weil es hier vor allem darum geht, kreative Lösungen für Probleme zu finden, die auf den ersten Blick vielleicht gar nicht auffallen. Unsere Empfehlungen bieten daher auch keine Garantie für eine perfekte barrierefreie Website, sondern sollen viel mehr Anregungen geben, worauf es zu achten gilt und über welche Dinge es sich lohnt nachzudenken.

Beginnen wir gleich mit einem der wichtigsten Leitsätze: Know your Users.

Für wen wird entwickelt?

Ein TL;DR des ersten Artikels:

• Es gibt nicht nur chronische, sondern auch temporäre Einschränkungen.
• Viele dieser Einschränkungen ergeben sich auch aus klassischen Alltagssituationen.
• Einige Einschränkungen sind auch nicht auf den ersten Blick erkennbar und werden deshalb bei UI und UX Design oft vergessen

Fragen, die ihr immer im Hinterkopf haben solltet: Kann ich die App nur mit einer Tastatur, einhändig oder über Sprache bedienen? Falls ja: Wie gut funktioniert das?

Auf welche Teile der App lohnt es sich, besonders zu achten?

Die Navigation

User:innen, die die Website über einen Screenreader nutzen, müssen sich zu Beginn meist einmal die komplette Navigation vorlesen lassen, um sich orientieren zu können. Meist müssen sie diesen Schritt für jede Unterseite wiederholen, bis sie zum Ziel gelangt sind. Sind hier eventuell Breadcrumbs sinnvoll?

User:innen, die die Website überwiegend mit der Tastatur bedienen, müssen sich meist durch die einzelnen Punkte "tabben". Wie gut funktioniert das? Sind die Hauptnavigationspunkte der Seite gleich ersichtlich, oder muss erst jedes Navigationselement geöffnet werden?

Ganz klassisch ist hier der Konflikt zwischen einer flachen und einen tiefen Seiten-Hierarchie. Eine Sitemap ist Pflicht, oft ist auch eine Suche sinnvoll.

Menschen mit kognitiven Einschränkungen haben oft Probleme mit komplexen Navigationsstrukturen, auch das gilt es zu bedenken.

Sprache und Medien

Jeder möchte gerne einzigartige Texte auf seiner Website haben. Genauso wie es Stockfotos gibt, gibt es auch austauschbare Textbausteine, die sich auf jeder Website wiederfinden. Hier gilt es zu bedenken: Nicht nur User:innen mit kognitiven Einschränkungen könnten gegebenenfalls Schwierigkeiten beim Verständnis komplexer Texte haben, auch Nicht-Muttersprachler:innen stehen vor Herausforderungen. Ganz zu schweigen von den User:innen, die einfach nur schnell zum Ziel kommen möchten und keinen Roman interpretieren wollen. Hier lohnen sich die folgenden Gedanken:

• Sind die gewählten Texte eindeutig, klar und nah an der Alltagssprache?
• Werden Fremdwörter erklärt oder gar ersetzt durch gebräuchliche Begriffe?
• Sind die Sätze vollständig, strukturiert und prägnant?
• Ist es hilfreich und sinnvoll eine Version in einfacher Sprache anzubieten oder ist die "erste Version" der Website schon ausreichend zugänglich?
• Kann der Happy-Path vielleicht auch intuitiv gestaltet werden? Tausche doch einfach mal alle Texte der Seite mit "Lorem Ipsum" aus. Ist immer noch ersichtlich, wie ich beispielsweise eine Versicherung abschließen kann? Besuche einmal die Website einer niederländischen Bank oder Versicherung und teste, wie gut du dich auf den ersten Blick zurecht findest. Dieses kleine Experiment gibt dir vielleicht ein Gefühl dafür, worauf es ankommt.
• Sind "Call to Action"-Elemente so benannt, dass sie die auslösende Aktion exakt beschreiben?

Sind Medien auf der Website eingebunden? Wenn es sich um Videos handelt, sind diese auch ohne Ton zu verstehen? Sind diese Medien notwendig, um die Seite benutzen zu können?

Formulare

Gestalten wir eine interaktive Website, werden wir nicht um Formularfelder herumkommen. Irgendwie müssen die Anwender:innen ja ihre Wünsche äußern können. Hier lohnen sich die folgenden Gedanken:

• Boundaries: Wo muss ich denn nun klicken, um eine Eingabe tätigen zu können? Wo hört mein Formularfeld auf, wo fängt es an?
• Placeholdertext: Sobald in das Feld navigiert und eine Eingabe gemacht wurde, verschwindet dieser. Was sollte da nun nochmal stehen?
• Placeholdertext: Sind vorformatierte Placeholder wirklich hilfreich? Versteht der Nutzer, was er wie eingeben soll?
• Validierungen: Wir können uns nicht alleine auf Farben verlassen. Für jemanden mit Rot-Grün-Schwäche ist ein Feld mit roter Border im Fehlerfall keine Hilfe. Wie können wir Nutzer:innen verständlich machen, dass etwas schief gelaufen ist? (Benötigen wir einen „Hint“ am Formularfeld?)
• Funktionalität nicht alleine durch Hovern: Wenn bei einem Feld erst durch Hovern erkennbar wird, dass es bearbeitet werden kann, führt die Bedienung per Tastatur oder Touch-Gerät zu Einschränkungen.

Komponenten und ihre Identität

Jetzt wird es etwas theoretisch! Eigentlich sollte jede Komponente eine Funktion haben. Ein Dropdown-Menü, in dem man suchen und gefundene Tags gleich löschen kann, ist ein gutes Beispiel für eine Komponente mit klarer Identität.

Farben

Farben erfüllen viele Funktionen: Sie können die Anwender:innen leiten, Emotionen hervorrufen oder auf neue Gedanken bringen. Die Bedeutung von Farben kann allerdings verloren gehen oder fehlinterpretiert werden, wenn sie nicht oder anders als beabsichtigt wahrgenommen werden.

• Verliert die App an Bedeutung, wenn ich die Farbe entferne?
• Geht die Orientierung durch fehlende Farben verloren?
• Für welchen Markt ist meine Anwendung gedacht? Haben die verwendeten Farben in anderen Ländern eine andere Symbolkraft?
• Überreize ich User:innen durch zu hohe Kontraste oder durch übersättigte Farben?

Apropos Kontrast

Farbkontraste ermöglichen es den User:innen, Elemente voneinander zu unterscheiden. Bilder mit höherem Kontrast erleichtern die Wahrnehmung. So kann ein Bild mit niedrigem Kontrast bei schwierigen Lichtverhältnissen, wie z. B. bei starkem Sonnenschein oder bei Nacht, für einige Benutzer:innen schwer zu erfassen sein.

Die Kontrastverhältnisse geben an, wie sich eine Farbe von einer anderen Farbe unterscheidet, üblicherweise z. B. durch 1:1 angegeben. Je größer der Unterschied im Verhältnis ist, desto größer ist auch der Unterschied in der Luminanz zwischen den Farben. Das Kontrastverhältnis zwischen einer Farbe und ihrem Hintergrund liegt laut dem World Wide Web Consortium (W3C) im Bereich von 1-21.

Das W3C empfiehlt die folgenden Kontrastverhältnisse für Fließtext und Bildtext:

• Großer Text (ab 14px fett/18px normal) und Grafiken 3:1 vor dem Hintergrund
• Kleiner Text (unter 14px fett/18px normal) 4.5:1 vor dem Hintergrund

Also: Entsprechen Vorder- und Hintergrundfarben aller Texte, Symbole, Icons und Steuerungselemente den Kontrastverhältnis-Richtlinien?

Um das zu prüfen, gibt es einige praktische Online-Tools:

• Material Design
• Colorable
• Contrast Grid
• Um Sketch oder Figma im Design-Prozess nicht zu verlassen, gibt es ein tolles Plugin.

Bilder, Grafiken & Icons

Bilder können ein Design und die Botschaft einer Anwendung unterstreichen, sie können aber auch komplexe Ideen veranschaulichen. Egal, welchen Zweck ein Bild erfüllt, jeder sollte über die Bedeutung des Bildes informiert werden, auch User:innen, die auf Screenreader angewiesen sind.

Idealerweise kommentieren Designer die Bilder in ihren Entwürfen so, dass die Bedeutung vermittelt wird. Diese Informationen können Entwickler:innen im Alt-Text des Bildes einbinden.

Hinweise für gute Alt-Texte:

• Nicht beschreiben, wie das Bild aussieht, sondern welche Informationen enthalten sind.
• Schmuck-Elemente wenn möglich über CSS einbinden, sodass Screenreader nicht über unwichtige Inhalte stolpern und User:innen verwirren.
• Prägnante und kurze Beschreibungen erstellen, höchstens zwei Sätze mit je unter 20 Wörtern.
• Falls die Informationen eines Bildes eine längere Beschreibung benötigen, sollten diese als Überschrift, Caption (innerhalb eines Picture Elements), Absatz o.ä. eingefügt werden. Der Alt-Tag enthält dann nur eine kurze Beschreibung.
• Diagramm-Beschreibungen sollten so ausführlich sein, dass sie alle Zahlen und Fakten wiedergeben.

Behaltet stets folgende Fragen im Blick:

• Enthält ein Bild Informationen, die verloren gehen würden, wenn es nicht sichtbar wäre?
• Wie könnte ich die Informationen auf nicht-visuelle Weise bereitstellen?
• Wenn ein Bild-Upload möglich ist, können Anwender:innen ebenfalls eine Alt-Text-Beschreibung angeben?

Fonts & Typografie

Nicht nur das Design sollte auf unterschiedliche Ausgabegeräte reagieren können, sondern auch Texte sollten flexibel genug sein, um es den Benutzer:innen zu ermöglichen, Schriftgröße, Zeilenhöhe oder den Buchstabenabstand so anzupassen, dass ein angenehmes Lesen möglich ist. Viele User:innen mit permanenten Einschränkungen verwenden benutzerdefiniertes CSS, das ihnen zu einem besseren Leseerlebnis verhilft.

Interessant ist, dass nicht die Schriftart ausschlaggebend für gute Lesbarkeit ist, sondern der Schriftstil: dekorative oder kursive Schriftschnitte sind für viele Menschen – insbesondere für Legastheniker – schwer zu verarbeiten. Das gleiche gilt für kleine Schriftgrößen und Texte in Versalien.

Insgesamt können ein größerer Text, kürzere Zeilenlängen, höhere Zeilenhöhen und ein größerer Buchstabenabstand allen Benutzer:innen zu einem besseren Leseerlebnis verhelfen.

Diese Texte sind ideal für ein breites lesendes Publikum:

• links- bzw. rechtsausgerichtet
• mit minimaler Schriftgröße von 16p
• mit einem Zeilenabstand des mindestens 1,5-Fachen der Schriftgröße
• mit einen Absatzabstand des mindestens 1,5-Fachen des Zeilenabstands
• mit einer Zeilenlänge von maximal 80 Zeichen

Schriftschnitte unter 400 sollten vermieden werden: Sie können für große Überschriften funktionieren, sind aber bei kleineren Größen zu schwer zu lesen.

Die Richtlinie für barrierefreie Webinhalte, WCAG 2.0 empfiehlt keine feste Schriftgröße, aber 16px ist eine sinnvolle Orientierung für den Browserstandard. Sie verlangt aber auch, dass sich Layouts ab 320px flüssig an alle Bildschirmgrößen anpassen und auch dann voll lesbar bleiben, wenn die Ansicht auf 200 % gezoomt ist - das stellt sicher, dass Texte nicht versehentlich über das Fenster hinauslaufen.

Es gilt zu beachten:

• Ist das Design flexibel genug, dass die Schrift vom Benutzer auf ein angenehmes und lesbares Schriftbild angepasst werden kann?
• Ist der Schriftstil gut lesbar?

Animationen

Animationen sind toll, oder? Sie können den Fokus unserer User:innen lenken, ihnen Orientierung geben. Bewegte Elemente erwecken Seiten und Marken zum Leben, können sie besonders machen. Aber diese Medaille hat zwei Seiten, denn: Animationen können auch ablenken, verwirren oder sogar Auslöser von gesundheitlichen Problemen sein.

Schnell flackernde (mehr als dreimaliges Blinken pro Sekunde) oder expressive Animationen und Muster können epileptische Anfälle verursachen, aber auch Kopfschmerzen und Schwindel hervorrufen.

Nutzer:innen mit vestibulären Störungen (das vestibuläre System kontrolliert das Gleichgewicht und den Bewegungssinn) können auch bei anderen Phänomenen wie Parallax- oder Bewegungseffekten Schwindelgefühle entwickeln. Fortlaufende Animationen können für alle Benutzer:innen ablenkend sein, insbesondere bei denjenigen, die unter Konzentrationsschwierigkeiten leiden.

Wir wollen Animationen nicht verbannen, aber es ist wichtig zu wissen, welchen Zweck sie erfüllen und wie man „sichere“ Animationen entwirft. Im Allgemeinen solltet ihr versuchen, Animationen zu entwerfen, die kleine Entfernungen abdecken, der Richtung und Geschwindigkeit anderer sich bewegender Objekte (einschließlich der Bildlaufleiste) entsprechen und relativ klein im Verhältnis zur Bildschirmgröße sind.

User:innen können an ihren Geräten den „reduced motion“ Modus aktivieren, bewegte Elemente können hiermit alternativ ausgespielt werden. Und das Beste: Entwickler:innen können diesen Modus abfangen und über ein media query andere Styles ausspielen. Hier sollte man sich folgende Fragen stellen:

• Gibt es Effekte, die Anfälle oder Schwindel verursachen könnten?
• Gibt es Animationen, die durch ständige Bewegung oder Auto-Updates ablenken könnten?
• Kann man Optionen zum Anhalten, Unterbrechen, Ausblenden oder von Animationen/Effekten bereitstellen?
• Kann ich Effekte schon über CSS gezielt steuern?

Testing

Hier kann man sich mit kleinen Kniffen behelfen und die Nutzung unter Accessibility-Gesichtspunkten schnell selber testen, indem man sich in typische Situationen bringt, in denen man eingeschränkt ist. Und keine Angst, ihr müsst euch dafür nicht den Arm brechen. Es reicht wenn ihr die App (z.B. als Prototyp) im Bus oder in Bahn versucht zu benutzen, während ihr euch mit einer Hand festhaltet. Ist die Nutzung der App grundsätzlich noch möglich? Sind alle Funktionen gut erreichbar und anwendbar mit einer Hand? Schaffe ich das gewünschte Nutzungsziel zu erreichen? Falls ihr eine der Frage nach dem kleinen Accessibility-Test verneinen müsst, solltet ihr an den entsprechenden Stellen, das Konzept anpassen und den Test danach einfach noch mal machen. So ein kleiner Test während der Entwicklung, garantiert ein optimales Nutzungserlebnis und spart hinterher teure Anpassungen.

Wenn ihr während des Entwicklungsprozesses über all diese Fragen einmal nachgedacht habt, ist ein wichtiger Schritt in Richtung universelles Design bereits getan. Es liegt nun noch an den Entwickler:innen, die Frontends entsprechend umzusetzen. Worauf hier besonders geachtet werden sollte, erzählen wir euch dann im nächsten und letzten Teil unserer Artikel-Reihe.