Kurz und einfach erklärt
Viele Firmen müssen ihre Website für alle Menschen nutzbar machen. Das gilt auch für Menschen mit Behinderung. Ein Gesetz verlangt das seit Ende Juni 2025.
Einen ersten Test können Sie selbst machen. Sie brauchen dafür nur den Browser und die Tastatur. Ein extra Programm brauchen Sie nicht.
Probieren Sie zum Beispiel: Geht alles ohne Maus? Kann man die Seite groß zoomen? Haben Videos Untertitel? Kommt eine klare Meldung, wenn man ein Formular leer abschickt?
Der Test findet aber nicht alles. Wie ein Vorlese-Programm die Seite vorliest, merkt man so nicht. Auch Farben kann man so nur grob prüfen.
Darum sollten Fachleute die Seite danach genau prüfen. Sie prüfen alle Regeln. Sie schreiben auf, was man ändern muss.
Das Barrierefreiheitsstärkungsgesetz gilt für bestimmte Dienstleistungen, die nach dem 28. Juni 2025 für Verbraucher erbracht werden, darunter Dienstleistungen im elektronischen Geschäftsverkehr (BFSG § 1), und viele Betreiber stellen sich seitdem dieselbe Frage: Wie barrierefrei ist meine Website eigentlich? Die belastbare Antwort liefert ein Audit. Einen ersten Eindruck verschaffen Sie sich aber selbst, mit nichts weiter als Browser, Tastatur und einem Notizzettel. Das W3C hat dafür die „Easy Checks“ zusammengestellt: kurze Proben für den Einstieg, die ausdrücklich keine vollständige Prüfung ersetzen (W3C Easy Checks). Dieser Beitrag macht daraus acht Handgriffe, die Sie ohne Zusatzprogramm an Ihrer eigenen Website ausprobieren können, und zieht die Grenze so klar wie das W3C selbst: was der Selbsttest zeigt, was er nur grob einschätzt und was er gar nicht sehen kann.
Das Wichtigste in Kürze
- Die Schnelltests des W3C decken nur wenige Barrieren ab: Eine Seite kann sie bestehen und trotzdem erhebliche Barrieren haben (W3C Easy Checks). Ein Selbsttest zeigt die Richtung, er ist kein Nachweis der Konformität.
- Probe ohne Maus: Jede Funktion muss sich über die Tastatur bedienen lassen, mit Tab, Umschalt+Tab, Enter, Leertaste, Pfeiltasten und Escape, und der Fokus muss sichtbar sein (W3C WCAG 2.2).
- Zoom auf 200 Prozent im schmalen Fenster: Text bleibt lesbar, nichts überlagert sich, waagerechtes Scrollen ist nicht nötig. Fünfmal Strg und Plus sollte dorthin führen (W3C Easy Checks).
- Zu geringer Textkontrast steht auf 83,9 Prozent der eine Million meistbesuchten Startseiten (WebAIM Million 2026). Ohne Werkzeug lässt er sich nur grob in Graustufen einschätzen, das Verhältnis 4,5:1 (W3C WCAG 2.2) misst erst ein Werkzeug.
- Ein leer abgeschicktes Formular verrät viel: Jede Fehlermeldung muss das betroffene Feld nennen und den Fehler in Text beschreiben (W3C WCAG 2.2), Pflichtfelder brauchen eine sichtbare Kennzeichnung.
- Screenreader-Ausgabe, ARIA-Zustände und Fokusführung in Dialogen findet kein Selbsttest. Wer eine Dienstleistung entgegen § 14 Abs. 1 BFSG anbietet, riskiert eine Geldbuße bis zu 100.000 Euro (BFSG § 37).
Was ein Selbsttest leisten kann
Das W3C beschreibt seine Easy Checks als Einstieg: Mit einfachen Proben finden Sie heraus, ob Barrierefreiheit auf einer Seite überhaupt in Grundzügen bedacht wurde. Im selben Atemzug warnt es: Die Proben decken nur wenige Themen ab, sind auf Tempo statt Vollständigkeit angelegt, und eine Seite kann sie bestehen und trotzdem erhebliche Barrieren enthalten (W3C Easy Checks). Diese Grenze gilt für alles, was in diesem Beitrag folgt. Ein bestandener Selbsttest ist keine Freigabe. Ein nicht bestandener ist dagegen ein deutliches Signal, dass Handlungsbedarf besteht.
Warum sich der Blick trotzdem lohnt, zeigt die WebAIM Million 2026. Auf 95,9 Prozent (WebAIM Million 2026) der Startseiten der eine Million meistbesuchten Websites fand die automatische Auswertung Fehler gegen die WCAG. 96 Prozent (WebAIM Million 2026) aller erkannten Fehler fallen in nur sechs Arten: zu geringer Textkontrast, fehlende Alternativtexte, fehlende Formularbeschriftungen, leere Links, leere Schaltflächen und eine fehlende Angabe der Dokumentsprache. Vier dieser sechs Arten lassen sich mit den Proben in diesem Beitrag zumindest grob aufspüren. Leere Links und Schaltflächen zeigen sich dagegen erst, wenn ein Screenreader oder ein Werkzeug den Namen eines Bedienelements ausliest.
Wen die Proben betreffen, zeigt die amtliche Statistik. Zum Jahresende 2025 lebten in Deutschland gut 7,8 Millionen (Destatis) Menschen mit schwerer Behinderung, das sind 9,4 Prozent (Destatis) der Bevölkerung. Bei 4 Prozent (Destatis) der Schwerbehinderten lag Blindheit oder eine Sehbehinderung vor, bei weiteren 4 Prozent (Destatis) Schwerhörigkeit, Gleichgewichts- oder Sprachstörungen. Die Statistik zählt nur Menschen mit amtlich festgestellter schwerer Behinderung. Wer seine Lesebrille vergessen hat, mit eingegipstem Arm nur die Tastatur nutzt oder im Zug ein Video ohne Ton ansieht, steht in keiner Tabelle und profitiert von denselben Korrekturen.
Was „ohne Werkzeug“ hier heißt
Vorbereitung: drei Seiten und ein Prüfbogen
Prüfen Sie nicht die ganze Website, sondern drei Seiten, die für Ihr Geschäft zählen: die Startseite, eine typische Inhalts- oder Produktseite und die Seite mit dem wichtigsten Formular, also Kontakt, Terminbuchung oder den ersten Schritt im Bestellablauf. Arbeiten Sie im Browser, den Sie im Alltag nutzen, und schließen Sie das Cookie-Banner nicht vorab mit der Maus. Wie es sich mit der Tastatur bedienen lässt, gehört bereits zur ersten Probe. Für jeden Befund notieren Sie fünf Angaben:
- Seite und Adresse: welche der drei Seiten, mit vollständiger URL.
- Probe: welcher der acht Handgriffe, zum Beispiel „Zoom“ oder „Formular leer absenden“.
- Beobachtung: was genau passiert ist, in einem Satz und ohne Bewertung, etwa „Menü lässt sich mit Enter nicht öffnen“.
- Bildschirmfoto: mit sichtbarem Fokus oder sichtbarer Fehlermeldung, damit Entwicklung oder Agentur den Befund nachstellen können.
- Wirkung: Verhindert die Stelle eine Aufgabe, erschwert sie sie oder stört sie nur?
Die Wirkung ist das wichtigste Feld. Ein Kontaktformular, das sich ohne Maus nicht absenden lässt, wiegt schwerer als ein blasser Text in der Fußzeile. Halten Sie Beobachtung und Wirkung getrennt: Die Beobachtung beschreibt, was Sie gesehen haben, die Wirkung, was das für einen Menschen bedeutet, der auf die Tastatur, die Vergrößerung oder Untertitel angewiesen ist.
Probe 1: nur mit der Tastatur
Legen Sie die Maus beiseite, laden Sie die Startseite neu und drücken Sie einmal Tab. Auf einer gut gebauten Seite erscheint jetzt ein Link wie „Zum Inhalt springen“. Er ist das erste Bedienelement und führt an Menü und Suche vorbei direkt zum Hauptinhalt. Gestalter dürfen ihn verstecken, solange er beim Ansteuern deutlich sichtbar wird (W3C Easy Checks). Ein solcher Sprunglink ist ein verbreiteter Weg, wiederholte Blöcke überspringbar zu machen, wie es das Kriterium 2.4.1 verlangt (W3C WCAG 2.2). Auf den eine Million meistbesuchten Startseiten hatten nur 17,1 Prozent (WebAIM Million 2026) einen solchen Link, und jeder zehnte davon war defekt (WebAIM Million 2026), etwa weil sein Sprungziel fehlte.
Gehen Sie dann mit Tab weiter durch die Seite und mit Umschalt+Tab zurück. Jede Funktion muss sich über die Tastatur bedienen lassen, und der Fokus, also der Rahmen oder die Markierung am gerade angesteuerten Element, muss sichtbar sein (W3C WCAG 2.2). Achten Sie auf diese Punkte:
- Jeder Link, jede Schaltfläche und jedes Formularfeld wird erreicht, auch das Cookie-Banner, die Suche und der Warenkorb.
- Der Fokus ist an jeder Stelle zu sehen. Verschwindet er, steht er oft auf einem unsichtbaren Element oder wurde per Gestaltung entfernt.
- Menüs, Aufklapper und Reiter öffnen sich mit Enter oder Leertaste, die Pfeiltasten bewegen sich innerhalb von Auswahllisten.
- Escape schließt Dialoge und Ebenen, und Sie kommen aus jedem Element wieder heraus, ohne in einer Schleife festzuhängen.
- Der Fokus verschwindet nicht hinter einer klebenden Kopfleiste, einem Chatfenster oder dem Cookie-Banner.
- Die Reihenfolge folgt dem Lesefluss und springt nicht quer über die Seite.
Zwei dieser Punkte haben in WCAG 2.2 eigene Kriterien: Aus einem Element muss man mit der Tastatur wieder herauskommen (Kriterium 2.1.2), und ein angesteuertes Element darf nicht vollständig von Inhalten der Seite verdeckt sein (Kriterium 2.4.11) (W3C WCAG 2.2). Mehr zu Reihenfolge, Tastaturmustern und Fokusgestaltung steht im Beitrag zur Tastaturnavigation. Wie Sprunglinks und Menüs gebaut sein sollten, zeigt der Beitrag zur barrierefreien Navigation.
Probe 2: Zoom auf 200 Prozent
Verkleinern Sie das Browserfenster auf etwa halbe Bildschirmbreite und drücken Sie Strg und Plus, auf dem Mac Cmd und Plus. Fünfmal sollte Sie auf 200 Prozent bringen (W3C Easy Checks). Der Wert ist nicht willkürlich: Text muss sich ohne Hilfstechnik bis 200 Prozent (W3C WCAG 2.2) vergrößern lassen, ohne dass Inhalt oder Funktion verloren gehen. Mit Strg und der Null kehren Sie zur gewohnten Größe zurück.
Lesen Sie die vergrößerte Seite von oben nach unten. Bestanden ist die Probe, wenn aller Text lesbar bleibt, nichts hinter anderem Text oder Bildern verschwindet und Sie nicht waagerecht scrollen müssen, um eine Zeile zu Ende zu lesen. Dass sich das Hauptmenü in ein Symbol zum Aufklappen verwandelt, ist ausdrücklich in Ordnung (W3C Easy Checks). Typische Befunde sind abgeschnittene Schaltflächen, übereinanderliegende Textblöcke in Bannern und Dialoge, deren Schließen-Schaltfläche aus dem sichtbaren Bereich rutscht.
Wer weitergehen will, zoomt auf 400 Prozent. Bei einem Fenster von 1.280 CSS-Pixeln Breite entspricht das einer Ansicht von 320 CSS-Pixeln (W3C WCAG 2.2), etwa einem kleinen Smartphone. Damit prüfen Sie das Kriterium 1.4.10: Inhalte sollen sich neu anordnen, statt seitlich aus dem Bild zu laufen. Text in Bildern wird dabei nur unscharf größer und bricht nicht um. Warum Aktionsbanner deshalb als HTML gebaut werden sollten, erklärt der Beitrag zu Text im Bild.
Probe 3: Bilder ausschalten
Ein Alternativtext ist die kurze Beschreibung, die den Zweck eines Bildes für Menschen wiedergibt, die es nicht sehen (W3C Easy Checks). Auf 53,1 Prozent (WebAIM Million 2026) der untersuchten Startseiten fehlte er an mindestens einem Bild. Für einen blinden Besucher ist ein Aktionsbild ohne Text eine Lücke, ein verlinktes Logo ohne Text ein Link ohne erkennbares Ziel.
Ohne Zusatzprogramm nähern Sie sich dem, indem Sie die Bilder abschalten. Viele Browser erlauben es, Bilder für eine Website zu sperren, meist über die Website-Einstellungen oder das Menü für Entwickler. Laden Sie die Seite neu und fragen Sie sich an jeder Stelle, an der vorher ein Bild war: Fehlt jetzt eine Information? Steht an Stelle eines Werbebanners, eines Preisschilds oder einer Schaltfläche mit Symbol ein Text, der dieselbe Aufgabe erfüllt? Rein schmückende Bilder dürfen ersatzlos verschwinden, für sie nennt das W3C ausdrücklich einen leeren Alternativtext (W3C Easy Checks).
Die Probe hat eine Schwäche, die Sie kennen sollten: Browser zeigen Alternativtexte unterschiedlich an, manche nur, wenn genug Platz ist. Bleibt eine Stelle leer, notieren Sie sie als Verdacht, nicht als Befund. Ob ein vorhandener Text auch treffend formuliert ist, entscheidet ohnehin ein Mensch. Wie gute Alternativtexte für Produktbilder, Grafiken und verlinkte Bilder aussehen, steht im Beitrag zu Alt-Texten.
Probe 4: Seitentitel und Sprache
Der Seitentitel steht im Reiter des Browsers und in den Suchergebnissen, und er ist das Erste, was ein Screenreader beim Öffnen einer Seite vorliest (W3C Easy Checks). Öffnen Sie mehrere Ihrer Seiten nebeneinander und lesen Sie die Reiter. Jede Seite braucht einen eigenen Titel, der Thema oder Zweck beschreibt (W3C WCAG 2.2). Das Wichtige gehört an den Anfang: „Kontakt – Firmenname“ hilft mehr als ein langer Markenname vor jeder Seite. Ein Titel wie „Startseite“ auf allen Unterseiten ist ein klarer Befund.
Gleich daneben liegt die Sprache der Seite. Screenreader und Vorlesefunktionen brauchen sie, um Wörter richtig auszusprechen (W3C Easy Checks). Öffnen Sie mit einem Rechtsklick „Seitenquelltext anzeigen“ und suchen Sie in den ersten Zeilen das Element html mit der Angabe lang="de". Auf 13,5 Prozent (WebAIM Million 2026) der Startseiten fehlte diese Angabe. Ein englischer Abschnitt innerhalb einer deutschen Seite bräuchte eine eigene Sprachangabe; diesen Wechsel erkennt die einfache Probe nicht (W3C Easy Checks).
Probe 5: Überschriften als Gliederung
Überschriften funktionieren wie ein Inhaltsverzeichnis. Sie gliedern die Seite, und beim Untergliedern sollen keine Ebenen übersprungen werden (W3C Easy Checks). Für Screenreader-Nutzende sind sie das wichtigste Mittel, sich zu orientieren. Eine Befragung von Screenreader-Nutzenden mit 1.539 (WebAIM Screen Reader Survey 2024) gültigen Antworten wollte wissen, was sie auf einer langen Seite am ehesten zuerst tun, um eine Information zu finden: 71,6 Prozent (WebAIM Screen Reader Survey 2024) derer, die diese Frage beantworteten, nannten das Springen über die Überschriften.
Ohne Werkzeug prüfen Sie zuerst die sichtbare Gliederung. Lesen Sie nur die groß und fett gesetzten Zeilen: Ergeben sie für sich eine verständliche Übersicht? Beschreibt jede den Abschnitt darunter? Dann folgt der Blick in den Code. Im Seitenquelltext suchen Sie mit Strg+F nach <h1, <h2 und <h3. Die Hauptüberschrift trägt in der Regel die oberste Ebene, die folgenden Abschnitte die Ebenen darunter, und auf eine h2 folgt eine h3, nicht direkt eine h4 (W3C Easy Checks). Übersprungene Ebenen fand die WebAIM Million auf 41,8 Prozent (WebAIM Million 2026) der Startseiten, gar keine Überschriften auf 7,5 Prozent (WebAIM Million 2026).
Diese Probe hat eine Grenze. Der Quelltext zeigt das HTML, das der Server ausliefert. Was Skripte erst im Browser einfügen, etwa Filter, Reiter oder nachgeladene Abschnitte, steht dort nicht. Fehlt eine sichtbare Überschrift im Quelltext, ist das deshalb ein Hinweis, kein Beweis.
Probe 6: Kontrast grob einschätzen
Zu geringer Textkontrast ist der häufigste automatisch erkannte Fehler: Er fand sich auf 83,9 Prozent (WebAIM Million 2026) der Startseiten, im Schnitt an 34 (WebAIM Million 2026) Stellen je Seite. Typische Kandidaten sind hellgraue Hinweistexte, Platzhalter in Eingabefeldern, weiße Schrift auf Fotos und farbige Schaltflächen.
Ohne Werkzeug bleibt Ihnen der Graustufentest. Windows und macOS bieten in ihren Bedienungshilfen einen Farbfilter, der den Bildschirm in Graustufen zeigt. Das W3C nennt das ausdrücklich eine grobe Probe, ob Text gut lesbar ist oder mehr Kontrast braucht (W3C Easy Checks). Was in Graustufen verschwimmt, verliert auch für viele Menschen mit Sehbehinderung an Kontur. Achten Sie zusätzlich darauf, ob Links nur durch ihre Farbe vom Fließtext zu unterscheiden sind und ob ein Fehlerhinweis allein über die Farbe Rot transportiert wird.
Für den genauen Wert verweist das W3C auf Werkzeuge, die das Verhältnis berechnen (W3C Easy Checks). Normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1 (W3C WCAG 2.2), großer Text mindestens 3:1 (W3C WCAG 2.2). Ob ein Grau knapp über oder knapp unter dieser Schwelle liegt, sieht niemand mit bloßem Auge. Deshalb steht der Kontrast im Prüfbogen als einzige Probe mit dem Vermerk „nur grob“. Die Grundlagen der Messung erklärt der Beitrag zu Farbkontrasten.
Graustufen sind kein Messwert
Probe 7: Formular leer absenden
Formulare sind die Stelle, an der aus Besuchern Kunden werden, und zugleich eine häufige Fehlerquelle. 51 Prozent (WebAIM Million 2026) der Startseiten hatten mindestens ein Eingabefeld ohne korrekte Beschriftung. Prüfen Sie zuerst das Sichtbare: Steht neben oder über jedem Feld eine dauerhafte Beschriftung, die sagt, was einzutragen ist? Ein grauer Platzhalter im Feld, der beim Tippen verschwindet, ersetzt sie nicht.
Dann folgt ein einfacher Handgriff aus den Easy Checks: Klicken Sie auf die Beschriftung. Ist das Feld richtig mit ihr verknüpft, springt der Cursor hinein (W3C Easy Checks). Passiert nichts, fehlt in vielen Fällen genau die Verknüpfung, die ein Screenreader braucht, um das Feld anzusagen. Bei Kontrollkästchen und Auswahlknöpfen vergrößert die Verknüpfung zudem die Klickfläche, was Menschen mit unruhiger Hand hilft (W3C Easy Checks).
Jetzt schicken Sie das Formular leer ab, möglichst nur mit der Tastatur. Wird ein Eingabefehler automatisch erkannt, muss das betroffene Feld benannt und der Fehler in Text beschrieben werden (W3C WCAG 2.2). Ein rot umrandetes Feld ohne Text genügt dem nicht. Prüfen Sie außerdem, ob Pflichtfelder vorab sichtbar gekennzeichnet sind. Das W3C empfiehlt das Wort für „erforderlich“ in der Beschriftung, weil ein Sternchen von Screenreadern oft als Satzzeichen übergangen und von Menschen mit Sehbehinderung leicht übersehen wird (W3C Easy Checks).
Wer einen Bestellablauf betreibt, wiederholt die Probe in jedem Schritt bis vor die Zahlung, ohne eine echte Bestellung auszulösen. Mehr zu Beschriftungen, Fehlermeldungen und Prüfregeln steht im Beitrag zu barrierefreien Formularen.
Probe 8: Video ohne Ton
Schalten Sie den Ton ab und starten Sie jedes Video auf den drei Seiten. Sind Untertitel zu sehen, oder lassen sie sich über eine Schaltfläche im Player einschalten, oft mit „CC“ beschriftet? Untertitel für aufgezeichnete Videos verlangt das Kriterium 1.2.2 (W3C WCAG 2.2). Nur automatisch erzeugte Untertitel reichen nach Einschätzung des W3C nicht aus (W3C Easy Checks).
Sind Untertitel vorhanden, prüfen Sie ihre Qualität: Stimmen Zeichensetzung sowie Groß- und Kleinschreibung, laufen sie synchron zum Gesprochenen, ist erkennbar, wer gerade spricht, und stehen wichtige Geräusche wie Applaus oder Donner mit im Text (W3C Easy Checks)? Reine Audiobeiträge wie Podcasts brauchen ein Transkript. Videos, deren Bildinhalt für das Verständnis wichtig ist, brauchen eine Audiodeskription, die das Gezeigte beschreibt.
Bei älteren Videos lohnt ein Blick ins Gesetz: Aufgezeichnete zeitbasierte Medien, die vor dem 28. Juni 2025 veröffentlicht wurden, nimmt das BFSG ausdrücklich aus (BFSG § 1). Was danach veröffentlicht wurde, fällt nicht unter diese Ausnahme. Wie Untertitel, Transkripte und Audiodeskription praktisch entstehen, beschreibt der Beitrag zu barrierefreien Medien.
Der Prüfbogen auf einen Blick
Die Tabelle fasst die acht Proben zusammen. Die rechte Spalte nennt die Erfolgskriterien laut WCAG 2.2, auf die sich eine Probe vor allem bezieht (W3C WCAG 2.2). Eine bestandene Probe heißt nicht, dass das Kriterium erfüllt ist; sie heißt nur, dass an dieser Stelle nichts Offensichtliches auffällt.
| Probe | Handgriff | Bestanden, wenn | WCAG 2.2 |
|---|---|---|---|
| Tastatur | Tab, Umschalt+Tab, Enter, Leertaste, Escape | alles erreichbar, Fokus sichtbar, keine Falle | 2.1.1, 2.1.2, 2.4.7 |
| Zoom | Strg oder Cmd und Plus, fünfmal | Text lesbar, nichts überlagert, kein waagerechtes Scrollen | 1.4.4, 1.4.10 |
| Bilder aus | Bilder für die Website sperren, neu laden | keine Information fehlt, Schmuckbilder dürfen fehlen | 1.1.1 |
| Seitentitel und Sprache | Reiter lesen, Quelltext öffnen | eigener, sprechender Titel, Sprachangabe vorhanden | 2.4.2, 3.1.1 |
| Überschriften | fette Zeilen lesen, im Quelltext nach h1 bis h3 suchen | verständliche Gliederung ohne übersprungene Ebenen | 1.3.1, 2.4.6 |
| Kontrast (nur grob) | Graustufenfilter des Betriebssystems | Text auch in Grau gut lesbar, genauer Wert braucht Messung | 1.4.3 |
| Formular | Beschriftung anklicken, leer absenden | Cursor springt ins Feld, Fehler steht als Text am Feld | 3.3.1, 3.3.2 |
| Video | Ton aus, Untertitel an | vollständige, synchrone Untertitel, nicht nur automatisch erzeugt | 1.2.2 |
Was der Selbsttest nicht findet
Die Grenze verläuft dort, wo Barrierefreiheit nicht mehr sichtbar ist. Ein Screenreader liest nicht den Bildschirm, sondern Namen, Rolle und Zustand jedes Bedienelements aus dem Code. Für alle Bedienelemente müssen Name und Rolle programmatisch ermittelbar sein, ebenso Zustände und deren Änderungen (W3C WCAG 2.2). Ob ein Aufklappmenü als „erweitert“ angesagt wird oder ob eine Schaltfläche mit Lupensymbol einen Namen hat, sieht man ihr nicht an.
Screenreader-Ablauf
Ob Titel, Überschriften, Links und Formularfelder in sinnvoller Reihenfolge und mit verständlichen Namen angesagt werden, hört nur, wer mit einem Screenreader durch die Seite geht.
ARIA-Zustände
Aufgeklappt, ausgewählt, gedrückt: Solche Zustände stehen im Code. Fehlen sie oder ändern sie sich beim Bedienen nicht mit, bleibt das auf dem Bildschirm unsichtbar.
Fokus in Dialogen
Ein Dialog muss den Fokus aufnehmen, ihn bis zum Schließen halten und danach an die auslösende Stelle zurückgeben. Das prüft ein geübter Durchgang mit Tastatur und Screenreader.
Statusmeldungen
Meldungen wie „Artikel hinzugefügt“ oder „Keine Treffer“ muss ein Screenreader ansagen, ohne dass der Fokus springt. Ob das geschieht, zeigt der Bildschirm nicht.
Messwerte
Kontrastverhältnisse und Zielgrößen von mindestens 24 mal 24 CSS-Pixeln (W3C WCAG 2.2) sind Messungen, keine Fragen des Augenmaßes. Der Selbsttest liefert hier nur einen Verdacht.
Hinter dem Login
Kundenkonten, PDF-Rechnungen und Zahlungsschritte fallen aus einer Probe an drei öffentlichen Seiten heraus, gehören aber zur Dienstleistung.
Werkzeuge schließen diese Lücke nur zum Teil. Die WebAIM Million selbst betont, dass keine automatische Prüfung alle Konformitätsfehler erkennt und dass eine Seite ohne gefundene Fehler damit noch nicht barrierefrei ist (WebAIM Million 2026). Was Prüfprogramme, Tastaturtests und Screenreader jeweils leisten, ordnet der Beitrag zu Prüfmethoden ein. Für die Ausgabe an Screenreader bieten wir einen eigenen Screenreader-Test an.
Befunde festhalten und einordnen
Nach den acht Proben haben Sie eine Liste. Sortieren Sie sie nach Wirkung, nicht nach Probe. Ganz oben steht alles, was eine Aufgabe verhindert, etwa ein Formular, das sich ohne Maus nicht absenden lässt, oder ein Cookie-Banner, das per Tastatur nicht zu schließen ist. Danach kommt, was eine Aufgabe erschwert, zuletzt, was nur stört. Diese Reihenfolge hilft Entwicklung oder Agentur mehr als jede Punktzahl.
Geben Sie die Liste mit Bildschirmfotos weiter und bitten Sie darum, jeden Befund einem Erfolgskriterium zuzuordnen. Viele Befunde haben eine gemeinsame Ursache in einer Vorlage oder einem Baustein. Ist der Baustein korrigiert, verschwinden sie auf allen Seiten zugleich. Wie aus einer Befundliste ein Plan mit Wellen und Zuständigkeiten wird, beschreibt der Beitrag vom Prüfbericht zum Maßnahmenplan.
Die Prüffrage hinter allen acht Proben
Wiederholen Sie den Selbsttest nach jeder größeren Änderung: neuem Banner, neuem Formular, neuem Video, neuer Vorlage. Er kostet wenig Zeit und fängt Rückschritte ab, bevor sich eine Kundin beschwert oder eine Behörde nachfragt.
Vom Selbsttest zum Audit
Das BFSG fragt nicht, ob eine Seite einen Selbsttest besteht. Barrierefrei ist eine Dienstleistung nach dem Gesetz, wenn sie für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar ist (BFSG § 3). Ein Dienstleistungserbringer darf seine Dienstleistung nur anbieten, wenn sie die Anforderungen erfüllt (BFSG § 14). Wer dagegen verstößt, riskiert eine Geldbuße bis zu 100.000 Euro (BFSG § 37). Welche Anforderungen im Einzelnen gelten, fasst die Seite zu den BFSG-Anforderungen zusammen.
Ausgenommen sind Kleinstunternehmen, die Dienstleistungen anbieten (BFSG § 3), also Unternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme (BFSG § 2). Ob die Ausnahme für Sie greift, klärt der Beitrag zur Ausnahme für Kleinstunternehmen. Für alle anderen ist der Selbsttest ein guter Anfang und ein schlechter Schluss.
Ein WCAG-Audit setzt dort an, wo die acht Proben aufhören. Es bewertet jedes Erfolgskriterium der Stufen A und AA für jede geprüfte Ansicht, bedient alle festgelegten Abläufe mit der Tastatur, prüft die Ausgabe für Screenreader und dokumentiert jede Barriere mit Kriterium, Schweregrad und Lösungsweg. Ihr ausgefüllter Prüfbogen ist dafür ein nützlicher Ausgangspunkt, weil er zeigt, welche Seiten und Abläufe Ihnen wichtig sind und wo Sie selbst schon gestolpert sind.
Nach der Korrektur hält ein regelmäßiges BFSG-Monitoring den erreichten Stand im Blick. Die Umsetzung selbst übernimmt unsere barrierefreie Webentwicklung, wenn Ihrem Team dafür die Zeit fehlt.
Quellen
Verwandte Artikel
Barrierefreie Kundenportale: Login-Bereiche richtig prüfen
Automatische Scans enden an der Anmeldemaske. Wie ein WCAG-Audit den geschützten Bereich mitprüft: Prüfumfang, Testkonten, Sitzungsablauf, Screenreader.
Accessibility-Audit Kosten 2026: Preise, ROI und Förderung
Was ein WCAG-2.2-Audit 2026 kostet: Preise nach Umfang, Stichprobe gegen Vollprüfung, Monitoring, BFSG-Bußgeldrahmen, Conversion-ROI und Förderung im Überblick.
KI-generierter Code: was Barrierefreiheitsprüfungen finden
Was Barrierefreiheitsprüfungen in KI-generiertem Code finden: vier typische Muster von div-Schaltfläche bis Fokusrahmen und wie die Prüfung in den Ablauf kommt.