Barrierefreiheit im B2B-Relaunch als Beispiel
Ein Relaunch scheitert selten an fehlenden Funktionen. Häufiger liegt das Problem in Details, die im Projektverlauf zu spät geprüft werden: nicht bedienbare Formulare, unklare Fokuszustände, redaktionell schwer nutzbare Komponenten oder PDFs, die zentrale Informationen nur als Bild transportieren. Ein Beispiel für Barrierefreiheit im B2B-Relaunch zeigt, weshalb diese Anforderungen nicht erst im Abnahmetest auf die Liste gehören, sondern die Informationsarchitektur, das Design und die Entwicklung von Anfang an prägen müssen.
Für B2B-Unternehmen geht es dabei nicht allein um gesetzliche Anforderungen. Eine zugängliche Website verbessert die Nutzbarkeit für Entscheider:innen unter Zeitdruck, für Mitarbeitende mit unterschiedlichen Arbeitsweisen und für Redaktionen, die Inhalte langfristig pflegen. Gerade bei komplexen Produktportfolios, internationalen Strukturen oder geschlossenen Bereichen entsteht daraus ein klarer Qualitätsvorteil.
Warum Barrierefreiheit beim B2B-Relaunch anders wirkt
Im B2C wird Barrierefreiheit oft zuerst mit Kaufprozessen und großen Reichweiten verbunden. Im B2B sind die Wege meist länger: Interessierte vergleichen technische Leistungen, laden Unterlagen herunter, suchen Ansprechpartner:innen oder bereiten interne Entscheidungen vor. Die Website muss deshalb Informationen verlässlich vermitteln, auch wenn jemand nur per Tastatur navigiert, stark vergrößert oder einen Screenreader nutzt.
Das betrifft nicht nur die sichtbare Oberfläche. Wenn eine Produktseite ohne logisch aufgebaute Überschriften auskommt, hilft der schönste Teaser wenig. Wenn ein Kontaktformular Fehlermeldungen nur rot markiert, bleibt eine Anfrage unter Umständen unvollständig. Und wenn ein redaktionelles System keine sinnvollen Alternativtexte, Tabellenüberschriften oder Linktexte unterstützt, wird Barrierefreiheit im Tagesgeschäft schnell wieder abgebaut.
Die Anforderungen aus WCAG und BITV liefern dafür einen belastbaren Rahmen. Welche Stufe und welche Prüftiefe erforderlich sind, hängt vom Unternehmen, der Zielgruppe und möglichen rechtlichen Verpflichtungen ab. Für viele B2B-Websites ist WCAG 2.1 AA ein sinnvoller Orientierungswert. Entscheidend ist jedoch nicht das Etikett, sondern eine Umsetzung, die auch nach dem Launch wartbar bleibt.
Barrierefreiheit im B2B-Relaunch: Beispiel aus dem Maschinenbau
Nehmen wir ein mittelständisches Maschinenbauunternehmen mit mehreren Geschäftsbereichen. Die bisherige Website ist über Jahre gewachsen: Produktseiten bestehen aus langen Texten, technische Daten liegen als PDF vor, Kontaktmöglichkeiten sind je nach Bereich unterschiedlich gestaltet. Das CMS ist veraltet, die Redaktion arbeitet mit vielen Sonderformaten, und die mobile Darstellung wurde nur punktuell angepasst.
Der Relaunch verfolgt drei Ziele. Erstens sollen Vertriebsanfragen besser qualifiziert werden. Zweitens soll das Unternehmen seine Produktkompetenz suchmaschinenfreundlich und verständlich darstellen. Drittens soll die Plattform die Anforderungen an digitale Barrierefreiheit strukturell erfüllen, statt sie über nachträgliche Korrekturen abzufedern.
Eine typische Fehlannahme wäre, zuerst ein neues Layout zu gestalten und danach einen Accessibility-Check zu beauftragen. In diesem Beispiel beginnt das Projekt anders: mit einer Bestandsaufnahme der Inhalte, Nutzerwege und technischen Risiken. Dabei wird früh sichtbar, dass nicht jeder bestehende Inhalt in die neue Plattform übernommen werden sollte. Veraltete Datenblätter, doppelte Produktbeschreibungen und schwer lesbare Download-Sammlungen würden die neue Struktur nur belasten.
Die Bestandsaufnahme schafft Prioritäten
Zunächst werden die zentralen Nutzungsszenarien definiert. Ein Einkäufer möchte technische Spezifikationen vergleichen. Eine Planerin sucht Zertifikate und CAD-Daten. Ein Servicetechniker braucht schnell eine Anleitung. Eine Bewerberin möchte das Karriereformular ausfüllen. Diese Wege sind fachlich unterschiedlich, folgen aber denselben Grundsätzen: klare Struktur, verständliche Beschriftungen und eine zuverlässige Bedienung ohne Maus.
Danach folgt ein Audit der bestehenden Website. Geprüft werden unter anderem die Überschriftenhierarchie, Kontraste, Tastaturbedienung, Fokusführung, Formularlogik, Bildalternativen, eingebundene Dokumente und die Qualität vorhandener Templates. Das Ergebnis ist keine abstrakte Mängelliste. Es wird nach Auswirkung priorisiert: Was verhindert die Nutzung? Was erschwert sie erheblich? Was lässt sich im Zuge der Content-Migration sinnvoll verbessern?
Diese Priorisierung schützt das Budget. Es ist selten wirtschaftlich, jedes historische PDF vollständig nachzubearbeiten. Wenn ein Dokument rechtlich oder vertrieblich relevant bleibt, muss es zugänglich bereitgestellt oder durch eine gleichwertige HTML-Seite ergänzt werden. Veraltete Unterlagen können dagegen aus dem öffentlichen Bereich entfernt werden. Barrierefreiheit bedeutet auch, Inhalte bewusst zu bereinigen.
Von der Konzeption bis zum CMS mitdenken
Im neuen Seitenkonzept werden Produktinformationen nicht mehr als unstrukturierte Textblöcke geführt. Wiederkehrende Inhalte erhalten klar definierte Module: Produktvorteile, technische Daten, Downloads, Einsatzbereiche, Ansprechpartner:innen und weiterführende Informationen. Für jedes Modul wird festgelegt, welche semantische Struktur es ausgibt und welche redaktionellen Eingaben erforderlich sind.
Das hat unmittelbare Folgen für UX und Design. Kontraste werden nicht erst anhand fertiger Screens bewertet. Bereits im Designsystem sind zulässige Farbkombinationen, sichtbare Fokusmarkierungen und Zustände für Links, Buttons, Formulare und Akkordeons definiert. Interaktive Elemente erhalten keine Bedeutung allein über Farbe, Icon oder Position. Ein Plus-Symbol kann eine Funktion ergänzen, ersetzt aber keine verständliche Beschriftung.
Bei komplexen B2B-Angeboten sind Tabellen ein häufiger Sonderfall. Technische Daten lassen sich nicht immer sinnvoll in Fließtext überführen. Dann braucht die Tabelle korrekte Spalten- und Zeilenüberschriften, eine verständliche Einordnung und auf mobilen Geräten eine Bedienung, die nicht zum horizontalen Rätsel wird. Je nach Datenmenge kann eine vergleichbare Kartenansicht oder eine Filterfunktion besser sein. Nicht jede Tabelle muss verschwinden, aber jede muss ihren Zweck erfüllen.
Auch das CMS wird Teil der Lösung. In einem professionell konfigurierten TYPO3-System lassen sich Inhaltselemente so anlegen, dass Redaktionen sinnvolle Leitplanken erhalten. Pflichtfelder für Alternativtexte, Warnhinweise bei nichtssagenden Linktexten, klar getrennte Überschriftenebenen und geprüfte Komponenten reduzieren spätere Fehler. Eine Redaktion braucht trotzdem Schulung und Verantwortung. Technik kann gute Entscheidungen unterstützen, aber nicht jeden Inhalt automatisch verständlich machen.
Entwicklung: Semantik vor Effekten
In der Umsetzung werden HTML-Struktur und Interaktionen konsequent geprüft. Navigation, Suche, Formulare, Filter und Download-Bereiche müssen vollständig per Tastatur bedienbar sein. Der sichtbare Fokus darf nicht durch pauschale CSS-Regeln entfernt werden. Bei aufklappbaren Elementen müssen Zustand und Beziehung für assistive Technologien erkennbar sein.
Besonders kritisch sind Formulare. Im Beispiel wird das Vertriebsformular neu strukturiert: Jede Eingabe besitzt ein zugeordnetes Label, Pflichtfelder werden nicht nur über ein Sternchen erklärt, Fehlermeldungen stehen direkt am betroffenen Feld und werden programmatisch vermittelt. Nach dem Absenden erhält die Person eine klare Rückmeldung. Das erhöht nicht nur die Zugänglichkeit, sondern senkt auch die Zahl unvollständiger Anfragen.
Bei eingebundenen Drittanwendungen ist eine ehrliche Prüfung nötig. Cookie-Banner, Karten, Videos, Bewerbungssoftware oder Marketing-Tools können die Zugänglichkeit beeinträchtigen, obwohl der eigene Code sauber entwickelt wurde. Hier gibt es keinen pauschalen Ausweg. Manchmal lässt sich ein Anbieter korrekt einbinden, manchmal ist eine alternative Darstellung oder ein anderer Dienst die bessere Entscheidung. Diese Abhängigkeiten sollten vor der technischen Festlegung bekannt sein.
Prüfen, bevor der Relaunch live geht
Automatisierte Tests sind hilfreich, finden aber nur einen Teil der Fehler. Sie erkennen beispielsweise fehlende Alternativtexte oder Kontrastprobleme. Ob ein Alternativtext tatsächlich sinnvoll ist, ob ein Dialog nachvollziehbar funktioniert oder ob die Reihenfolge beim Tastaturfokus logisch bleibt, muss zusätzlich manuell geprüft werden.
Für das Maschinenbau-Beispiel umfasst die Qualitätssicherung daher automatisierte Prüfungen im Entwicklungsprozess, manuelle Tastaturtests, Screenreader-Stichproben und Tests mit realistischen Redaktionsinhalten. Nicht nur die Startseite wird betrachtet. Entscheidend sind wiederkehrende Seitentypen, Formulare, Suchergebnisse, Downloads und mobile Ansichten. Werden dabei Fehler gefunden, fließen sie in die Komponenten zurück. So wird nicht jede Produktseite einzeln repariert.
Nach dem Launch endet die Aufgabe nicht. Neue Module, Kampagnenseiten oder externe Integrationen können bestehende Standards unterlaufen. Sinnvoll sind feste Prüfungen bei Releases, eine dokumentierte Komponentenbibliothek und klare Zuständigkeiten zwischen Marketing, Redaktion und Entwicklung. Langfristige Qualität entsteht durch diese Prozesse, nicht durch ein einmaliges Zertifikat.
Ein Relaunch bietet die seltene Gelegenheit, technische Schulden und inhaltliche Unklarheiten gemeinsam zu reduzieren. Wer Barrierefreiheit dabei als Teil von UX, CMS-Konzept und Qualitätssicherung behandelt, baut keine Sonderlösung für wenige Nutzergruppen. Es entsteht eine Website, die Informationen klarer vermittelt, verlässlicher funktioniert und auch bei der nächsten Weiterentwicklung auf einem tragfähigen Fundament steht.
