Accessibility als Pflicht: Barrierefreiheit planen statt nachrüsten

Seit Juni 2025 ist das Barrierefreiheitsstärkungsgesetz in Kraft. Es setzt die europäische Richtlinie zum European Accessibility Act in deutsches Recht um. Und es betrifft nicht nur öffentliche Stellen, sondern auch private Unternehmen, die digitale Produkte und Dienstleistungen anbieten. Wer einen Onlineshop betreibt, wer digitale Services verkauft, wer als B2B-Unternehmen Kunden über die eigene Website gewinnt — für all diese Unternehmen gelten jetzt verbindliche Anforderungen an die Barrierefreiheit.

Das klingt erstmal nach Bürokratie. Ist es auch, teilweise. Aber hinter dem Gesetz steckt ein berechtigter Gedanke: Rund 13 Millionen Menschen in Deutschland leben mit einer Behinderung. Dazu kommen Millionen ältere Menschen, die mit kleinen Schriftgrößen, schlechten Kontrasten und unlogischer Navigation kämpfen. Und dann sind da noch die situativen Einschränkungen — das Smartphone in der prallen Sonne, die gebrochene Hand, die laute Baustelle, in der man kein Audio abspielen kann. Barrierefreiheit betrifft am Ende alle.

Was mich in Gesprächen mit Kunden immer wieder überrascht: Viele wissen gar nicht, dass sie betroffen sind. Und die, die es wissen, denken, sie könnten das Problem irgendwann mal mit einem Plugin lösen. Das ist ungefähr so, als würde man versuchen, die Statik eines fertigen Hauses mit Klebeband zu reparieren.

Das Gesetz verweist auf die harmonisierte europäische Norm EN 301 549, die wiederum auf die Web Content Accessibility Guidelines (WCAG) 2.1 in der Konformitätsstufe AA verweist. Das ist der Standard, den man einhalten muss. Keine Empfehlung, kein Nice-to-have. Eine rechtliche Anforderung.

WCAG 2.1 AA umfasst vier Prinzipien: Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. Das klingt abstrakt, wird aber sehr konkret, wenn man die einzelnen Erfolgskriterien durchgeht. Textalternativen für Bilder. Untertitel für Videos. Ausreichende Farbkontraste — mindestens 4,5:1 für normalen Text, 3:1 für großen Text. Vollständige Bedienbarkeit per Tastatur. Konsistente Navigation. Fehlervermeidung in Formularen. Kompatibilität mit assistiven Technologien wie Screenreadern.

Insgesamt sind es 50 Erfolgskriterien auf AA-Stufe. Das ist keine Checkliste, die man mal eben an einem Nachmittag abhakt. Das ist ein grundlegendes Qualitätsmerkmal, das in die DNA einer Website eingebaut werden muss — von der Informationsarchitektur über das Design bis in den Code.

Ich sehe das regelmäßig bei Projekten, die zu uns kommen. Eine Website ist seit Jahren live, gebaut mit einem Page Builder in WordPress oder zusammengestückelt in TYPO3. Jetzt soll sie barrierefrei werden. Das Management hat von der neuen Gesetzeslage gehört, der Rechtsabteilung wird mulmig, und irgendwer soll das jetzt bitte schnell fixen.

Das Problem: Barrierefreiheit lässt sich nicht einfach obendrauf packen. Sie ist kein Feature, das man nachträglich aktiviert. Sie ist eine Eigenschaft der gesamten Architektur. Wenn das HTML-Fundament nicht semantisch ist, wenn die Heading-Hierarchie willkürlich gesetzt wurde, wenn interaktive Elemente keine entsprechenden ARIA-Attribute haben, wenn der Fokus-Flow nicht durchdacht ist — dann reicht es nicht, ein paar Alt-Texte hinzuzufügen und die Kontraste anzupassen.

Bei Page-Builder-Websites ist die Situation besonders heikel. Elementor, WPBakery, Divi — diese Tools erzeugen HTML-Strukturen, die für Screenreader oft ein Albtraum sind. Verschachtelte Div-Container ohne semantische Bedeutung. Buttons, die eigentlich Links sind. Modale Dialoge ohne Fokus-Trapping. Custom-Slider ohne Keyboard-Navigation. Das alles nachträglich zu reparieren, bedeutet im Grunde: Die Seite neu bauen.

Und das sage ich nicht, weil ich Websites verkaufen will — obwohl ich das natürlich auch tue. Ich sage das, weil ich es technisch beurteilen kann. Wenn der generierte Markup von einem Page Builder kommt, hat man als Entwickler kaum Kontrolle über die Ausgabe. Man kann CSS anpassen, aber nicht die DOM-Struktur. Und genau die ist entscheidend für Barrierefreiheit.

Es gibt einen ganzen Markt von Anbietern, die versprechen, Barrierefreiheit mit einer Zeile JavaScript zu lösen. AccessiBe, UserWay, EqualWeb — sie alle verkaufen sogenannte Accessibility Overlays. Ein Widget, das sich über die bestehende Website legt und Schriftgrößen anpasst, Kontraste verändert, angeblich Screenreader-Kompatibilität herstellt.

Das ist, diplomatisch ausgedrückt, Unsinn. Weniger diplomatisch: Es ist Schlangenöl.

Die National Federation of the Blind in den USA hat AccessiBe öffentlich kritisiert. Hunderte von Accessibility-Experten haben eine gemeinsame Erklärung gegen Overlay-Widgets unterschrieben. Der Grund: Diese Tools lösen nicht das zugrundeliegende Problem. Sie legen eine kosmetische Schicht über kaputten Code. Screenreader-Nutzer berichten regelmäßig, dass Overlay-Widgets ihre Nutzungserfahrung sogar verschlechtern, weil sie mit der eigentlichen assistiven Technologie interferieren.

Dazu kommt: Overlays bieten keinen rechtlichen Schutz. In den USA gab es bereits erfolgreiche Klagen gegen Unternehmen, die Overlay-Widgets eingesetzt hatten. Das Gericht befand, dass das Widget die Anforderungen der ADA nicht erfüllte. Es gibt keinen Grund anzunehmen, dass europäische Gerichte das anders sehen werden.

Wer seinen Kunden ein Overlay-Widget empfiehlt, handelt entweder aus Unwissenheit oder aus Bequemlichkeit. Beides ist keine gute Basis für eine Geschäftsbeziehung.

Barrierefreiheit beginnt nicht bei ARIA-Attributen. Sie beginnt bei semantischem HTML. Und damit bei einer Entscheidung, die viele Entwickler und Designer unbewusst treffen — oder eben nicht treffen.

Semantisches HTML bedeutet: Das richtige Element für den richtigen Zweck verwenden. Ein Button ist ein <button>, kein <div onclick>. Eine Navigation ist ein <nav>-Element. Ein Hauptinhaltsbereich ist <main>. Überschriften folgen einer logischen Hierarchie — h1, dann h2, dann h3, ohne Stufen zu überspringen.

Das klingt selbstverständlich. Ist es aber nicht. Ich habe in den letzten Jahren Dutzende von Websites auditiert, und in mindestens der Hälfte der Fälle war die Heading-Hierarchie kaputt. Oft werden h2 und h3 nach visuellem Gefühl vergeben — weil die h3 halt kleiner aussieht — und nicht nach semantischer Struktur. Das ist für sehende Nutzer kein Problem, für Screenreader-Nutzer aber eine Katastrophe, weil sie Überschriften als Navigationshilfe verwenden.

Semantisches HTML gibt dem Browser und assistiven Technologien die Informationen, die sie brauchen, um den Inhalt richtig zu interpretieren. Landmark-Roles wie <header>, <main>, <aside> und <footer> ermöglichen Screenreader-Nutzern, direkt zu bestimmten Seitenbereichen zu springen. Formulare mit korrekten <label>-Elementen, die per for-Attribut mit dem Eingabefeld verknüpft sind, machen den Unterschied zwischen benutzbar und unbenutzbar.

ARIA — Accessible Rich Internet Applications — ist eine Spezifikation, die es ermöglicht, zusätzliche Informationen an HTML-Elemente zu hängen. Ein aria-label beschreibt ein Element für Screenreader. aria-expanded zeigt an, ob ein Dropdown geöffnet oder geschlossen ist. aria-live informiert Screenreader über dynamische Änderungen auf der Seite.

ARIA ist mächtig. Aber es gibt eine goldene Regel in der Accessibility-Community: Kein ARIA ist besser als schlechtes ARIA. Wenn ein natives HTML-Element die gewünschte Funktion bereits bereitstellt, sollte man es verwenden. Ein <button> bringt Tastatur-Interaktion, Fokus-Management und Screenreader-Kompatibilität von Haus aus mit. Ein <div role="button" tabindex="0"> muss all das manuell implementiert werden — und wird in der Praxis fast nie vollständig umgesetzt.

ARIA ist für die Fälle gedacht, in denen natives HTML nicht ausreicht. Komplexe Widgets wie Tabs, Accordions, Autocomplete-Felder, Drag-and-Drop-Interfaces. Hier braucht es ARIA-Rollen, -Zustände und -Eigenschaften, um die Interaktion für assistive Technologien verständlich zu machen. Aber das setzt voraus, dass man weiß, was man tut. Falsches ARIA ist schlimmer als fehlendes ARIA, weil es falsche Informationen an den Screenreader liefert.

Ein Aspekt der Barrierefreiheit, der in Designprozessen fast nie vorkommt: Tastaturnavigation. Jedes interaktive Element einer Website muss per Tastatur erreichbar und bedienbar sein. Jedes. Ohne Ausnahme.

Das bedeutet: Wenn man die Tab-Taste drückt, sollte der Fokus in einer logischen Reihenfolge durch die Seite wandern. Links, Buttons, Formularfelder — alles muss ansteuerbar sein. Dropdown-Menüs müssen sich mit Enter öffnen und mit Escape schließen lassen. Modale Dialoge müssen den Fokus einfangen, damit der Nutzer nicht aus dem Dialog heraus-tabbt und in den Hintergrund gerät. Und wenn ein Dialog geschlossen wird, muss der Fokus zurück auf das Element springen, das den Dialog geöffnet hat.

Das ist keine exotische Anforderung. Menschen mit motorischen Einschränkungen, die keine Maus verwenden können, sind darauf angewiesen. Aber auch Power User, die lieber mit der Tastatur arbeiten, profitieren davon. Und Suchmaschinen-Crawler bewerten die Erreichbarkeit von Inhalten ebenfalls positiv.

Ein häufiges Problem: Der Fokus-Indikator wird per CSS unterdrückt. outline: none auf allen Elementen — weil der blaue Fokusring angeblich hässlich aussieht. Das ist so, als würde man die Stufen vor einem Gebäude entfernen, weil sie das Architektur-Rendering stören. Die Lösung ist nicht, den Fokusring zu entfernen, sondern ihn gut zu gestalten. Mit :focus-visible in CSS kann man den Fokusring nur dann anzeigen, wenn er per Tastatur ausgelöst wurde — nicht bei Mausklicks. Das ist der Kompromiss zwischen Design und Zugänglichkeit.

WCAG 2.1 AA fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt oder 14pt fett). Das klingt technisch, hat aber massive Auswirkungen auf das Webdesign. Hellgrauer Text auf weißem Grund, wie er in vielen modernen Designs beliebt ist? Fällt durch. Pastellfarbene Call-to-Action-Buttons? Oft zu wenig Kontrast. Platzhaltertext in Formularen als einzige Beschriftung? Doppelt problematisch — zu wenig Kontrast und keine persistente Beschriftung.

Ich empfehle Designern, Kontrastprüfungen in ihren Workflow einzubauen. Tools wie den Contrast Checker von WebAIM oder die eingebauten Accessibility-Tools in Figma. Jede Farbkombination im Design sollte geprüft werden, bevor sie in die Entwicklung geht. Nachträgliche Korrekturen bedeuten immer Mehraufwand und Diskussionen über die Brand Identity.

Und noch etwas: Farbe darf nicht das einzige Mittel sein, um Informationen zu vermitteln. Ein Formularfeld, das bei Fehleingabe nur rot umrandet wird, ist für farbenblinde Nutzer nicht erkennbar. Es braucht zusätzlich ein Icon, einen Text, eine Positionsänderung — irgendetwas, das die Information auch ohne Farbe transportiert. Rund 8 Prozent aller Männer haben eine Farbfehlsichtigkeit. Das ist keine Randgruppe.

Hier kommt die Technologieentscheidung ins Spiel. Und hier wird es für mich als Agenturinhaber persönlich. Wir setzen bei happycoding auf Next.js mit React-Komponenten und Tailwind CSS. Nicht weil es hip ist — obwohl es das auch ist — sondern weil diese Architektur Barrierefreiheit strukturell unterstützt.

In einer komponentenbasierten Architektur baut man einen Button einmal. Mit korrektem semantischem HTML, mit Tastatur-Events, mit ARIA-Attributen, mit Fokus-Styling. Dieser Button wird dann überall in der Anwendung verwendet. Wenn man ihn verbessert, verbessert sich die gesamte Anwendung. Wenn man einen Accessibility-Bug in der Komponente fixt, ist er überall gefixt.

Vergleich das mal mit einem WordPress-Page-Builder, wo jeder Button ein individuelles HTML-Konstrukt ist, zusammengesetzt aus den Modulen des Builders. Da gibt es keine zentrale Stelle, an der man Accessibility-Verbesserungen einbauen kann. Jede Seite, jedes Modul, jeder Block muss einzeln angefasst werden. Bei einer Website mit 50 Seiten und hunderten von interaktiven Elementen ist das ein Fass ohne Boden.

Next.js bringt einige Features mit, die Accessibility direkt unterstützen. Der eingebaute ESLint-Plugin eslint-plugin-jsx-a11y prüft automatisch auf häufige Accessibility-Fehler im JSX-Code. Fehlende Alt-Texte, falsche ARIA-Attribute, nicht-interaktive Elemente mit Click-Handlern — all das wird direkt im Editor als Warnung angezeigt, noch bevor der Code committed wird.

Dazu kommt die Möglichkeit, TypeScript-Typen für ARIA-Props zu nutzen. Wenn eine Komponente ein aria-label erwartet, kann man das als Required-Prop definieren. Die Komponente lässt sich dann gar nicht verwenden, ohne dass ein Label angegeben wird. Das verschiebt Accessibility von der Disziplin in die Architektur — es ist nicht mehr möglich, es zu vergessen.

Auch das Routing in Next.js unterstützt Barrierefreiheit. Bei Single-Page-Applications ist es ein bekanntes Problem, dass Seitenwechsel von Screenreadern nicht angekündigt werden. Next.js handhabt Route-Announcements automatisch — bei jedem Seitenwechsel wird der neue Seitentitel an assistive Technologien kommuniziert. Das klingt nach einem Detail, aber für Screenreader-Nutzer ist es der Unterschied zwischen einer benutzbaren und einer verwirrenden Navigation.

Headless CMS wie Sanity, das wir bei happycoding einsetzen, trennen Inhalt von Darstellung. Das gibt Entwicklern die volle Kontrolle über das Frontend-Markup. Kein CMS-generierter HTML-Müll, keine fest verdrahteten CSS-Klassen, keine eingeschränkten Template-Engines. Jedes HTML-Element kann exakt so ausgegeben werden, wie es semantisch korrekt ist. Diese Kontrolle ist der Schlüssel zu nachhaltiger Barrierefreiheit.

Ich weiß, dass in vielen B2B-Unternehmen das Argument Barrierefreiheit allein nicht ausreicht, um Budget freizubekommen. Also reden wir über Zahlen und Geschäftsvorteile.

Erstens: Rechtliche Compliance. Die Marktüberwachungsbehörden können bei Verstößen gegen das Barrierefreiheitsstärkungsgesetz Bußgelder verhängen. Die genaue Höhe ist noch nicht abschließend definiert, aber die Richtlinie sieht vor, dass Sanktionen wirksam, verhältnismäßig und abschreckend sein müssen. In anderen EU-Ländern gibt es bereits Bußgeldkataloge, die bei mehreren zehntausend Euro beginnen. Dazu kommen potenzielle Abmahnungen und Unterlassungsklagen von Wettbewerbern oder Verbraucherschutzverbänden.

Zweitens: SEO. Google bewertet Accessibility-Faktoren als Teil der User Experience. Semantisches HTML, klare Überschriftenstruktur, Alt-Texte für Bilder, schnelle Ladezeiten, mobile Optimierung — all das sind gleichzeitig Accessibility- und SEO-Faktoren. Eine barrierefreie Website rankt tendenziell besser als eine nicht barrierefreie. Nicht weil Google explizit Accessibility misst, sondern weil die gleichen technischen Qualitätsmerkmale beiden Zielen dienen.

Drittens: Reichweite. In Deutschland leben rund 13 Millionen Menschen mit einer anerkannten Behinderung, dazu kommen temporäre und situative Einschränkungen. Im B2B-Kontext bedeutet das: Der Einkäufer mit Sehbehinderung, die Projektmanagerin mit Karpaltunnelsyndrom, der CTO, der Ihre Website abends auf dem Tablet mit müden Augen durchgeht. Wenn Ihre Website für diese Menschen nicht funktioniert, verlieren Sie potenzielle Kunden — ohne es je zu erfahren.

Viertens: Qualitätssignal. Im B2B-Geschäft zählt Vertrauen. Eine barrierefreie Website signalisiert technische Kompetenz und gesellschaftliche Verantwortung. Wenn Ihre Wettbewerber es nicht machen, ist es ein Differenzierungsmerkmal. Wenn Ihre Wettbewerber es machen und Sie nicht, ist es ein Nachteil.

Ich war sechs Jahre in einer Werbeagentur, bevor ich happycoding gegründet habe. Ich kenne die Branche. Und ich weiß, warum die meisten Agenturen Accessibility nicht auf dem Schirm haben.

Es ist aufwändig. Es erfordert technisches Verständnis. Und es lässt sich schwer verkaufen, weil der Nutzen nicht sofort sichtbar ist. Kein Stakeholder sagt nach einem Relaunch: Wow, die Heading-Hierarchie ist perfekt. Aber alle sagen: Die Animationen sind toll, die Bilder sind groß, das sieht modern aus.

Viele Agenturen arbeiten mit WordPress und Page Buildern, weil die Margen stimmen. Template kaufen, anpassen, Content reinschütten, fertig. In diesem Modell ist Barrierefreiheit ein Störfaktor. Sie erfordert Custom Development, HTML-Kontrolle, Testing — alles Dinge, die Zeit und Geld kosten und die Marge drücken.

Dazu kommt: Viele Webdesigner haben Accessibility nie gelernt. Es ist kein Standardthema in Designausbildungen. Und in den meisten Agenturprozessen gibt es keinen Schritt, in dem die Barrierefreiheit systematisch geprüft wird. Es gibt ein Design-Review, ein Code-Review, ein Content-Review — aber selten ein Accessibility-Review.

Das ändert sich gerade. Nicht weil Agenturen plötzlich ihr soziales Gewissen entdecken, sondern weil das Gesetz sie dazu zwingt. Und weil Unternehmen anfangen, danach zu fragen. Der Druck kommt von beiden Seiten — von der Regulierung und vom Markt.

Wenn Sie vor einem Website-Relaunch stehen oder eine neue digitale Plattform planen, ist jetzt der richtige Zeitpunkt, Barrierefreiheit von Anfang an mitzudenken. Nicht als separates Projekt, sondern als integraler Bestandteil des Entwicklungsprozesses.

Beginnen Sie mit dem Farbsystem. Definieren Sie Farbkombinationen, die die WCAG-Kontrastanforderungen erfüllen. Nutzen Sie Tools wie den Stark-Plugin für Figma, um Kontraste direkt im Designprozess zu prüfen. Planen Sie Ihre Typografie mit ausreichenden Schriftgrößen — 16px als Mindestgröße für Fließtext. Definieren Sie eine klare Heading-Hierarchie, die visuell und semantisch konsistent ist. Denken Sie Interaktionszustände mit: Hover, Fokus, Active, Disabled. Und planen Sie Fehlerzustände in Formularen so, dass sie auch ohne Farbe verständlich sind.

Setzen Sie auf eine komponentenbasierte Architektur. Bauen Sie eine Component Library, in der jede Komponente von Grund auf barrierefrei ist. Verwenden Sie semantisches HTML als Basis. Implementieren Sie Tastatur-Events und Fokus-Management in jeder interaktiven Komponente. Nutzen Sie eslint-plugin-jsx-a11y und integrieren Sie automatisierte Accessibility-Tests in Ihre CI/CD-Pipeline. Tools wie axe-core von Deque können als Teil Ihrer Teststrategie automatisiert WCAG-Verletzungen finden — sie decken zwar nur etwa 30 bis 40 Prozent aller möglichen Probleme ab, aber sie fangen die offensichtlichsten Fehler ab, bevor sie in Produktion gehen.

Automatisierte Tests sind notwendig, aber nicht ausreichend. Manuelle Tests gehören dazu. Navigieren Sie Ihre Website einmal komplett nur mit der Tastatur. Testen Sie mit einem Screenreader — VoiceOver auf dem Mac, NVDA auf Windows. Lassen Sie die Website von Menschen mit unterschiedlichen Einschränkungen testen, wenn möglich. Und wiederholen Sie diese Tests regelmäßig, nicht nur vor dem Launch. Barrierefreiheit ist kein Projekt mit Enddatum. Sie ist ein fortlaufender Qualitätsanspruch.

Barrierefreiheit endet nicht mit dem Code. Jedes Bild braucht einen sinnvollen Alt-Text — nicht einfach den Dateinamen, sondern eine Beschreibung, die den Informationsgehalt des Bildes transportiert. Dekorative Bilder bekommen ein leeres Alt-Attribut. Videos brauchen Untertitel und idealerweise eine Audiodeskription. Dokumente zum Download — PDFs, Präsentationen — müssen ebenfalls barrierefrei sein. Das wird oft vergessen: Das beste barrierefreie Frontend nützt nichts, wenn die verlinkten PDFs nicht mit einem Screenreader gelesen werden können.

Ein Headless CMS wie Sanity kann hier helfen, indem es Alt-Text-Felder als Pflichtfelder definiert und Redakteuren Hinweise gibt, was einen guten Alt-Text ausmacht. Die Technologie kann den Prozess unterstützen, aber die Verantwortung liegt bei den Menschen, die den Content pflegen.

Ein Punkt, der selten im Zusammenhang mit Barrierefreiheit diskutiert wird: die Infrastruktur. Wir hosten unsere Projekte auf Hetzner mit Coolify und Docker. Selbstgehostet, kein Vendor-Lock-in. Warum ist das relevant?

Weil Barrierefreiheit auch mit Performance zu tun hat. WCAG 2.1 fordert unter anderem, dass Inhalte auch bei langsamer Internetverbindung zugänglich bleiben. Websites, die auf überdimensionierten Cloud-Stacks laufen und bei jedem Request drei Sekunden brauchen, sind für Menschen mit assistiven Technologien besonders problematisch — Screenreader müssen warten, bis das DOM vollständig geladen ist, bevor sie den Inhalt vorlesen können.

Mit Next.js und Server-Side Rendering bekommt der Browser sofort vollständiges HTML. Kein leerer Body, der erst durch JavaScript befüllt wird. Kein Skeleton-Loader, der einen Screenreader verwirrt. Der Inhalt ist sofort da, semantisch korrekt und für assistive Technologien lesbar. Das ist ein struktureller Vorteil gegenüber reinen Client-Side-Rendering-Ansätzen.

Und mit einer kontrollierten Infrastruktur — ob Hetzner, ein anderer europäischer Hoster oder ein eigener Server — behalten Sie die volle Kontrolle über Caching, Kompression, CDN-Konfiguration und Response-Times. Keine magischen Optimierungen eines Cloud-Anbieters, die Sie nicht verstehen. Keine plötzlichen Preiserhöhungen, die Ihr Hosting-Budget sprengen. Keine Abhängigkeit von einem Ökosystem, das morgen seine Preise verdoppelt.

Barrierefreiheit ist kein Thema für die IT-Abteilung allein. Es ist eine strategische Entscheidung. Sie betrifft Design, Entwicklung, Content, Recht und Geschäftsführung. Wenn der CTO allein dafür verantwortlich gemacht wird, wird es nicht funktionieren — weil Barrierefreiheit auch Designänderungen, Contentvorgaben und Budgetentscheidungen erfordert.

Mein Rat an CTOs und Produktmanager in mittelständischen B2B-Unternehmen: Macht Barrierefreiheit zur Anforderung in eurem nächsten Briefing. Nicht als optionalen Punkt unter ferner liefen, sondern als harte Anforderung neben Performance, SEO und Responsive Design. Fragt eure Agentur, wie sie Accessibility umsetzt. Fragt nach ihrer Teststrategie. Fragt nach konkreten WCAG-Kriterien. Wenn die Antwort ein Overlay-Widget oder betretenes Schweigen ist, sucht euch eine andere Agentur.

Die Technologie ist da. Das Wissen ist da. Die rechtliche Pflicht ist da. Was fehlt, ist der Wille, es richtig zu machen. Barrierefreiheit ist keine Bürde. Sie ist ein Qualitätsmerkmal. Und Qualität war schon immer das Argument, das im B2B den Unterschied macht.

Wer heute eine Website plant, ohne Barrierefreiheit von Anfang an einzubauen, baut technische Schulden auf. Schulden, die mit jedem neuen Feature, jeder neuen Seite, jedem neuen Content-Update wachsen. Und die irgendwann teurer zu beheben sind als ein kompletter Relaunch. Planen statt nachrüsten. Das ist der einzige Weg, der langfristig funktioniert.