Acces­si­bil­i­ty by Design Engineering

Web Accessibility wird oft als rein technisches Problem missverstanden, das erst im Development oder im abschließenden Audit gelöst werden muss. Dabei entstehen die meisten Probleme nicht durch klassische Bugs im Code, sondern dort, wo die Disziplinen nicht miteinander sprechen: ein Fokus-Zustand, der nie definiert wurde; Farbwerte, die in Figma die Kontrastprüfung bestehen, in der Umsetzung aber leicht abweichen; Fehlermeldungen, die visuell vorhanden sind, aber von Screenreadern nicht angekündigt werden, weil das semantische Markup fehlt, ob nativ oder über ARIA.

Wenn solche Lücken sichtbar werden, werden aus kleinen Unschärfen schnell strukturelle Probleme: Komponenten müssen neu gebaut und Entscheidungen neu getroffen werden, die längst als geklärt galten.

Ein Beispiel, das mir immer wieder begegnet:

Im Design stört der standardmäßige Fokusring des Browsers um interaktive Elemente die visuelle Ästhetik. Die scheinbar einfache Lösung: eine Zeile CSS – outline: none. Outline ausgeblendet. Das Ergebnis wirkt ruhiger und konsistenter und automatische Accessibility-Scans bleiben unauffällig.

Das Problem: Bei Navigation mit der Tastatur ist jetzt nicht mehr erkennbar, wo sich der Fokus befindet. Für Menschen, die auf diese Form der Interaktion angewiesen sind – etwa Screenreader-Nutzende, Personen mit motorischen Einschränkungen oder auch Power-User – ist die Website damit kaum noch bedienbar.

Die Designentscheidung war nachvollziehbar, die Umsetzung technisch korrekt, der automatisierte Scan unauffällig – denn viele automatisierte Tools prüfen nicht zuverlässig was im Browser tatsächlich wahrgenommen wird. Und das Ergebnis trotzdem nicht barrierefrei.

Mit :focus-visible gibt es eine CSS-Eigenschaft, die genau dieses Problem löst. Aber ob sie im Team bekannt ist, im Design berücksichtigt und in der Umsetzung eingesetzt wird, das fällt in genau den Bereich, für den sich oft niemand zuständig fühlt.

Barrierefreiheit scheitert in solchen Fällen also nicht an fehlendem Bewusstsein. Sondern daran, dass niemand den Moment begleitet, in dem aus einer Designentscheidung eine technische Realität wird.

Design und Code aus einer Hand #

Genau dort setze ich als Web Design Engineer an – als jemand, der Gestaltung und Code nicht als zwei getrennte Disziplinen behandelt, sondern als Einheit.

Ich gestalte und prüfe dieselbe Komponente in Figma und im Browser. Ich bespreche mit Designer:innen, warum bestimmte Lösungen in der Umsetzung scheitern – und welche Muster sich robust implementieren lassen. Und ich stelle gemeinsam mit Entwickler:innen sicher, dass das Ergebnis der ursprünglichen Intention entspricht, ohne UX- und Designqualität zu verlieren.

Nicht Koordination zwischen zwei Gewerken. Sondern eine Person, die beide Sprachen fließend spricht.

Drei Formen der Zusammenarbeit #

Barrierefreiheits-Audit #

Eine manuelle Prüfung nach WCAG 2.2 und EN 301 549 – den Standards, die sowohl dem EAA als auch dem BFSG zugrunde liegen – und für öffentliche Auftraggeber BITV 2.0. Getestet mit assistiven Technologien, nicht nur mit automatisierten Tools.

Das Ergebnis ist eine klar priorisierte Auswertung mit konkreten, kontextbezogenen Empfehlungen – sowie Tipps wie sich in bestehenden Design- und Entwicklungsprozessen Probleme künftig vermeiden lassen. Keine abstrakte Checkliste. Kein PDF fürs Archiv. Sondern ein praxisnaher Fahrplan mit dem Design- und Engineering-Teams wirklich weiterkommen.

Geeignet für: Produkte in Vorbereitung auf EAA/BFSG-Konformität. Redesigns, die eine fundierte Bestandsaufnahme brauchen. Designsysteme ohne bisherige End-to-End-Prüfung.

Hands-on-Umsetzung #

Ich arbeite direkt in der Codebase: Reviews, Entwicklung barrierefreier Komponenten, gezielte Behebung konkreter Probleme oder Unterstützung in fokussierten Remediation-Sprints.

Der Fokus liegt dabei auf realen Verbesserungen im Produkt – insbesondere dann, wenn gerade interne Kapazitäten begrenzt sind oder die Lücke zwischen Audit und Umsetzung geschlossen werden soll.

Geeignet für: Teams, die Unterstützung bei der Umsetzung brauchen – nach einem Audit oder wenn bestehende Websites, Anwendungen oder Design Systeme barrierefrei gemacht werden sollen.

Workshops für interdisziplinäre Teams #

Halb- oder ganztägige Sessions, in denen Designer:innen und Entwickler:innen gemeinsam an realen Fragestellungen aus konkreten Produkten arbeiten.

Im Mittelpunkt stehen Fragen wie: Wie muss sich eine Komponente semantisch verhalten? Was sollte im Design klar definiert sein? Was ist in der Umsetzung entscheidend? Und wo entstehen typische Bruchstellen?

Das Ziel: ein Team, das eigenständig bessere Entscheidungen trifft – ohne dauerhaften externen Support.

Geeignet für: Teams im Aufbau einer nachhaltigen Accessibility-Praxis. Agenturen in Vorbereitung auf EAA/BFSG-Anforderungen. Organisationen, die internes Know-how stärken wollen.

Wie ich arbeite #

Ich bin selbstständig – keine Agentur, keine Zwischenebenen. Teams arbeiten direkt mit mir, in Calls, in Figma und im Repository. Seit rund zwanzig Jahren arbeite ich an der Schnittstelle von Design und Engineering; seit über zehn Jahren unterrichte ich Interface Prototyping an der Muthesius Kunsthochschule. Ich kenne die typischen Probleme, weil ich sie in der Praxis gesehen habe, nicht nur im Audit.

Ich arbeite vom Raum Stuttgart aus mit Teams in Deutschland, Europa und international, auf Deutsch und Englisch.

Sprechen Sie mit mir über Ihr Projekt #

Viele Teams wissen, dass Barrierefreiheit seit dem BFSG nicht mehr ignoriert werden kann – aber nicht genau, wo sie ansetzen sollen. Genau dafür ist ein erstes Gespräch da: Es dauert selten länger als dreißig Minuten und reicht, um zu verstehen, wo der größte Hebel liegt.