Der Relaunch ist fast live. Design und Branding sitzen, der Shop wirkt modern, das CMS ist sauber aufgesetzt. Dann kommt der Moment, den viele Teams zu spät erleben: Jemand versucht die Seite nur mit Tastatur zu bedienen, ein Screenreader liest kryptische Navigationspunkte vor, Formulare geben Fehler nur in Rot aus, und wichtige Buttons sind technisch klickbar, aber praktisch nicht nutzbar.
Genau so starten viele Barrierefreiheits-Projekte in Agenturen. Nicht mit Strategie, sondern mit einem späten Schreck. Das Problem ist selten fehlender Wille. Meist fehlt ein Prozess, der Barrierefreiheit von Anfang an in Konzeption, Design, Entwicklung und Redaktion einbaut. Wer erst kurz vor dem Go-live merkt, dass die Website für Teile der Zielgruppe kaum benutzbar ist, zahlt fast immer doppelt. Erst für die Umsetzung, dann für die Korrektur.
Wenn man eine barrierefreie Website erstellen will, braucht man deshalb keinen separaten Sonderprozess am Ende. Man braucht einen besseren Standardprozess von Anfang an. Genau dort liegt in Agenturen der Unterschied zwischen hektischem Nachbessern und sauberer Projektarbeit.
Inhaltsverzeichnis
- Warum digitale Barrierefreiheit jetzt unverzichtbar ist
- Die rechtlichen Anforderungen verständlich erklärt
- Barrierefreiheit von Anfang an richtig planen
- Technische Umsetzung für eine robuste Basis
- Barrierefreie Inhalte Medien und Dokumente
- Die eigene Website auf Barrierefreiheit testen
- Barrierefreiheit als fortlaufenden Prozess etablieren
Warum digitale Barrierefreiheit jetzt unverzichtbar ist
Ein typischer Fall aus dem Agenturalltag sieht so aus: Ein Unternehmen investiert in einen neuen Online-Shop, optimiert Produktseiten, baut Kampagnen auf und wundert sich trotzdem über Abbrüche an Stellen, die intern niemand problematisch fand. Erst bei einem einfachen Praxistest fällt auf, dass der Filter nicht per Tastatur bedienbar ist, Formularhinweise im Checkout fehlen und Bildbuttons vom Screenreader kaum verständlich vorgelesen werden.
Dann wird aus einem vermeintlichen Detail plötzlich ein Geschäftsproblem. Nutzer kommen nicht ans Ziel. Support-Anfragen häufen sich. Im schlimmsten Fall landet das Thema bei der Rechtsabteilung oder in der Geschäftsführung, weil klar wird: Es geht nicht nur um Komfort, sondern um Zugang.
Was in der Praxis wirklich auf dem Spiel steht
Barrierefreiheit ist keine Randanforderung für Sonderfälle. Sie betrifft reale Nutzungssituationen jeden Tag. Menschen mit dauerhaften Einschränkungen profitieren davon. Genauso ältere Nutzer, Menschen mit vorübergehenden Verletzungen, Nutzer mit schlechtem Bildschirm, zu wenig Licht oder einer Hand am Handy im Zug.
Wer Websites baut, sieht schnell den Nebeneffekt: Gute Barrierefreiheit verbessert oft auch die allgemeine Usability. Klare Überschriften, verständliche Linktexte, saubere Fokuszustände, logische Formulare und semantische Strukturen helfen nicht nur Screenreader-Nutzern. Sie helfen allen.
Barrierefreiheit ist selten ein Projektproblem. Fast immer ist es ein Qualitätsproblem im Standardprozess.
Dazu kommt die wirtschaftliche Perspektive. Wenn ein Shop, ein Kundenportal oder eine Terminbuchung für Teile der Zielgruppe schwer nutzbar ist, verliert das Unternehmen Anfragen, Abschlüsse und Vertrauen. Das ist kein theoretischer Schaden. Das merkt man in Conversion-Strecken, im Serviceaufwand und im Markenbild.
Warum das Thema auch SEO und Sichtbarkeit berührt
Viele Massnahmen überschneiden sich mit sauberer technischer Qualität. Semantisches HTML, klare Informationsarchitektur, gute Linktexte und nachvollziehbare Inhalte machen Seiten nicht nur zugänglicher, sondern oft auch besser interpretierbar. Deshalb gehört Barrierefreiheit aus meiner Sicht in dieselbe Qualitätsdiskussion wie Performance, Wartbarkeit und Suchmaschinenoptimierung. Wer an Sichtbarkeit arbeitet, sollte Barrierefreiheit nicht ausklammern. Das passt auch zur strategischen Perspektive einer SEO-Agentur in Münster und NRW, wenn nachhaltige Reichweite und nutzbare Seiten zusammen gedacht werden.
Die rechtlichen Anforderungen verständlich erklärt
Die rechtliche Seite wirkt oft komplizierter, als sie im Projektalltag sein muss. Für Teams ist entscheidend, die Hierarchie zu verstehen: Auf europäischer Ebene setzt der European Accessibility Act den Rahmen. In Deutschland wird das Thema für viele Angebote über das Barrierefreiheitsstärkungsgesetz relevant. Für öffentliche Stellen spielt zusätzlich die BITV 2.0 eine zentrale Rolle. Die technische Umsetzung orientiert sich an EN 301 549, die wiederum stark auf den WCAG aufbaut.
Welche Regelwerke praktisch relevant sind
Wenn ein Unternehmen digitale Produkte oder Services anbietet, muss es nicht jedes Dokument im Original studieren. Es reicht, die Ebenen sauber zuzuordnen:
- EAA als politischer Rahmen: Der European Accessibility Act definiert, dass digitale Angebote in bestimmten Bereichen barrierefrei zugänglich sein müssen.
- BFSG als deutsche Umsetzung: Für viele privatwirtschaftliche Anbieter, besonders im digitalen Vertrieb, wird daraus eine operative Pflicht.
- EN 301 549 als technischer Referenzrahmen: Hier wird greifbar, was Teams tatsächlich bauen und prüfen müssen.
- WCAG als Umsetzungslogik: Entwickler, Designer und Redakteure arbeiten in der Praxis meist mit diesen Kriterien.
- BITV 2.0 für öffentliche Stellen: Kommunen, Behörden und andere öffentliche Einrichtungen orientieren sich daran besonders eng.
Der Stichtag 28. Juni 2025 ist in diesem Zusammenhang wichtig. Er markiert den Zeitpunkt, an dem die Anforderungen für viele betroffene Angebote relevant werden. Wer erst dann anfängt, arbeitet unter Druck. Wer vorher plant, spart Diskussionen, Budget und Rework.
Für kleinere Organisationen, die das Thema nicht nur juristisch, sondern auch organisatorisch sortieren wollen, ist der Compliance Reporting Guide für KMU ein nützlicher Einstieg, weil er die Dokumentationsseite verständlich aufzieht.
Praktische Prüffragen für Unternehmen
Im Kick-off stelle ich meist keine Paragrafenfrage, sondern diese Liste:
- Verkauft ihr digital an Endkunden oder stellt zentrale Services online bereit?
- Gibt es Buchungs-, Anmelde-, Shop-, Portal- oder Self-Service-Strecken?
- Ist eure Website für öffentliche Informationen oder Verwaltungsleistungen relevant?
- Arbeitet ihr mit PDFs, Formularen, Kundenkonten oder Transaktionsprozessen?
- Ist aktuell jemand verantwortlich, Anforderungen in Design, Code und Content zu übersetzen?
Wenn mehrere Punkte mit Ja beantwortet werden, ist das Thema in der Regel kein Nice-to-have mehr.
So wird aus Recht ein umsetzbares Ticket
Die grösste Hürde ist selten das Gesetz. Die grösste Hürde ist die Übersetzung ins Backlog. Bei einer kommunalen Website haben wir die Anforderungen der BITV 2.0 nicht als abstrakte Prüfpunkte stehen lassen, sondern in konkrete Arbeitspakete zerlegt. Aus „Inhalte müssen wahrnehmbar und bedienbar sein“ werden dann Tickets wie: Fehlermeldungen programmatisch mit Formularfeldern verknüpfen, Sprunglinks einbauen, Fokusreihenfolge im Hauptmenü korrigieren, PDF-Export im Redaktionsworkflow ersetzen.
Praxisregel: Wenn ein jurischer Satz nicht in Designentscheidungen, Content-Vorgaben oder Development-Tickets übersetzt werden kann, ist er fürs Projekt noch nicht verarbeitet.
Barrierefreiheit von Anfang an richtig planen
Die teuerste Form von Barrierefreiheit ist die nachträgliche. Dann sind Navigationskonzepte beschlossen, Komponenten gebaut, Texte eingefüllt und der Go-live-Termin steht schon im Kalender. Genau deshalb gehört Barrierefreiheit in die frühe Projektphase. Nicht als Zusatzspur, sondern als Teil der normalen Delivery.
Im Agenturalltag funktioniert das am besten, wenn Accessibility in Discovery, Design und Sprint-Planung sichtbar verankert wird. Wer eine barrierefreie Website erstellen will, sollte nicht mit einem Audit am Ende beginnen, sondern mit klaren Annahmen über reale Nutzung.
Personas die echte Nutzung abbilden
Viele Personas in Projekten sind marketingtauglich, aber nicht produkttauglich. Es steht dort, wie alt jemand ist, was er kauft und welche Ziele er hat. Was fast immer fehlt, sind Nutzungseinschränkungen und konkrete Bedienkontexte.
Besser sind Personas wie diese:
- Klaus nutzt Vergrösserung im Browser: Er braucht klare Strukturen, stabile Layouts und gut erkennbare Fokuszustände.
- Maria navigiert ausschliesslich per Tastatur: Sie merkt sofort, wenn Menüs, Filter oder Dialoge nicht erreichbar sind.
- Tobias hört Inhalte mit Screenreader: Für ihn entscheiden Landmarken, Überschriften und aussagekräftige Button-Beschriftungen darüber, ob die Seite verständlich ist.
Solche Personas ändern Diskussionen im Team. Plötzlich wird aus „Der Button ist doch sichtbar“ die sinnvollere Frage: „Ist der Button in der Tab-Reihenfolge, verständlich benannt und ohne Maus aktivierbar?“
Ein sauber geplanter Relaunch beginnt deshalb oft schon im Konzept mit Anforderungen an Struktur, Interaktionen und Content. Das ist eng verwandt mit der frühen Phase professioneller Webdesign-Projekte in Münster und NRW, nur mit schärferem Blick auf Bedienbarkeit.
User Stories mit klaren Akzeptanzkriterien
In agilen Teams gehört Accessibility direkt in die Story. Nicht als Sammelaufgabe im Sprintende, sondern als Definition von Done.
Gute User Story:
„Als Nutzerin möchte ich den Warenkorb ohne Maus öffnen, Positionen ändern und den Checkout starten, damit ich den Kauf vollständig per Tastatur abschliessen kann.“
Dazu passende Akzeptanzkriterien:
- Erreichbarkeit: Alle interaktiven Elemente sind per Tab erreichbar.
- Sichtbarkeit: Der aktuelle Fokus ist klar sichtbar.
- Verständlichkeit: Buttons und Formularfelder haben eindeutige Beschriftungen.
- Fehlerbehandlung: Eingabefehler werden nicht nur farblich, sondern auch textlich ausgegeben.
Schlechte Stories sind leicht zu erkennen. Sie lauten oft nur „Formular bauen“ oder „Filter-Komponente entwickeln“. Dann fehlen genau die Kriterien, die später teuer werden.
Wireframes und Designsysteme barrierefrei denken
Viele Barrieren entstehen nicht im Code, sondern schon im Wireframe. Zu kleine Klickflächen, modale Overlays ohne klare Schliesslogik, visuell schicke aber unklare Formularzustände. Wenn das erst im Frontend auffällt, muss das Team gegen bereits freigegebene Entwürfe arbeiten.
Deshalb definieren wir im Design früh Dinge wie:
- Lesereihenfolge und Überschriftenstruktur
- sichtbare Fokuszustände für alle Komponenten
- Zustände für Fehler, Erfolg und deaktivierte Elemente
- Navigation auf kleinen und grossen Viewports
- Muster für Akkordeons, Tabs, Dialoge und Formulare
Ein SaaS-Projekt aus dem B2B-Umfeld ist dafür ein gutes Beispiel. Das Team wollte ein sehr kompaktes Dashboard mit vielen Karten, Filtern und Quick Actions. Im ersten Entwurf war fast alles visuell effizient, aber für Tastaturnavigation unruhig und für Screenreader schlecht strukturiert. Nach einer frühen Überarbeitung im Wireframe konnten wir Komponenten vereinheitlichen, unnötige Sonderlogiken streichen und den Entwicklungsaufwand stabil halten. Der entscheidende Punkt war nicht mehr Arbeit, sondern frühere Arbeit.
Ein guter Einstieg für Teams, die genau diese Denkweise im Alltag verankern wollen, ist dieses kurze Video:
Technische Umsetzung für eine robuste Basis
Wenn Konzeption und Design sauber sind, entscheidet die technische Umsetzung darüber, ob die Website im Alltag wirklich zugänglich ist. In Projekten mit hohem Druck sehe ich dabei immer dieselben Baustellen: generische Div-Konstruktionen statt echter HTML-Elemente, unklare Fokusführung, Formulare ohne belastbare Zuordnung und unnötiger ARIA-Einsatz an den falschen Stellen.
Die gute Nachricht: Ein grosser Teil der Probleme lässt sich mit wenigen Grundprinzipien vermeiden. Ich nenne sie die Big Five der technischen Umsetzung.
Semantisches HTML zuerst
Das stärkste Werkzeug ist oft das unspektakulärste. Sauberes HTML trägt bereits viel Bedeutung in sich. Wer statt klickbarer div-Container echte Buttons und statt beliebiger Wrapper passende Landmarken nutzt, spart oft spätere Korrekturen.
Schlecht:
<div class="cta" onclick="submitForm()">Jetzt absenden</div>
Besser:
<button type="submit">Jetzt absenden</button>
Auch für die Seitenstruktur gilt das:
<header>...</header>
<nav aria-label="Hauptnavigation">...</nav>
<main>...</main>
<footer>...</footer>
Semantik hilft Screenreadern, Tastaturnutzern und oft auch der internen Wartung. Entwickler erkennen schneller, was ein Element tatsächlich tun soll.
ARIA gezielt und sparsam einsetzen
Der wichtigste Satz dazu lautet: Nutze ARIA erst, wenn semantisches HTML nicht ausreicht. Viele Teams versuchen, schlechte Grundstrukturen mit role, aria-label oder aria-expanded nachträglich zu reparieren. Das funktioniert manchmal, aber nicht zuverlässig.
Sinnvoll ist ARIA zum Beispiel hier:
<form role="search" aria-label="Seitensuche">
<label for="q">Suchbegriff</label>
<input id="q" name="q" type="search">
<button type="submit">Suchen</button>
</form>
Oder bei einem Akkordeon-Button:
<button aria-expanded="false" aria-controls="faq-1" id="faq-button-1">
Lieferzeiten anzeigen
</button>
<div id="faq-1" aria-labelledby="faq-button-1" hidden>
...
</div>
Was nicht funktioniert: wahllos Rollen zu ergänzen, ohne Interaktionslogik, Tastatursteuerung und Zustandswechsel korrekt zu implementieren.
Wenn ein Custom-Widget gebaut wird, muss das Team auch das Verhalten eines nativen Elements vollständig nachbilden. Genau daran scheitern viele Eigenlösungen.
Tastatur Fokus und Bedienlogik
Eine Seite ist nicht barrierefrei, wenn sie nur mit der Maus gut aussieht. Jede Funktion, die geklickt werden kann, muss auch per Tastatur erreichbar und nutzbar sein. Das betrifft Navigation, Filter, Modale, Tabs, Akkordeons, Karussells und Formulare.
Drei Prüfpunkte sind unverzichtbar:
- Tab-Reihenfolge: Der Fokus springt in logischer Reihenfolge über die Seite.
- Sichtbarer Fokus: Nutzer sehen klar, welches Element aktiv ist.
- Keine Fokusfalle: Modale Dialoge dürfen den Fokus gezielt halten, aber beim Schliessen sauber zurückgeben.
Ein klarer Fokusstil sieht etwa so aus:
:focus-visible {
outline: 3px solid #1a73e8;
outline-offset: 2px;
}
Viele Teams entfernen Fokusrahmen aus Designgründen. Das ist fast immer ein Fehler. Wenn der Standardstil optisch nicht passt, ersetzt man ihn durch einen besseren. Man löscht ihn nicht.
Kontraste Zustände und verständliche Formulare
Farben entscheiden mit über Lesbarkeit. Für normalen Text gilt bei WCAG AA ein Kontrastverhältnis von 4.5:1. Das ist kein Detail aus der Designabnahme, sondern Grundvoraussetzung dafür, dass Inhalte lesbar bleiben.
Noch wichtiger ist der zweite Teil: Farbe darf nie allein Bedeutung tragen. Ein roter Rand am Formularfeld reicht nicht. Es braucht zusätzlich Text, Icon oder klaren Hinweis.
Schlecht:
<input aria-invalid="true">
Besser:
<label for="email">E-Mail</label>
<input id="email" name="email" type="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error">Bitte geben Sie eine gueltige E-Mail-Adresse ein.</p>
Wichtige WCAG 2.1 AA Kriterien in der Praxis
| WCAG-Kriterium | Anforderung | Praktische Umsetzung |
|---|---|---|
| Wahrnehmbare Struktur | Inhalte müssen sinnvoll gegliedert sein | Überschriftenhierarchie, Listen, Landmarken und Labels korrekt einsetzen |
| Tastaturbedienbarkeit | Funktionen müssen ohne Maus nutzbar sein | Buttons, Menüs, Filter, Dialoge und Formulare vollständig per Tastatur testen |
| Sichtbarer Fokus | Aktives Element muss erkennbar sein | :focus-visible gestalten und nicht entfernen |
| Kontrast | Text und wichtige UI-Elemente müssen gut unterscheidbar sein | Farbpalette mit Kontrast-Checker im Designsystem absichern |
| Fehleridentifikation | Fehler müssen verständlich kommuniziert werden | Fehlermeldungen textlich ausgeben und programmatisch mit Feldern verknüpfen |
| Name Rolle Wert | Interaktive Elemente müssen ihren Zweck mitteilen | Native Elemente bevorzugen, ARIA nur gezielt ergänzen |
In komplexeren Plattformen lohnt sich dafür eine saubere Komponentenbibliothek. Gerade bei Portalen, SaaS-Oberflächen oder Integrationsprojekten ist das eng verknüpft mit professioneller Web-Entwicklung für SaaS in Münster und NRW, weil wiederverwendbare, getestete Komponenten langfristig die stabilere Lösung sind.
Barrierefreie Inhalte Medien und Dokumente
Viele Teams konzentrieren sich zuerst auf Code. Das ist nachvollziehbar, reicht aber nicht. Eine technisch sauber gebaute Seite bleibt trotzdem unzugänglich, wenn Redakteure unklare Überschriften setzen, Bilder ohne sinnvollen Alternativtext einbauen oder PDFs als reine Druckdatei behandeln.
In der Praxis kippt Barrierefreiheit oft genau hier. Das Frontend ist ordentlich, aber der Content-Prozess nicht.
Alt-Texte die wirklich helfen
Der häufigste Fehler ist ein Alt-Text, der formal vorhanden ist, aber keinen Nutzen hat.
Vorher:alt="Bild"
Auch schlecht:alt="Mitarbeiterin am Laptop im Büro"
Besser, wenn das Bild einen konkreten Zweck im Inhalt erfüllt:alt="Redakteurin prueft Ueberschriftenstruktur und Alternativtexte im CMS"
Der Unterschied ist einfach. Gute Alt-Texte beschreiben nicht jedes visuelle Detail, sondern den Informationswert im Kontext. Bei rein dekorativen Bildern ist ein leerer Alt-Text oft korrekt. Bei Funktionsgrafiken, Produktbildern oder erklärenden Screenshots braucht es dagegen eine sinnvolle Beschreibung.
Linktexte und Überschriften mit Orientierung
Screenreader-Nutzer springen häufig über Überschriften und Links durch eine Seite. Deshalb scheitern Seiten mit generischen Formulierungen besonders schnell.
Vorher:
- mehr erfahren
- hier klicken
- weiterlesen
Nachher:
- mehr über unsere Web-Entwicklung erfahren
- zur Preisliste als PDF
- Kontaktformular für Projektanfragen öffnen
Dasselbe gilt für Überschriften. Wer visuell mit Fettungen arbeitet, aber technisch keine saubere H-Struktur pflegt, nimmt Nutzern die Orientierung. Gute Content-Teams arbeiten deshalb mit echten H2- und H3-Ebenen statt mit formatierten Fliesstext-Zeilen.
Ein Redaktionsworkflow ist erst dann barrierearm, wenn Redakteure ohne Spezialwissen trotzdem die richtige Struktur produzieren können.
Das bedeutet konkret: Das CMS braucht Vorlagen, Hinweise und manchmal auch Guardrails. Wenn im Editor jede optische Spielerei möglich ist, entstehen schnell unklare Seiten.
PDFs ohne Sackgassen
PDFs sind in vielen Organisationen der blinde Fleck. Jahresberichte, Satzungen, Broschüren, Preislisten, Formulare. Alles wird schnell exportiert, aber selten wirklich geprüft.
Ein einfaches „Speichern als PDF“ reicht nicht. Ein brauchbares barrierefreies PDF braucht unter anderem:
- getaggte Struktur: Überschriften, Absätze, Listen und Tabellen müssen als Struktur vorhanden sein
- korrekte Lesereihenfolge: Screenreader müssen Inhalte in sinnvoller Reihenfolge ausgeben
- beschriftete Links: URL oder Linkziel muss verständlich sein
- Alternativtexte: bei inhaltlich relevanten Grafiken
- erkennbare Formularfelder: falls Eingaben möglich sind
Aus Word oder InDesign lassen sich solche Dokumente deutlich besser exportieren, wenn die Quelldatei bereits sauber strukturiert wurde. Wer erst im PDF repariert, arbeitet unnötig mühsam.
Die eigene Website auf Barrierefreiheit testen
Testing trennt gute Absichten von funktionierender Umsetzung. Dabei scheitern viele Teams an einem Missverständnis: Sie verlassen sich entweder nur auf Tools oder nur auf einzelne manuelle Stichproben. Beides reicht nicht. Barrierefreiheit prüft man in zwei Säulen, automatisiert und manuell.
Was automatisierte Tools gut finden
Tools wie Lighthouse, axe DevTools oder WAVE sind sehr nützlich. Sie finden schnell typische Probleme wie fehlende Alt-Texte, unzureichende Beschriftungen, Kontrastprobleme oder auffällige Strukturfehler.
Im Entwicklungsprozess gehören solche Checks direkt in den Alltag. Ein schneller Lauf im Browser oder in der QA spart Zeit, weil grobe Schnitzer früh sichtbar werden. Auch Küstermann Media GmbH bietet für solche Fälle einen initialen WCAG-Audit an, bei dem manuelle und automatisierte Prüfungen kombiniert werden, um Hürden zu priorisieren.
Automatisierte Tools können aber nicht sicher beurteilen, ob eine Seite logisch verständlich ist, ob ein Alternativtext sinnvoll formuliert wurde oder ob ein komplexer Prozess tatsächlich nutzbar bleibt.
Wo manuell getestet werden muss
Der einfachste manuelle Test ist gleichzeitig einer der aussagekräftigsten: Maus weglegen und nur mit Tastatur arbeiten.
Prüfen Sie dabei:
- Erreiche ich alle Funktionen?
- Ist die Reihenfolge logisch?
- Sehe ich jederzeit den Fokus?
- Kann ich Dialoge öffnen und wieder sauber schliessen?
- Komme ich in Formularen verständlich durch alle Schritte?
Danach folgt der Screenreader-Test. Unter Windows ist NVDA ein gängiger Einstieg, unter macOS VoiceOver. Hier geht es nicht darum, sofort zum Accessibility-Spezialisten zu werden. Schon ein einfacher Durchlauf zeigt, ob Navigation, Überschriften, Buttons und Formulare verständlich angesagt werden.
Ein grüner Tool-Report ist kein Freifahrtschein. Wenn der Checkout logisch kaputt ist, nützt eine saubere Punktzahl niemandem.
Ein realistischer Testablauf im Projekt
Ein Shop-Projekt aus dem Mittelstand zeigt das sehr gut. Die automatisierten Checks sahen ordentlich aus. Kontrast, Labels und Grundstruktur waren weitgehend sauber. Im manuellen Test fiel dann auf, dass der Checkout per Tastatur zwar erreichbar war, aber in einer unlogischen Reihenfolge durchlaufen wurde. Rabattfeld, Versandoption und Zahlungsart sprangen so durcheinander, dass der Prozess faktisch unbenutzbar wurde.
Deshalb hat sich in Projekten dieser Ablauf bewährt:
- Komponenten einzeln prüfen im Designsystem oder Storybook
- Seiten-Templates automatisiert testen mit Lighthouse, axe oder WAVE
- Kernjourneys manuell durchspielen wie Navigation, Suche, Formular, Checkout oder Kontakt
- Screenreader-Stichprobe durchführen auf zentralen Seitentypen
- Regressionen nach Releases prüfen, damit funktionierende Elemente nicht wieder kaputtgehen
Barrierefreiheit als fortlaufenden Prozess etablieren
Die grösste Fehlannahme lautet: Wenn der Relaunch geschafft ist, ist das Thema erledigt. In Wirklichkeit beginnt dann erst die Phase, in der Standards im Alltag halten müssen. Neue Kampagnen, neue Landingpages, neue CMS-Inhalte, neue Module. Genau dort entstehen Rückschritte, wenn Accessibility nicht im Betrieb verankert ist.
Standards im Alltag verankern
Teams brauchen einen festen Rahmen. Bewährt haben sich ein Accessibility Style Guide oder ein erweitertes Designsystem, in dem Farben, Typografie, Komponenten, Formularmuster, Fokuszustände und Content-Regeln dokumentiert sind.
Hilfreich sind auch klare Redaktionsregeln:
- Neue Seiten nur mit Strukturvorlagen: Überschriften, Akkordeons und CTA-Blöcke kommen aus geprüften Mustern.
- Medien nie ohne Prüfung veröffentlichen: Alt-Texte, Untertitel, Dateititel und Linkbeschriftungen gehören in die Freigabe.
- PDFs bewusst begrenzen: Was als HTML veröffentlicht werden kann, sollte nicht unnötig als PDF enden.
Verantwortung Schulung und Qualitätssicherung
Ohne Zuständigkeit zerfällt das Thema. Ein Accessibility Champion im Team muss kein Vollzeit-Spezialist sein. Es reicht oft eine Person, die Standards pflegt, Fragen bündelt und bei kritischen Features früh eingebunden wird.
Dazu kommen drei operative Hebel:
- Schulung im Onboarding: Designer, Entwickler und Redakteure lernen die häufigsten Fehler direkt beim Einstieg.
- Automatisierte Checks in CI/CD: Kontrast-, Struktur- und Label-Probleme werden vor dem Release sichtbar.
- Regelmässige kleinere Audits: Lieber wiederkehrend prüfen als alle paar Jahre ein Grossprojekt daraus machen.
Barrierefreiheit wirkt nach aussen nicht wie ein spektakuläres Feature. Intern ist sie aber ein starkes Signal für Reife im Team. Wer sie konsequent in agile Abläufe integriert, baut nicht nur regelkonformer. Er baut klarer, stabiler und für echte Nutzungssituationen deutlich besser.
Eine barrierefreie Website zu erstellen ist kein Luxus und kein Last-Minute-Fix. Es ist saubere digitale Produktarbeit. Wenn Strategie, Design, Entwicklung, Content und QA gemeinsam daran arbeiten, sinkt der spätere Korrekturaufwand spürbar. Genau so wird aus Barrierefreiheit kein Sonderprojekt, sondern ein belastbarer Standard.
