Wie man A11y als UX Designer dokumentiert

Wie oft wurdest du als UX Designer*in schon von Entwicklern gefragt: „Und wie sieht der Link aus, wenn er fokussiert wird?“ Oder etwa, „Was soll hier stehen, wenn das Formular abgesendet wurde?“ In unserer täglichen Arbeit in der Agentur passiert das ständig. Die Entwickler müssen nachfragen und werden aus ihrem Flow gerissen, oder sie entscheiden selbst und es stellt sich heraus, dass es doch anders gedacht war.

Um die Zusammenarbeit zu verbessern und die Effektivität zu steigern, lohnt es sich, als UX-Designer schon früh im Prozess an gewissen Dinge, vor allem im Zusammenhang mit der Barrierefreiheit, zu denken und natürlich auch zu dokumentieren. Zusammen mit anderen Design-Spezifikationen sind sie ein fester Bestandteil des Designs.

Websites, die nicht mit Zugänglichkeit im Blick designed und gebaut wurden, sind ein bisschen wie Brillen, die mit Klebeband repariert werden. Die Frage ist: warum nachträglich reparieren, wenn man es gleich richtig machen kann?

Die Vorteile davon sind vielfältig: andere Teams bekommen ein Verständnis davon, wie wichtig Barrierefreiheit ist und man führt Diskussionen darüber – daraus entsteht ein Produkt oder ein Erlebnis, das für betroffene Personen gut durchdacht, bewusst und konsistent ist. Ein Designer ist in der guten Position, viele Dinge zu spezifizieren, die zu einem barrierefreien Erlebnis beitragen. Des Weiteren sorgt das Dokumentieren von Barrierefreiheit dafür, dass man mehr darüber lernt – ganz wie früher in der Schule, als das nochmalige Aufschreiben oder das Zusammenfassen eines Sachverhalts dafür gesorgt hat, sich Dinge besser merken zu können oder sie überhaupt erst zu verstehen.

Das Dokumentieren ist eine schöne geistige Anstrengung, die Designer zwingt, einen Schritt zurückzutreten und sich zu fragen:

• Wie wird jemand dies mit einer Maus bedienen?
• Einer Tastatur?
• Wie wird es bei Touch funktionieren?
• Was wird ein Screenreader dazu sagen? Und so weiter.

Mögliche Fallstricke und Probleme können so früher erkannt werden und man hat mögliche Einschränkungen der Nutzer immer im Hinterkopf. Dazu werden Designer, die Barrierefreiheit von Anfang an berücksichtigen, auch zu Fürsprechern in dem Bereich, in allen Aspekten ihrer Arbeit.

Wie dokumentiert man Barrierefreiheit?

Die eigentlich wichtigsten zwei Bereiche sind Tastatur-Verhalten und semantische Label, die von unterstützender Software (z. B. Screenreadern) verstanden werden können. Es ist sehr hilfreich, die zwei Bereiche voneinander zu trennen, dadurch denkt man in unterschiedlicheren Szenarien, auch über Screenreader hinaus.

Tastatur-Verhalten definieren

Alle interaktiven Elemente auf einer Website müssen per Tastatur erreich- und bedienbar sein, es handelt sich dabei um Buttons, Links, Menüs, Tooltips. Um eine grundlegende Tastatur-Funktionalität herauszufinden, ist dies ein guter Startpunkt:

• Beginne einfach: Füge alle interaktiven Elemente zu einer Tab-Schleife hinzu, die von links nach rechts und von oben nach unten auf der Seite verläuft. Es hilft, diese Tab-Schritte einmal zu sehen. Wenn das „Produkt“, also die Website oder Teile davon schon ein voreingebautes Tab-Verhalten hat, sollte man das auch berücksichtigen und den Rest genauso machen, da Konsistenz für eine barrierefreie Erfahrung essenziell ist.
• Lege die Reihenfolge der Elemente fest: Überprüfen, ob die Reihenfolge Sinn macht, hilft sie beim Erledigen von Aufgaben auf der Seite? Wenn sich die Reihenfolge falsch einfühlt, ist es am besten, das Layout der Elemente auf der Seite anzupassen (nicht die Tab-Reihenfolge später programmatisch zu ändern). Bei Elementen, die erst nach dem Anklicken eines Buttons erscheinen (z. B. ein Modal/Popup), dürfen die Elemente im Modal erst antab-bar sein, wenn das Modal geöffnet ist. Dokumentiere die Lesereihenfolge mit Pfeilen oder Nummern.
• Bewerte das Gesamterlebis: Fühlt sich die einfachste Lösung wie eine gute Erfahrung an? Gibt es zu viele Tabstopps, die jemanden daran hindern könnten, wichtige Aufgaben zu erledigen? Wenn Letzteres zutrifft, überlege, wie verbessert könnte, z. B. durch Hinzufügen von Pfeiltasten oder Tastenkombinationen. Mehr Info zu gängigen Tastaturmustern
• Dokumentiere das Tastaturverhalten für alle benutzerdefinierten Elemente: Bei benutzerdefinierten UI-Elementen, die nicht aus nativem HTML oder einer zugänglichen Komponente aus einem Designsystem bestehen, muss für jedes dieser Elemente ein individuelles Tastaturverhalten dokumentiert werden.

Beispiel für die Doku von Tabtasten-Verhalten:

Spezifikation semantischer Bezeichnungen für assistive Technologien

Nimm dir jedes Element vor und beschreibe Folgendes:

Typ/Art: Um welche Art von Element handelt es sich?

Die Art eines Elements soll Menschen, die assistive Technologien verwenden, genügend Informationen geben, um zu wissen, wie etwas funktioniert. Ein gutes Beispiel ist hier eine Gruppe von Radio-Buttons. Mit der richtigen Semantik erkennt der Screenreader, dass hier nur ein Element ausgewählt werden kann und gibt das auch so an den Benutzer zurück. Der Benutzer weiß dann auch, dass er die Pfeiltasten verwenden kann, um etwas auszuwählen.

Den richtigen Typ eines Elements zu benutzen, bedeutet so viel wie ein Versprechen an den Nutzer: man stellt dadurch sicher, dass sich etwas auf eine bestimmte bekannte Weise verhält.

Bei den WAI-ARIA Authoring Practices wird kann man nachschauen, was gängige Typen sind und wie sie sich verhalten.

(!) Als Designer solltest du dich auf den Output konzentrieren, nicht die Implementation. Beschreibe also nicht z. B. genaue Aria-labels, sondern beschreibe, was beim Nutzer als Information ankommen soll. Wie es dann später umgesetzt wird, sollten die Entwickler entscheiden.

Bezeichnung: Wie lautet der Name dieses Elements?

Beschriftungen sollen den Benutzern helfen, mehr Informationen darüber zu bekommen, was ein Element ist oder tut. Sie können komplex sein, sichtbar oder nur von assistiver Technologie verstanden werden. Die folgenden Tipps können in den meisten Fällen helfen:

Tipp 1: Versuche, eine sichtbare Beschriftung zu finden, bevor du eine unsichtbare Beschriftung hinzufügst. Ein Beispiel ist auf dem folgenden Bild zu sehen. Hier wird die sichtbare Überschrift „Recent Projects“ als Label-Angabe verwendet.

Tipp 2: Alle Bezeichnungen auf der Seite sollten eindeutig und spezifisch sein. Auf dem folgenden Bild sieht man mehrere Aktionsmenüs auf einer Seite, also verwenden wir den Projekttitel in der Beschriftung, damit jemand, der assistive Technologien verwendet, sie leichter unterscheiden kann.

Tipp 3: Wiederhole den Typ der Komponente nicht in der Beschriftung. Dies führt dazu, dass assistive Technologien den Typ zweimal vorlesen (z. B. „Suche-Button Button“).

Zustände und Werte: Hat dieses Ding noch andere Eigenschaften, die für das Verständnis wichtig sind?

Oft gibt es weitere Eigenschaften, die für das Verständnis eines Elements auf dem Bildschirm wichtig sind. Eine Umschalttaste zum Beispiel hat nicht nur einen Typ und eine Bezeichnung, sondern auch einen Zustand: ein oder aus. Diese Informationen sind entscheidend für das Verständnis und die Verwendung des Elements, daher sollten wir auch diese Informationen dokumentieren.

Checkboxen z. B. haben einen angekreuzten oder nicht angekreuzten Status, der an unterstützende Technologien weitergegeben werden muss.

Weitere Bereiche, die dokumentiert werden können bzw. sollten, werden im Folgenden erklärt.

Visuelles Design für Barrierefreiheit dokumentieren

Visuelles Design, insbesondere Farben, ist oft das Erste, was uns in den Sinn kommt, wenn wir an Design-Dokumentation denken. Hier gilt es ein paar Punkte zu beachten:

Stelle sicher, dass Farbe nicht die einzige visuelle Möglichkeit ist, Informationen zu vermitteln.
Identifiziere Informationen, die nur durch Farbe vermittelt werden, und biete sekundäre Möglichkeiten zur Vermittlung der Informationen, die sich nicht nur auf diese Farbe stützen. Dies ist in der Regel der Fall bei der Formularvalidierung (Fehler, Erfolg), jeder Art von Statusmeldung wie z. B. einem aktiven Menü-Punkt, aber auch bei Diagrammen, Grafiken usw.
Füge also z. B. eine Unterstreichnung hinzu oder einen Rahmen, oder mache den Schriftschnitt fett.

Stelle ausreichende Farbkontrastverhältnisse sicher.
Hier nochmal die Regeln für das Kontrastverhältnis für Text:
4.5:1 zwischen Text und Hintergrund für Text kleiner als 24px, oder 19px fett
3:1 zwischen Text und Hintergrund für Text größer als 24px oder 19px fett

Es beschränkt sich nicht nur auf Text, der Farbkontrast für Nicht-Text-Elemente (UI-Komponenten, grafische Objekte usw.) benötigt ein Kontrastverhältnis von 3:1 zu benachbarten Farben.

Exkurs: Was ist mit „Nicht-Text-Elementen“ gemeint?
– Visuelle Informationen zur Identifizierung von Komponenten der Benutzeroberfläche. Zum Beispiel die Umrandung eines Textfeldes, Kontrollkästchen, Optionsfelder (wenn du keine browsereigenen Elemente verwendest).
– Visuelle Informationen zur Identifizierung von Fokusindikatoren
– Grafische Objekte, die zum Verständnis des Inhalts erforderlich sind (z. B. wenn du einige Symbole hast, die Informationen ohne Text daneben vermitteln)

Diese Regel gilt auch für Fokusindikatoren: Der Fokusindikator muss zum Hintergrund ein Kontrastverhältnis von mindestens 3:1 aufweisen.

Stelle sicher, dass die Links in den Absätzen leicht erkennbar sind.
Am besten ist es, Links in Text-Absätzen zusätzlich zu unterstreichen. Wenn das nicht möglich ist, sollten sie mindestens ein Kontrastverhältnis von 3:1 zum angrenzenden Text haben und bei Hover visuelle Veränderungen haben.

Aufbau einer zugänglichen Farbpalette – von Anfang an

Eine Herangehensweise kann so aussehen:

• Mit den „Hauptfarben“ beginnen
• Farbvariationen (dunkler, heller) erstellen, die zusammen funktionieren können, Text auf Hintergrund. So aufbauen, dass alle „dunkleren“ mit „hellsten“ als Text verwendet werden können (und umgekehrt) mit 4,5 Kontrastverhältnis. Dafür sorgen, dass der dunkle Text auf jeder der „hellen“ Farben verwendet werden kann.
• Das Ganze mit einer Farbmatrix dokumentieren (Figma-Plugin oder Online-Tool)
• Zu guter Letzt: Im Styleguide Komponentenbeispiele dokumentieren, wie die Farben zusammen verwendet werden sollten.

Mit dem Online-Tool „Contrast Grid“ kann man sich leicht eine Farbmatrix erstellen. Es gibt auch ein Figma-Plugin.

Man kann beim Dokumentieren der Farben auch noch weiter gehen und aufzeigen, was kombiniert werden darf und was nicht, z. b. welche Farben miteinander kombiniert werden können.

Um das ganze Design-Team zu schulen, kann auch noch auf externe Links zum Thema hingewiesen werden. Hier ist z. B. „WCAG for designers“ ein gute Ressource.

Text-Resizing auf 200% und Tipps für die Typografie

Einige Richtlinien für die Größenanpassung von Text und die Gestaltung der Typografie:

• Vermeide Schaltflächen mit fester Höhe und Textfelder mit fester Höhe mit overflow:hidden
• Passe das Layout bei größerer Schriftgröße an, falls erforderlich (mehrere Spalten können zu einer einzigen werden, sekundärer Text auf der rechten Seite kann in die nächste Zeile wandern usw.)
• Behalte die Hierarchie auch bei größeren Schriftarten bei (H1-Titel sollten größer sein als H2 usw.)
• Teste die Schriftart auf Lesbarkeit mit „iIlL10oO“. Wie einfach ist es, die einzelnen Zeichen zu unterscheiden?
• Die meisten der WCAG-Kriterien für bewährte Praktiken im Bereich der Typografie sind technischer Natur. Zum Beispiel: Lass den Benutzer den Textabstand anpassen, um ihn besser lesen zu können: Zeilenhöhe, Buchstabenabstand, Wortabstand (WCAG 1.4.12 , technisch)

Hier noch einige praktische Tipps, die über die WCAG hinausgehen und die Lesbarkeit verbessern:

• Vermeide extrem helle und dünne Schriftarten. Eine sehr gut lesbare und kostenlose Schrift ist zum Beispiel die „Atkinson Hyperlegible„.
• Vermeide schwer lesbaren Blocksatz, zentrierten und rechtsbündigen Text (LtR-Sprache)
• Vermeide Unterstreichungen von Text, der kein Link ist.
• Vermeiden kursive Schrift und Großbuchstaben für lange Textpassagen
• Hindere niemanden daran, einfachen Text auszuwählen (z. B. für Übersetzungen).
• Für den Fließtext sollte die maximale Anzahl der Zeichen pro Zeile etwa 80 betragen, Leerzeichen eingeschlossen.

Last but not least, wenn es um Text geht: Verwende keine ausgefallenen Sonderzeichen, sie sind lästig und kein „echter“ Text.

Zugängliche Interaktionen und Interaktivität vermitteln

Links und Schaltflächen müssen konsistent und leicht zu verstehen sein:

• Versteht der Nutzer, was passiert, wenn er darauf klickt/tippt/interagiert?
• Vermeide „hier klicken“.
• Verwende direkte Aktionsverben (öffnen, abbrechen, schließen)

Links- und Button-Größe

WCAG 2.2 führte eine Mindestgröße für Zeigereingaben ein, die mindestens 24 x 24 CSS-Pixel betragen muss (AA, 44px für AAA). Wenn die 24 Pixel nicht erreichen werden können, gibt es eine Ausnahme für den Abstand. Wenn man einen Kreis mit einem Durchmesser von 24px um das Ziel zeichnet (beginnend in der Mitte des Elements), darf es nicht überschneiden. Genauere Infos, auch zu weiteren Ausnahmen, gibt es bei WCAG.

Dokumentiere die klickbaren Flächen und bei komplexen Komponenten, was genau angeklickt werden können soll.

Link- und Button Stati dokumentieren

Links: Standard, Hover (:hover), Fokus (:focus-visible), Aktiv (:active), Besucht (:visited)
Buttons: Standard, Hover (:hover), Fokus (:focus-visible), Aktiv / Gedrückt (:active), Deaktiviert, Laden/Fortschritt

Der Tastatur-Fokus wurde im Artikel schon erklärt, aber es ist auch eine gute Idee, einen Skip-Link, den jede Website haben sollte, zu dokumentieren. Mit Skip Links können Benutzer Blöcke mit sich wiederholenden Inhalten (Navigation) umgehen und direkt zum Hauptinhalt gelangen. Und manchmal auch zur Suche. Sie sind oft standardmäßig „unsichtbar“, werden aber sichtbar, wenn sie fokussiert werden (und von Screenreadern angezeigt). Sie können auch in der Kopfzeile immer sichtbar sein. Das bleibt den Designern überlassen.

Dokumentiert werden sollte, wo sich der Link befindet, wie er aussieht, wenn er fokussiert ist (wenn er standardmäßig unsichtbar ist) und wohin der Link die Benutzer schickt.

Formulare und Inputs

Der Fokusstatus ist für die Barrierefreiheit sehr wichtig. Er hilft Tastaturbenutzern zu wissen, wo sie sich beim Navigieren auf der Seite befinden. Für Formulareingaben auf Komponentenebene ist es wichtig, diese Eigenschaften zu dokumentieren: Standard, fokussiert, ausgefüllt, schreibgeschützt (oder deaktiviert).

Zusätzlich ist noch wichtig: Fehler, Erfolg und Information. Für diese sollte man nicht nur Farbe verwenden, sondern auch Text und Icons.

Auf der Seite, auf der das Formular später eingefügt wird, sollte dokumentiert werden:

Dazu dokumentiere ich auf Seitenebene:

• Was den Fehler auslöst (= Fehlerfall)
• Wie die genaue Meldung (Kopie) lauten soll. (all die Elemente, die den Leuten helfen, Fehler zu vermeiden oder zu beheben)

Mehr zum Designen von Formularen hier im Blog.

Komplexe Interaktionen zwischen Komponenten

Für komplexe Komponenten mit vielen Interaktionen kann man als Designer „Interaktionsabläufe“ erstellen. Diese dokumentieren, wie diese Komponenten funktionieren sollen, wenn es verschiedene Interaktionen gibt. Hier ein Beispiel zur Maus-Interaktion, es handelt sich um einem Filter mit Checkboxen:

Hier ist Schritt für Schritt dokumentiert, was passiert, wenn ein Benutzer:

• über eine Schaltfläche hovert
• ein Dropdown öffnet
• auf ein Element innerhalb hovert
• klickt

Zusätzlich zur Mausinteraktion ist auch Tastaturinteraktion dokumentiert. So komme man zu einem ähnlichen Ablauf, der auch die Tastaturnavigation in dieser Komponente zeigt:

• Öffnen der Komponente (Enter/Leertaste), Schließen der Komponente (Esc)
• Wie man durch die Elemente navigiert (Auf/Ab-Taste)
• Wie wird ein Link aktiviert (enter)

Wenn die Komponente Tastatur-Kürzel hätte, wäre es gut, auch diese zu dokumentieren. Eine kleine Hilfe zum Dokumentieren von Tastatur-Navigation:

• Mit der Tabulatortaste kann man zwischen den Abschnitten springen
• Pfeiltaste hilft bei der Navigation innerhalb der Komponente
• Leertaste/Enter aktiviert das Element

Informationsarchitektur für jedermann

Die vorangehenden Themen waren sehr Komponenten-basiert. Jedoch sollten auch auf Seitenebende ein paar Dinge dokumentiert werden.

Jede Seite sollte einen eindeutigen HTML-Titel haben, der den Inhalt der Seite beschreibt. Designer können Titel für jede Seite dokumentieren. SEO, UX-Autoren oder Inhaltsexperten können ebenfalls beim Schreiben der Seitentitel (und Beschreibungen) helfen. Ein guter Seitentitel ist für jede Seite einzigartig, kurz und beschreibend, hilft den Nutzern zu wissen, wo sie sich befinden und was sie auf dieser Seite erwarten können und ist KEIN SEO-Keyword-Stuffing.

Die Überschriften-Struktur auf jeder Seite ist ein weiteres wichtiges Thema. Mit ihnen kann man als Designer folgendermaßen umgehen:

• Man benennt die Stile in der Regel direkt mit der richtigen Überschriftsebene, damit andere Designer sie wiederverwenden können (und die Entwickler den Namen bei der Überprüfung sehen)
• Oder man machet für die Überschriftenebene Anmerkungen auf den Mockups

Überschriften sollten nicht erst in Figma o.ä. geplant werden, sondern als Struktur vorher einmal aufgezeichnet werden! Sie sollten auch zusammen mit anderen, z. B. dem Content-Team oder PO erstellt werden.

Genauso sollten auch vorher die Landmarks und Sektionen bestimmt werden. Es reicht hier jedoch, wenn der Designer die Hauptbereiche dokumentiert, die Details innerhalb können dann von Entwicklern in Absprache mit dem Design erstellt werden.

Benutzerfluss zur Dokumentation der Interaktion zwischen den Seiten

Benutzerabläufe (links) sind eine Art „Schritt-für-Schritt“-Kästen und Pfeildiagramme, die dokumentieren, wie jemand eine Aufgabe erledigt. Sie listen Seiten, Ansichten, Verzweigungen usw. auf. Sie werden in der Regel zu Beginn des Projekts erstellt, um die Planung dieser Seiten und Abläufe zu unterstützen.

Die Bildschirmabläufe (rechts) sind in etwa die gleichen. Aber anstelle der Boxen für die Seiten werden die echten Schnittstellen-Mockups eingefügt. Diese werden am Ende erstellt, nachdem Usability-Tests und Verfeinerungen durchgeführt wurden und man über Mockups verfügt. Beide helfen dem Entwicklungsteam zu verstehen, wie der Benutzer durch die gesamte Oberfläche navigieren wird.

Weitere Tipps und Informationen zum Dokumentieren finden sich im sehr ausführlichen Artikel von Stéphanie Walter, aus dem die meisten Infos und Grafiken in diesem Artikel stammen. Dort finden sich auch Links zu Tools und Figma-Plugins, die das Dokumentieren von Barrierefreiheit erleichtern.

Quellen und Links:
How to document accessibility as a UX designer,
A Designer’s Guide to Documenting Accessibility & User Interactions

Figma Plugin „Include – Accessibility Annotations“