Barrierefreiheit im UX-Prozess: Was in jede Phase gehört

Barrierefreiheit wird teuer, wenn sie am Ende kommt. Dann steckt das Problem nicht mehr in einem Screen, sondern in einer Komponente, die dein Team an zwanzig Stellen verbaut hat. In jeder Phase davor kostet sie meist nur eine Frage zur richtigen Zeit.

Dieser Guide zeigt dir diese Fragen für jede Phase im UX-Prozess, vom Briefing bis zum Betrieb nach dem Launch.

Die Kurzfassung: Barrierefreiheit im UX-Prozess heißt, sie in jeder Projektphase einzuplanen statt sie vor dem Launch zu prüfen. Konkret: den Ziel-Standard (meist WCAG 2.2 AA) schon im Auftrag festlegen, im Kickoff mit inklusiven Personas arbeiten, Tastatur und Struktur im Wireframe klären, barrierefreie Komponenten im Design-System bauen, die Anforderungen im Handoff mitgeben und nach dem Launch einen Meldeweg für Barrieren anbieten.

Für das Kickoff gibt es drei Übungen, mit denen dein Team Barrieren selbst erlebt, als Workshop-Guide zum Herunterladen.

Warum Barrierefreiheit am Ende so teuer wird

Stell dir vor, dein Team launcht nach acht Monaten ein neues Projekt-Tool. Kern des Produkts ist ein Kanban-Board: Karten per Drag & Drop von „Offen“ nach „Erledigt“ ziehen. In der Woche nach dem Launch kommt die erste Mail von einem Kunden. Eine Mitarbeiterin bedient den Computer nur per Tastatur und kann keine einzige Karte verschieben.

Seit WCAG 2.2 ist das ein eigener Prüfpunkt. Wer Elemente ziehen lässt, muss auch einen Weg ohne Ziehen anbieten, zum Beispiel ein Menü „Verschieben nach …“ (WCAG-Checkliste: 2.5.7 Ziehbewegungen). Im Wireframe wäre das ein zusätzliches Menü gewesen. Jetzt betrifft es die Board-Komponente, die Karten-Komponente, die Tastatursteuerung und die Tests. Ein Sprint ist weg.

Das Prinzip dahinter heißt Shift Left: Prüfungen auf dem Zeitstrahl eines Projekts nach links schieben, also nach vorne. Je früher eine Barriere auffällt, desto weniger hängt an ihr.

Ein Audit kurz vor dem Launch ist trotzdem sinnvoll. Es kann den Prozess aber nicht ersetzen. Das zeigt schon ein Blick auf die Tools: Als das britische Government Digital Service zehn automatische Prüftools auf eine Testseite mit 143 bekannten Barrieren losließ, fand das beste einzelne Tool rund 40 % davon (GOV.UK Accessibility Blog). Der Tool-Anbieter Deque kommt in eigenen Auswertungen auf 57 % der gefundenen Probleme (Deque). Selbst im besten Fall bleibt also fast die Hälfte für Menschen übrig. Und die findet man am günstigsten, bevor es Code gibt.

Phase 0: Briefing & Beauftragung

Ziel: die gemeinsame Wertebasis legen.

Bevor das Projekt startet, entscheidet ihr, was „fertig“ bedeutet. Steht Barrierefreiheit hier nicht drin, ist sie später ein Extra, das in jeder Priorisierung als Erstes fliegt.

Schreibt deshalb den Ziel-Standard direkt ins Briefing, in den Auftrag an eure Agentur oder in die Definition of Done. In Europa ist das in der Regel WCAG AA. Für neue Projekte lohnt es sich, gleich mit WCAG 2.2 zu planen. Die europäische Norm EN 301 549 ist im September 2026 in einer neuen Fassung erschienen, die auf WCAG 2.2 umstellt (AccessibleEU, EU-Kommission).

Ob ihr gesetzlich verpflichtet seid, hängt von euren Kund:innen ab. Mehr dazu in den FAQ unten.

Das macht ihr in dieser Phase:

• Ziel-Standard festlegen (z. B. WCAG 2.2 AA) und schriftlich in Briefing oder Auftrag aufnehmen

• klären, wer im Team für Barrierefreiheit zuständig ist, auch wenn es „nur“ eine Ansprechperson ist

• Barrierefreiheit in die Definition of Done schreiben, damit sie in jedem Ticket mitläuft

Diese Fragen solltet ihr klären:

• Welchen Standard wollen und müssen wir erfüllen? Gibt es Vorgaben von Kund:innen, etwa aus Ausschreibungen?

• Wer sind unsere Nutzer:innen, und wen schließen wir heute vielleicht schon aus?

• Wie stellen wir sicher, dass das Thema jede Phase durchläuft und nicht nur im Kickoff vorkommt?

Ergebnis: ein Satz im Auftrag, an dem sich das ganze Projekt messen lässt.

Phase 1: Kickoff & Fokus-Workshop

Ziel: den Scope inklusiv denken.

Im Kickoff legt ihr fest, was gebaut wird. Genau hier entstehen die teuersten Barrieren: Features, die von Anfang an nur für eine bestimmte Art der Bedienung gedacht sind.

Legt die geplante Feature-Liste deshalb neben inklusive Personas. Eine gute Grundlage ist das Persona-Spektrum aus dem Inclusive Design Toolkit von Microsoft. Es unterscheidet dauerhafte, vorübergehende und situative Einschränkungen. Ein Beispiel: Nur einen Arm nutzen zu können, kann dauerhaft sein, nach einem Bruch vorübergehend oder situativ, wenn jemand ein Baby auf dem Arm hält. Das macht greifbar, dass ihr nicht für eine kleine Randgruppe plant.

Mit diesem Blick fallen kritische Muster sofort auf. Komplexes Drag & Drop, Hover-Menüs, reine Wisch-Gesten, Zeitlimits. Für jedes plant ihr schon jetzt einen zweiten Weg im Scope ein. Wie das bei Bewegungseinschränkungen konkret aussieht, zeigt der Artikel zu motorischer Barrierefreiheit.

Das macht ihr in dieser Phase:

• Personas um Einschränkungen ergänzen (dauerhaft, vorübergehend, situativ)

• Feature-Liste gegen diese Personas prüfen und kritische Interaktionen markieren

• für jede markierte Interaktion eine Alternative in den Scope aufnehmen

• Barrieren im Team erlebbar machen, zum Beispiel mit den drei Übungen aus dem Workshop-Guide in der Download-Box

Diese Fragen solltet ihr klären:

• Welche Anforderungen haben Menschen mit motorischen, visuellen, auditiven oder kognitiven Einschränkungen an unser Produkt?

• Welche geplanten Features funktionieren nur mit Maus, nur mit gutem Sehen oder nur in Ruhe?

• Gibt es für jede Kernaufgabe mindestens zwei Wege?

Ergebnis: eine Feature-Liste, in der die Alternativen schon eingeplant sind und nicht später nachgeschoben werden.

Phase 2: UX-Analyse & Research

Ziel: Barrieren im Status quo aufdecken.

Gibt es schon ein Produkt, prüft ihr in dieser Phase systematisch, wo es heute hakt. Bei einer Neuentwicklung schaut ihr euch an, wie vergleichbare Produkte mit Tastatur und Screenreader funktionieren.

Startet mit einem automatischen Check, zum Beispiel mit der Browser-Erweiterung axe DevTools, WAVE oder Google Lighthouse. Das dauert Minuten und findet die offensichtlichen Fehler: fehlende Alt-Texte, zu wenig Kontrast, Buttons ohne Namen. Danach kommt der Teil, den kein Tool kann: die Kernabläufe einmal komplett per Tastatur bedienen, einmal mit Screenreader, einmal bei 200 % Zoom. Wie du jeden dieser Schnelltests in wenigen Minuten machst, steht in der WCAG-Checkliste.

Am meisten lernt ihr aber in Gesprächen mit Menschen, die auf Hilfsmittel angewiesen sind. Lasst sie eure Kernabläufe oder die eines Wettbewerbers bedienen und hört zu.

Das macht ihr in dieser Phase:

• automatischer Check der wichtigsten Seiten und Abläufe

• manueller Test der Kernabläufe mit Tastatur, Screenreader und Zoom

• Gespräche oder begleitete Tests mit betroffenen Nutzer:innen

• Befunde nach Schwere und Aufwand priorisieren, Quick Wins zuerst

Diese Fragen solltet ihr klären:

• Wo scheitert unser Produkt (oder der Markt) heute für Menschen mit Einschränkungen?

• Welche Hürden blockieren eine Kernaufgabe komplett, und welche sind nur lästig?

• Was lässt sich mit kleinem Aufwand sofort beheben?

Ergebnis: eine priorisierte Liste von Barrieren, die direkt in die Konzeption einfließt.

Phase 3: User Journey, UX-Konzept & Wireframes

Ziel: das barrierefreie Skelett bauen.

Jetzt entsteht die Struktur des Produkts: Wege, Seitenaufbau, Reihenfolgen. Barrieren in der Informationsarchitektur lassen sich hier mit dem Radiergummi beheben. Später brauchen sie einen Umbau.

Denkt die User Journeys nicht nur für die Maus. Wie kommt jemand per Tastatur durch den Checkout? Wo landet der Fokus, nachdem ein Dialog geschlossen wurde? Gibt es eine logische Überschriften-Struktur, an der sich ein Screenreader entlanghangeln kann?

Schreibt die Antworten direkt in die Wireframes: Tab-Reihenfolge als Nummern, Überschriften-Ebenen als H1, H2, H3, Sprungziele und Landmarks. Das kostet pro Screen ein paar Minuten und spart später lange Diskussionen.

Lange Formulare teilt ihr in Schritte, Fehlermeldungen plant ihr direkt mit ein. Wie das gut funktioniert, steht im Leitfaden barrierefreie Formulare erstellen.

Das macht ihr in dieser Phase:

• Journeys für Tastatur, Screenreader und Sprachsteuerung durchspielen

• Tab-Reihenfolge, Überschriften-Ebenen und Landmarks in den Wireframes annotieren (z. B. in Figma oder Miro)

• erste Tests mit klickbaren, farblosen Prototypen, solange Logikfehler noch billig sind

Diese Fragen solltet ihr klären:

• Lässt sich jeder Ablauf komplett per Tastatur erledigen, ohne Sackgasse?

• Ist die Struktur auch ohne visuelles Layout verständlich, zum Beispiel für Menschen mit kognitiven Einschränkungen?

• Sind kritische Abläufe wie Registrierung, Login und Checkout für alle machbar?

Ergebnis: annotierte Wireframes, die Fokus, Reihenfolge und Struktur festhalten.

Phase 4: UI-Design & Design-System

Ziel: Inklusion visuell systematisieren.

In dieser Phase bekommt das Produkt sein Gesicht. Die wichtigste Regel: Komponenten zuerst. Ein barrierefreier Button im Design-System ist an hundert Stellen barrierefrei. Ein barrierefreier Button in einem Screen ist es an einer.

Prüft Kontraste direkt beim Gestalten, zum Beispiel mit einem Figma-Plugin wie Stark, das auch Farbfehlsichtigkeiten simuliert. Gestaltet für jede interaktive Komponente einen klar sichtbaren Fokus-Zustand. Achtet auf ausreichend große Klickflächen (WCAG 2.2 verlangt mindestens 24 × 24 Pixel) und auf Text, der sich ohne Bruch vergrößern lässt.

Spannend wird es bei bestehenden Markenfarben. Erfüllt die CI-Farbe den Kontrast nicht, heißt das nicht, dass sie raus muss. Oft reicht eine dunklere Variante für Text und Buttons, während die Originalfarbe für Flächen bleibt. Wie du das systematisch angehst, zeigt der Guide zu barrierefreien Farben und Farbkontrasten.

Wer das in dieser Phase auslässt, baut sich Design Debt auf: Jedes neue Feature erbt die alten Barrieren.

Das macht ihr in dieser Phase:

• Kontrast und Farbfehlsichtigkeit direkt in Figma prüfen

• Fokus-, Fehler- und Deaktiviert-Zustände für jede Komponente gestalten

• Klickflächen und Abstände nach WCAG 2.2 festlegen

• Typografie skalierbar planen (siehe lesbare, barrierefreie Schriftarten)

Diese Fragen solltet ihr klären:

• Nutzen wir ein bestehendes Design-System, und ist es in seinen Grundlagen barrierefrei?

• Wo kollidiert unsere Marke mit Kontrast-Anforderungen, und welche Varianten brauchen wir?

• Funktionieren gleiche Funktionen überall gleich?

Ergebnis: eine Komponenten-Bibliothek, in der Barrierefreiheit eingebaut ist und nicht pro Screen geprüft werden muss.

Phase 5: Developer Handoff & Support

Ziel: die Brücke in den Code bauen.

Ein Großteil der Barrierefreiheit ist unsichtbar: Rollen, Namen, Fokus-Reihenfolge, Statusmeldungen für Screenreader. Steht davon nichts im Handoff, muss das Entwicklungsteam raten. Und raten führt zu Barrieren.

Hinterlegt die Anforderungen deshalb direkt an den Komponenten, zum Beispiel als Annotationen im Dev Mode von Figma: Wie heißt ein Icon-Button für den Screenreader? Wohin springt der Fokus nach dem Speichern? Was wird vorgelesen, wenn ein Fehler auftritt?

Die Prüfung wandert dann in die Entwicklung. Mit axe DevTools im Browser oder axe-core in der CI-Pipeline fallen typische Fehler bei jedem Build auf statt erst im nächsten Audit.

Baut euer Team mit KI-Tools wie Cursor oder Claude Code, gilt das doppelt. KI-generierter Code hat ohne konkrete Vorgaben besonders viele Barrieren, wie der Artikel Vibe Coding & Barrierefreiheit zeigt.

Das macht ihr in dieser Phase:

• Rollen, zugängliche Namen, Fokus-Reihenfolge und Statusmeldungen an den Komponenten annotieren

• automatische Prüfung (axe-core o. Ä.) in die Pipeline aufnehmen

• feste Ansprechperson aus dem Design für Umsetzungsfragen benennen

Diese Fragen solltet ihr klären:

• Hat das Entwicklungsteam alle Anforderungen, die man im Design nicht sieht?

• Wie klären wir Umsetzungsfragen schnell, bevor jemand eine Notlösung baut?

• Woran merken wir im Review, dass eine Komponente barrierefrei umgesetzt ist?

Ergebnis: ein Handoff, der auch die unsichtbare Logik beschreibt, und eine Pipeline, die Rückschritte meldet.

Phase 6: Live-Betrieb & Monitoring

Ziel: Nach dem Launch ist vor dem Sprint.

Mit dem Launch ist Barrierefreiheit nicht erledigt. Jedes neue Feature kann sie wieder kaputt machen. Deshalb gehört sie in den normalen Sprint-Rhythmus.

Testet das Live-Produkt regelmäßig mit echten Menschen und unterschiedlichen Fähigkeiten. Und gebt euren Nutzer:innen einen einfachen Weg, Barrieren zu melden. Für öffentliche Stellen ist ein solcher Feedback-Mechanismus nach BITV 2.0 Pflicht. Für Unternehmen verlangt das BFSG keinen, sondern vor allem Informationen dazu, wie das Angebot die Anforderungen erfüllt (Anlage 3 BFSG). Sinnvoll ist ein Meldeweg trotzdem: Er ist die günstigste Testquelle, die ihr bekommen könnt.

Das macht ihr in dieser Phase:

• regelmäßige manuelle Checks der Kernabläufe, zum Beispiel einmal pro Quartal

• Meldeweg für Barrieren anbieten (Formular oder feste Mailadresse) und Meldungen ins Backlog übernehmen

• Barrierefreiheit in die Definition of Done jedes neuen Features aufnehmen

Diese Fragen solltet ihr klären:

• Wie testen wir das Live-Produkt mit Menschen mit unterschiedlichen Fähigkeiten?

• Wie einfach können Nutzer:innen uns eine Barriere melden?

• Wie fließt dieses Feedback in unsere Sprints, und wer entscheidet über die Priorität?

Ergebnis: Barrierefreiheit als fester Teil des Produktbetriebs statt als einmaliges Projekt.

Überblick: Barrierefreiheit in jeder UX-Phase

Zielkonflikte: Wenn eine Lösung nicht für alle passt

In der Praxis gibt es selten die eine Lösung, die für alle funktioniert. Ein typisches Beispiel ist Kontrast. Für Menschen mit Sehbeeinträchtigung kann er nicht hoch genug sein. Die British Dyslexia Association rät dagegen zu dunklem Text auf hellem, aber nicht reinweißem Hintergrund, weil reines Weiß blenden kann (Dyslexia Style Guide).

Zwei Prinzipien helfen, solche Konflikte zu lösen:

• Mehrere Wege anbieten: Dieselbe Funktion ist auf unterschiedlichen Wegen erreichbar, etwa per Klick, per Tastatur und über die Suche.

• Personalisierung erlauben: Nutzer:innen passen das Interface an ihre Bedürfnisse an, zum Beispiel mit einem echten Dark Mode, Systemeinstellungen für Kontrast und Bewegung oder skalierbarer Schrift.

Wichtig: Personalisierung ist kein Ersatz für eine barrierefreie Grundeinstellung. Die Standardansicht muss den Ziel-Standard erfüllen. Die Optionen kommen obendrauf.

Accessibility-Overlays: Warum die Abkürzung nicht funktioniert

Irgendwann im Projekt kommt meist die Frage: Gibt es dafür nicht ein Plugin? Gemeint sind sogenannte Accessibility-Overlays, Skripte mit einem Widget, die eine Website angeblich mit einem Klick barrierefrei machen.

Die Antwort ist nein. Overlays setzen auf der fertigen Oberfläche an und lösen die Probleme im Code nicht. Im schlimmsten Fall stören sie Screenreader, die Menschen ohnehin nutzen. Über 1.000 Fachleute und Organisationen aus der Barrierefreiheits-Community raten im Overlay Fact Sheet davon ab.

Auch die US-Handelsbehörde FTC hat sich eingeschaltet. Im April 2025 musste der Overlay-Anbieter accessiBe 1 Million US-Dollar zahlen, weil er mit falschen oder unbelegten Versprechen geworben hatte, sein Tool mache jede Website WCAG-konform (FTC-Verfahren, Zusammenfassung bei Data Privacy + Cybersecurity Insider).

Barrierefreiheit entsteht im Prozess. Nicht in einem Widget.

Fazit & nächste Schritte

Barrierefreiheit ist kein Haken, den man vor dem Launch setzt. Sie ist eine Frage, die in jeder Phase einmal gestellt werden muss: im Auftrag, im Kickoff, im Wireframe, in der Komponente, im Handoff und im Betrieb. Wer das tut, braucht am Ende kein Feuerwehr-Audit, sondern nur noch eine Kontrolle. Und das Produkt wird nebenbei für alle einfacher zu bedienen.

So startest du:

1. Schreib den Ziel-Standard (z. B. WCAG 2.2 AA) in euer nächstes Briefing und in die Definition of Done.

2. Mach im nächsten Kickoff eine der drei Übungen aus dem Workshop-Guide.

3. Bediene euren wichtigsten Ablauf einmal komplett per Tastatur und notiere jede Stelle, an der du hängen bleibst.

4. Nimm Fokus-Zustände und Kontraste als Pflicht in euer Design-System auf.

Häufig gestellte Fragen zu Barrierefreiheit im UX-Prozess

Was bedeutet Barrierefreiheit im UX-Prozess?

Barrierefreiheit im UX-Prozess bedeutet, Anforderungen an Zugänglichkeit in jeder Projektphase einzuplanen, vom Briefing über Wireframes und Design-System bis zum Live-Betrieb. Statt das fertige Produkt am Ende zu prüfen, stellt das Team in jeder Phase die passenden Fragen. Das ist günstiger, weil Barrieren entfernt werden, bevor sie in Code und Komponenten stecken.

Warum sollte ich Barrierefreiheit von Anfang an einplanen?

Weil spät entdeckte Barrieren meist in wiederverwendeten Komponenten stecken und dann an vielen Stellen gleichzeitig behoben werden müssen. Dieses Prinzip heißt Shift Left: Prüfungen nach vorne verschieben. Eine fehlende Tastatur-Alternative ist im Wireframe ein zusätzliches Menü, nach dem Launch oft ein ganzer Sprint.

Gilt das BFSG für meine Software?

Das kommt auf deine Kund:innen an. Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025 für bestimmte Produkte und Dienstleistungen für Verbraucher:innen. Reine B2B-Geschäfte fallen laut Bundesfachstelle Barrierefreiheit nicht darunter, Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz sind als Dienstleister ausgenommen (Bundesfachstelle Barrierefreiheit, FAQ). Details und Gründe, warum WCAG auch im B2B relevant ist, findest du in der WCAG-Checkliste. Das ist keine Rechtsberatung.

Muss ich WCAG 2.1 oder WCAG 2.2 erfüllen?

Rechtlich verweisen BFSG und BITV auf die europäische Norm EN 301 549. Deren gültige Fassung basiert noch auf WCAG 2.1 AA. Die neue Fassung mit WCAG 2.2 ist seit September 2026 veröffentlicht und wird gültig, sobald die EU-Kommission sie im Amtsblatt bekannt gibt. Für neue Projekte lohnt es sich deshalb, direkt mit WCAG 2.2 AA zu planen. Wer 2.2 erfüllt, erfüllt auch 2.1.

Können automatische Tools einen manuellen Test ersetzen?

Nein. Tools wie axe DevTools, WAVE oder Lighthouse sind ein schneller erster Schritt, finden aber je nach Studie nur rund 40 bis 57 % der Probleme (GOV.UK, Deque). Ob eine Tab-Reihenfolge logisch ist oder ein Alt-Text im Kontext Sinn ergibt, kann nur ein Mensch beurteilen.

Wie gehen Produktteams mit Zielkonflikten in der Barrierefreiheit um?

Mit zwei Prinzipien: mehrere Wege zur selben Funktion anbieten und Personalisierung erlauben, etwa über Dark Mode, Kontrast-Einstellungen oder skalierbare Schrift. Die Standardansicht muss trotzdem den Ziel-Standard erfüllen. Optionen sind eine Ergänzung, kein Ersatz.

Helfen Accessibility-Overlays, schnell barrierefrei zu werden?

Nein. Overlays lösen die Probleme nicht im Code und können Screenreader sogar stören. Die US-Handelsbehörde FTC hat den Anbieter accessiBe 2025 wegen irreführender Werbeversprechen zu 1 Million US-Dollar verpflichtet. Barrierefreiheit muss im Produkt selbst umgesetzt werden.

Welche Tools helfen Design und Entwicklung im Sprint?

Im Design helfen Figma-Plugins wie Stark für Kontrast und Farbfehlsichtigkeit sowie Annotationen im Dev Mode für den Handoff. In der Entwicklung findet axe DevTools Fehler direkt im Browser, axe-core lässt sich in die CI-Pipeline einbinden. WAVE und Lighthouse eignen sich für einen schnellen Check der Live-Oberfläche, auch für Produktmanagement und QA.