// audit · bfsg
Du willst deine Website auf Barrierefreiheit prüfen — und ein grünes Scanner-Ergebnis beruhigt dich nicht? Zu Recht. siteway testet Tastaturbedienung, Screenreader, Kontraste und Fokus nach WCAG 2.2 und BFSG — mit echten Hilfsmitteln, nicht nur mit einem Tool. Heraus kommt ein Report, der sagt, was zuerst zu tun ist.
// definition
Ein Barrierefreiheits-Audit ist die Prüfung einer bestehenden Website auf digitale Barrieren — nach WCAG 2.2 und den Anforderungen des BFSG. Geprüft werden Tastaturbedienung, Screenreader-Ausgabe, Kontraste, Fokus, Formulare, Zoom und Medien. Nicht auf Verdacht, sondern Kriterium für Kriterium.
Der Unterschied zu einem kostenlosen Accessibility-Check: Ein Tool zeigt dir eine Liste mit Fehlern und eine Punktzahl. Wir sagen dir, welche Barriere wen ausschließt, wie schwer sie wiegt und in welcher Reihenfolge du sie abarbeitest. Heraus kommt der a11y-befund — priorisierte Befunde mit Aufwand und Wirkung. Wer ihn umsetzt, entscheidest du.
// anlass
erst prüfen, dann bauen
Der teuerste Weg zu einer barrierefreien Website ist Raten. Ein Overlay-Widget einbauen, ein paar Alternativtexte nachtragen, die Schrift vergrößern — und danach ist die Seite für einen Screenreader genauso unbedienbar wie vorher, nur das Budget ist weg. Das Audit dreht die Reihenfolge um: erst wissen, welche Barrieren existieren, dann Geld ausgeben.
Typischer Anlass ist eine Frage, die niemand belegen kann. Seit dem 28. Juni 2025 gilt das BFSG, die Geschäftsführung fragt „sind wir konform?", die Agentur sagt „unser Tool zeigt 98 von 100" — und niemand hat je versucht, das Kontaktformular mit der Tastatur auszufüllen. Genau hier liefert das Audit die Belege, mit denen die Diskussion endet. Was danach umgesetzt werden muss, steht bei der Leistung Barrierefreiheit.
// prüfung · 6 felder
jedes feld ein befund
Sechs Felder, in denen Barrierefreiheit entschieden wird. Jedes prüfen wir am Gerät: Tastatur in der Hand, Screenreader an, Kontrastmesser offen, Browser auf 200 % gezoomt. Ein Scanner läuft vorher — er liefert die Breite, nicht das Urteil.
// p-01tastatur
Die ganze Seite ohne Maus: Tab, Enter, Escape, Pfeiltasten. Menüs, Dialoge, Slider, Cookie-Banner. Häufigster Befund sind Tastaturfallen — ein Overlay öffnet sich, und der Fokus kommt nicht mehr heraus.
befund: durchlauf je prozess
// p-02screenreader
Durchlauf mit NVDA unter Windows und VoiceOver unter macOS. Wir hören zu: Überschriften-Hierarchie, Landmarks, Alternativtexte, Tabellen, ARIA-Rollen, Live-Regionen. Vieles wird vorgelesen — die Frage ist, ob es auch verständlich ist.
befund: ausgabe-protokoll
// p-03kontrast
Gemessene Werte gegen die WCAG-Schwellen: 4,5:1 für Text, 3:1 für große Schrift, Bedienelemente und Grafiken. Inklusive der Zustände, die jeder vergisst — Hover, Fokus, Disabled, Platzhaltertext, Text auf Bild.
befund: messwerte je element
// p-04fokus
Ist der Fokus sichtbar oder wegdesignt? Verdeckt ihn der Sticky-Header? Folgt die Tab-Reihenfolge der Leserichtung, springt der Fokus beim Öffnen eines Dialogs hinein und danach zurück? WCAG 2.2 hat hier neue Kriterien.
befund: fokus-pfad + lücken
// p-05formulare
Labels, Pflichtfelder, Autocomplete, Fehlertexte. Die harte Frage: Kommt ein Fehler auch an, wenn du das rote Rähmchen nicht siehst? Formulare sind die Stelle, an der ein Kontakt, eine Buchung oder ein Kauf scheitert.
befund: feld für feld
// p-06zoom · medien
200 % Zoom und 400 % Vergrößerung: Bleibt alles lesbar und bedienbar, ohne horizontal zu scrollen? Dazu Autoplay und Animationen, Untertitel und Transkripte bei Video und Audio.
befund: reflow + medien-check
// mehrwert
tools zählen, menschen urteilen
Wer „Barrierefreiheit prüfen" sucht, findet ein Dutzend kostenloser Checker. Sie liefern alle dasselbe: eine Fehlerliste und eine Punktzahl. Die Liste stimmt sogar — sie ist nur unvollständig, und sie sagt dir nicht, womit du anfangen sollst.
Wie groß der maschinell messbare Teil ist, zeigt die WebAIM Million 2026, eine automatisierte Auswertung von einer Million Startseiten: Auf 95,9 % der Seiten fanden die Tools WCAG-Verstöße, im Schnitt 56,1 pro Seite. Sechs Fehlertypen machen dabei rund 96 % aller gefundenen Fehler aus — sie stehen rechts.
Und genau das ist der Punkt: Das sind die Fehler, die eine Maschine erkennen kann. Ob der Alternativtext das Bild beschreibt, ob die Tab-Reihenfolge der Leserichtung folgt, ob eine Fehlermeldung im Screenreader ankommt, ob ein Dialog den Fokus wieder freigibt — das prüft kein Tool. Deshalb läuft der Scanner bei uns zuerst, und danach fängt die Arbeit an.
// output
der report gehört dir
Ein Dokument, das eine fremde Entwicklungsabteilung ohne Rückfragen abarbeiten kann. Kein Score, keine Ampel ohne Erklärung — sondern je Barriere: Was ist kaputt, wen schließt es aus, welches WCAG-Kriterium ist verletzt, wo im Code steht es, was ist zu tun. Dazu ein Termin, in dem wir den a11y-befund durchgehen.
// r-01befunde
Jede Barriere mit Screenshot, Code-Stelle und dem verletzten WCAG-Kriterium — sortiert danach, wie viele Menschen sie ausschließt. Oben steht der Blocker, nicht der Schönheitsfehler.
liste, nach wirkung sortiert
// r-02bewertung
Zu jeder Maßnahme eine ehrliche Schätzung: eine Stunde CSS oder zwei Wochen Umbau der Komponente. Viele Barrieren stecken in einer Vorlage — eine Korrektur, hundert Seiten repariert.
schätzung je maßnahme
// r-03nächste schritte
To-dos mit Adressat: Was Design ist, was Entwicklung, was die Redaktion selbst erledigt — etwa Alternativtexte und Linktexte. Formuliert so, dass du den Punkt einfach weiterleiten kannst.
to-dos je adressat
// ablauf · 4 schritte
5–10 werktage bis zum befund
// schritt 01 · briefing
Welche Seitentypen, welche Prozesse — Formular, Suche, Login, Kauf. Wir wählen eine repräsentative Auswahl statt jeder Unterseite. Danach steht der Festpreis.
output: scope + festpreis
// schritt 02 · scan
Der Scanner läuft über alle ausgewählten Seiten und liefert die Breite: Kontraste, fehlende Labels, fehlende Alternativtexte, Sprachauszeichnung. Das ist die Grundlage, nicht das Ergebnis.
output: rohbefunde
// schritt 03 · handprüfung
Tastatur-Durchlauf durch jeden Prozess, Screenreader-Durchlauf mit NVDA und VoiceOver, 200-%-Zoom, Fokus-Pfad. Hier fällt auf, was kein Tool findet — und hier entstehen die Befunde, die zählen.
output: befunde je kriterium
// schritt 04 · übergabe ● ergebnis
Der a11y-befund kommt als Dokument, priorisiert und mit Adressat je To-do. Wir gehen ihn in einem Termin mit dir durch — und sagen ehrlich, was Pflicht ist und was warten kann.
output: a11y-befund
// faq
Ein Barrierefreiheits-Audit ist die Prüfung einer bestehenden Website auf digitale Barrieren — nach WCAG 2.2 und den Anforderungen des BFSG. Geprüft werden Tastaturbedienung, Screenreader-Ausgabe, Kontraste, Fokus, Formulare, Zoom und Medien. Ergebnis ist kein Score, sondern ein Report mit priorisierten Befunden: welche Barriere wen ausschließt, wie schwer sie wiegt, was sie kostet und in welcher Reihenfolge sie zu beheben ist.
Ein Scanner findet nur, was sich automatisch messen lässt: fehlende Alternativtexte, zu schwache Kontraste, fehlende Labels, fehlende Sprachauszeichnung. Ob der Alternativtext das Bild beschreibt, ob die Tab-Reihenfolge der Leserichtung folgt, ob ein Screenreader die Fehlermeldung im Formular überhaupt vorliest — das entscheidet kein Tool, das entscheidet ein Mensch am Gerät. Deshalb ist der Scanner bei siteway der erste Schritt und nicht der letzte.
Nach beidem, denn es ist dieselbe Kette. Das BFSG verlangt Barrierefreiheit, die europäische Norm EN 301 549 füllt die Anforderung technisch, und deren Grundlage sind die WCAG. Wir prüfen die Erfolgskriterien der WCAG 2.2 auf Level AA und ordnen jeden Befund der BFSG-Anforderung zu, damit klar ist, was Pflicht ist und was Kür.
Festpreis nach Briefing. Sobald klar ist, wie viele Seitentypen und Prozesse geprüft werden — Startseite, Formular, Suche, Checkout, Login —, nennen wir einen Preis und halten ihn fest. Keine Tagessätze, keine offene Rechnung am Ende.
Nein. Der a11y-befund gehört dir. Du kannst ihn deiner internen Entwicklung geben, an deine bestehende Agentur weiterreichen oder selbst abarbeiten — er ist so geschrieben, dass ein fremdes Team ohne Rückfragen damit arbeiten kann. Wenn du willst, übernimmt siteway die Umsetzung über die Leistung Barrierefreiheit. Das ist eine eigene Entscheidung nach dem Report.
Nein. siteway ist keine akkreditierte Prüfstelle und stellt kein Zertifikat und kein Testat aus. Wir prüfen nach denselben Kriterien und dokumentieren jeden Befund nachvollziehbar — aber wenn du ein formales Prüfsiegel brauchst, ist eine offizielle Prüfstelle die richtige Adresse. Und: Das Audit ist keine Rechtsberatung. Ob dein Unternehmen unter das BFSG fällt und welche Ausnahme greift, beantwortet ein Anwalt, nicht eine Web-Agentur.
Fünf bis zehn Werktage, je nach Umfang. Geprüft wird nicht jede Unterseite, sondern eine repräsentative Auswahl: jeder Seitentyp einmal plus die Prozesse, an denen es ernst wird — Formular, Suche, Login, Kauf. Barrieren stecken fast immer in Vorlagen und Komponenten, nicht in einzelnen Seiten. Wer die Vorlage repariert, repariert alle Seiten, die darauf beruhen.
// passt dazu
audits & umsetzung
// leistung · umsetzung
Wenn der Befund steht und jemand ihn abarbeiten soll: Hier bauen wir die Barrieren weg — bis WCAG 2.2 AA und BFSG erfüllt sind.
weiterlesen →
// audit · technik
Die Etage darunter: Code, Semantik, Struktur und Technik der Seite. Vieles, was Screenreader stört, ist ein Struktur-Problem.
weiterlesen →
// leistung · design
Kontrast, Fokus-Zustände und Formular-Layout entstehen im Design. Wer sie dort richtig macht, spart sich die Hälfte der Befunde.
weiterlesen →
// Wissen, wo eure Barrieren wirklich stecken?
Audit anfragen