Behind the scenes: Ein Barrierefreiheits-Audit

Die Anfrage

Was dann passiert, erzählen wir euch gerne:

Verstehen, was wirklich gefragt ist

Schritt 1: Erst mal: die richtigen Seiten

Bevor wir irgendetwas testen, präzisieren wir gemeinsam die Zielsetzung. Was soll das Audit leisten? Gibt es bereits bekannte Probleme oder konkrete Anforderungen? Wir wählen exemplarische Seiten aus, die mit dem meisten Traffic, den komplexesten Interaktionen, den kritischsten Flows. Diese Auswahl ist der erste echte Schritt, und er entscheidet, wie aussagekräftig das Ergebnis wird.

Irgendwas mit Scanner drüberlaufen lassen….

Der naheliegendste Gedanke: Es gibt Tools für sowas. Einmal drüberlaufen lassen, Bericht runterladen, fertig. Sorry, to say: But No Automatisierte Tests finden ungefähr 30–40 % aller Barrieren. Die fehlenden Alt-Texte, ja. Den schlechten Kontrast, meistens. Aber nicht, wie sich die Seite anfühlt, wenn du sie mit einem Screenreader navigierst. Nicht, ob der Warenkorb-Button für jemanden ohne Maus erreichbar ist. Und schon gar nicht, ob das Interface zusammenbricht, wenn jemand die Schrift auf 200 % vergrößert.

Mehr dazu haben wir übrigens hier schon ausführlich aufgeschrieben

Wie ein Audit bei uns abläuft

Schritt 2: Automatisierter Scan

Der Tool-Run kommt trotzdem, aber als Ausgangspunkt, nicht als Ergebnis. Fehlende Labels, Kontrastprobleme, kaputte ARIA-Attribute – schnell, systematisch, reproduzierbar.

Schritt 3: Manuelle Tests

Hier passiert das Eigentliche. Wir gehen jede Seite durch. Was fällt sofort auf, noch bevor man irgendetwas analysiert?

Dann: Screenreader an. Die Seite wird zum Hörerlebnis und plötzlich merkt man, wie viel Information implizit über visuelle Gestaltung transportiert wird, ohne je in Text übersetzt worden zu sein. Alles, was dabei auffällt, wird notiert.

Danach: Schrift auf 200 % hochschrauben. Bricht das Layout? Überlappen sich Elemente? Verschwindet Inhalt hinter der Navigation?

Dabei fallen auch subtilere Probleme auf: ARIA-Labels, die zwar vorhanden sind, aber nicht mit der Seitensprache wechseln, sodass ein deutschsprachiger Screenreader plötzlich englische Bezeichnungen vorliest. Oder ein Tastaturfokus, der per CSS unsichtbar gemacht wurde, weil er optisch störte. Für Nutzer:innen, die auf Tastaturnavigation angewiesen sind, bedeutet das: Sie wissen nicht mehr, wo sie sich auf der Seite befinden. Und Formularfelder, die zwar ein sichtbares Label haben, das aber nicht programmatisch mit dem Eingabefeld verknüpft ist: der Screenreader liest, dass eine Checkbox existiert, aber nicht, was sie bedeutet.

Schritt 4 (optional): User Tests mit echten Betroffenen

Menschen, die tatsächlich auf assistive Technologien angewiesen sind. Meist fallen hier nochmal Dinge auf, die kein Tool und kein manueller Check ersetzen kann.

Ein Beispiel dafür, wie unterschiedlich Bedürfnisse sein können: Menschen, die erst im Laufe ihres Lebens erblindet sind, profitieren davon, wenn Alt-Texte auch visuelle Eigenschaften beschreiben, etwa die Farben eines Bildes. Diese Information ist für sie interessant, weil sie ein visuelles Gedächtnis mitbringen. Menschen, die von Geburt an blind sind, können damit hingegen wenig anfangen, für sie ist diese Beschreibung bestenfalls irrelevant, im schlimmsten Fall lenkt sie ab. Solche Nuancen lassen sich weder automatisiert noch durch manuelle Tests allein herausarbeiten. Sie zeigen sich erst im Gespräch mit echten Betroffenen.

Schritt 5: Der Bericht

Kein 80-seitiges PDF. Stattdessen eine strukturierte Liste für jedes Problem mit genau diesen Informationen:

• Welche WCAG-Regel betroffen ist
• Ob es manuell, automatisiert oder durch User Testing gefunden wurde
• Bei welchem konkreten Element das Problem liegt
• Eine klare Handlungsempfehlung mit Links zu weiterführenden Ressourcen

Das Format ist so gebaut, dass die zuständigen Entwickler:innen es direkt in ihren Workflow übernehmen können. Kein Interpretieren, kein Nachfragen.

Und was passiert nach dem Audit?

Schritt 6: Ergebnisse gemeinsam besprechen

Wir gehen die Findings durch, klären Fragen und helfen beim Priorisieren. Was muss vor dem nächsten Release? Was kann in Ruhe eingeplant werden?

Der Bericht ist nicht das Ende. Er ist der Startpunkt.

Je nachdem, was ihr braucht, begleiten wir euch weiter. Einige arbeiten mit uns im Anschluss an einem zugänglichen Design-System weiter. Andere wollen ein Folge-Audit in sechs Monaten. Und manche reicht der klare Bericht und das Entwicklungsteam macht den Rest. Alle drei Wege funktionieren. Wir passen uns an, was wirklich gebraucht wird.

Neugierig, was wir bei euch finden würden?

Wir finden und erklären es und sagen euch, was ihr damit machen sollt. 
Meld dich einfach kurz. Der Rest läuft bei uns!

Jetzt melden