Accessibility Testing: So prüfen Unternehmen ihre Website auf Barrierefreiheit und erkennen, wann ein Audit sinnvoll ist

Bevor wir in die Testing-Praxis einsteigen, kurz zum rechtlichen Rahmen, denn nicht jede Website ist automatisch betroffen. Das BFSG setzt den European Accessibility Act (EAA) in deutsches Recht um und gilt für Produkte und Dienstleistungen, die ab dem 28. Juni 2025 in Verkehr gebracht oder für Verbraucher:innen erbracht werden.

Für Websites bedeutet das konkret: Erfasst sind in der Regel die Seiten, über die Dienstleistungen für Verbraucher:innen angeboten werden. Dazu gehören also vor allem Online-Shops, Online-Marktplätze, Online-Banking, Online-Terminbuchungen oder Buchungsplattformen. Reine Informations- oder Präsentationswebseiten und reine B2B-Angebote sind laut Bundesfachstelle Barrierefreiheit in der Regel nicht betroffen.

Auch wichtig: Es gibt eine Kleinstunternehmen-Ausnahme für Dienstleistungen. Wer weniger als zehn Beschäftigte hat und maximal zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme erreicht, kann von der Pflicht ausgenommen sein. Für Produkte gilt diese Erleichterung allerdings nicht.

Unser Tipp: Auch wenn Webseiten formal nicht unter das BFSG fallen, lohnt sich Barrierefreiheit. Sie ist kein Nice-to-have, sondern verbessert Reichweite, SEO und Conversion gleichermaßen. In den nächsten Jahren wird der Anwendungsbereich tendenziell wachsen, nicht schrumpfen.

Das BFSG sagt: Digitale Dienstleistungen müssen „barrierefrei“ sein. Aber was heißt das technisch? Die Bundesfachstelle Barrierefreiheit verweist hier auf die harmonisierte europäische Norm EN 301 549. Die wiederum stützt sich auf die international anerkannten Web Content Accessibility Guidelines (WCAG).

Hier wird es kurz technisch, aber wichtig: Die aktuell harmonisierte Version der EN 301 549 ist weiterhin V3.2.1. Sie verweist auf die WCAG 2.1 in den Konformitätsstufen A und AA. WCAG 2.2 wurde am 5. Oktober 2023 als W3C-Empfehlung veröffentlicht und ergänzt WCAG 2.1 um neun zusätzliche Erfolgskriterien. Die nächste Fassung der EN 301 549 wird diese Anforderungen voraussichtlich aufnehmen und damit den europäischen Barrierefreiheitsstandard an WCAG 2.2 angleichen.

Rechtlich verbindlich wird WCAG 2.2 jedoch erst, wenn die entsprechende Fassung der EN 301 549 im Amtsblatt der Europäischen Union referenziert ist. Bis dahin bleibt WCAG 2.1 AA der offizielle Maßstab der harmonisierten Norm.

Praktisch heißt das: Wer digitale Angebote aktuell gegen WCAG 2.1 AA prüft, orientiert sich am geltenden Standard und ist in vielen Fällen gut aufgestellt. Wer zukunftssicher prüfen möchte, berücksichtigt zusätzlich bereits heute die neun neuen Erfolgskriterien aus WCAG 2.2. So lassen sich mögliche Anpassungen frühzeitig einplanen und spätere Nachbesserungen reduzieren.

Egal ob man selbst testet oder ein Audit beauftragt: Die WCAG strukturieren Barrierefreiheit nach vier Grundprinzipien. Wer sie kennt, weiß auch ungefähr, wo eine Website hakt.

• Wahrnehmbar: Inhalte müssen so dargestellt werden, dass alle Sinne sie aufnehmen können. Klassische Fragen: Haben Bilder Alternativtexte? Sind Farbkontraste ausreichend? Gibt es Untertitel zu Videos?
• Bedienbar: Jede Funktion muss erreichbar sein, nicht nur per Maus. Lässt sich die Seite vollständig per Tastatur navigieren? Sind Klickflächen groß genug? Wird der Fokus klar dargestellt?
• Verständlich: Sprache, Strukturen und Interaktionen müssen nachvollziehbar sein. Sind Texte einfach formuliert? Sind Formulare verständlich beschriftet? Werden Fehler erklärt?
• Robust: Der Code muss so sauber sein, dass auch assistive Technologien (Screenreader, Spracheingaben) damit umgehen können. Hier kommen semantisches HTML, ARIA-Attribute und valide Strukturen ins Spiel.

Diese vier Prinzipien sind die Brille, durch die alle WCAG-Erfolgskriterien geschrieben sind.

Unternehmen müssen nicht auf ein Audit warten, um erste Schwachstellen zu finden. Mit ein paar Handgriffen bekommen sie in 30 Minuten ein erstes Gefühl dafür, wo ihre Website steht. Die Bundesfachstelle Barrierefreiheit empfiehlt für diesen Einstieg unter anderem Schnelltests und freie Tools. Wichtig zu wissen: Diese Tests liefern nur einen ersten Eindruck, keinen vollständigen Befund.

Ein einfacher Praxistest zeigt schnell, ob Tastaturnavigation und Fokus-Management funktionieren: Dafür wird zunächst in die Adressleiste geklickt und anschließend ausschließlich mit Tab, Shift+Tab, Enter und den Pfeiltasten navigiert. Sind alle relevanten Elemente erreichbar? Ist jederzeit sichtbar, welches Element gerade den Fokus hat? Lassen sich Menüs öffnen, Formulare ausfüllen und der Warenkorb vollständig durchklicken? Dieser Test deckt häufig bereits in wenigen Minuten auf, ob zentrale Anforderungen an die Bedienbarkeit erfüllt sind.

Auf Windows lässt sich der kostenlose, quelloffene Screenreader NVDA in wenigen Minuten installieren. Spätestens beim ersten Durchhören wird deutlich, ob Überschriften logisch verschachtelt sind, ob Bilder sinnvolle Alternativtexte tragen und ob Formularfelder verständlich angesagt werden. Für PDFs eignet sich zusätzlich PAC (PDF Accessibility Checker).

Drei Tools, die schnell installiert und direkt im Browser einsetzbar sind:

• Lighthouse ist in Chrome integriert (DevTools → Lighthouse → Accessibility) und liefert in unter einer Minute einen Score und konkrete Hinweise.
• axe DevTools von Deque ist eine Browser-Extension, die deutlich detailliertere Reports erzeugt und sich gut für Entwickler:innen eignet.
• WAVE zeigt grafisch direkt auf der Seite an, wo Probleme stecken. Das ist ideal für einen schnellen Überblick.

Ergänzend bietet die Initiative BIK für Alle einen BITV-Schnelltest, mit dem man zehn ausgewählte Anforderungen auch ohne tiefes Technik-Wissen prüfen kann.

• Die Seite auf 200 Prozent zoomen: Bleibt sie lesbar und bedienbar?
• Die Farbkontraste mit einem Contrast-Checker prüfen.
• Die Texte laut vorlesen: Sind sie verständlich und sinnvoll formuliert?
• Die Link-Texte prüfen: Sind sie aussagekräftig oder steht an vielen Stellen nur „Hier klicken“?

So entsteht bereits nach kurzer Zeit eine Liste mit Quick Wins. Dabei handelt es sich um Punkte, die häufig direkt im CMS oder mit kleineren Anpassungen im Frontend behoben werden können.

Wenn nach dem Selbsttest Unsicherheit besteht, ob eine Website grundsätzlich BFSG-tauglich ist, ist ein Quick Check der nächste sinnvolle Schritt. Dabei prüft ein:e Expert:in eine begrenzte Auswahl repräsentativer Seiten, zum Beispiel die Startseite, eine Produktseite, den Checkout oder ein Formular. Anschließend folgt eine erste fachliche Einschätzung.

Der Vorteil: Der Aufwand für Zeit und Budget bleibt überschaubar, gleichzeitig entstehen konkrete Aussagen dazu, ob sich ein vollständiges Audit lohnt und wo die größten Hebel liegen. Für viele kleinere und mittlere Websites ist das eine gute Entscheidungsgrundlage. Marktübliche Preise für solche Checks beginnen häufig im niedrigen vierstelligen Bereich, die genaue Höhe hängt jedoch stark vom Umfang ab.

Ein Quick Check ersetzt kein vollständiges Audit, verhindert aber, dass Unternehmen ohne klare Prioritäten ins Detail gehen.

Hier kommen wir zum Goldstandard: dem vollständigen Accessibility Audit. Während automatisierte Tests Symptome zeigen, legt ein Audit die Ursachen offen, priorisiert Maßnahmen und gibt einen klaren Fahrplan.

Ein Audit folgt einem strukturierten Prozess, der typischerweise drei große Phasen umfasst.

In der Analysephase prüfen Expert:innen alle relevanten WCAG-Erfolgskriterien systematisch über Code, Design und Inhalte hinweg – mit einer Kombination aus automatisierten Tools, manuellem Testing, Tastatur- und Screenreader-Prüfungen sowie Bewertung der Inhalte. Geprüft wird nicht „die Website“ als Ganzes, sondern repräsentative Seitentypen, kritische User Journeys (Login, Checkout, Suche, Formulare) und übergreifende Komponenten.

In der optionalen Nutzertest-Phase kommen reale Nutzer:innen mit unterschiedlichen Beeinträchtigungen ins Spiel. Hier zeigt sich, ob ein Formular zwar formal WCAG-konform ist, aber in der Praxis trotzdem stolpern lässt.

In der Reporting-Phase entsteht ein Dokument, das jede gefundene Barriere beschreibt, nach Schweregrad priorisiert und konkrete Lösungsvorschläge liefert. Gute Audits hören nicht beim „Was ist falsch?“ auf, sondern beantworten auch das „Was tun wir zuerst?“.

Drei Konstellationen, in denen wir aus unserer Erfahrung klar zum Audit raten:

• Wenn Websites unter das BFSG fallen und eine belastbare Grundlage für die nötigen Anpassungen gebraucht wird. Sie wird am besten dokumentiert, um bei einer Prüfung durch die MLBF nicht ohne Argumente dazustehen.
• Wenn größere Relaunch- oder Migrationsentscheidungen getroffen werden. Es ist deutlich günstiger, Barrierefreiheit von Anfang an mitzudenken, als sie später nachzurüsten.
• Wenn Unternehmen in einem stark regulierten oder reputationskritischen Umfeld unterwegs sind, etwa im Banking, im Gesundheitsbereich, in der öffentlichen Verwaltung oder bei großen Plattformen mit hoher Sichtbarkeit. Hier wird Accessibility schnell auch zum Risikomanagement-Thema.

Das ist die ehrlichste Stelle dieses Artikels: Automatisierte Tools sind wichtig, aber sie sind nur die halbe Miete. Eine viel zitierte Deque-Studie auf Basis von über 2.000 Audits, mehr als 13.000 geprüften Seiten und rund 300.000 erfassten Problemen kam zu dem Ergebnis, dass automatisierte axe-Tests im Durchschnitt rund 57 Prozent der gefundenen Probleme abdecken können. Das ist deutlich mehr als die früher oft genannten 20 bis 30 Prozent. Es bedeutet aber eben auch, dass 43 Prozent der Probleme unsichtbar bleiben, wenn ausschließlich automatisiert getestet wird.

Was Tools systematisch nicht zuverlässig prüfen können:

• Ob ein Alternativtext inhaltlich sinnvoll ist. Ein Tool sieht nur, dass eines vorhanden ist.
• Ob die Reihenfolge der Tastatur-Navigation logisch ist. Formal kann sie korrekt sein, gefühlt trotzdem chaotisch.
• Ob ein Formularfehler verständlich beschrieben wird.
• Ob das Zusammenspiel mit Screenreadern in der Praxis funktioniert.
• Ob komplexe Interaktionen wie Drag-and-Drop, modale Dialoge oder dynamisch nachgeladene Inhalte für Nutzer:innen wirklich bedienbar sind.

Genau diese Lücken schließt ein Audit mit menschlicher Prüfung, echten Hilfstechnologien und nutzerzentriertem Blick.

Auch wenn die neue EN 301 549 V4.1.1 mit WCAG 2.2 erst sukzessive verbindlich wird, lohnt sich der Blick auf die neuen Erfolgskriterien jetzt schon. Sie schließen Lücken, die in der Praxis besonders Menschen mit motorischen oder kognitiven Einschränkungen betreffen. Vier davon sind in Audits besonders häufig Thema:

Focus Not Obscured (2.4.11): Wenn ein Element den Fokus erhält, darf es nicht komplett von Cookie-Banner, Sticky-Header oder Chat-Widget verdeckt werden. Klingt banal, ist im Alltag aber ein Klassiker.

Dragging Movements (2.5.7): Funktionen, die per Ziehen bedient werden (Slider, Drag-and-Drop), brauchen eine alternative Bedienung über einen einzelnen Klick oder eine Tastatur.

Target Size (2.5.8): Klickflächen müssen mindestens 24×24 CSS-Pixel groß sein (mit Ausnahmen). Wer mobil entwickelt, sollte hier ohnehin nicht knausern.

Accessible Authentication (3.3.8): Login-Prozesse dürfen keine reinen kognitiven Tests verlangen. Passwortmanager, Passkeys, Copy-and-Paste müssen funktionieren, CAPTCHAs, die nur auf Erinnerung setzen, sind tabu.

Wer heute eine Seite testet oder neu baut, sollte diese vier Kriterien immer mitprüfen. Sie sind oft mit wenig Aufwand umsetzbar und ersparen später teure Nacharbeiten.

Als IT-Dienstleister entwickeln wir seit über 20 Jahren Software für mittelständische Unternehmen und internationale Konzerne. Accessibility ist für uns kein Add-on am Ende eines Projekts, sondern Teil unserer Arbeitsweise und getragen vom Prinzip „Security & Accessibility by Design“.

Konkret heißt das bei uns: Wir denken Barrierefreiheit von Anfang an mit, vom UX-Konzept über Komponentenbibliotheken bis zum sauberen, semantischen Code. In der Architektur- und Code-Review prüfen unsere Expert:innen auch Aspekte der digitalen Zugänglichkeit, statt sie erst am Schluss nachzuziehen.

Wir kombinieren automatisierte Tests in unseren CI/CD-Pipelines mit manuellem Testing, inklusive Tastatur-, Screenreader- und Kontrast-Prüfungen. Mit unserem UX-Partner UID auch mit echter Nutzerforschung, wenn das Projekt es erfordert.

Und wir sind ehrlich: Barrierefreiheit ist keine einmalige Aktion, sondern ein Prozess. Jede neue Funktion, jeder Relaunch, jedes Update kann Barrieren bringen. Deshalb empfehlen wir, Accessibility-Tests in den regulären Entwicklungs- und Release-Zyklus zu integrieren, statt einmal im Jahr nervös zu werden.

Accessibility Testing ist kein Bonustrack mehr, sondern Pflichtprogramm – seit dem 28. Juni 2025 nicht nur ethisch oder strategisch, sondern auch rechtlich. Die gute Nachricht: Unternehmen können sofort anfangen. Mit Tastatur, Screenreader und ein paar kostenlosen Tools bekommt man in einer halben Stunde ein erstes Bild davon, wo eine Website steht.

Die ehrlichere Nachricht: Automatisierte Tests zeigen Symptome, aber sie zeigen sie nicht alle. Ein Accessibility Audit zeigt Ursachen, priorisiert Maßnahmen und macht aus einem unübersichtlichen Thema einen klaren Fahrplan. Was richtig für ein Unternehmen ist, hängt von Größe, Branche und rechtlicher Betroffenheit ab, aber der Weg ist immer derselbe: Erst orientieren, dann gezielt prüfen, dann strukturiert umsetzen.

Und das Beste daran: Eine barrierefreie Website ist fast immer auch die bessere Website. Das gilt für Suchmaschinen, für Conversion, und vor allem für die Menschen, die sie benutzen.

Klingt nach Deinem Thema? Wenn Du wissen willst, wo Deine Website heute steht, und wie ein passender nächster Schritt aussehen kann, melde Dich gerne. Wir schauen gemeinsam, ob ein Quick Check, ein vollständiges Audit oder eine Integration von Accessibility in Euren Entwicklungsprozess für Euch sinnvoll ist.