Beispielbericht: fiktiver Musterladen. Technisch gemessene Testseiten, kein Kundenfall.
WCAG 2.1 ist der internationale Standard für barrierefreie Websites, auf den die europäischen Vorgaben verweisen. Er kennt drei Stufen; AA ist die mittlere und die für Ihr Angebot maßgebliche. Geprüft wird gegen 50 einzelne Anforderungen, den Prüfkatalog dazu finden Sie weiter unten.
Die automatisierte Prüfung hat in den geprüften Bereichen keine Auffälligkeiten gefunden. Beachten Sie aber unbedingt die Grenzen der Prüfung unten: Teile Ihrer Website konnten nicht geprüft werden.
Wie die Zahl zu lesen ist: Sie beginnt bei 100, und jede gefundene Ursache nimmt einen Anteil davon weg, schwere mehr als leichte und weit verbreitete mehr als einzelne. Sie zeigt damit, wie weit die Website von den geprüften Anforderungen entfernt ist, und sie bewegt sich sichtbar, sobald Sie etwas beheben. Sie ist keine Schulnote und kein Anteil erfüllter Anforderungen, und sie sagt nichts über die Punkte, die eine Maschine nicht entscheiden kann. Das Wort daneben folgt nicht aus der Zahl, sondern aus dem schwersten gefundenen Mangel; zwei Websites mit derselben Zahl können deshalb verschieden eingestuft sein. Was geprüft wurde, steht im Prüfkatalog weiter unten.
Auf Ihrer Website steht eine Seite zur Barrierefreiheit (http://127.0.0.1:44459/barrierefreiheit). Die nach Anlage 3 BFSG geforderten Angaben haben wir dort nicht erkannt. Zu ihrem Inhalt sagen wir deshalb nichts, weder gut noch schlecht.
Damit Sie das Ergebnis richtig einordnen können, legen wir offen, was nicht geprüft werden konnte:
Wir sind jedes Kriterium des Maßstabs WCAG 2.1, Stufen A und AA durchgegangen, nicht nur die, bei denen wir etwas gefunden haben. So sehen Sie, was geprüft wurde und was noch offen ist.
| 25 | Kriterien haben wir für Sie entschieden |
| 0 | davon mit Handlungsbedarf |
| 25 | bleiben zum Selberprüfen, jedes mit einer Anleitung unten |
Ein Kriterium ohne Befund heißt nicht, dass dieser Punkt erfüllt ist. Es heißt, dass die maschinell prüfbaren Anteile unauffällig waren. Wo eine Maschine grundsätzlich nichts entscheiden kann, steht das mit Begründung dabei.
„bitte selbst prüfen" heißt: das kann kein Programm entscheiden, auch keines am Markt. „prüfen wir noch nicht" heißt: entscheidbar wäre es, unsere Prüfung deckt es aber noch nicht ab. Die Anleitung darunter ist dieselbe, der Grund ist es nicht.
| Nr. | Kriterium | Ergebnis |
|---|---|---|
| 1.1.1A | Jedes Bild braucht eine Beschreibung
Menschen mit Sehbehinderung können nur lesen, was in Bildern steht, wenn eine Textbeschreibung vorhanden ist. Ein Vorleseprogramm liest dem Nutzer vor, was auf Fotos, Grafiken und Icons zu sehen ist, sonst hört er nur Bild. |
geprüft, unauffällig |
| 1.2.1A | Audio und Stumm-Videos brauchen Transkripte
Wenn Sie ein reines Audio-Stück veröffentlichen oder ein Video ohne Ton, muss ein schriftliches Transkript dabei sein. Menschen mit Hörbehinderung können sonst nicht verstehen, was gesagt oder gezeigt wird. So prüfen Sie es selbst: Suchen Sie auf Ihrer Website eine Audio-Datei oder ein Video ohne Ton. Prüfen Sie, ob direkt daneben oder darunter ein schriftliches Transkript oder ein Link zum Transkript steht. Wenn nicht, fehlt es.
Nur ein Mensch kann prüfen, ob ein Transkript vollständig und genau ist und alle wichtigen Informationen abbildet. |
bitte selbst prüfen |
| 1.2.2A | Videos brauchen Untertitel
Gehörlose und schwerhörige Menschen verstehen Ihre Videos nicht, wenn Untertitel fehlen. Untertitel zeigen nicht nur Dialoge, sondern auch Soundeffekte und Musikangaben, zum Beispiel Telefon klingelt. |
geprüft, unauffällig |
| 1.2.3A | Videos brauchen Bild-Beschreibung oder Transkript
Blinde Menschen sehen nicht, was auf Ihrem Video passiert, wenn es nur Dialog enthält. Sie brauchen entweder eine Beschreibung der Bilder oder ein ausführliches Transkript, das auch Handlungen und Szenenwechsel erklärt. So prüfen Sie es selbst: Öffnen Sie ein Video auf Ihrer Seite. Prüfen Sie, ob daneben ein Menü-Punkt Audiodeskription oder ein Link zu einem Transkript sichtbar ist. Klicken Sie drauf. Wird die Bildinformation verständlich gemacht?
Eine Maschine kann nur sehen, ob eine Datei vorhanden ist, nicht ob sie tatsächlich alle sichtbaren Informationen enthält. |
bitte selbst prüfen |
| 1.2.4AA | Live-Videos brauchen Echtzeit-Untertitel
Wenn Sie einen Livestream anbieten, können gehörlose Menschen ihn nicht verfolgen. Echtzeit-Untertitel müssen parallel zum Video ablaufen, nicht später hinzugefügt werden. So prüfen Sie es selbst: Wenn Sie einen Livestream betreiben, prüfen Sie während einer Übertragung, ob ein Untertitel-Menü vorhanden ist und ob die Untertitel mit dem Ton synchron laufen. Verzögerung von mehr als zwei Sekunden ist nicht brauchbar.
Es braucht einen Menschen, um zu beurteilen, ob Untertitel zeitnah genug und präzise genug eingefügt werden. |
bitte selbst prüfen |
| 1.2.5AA | Videos brauchen Tonbeschreibung
Menschen mit Sehbehinderung brauchen eine zusätzliche Stimme, die erklärt, was visuell passiert. Diese Audiodeskription wird während der normalen Pausen eingefügt und beschreibt Handlungen, Charaktere und wichtige Bilddetails. |
geprüft, unauffällig |
| 1.3.1A | Struktur muss maschinenlesbar sein
Wenn Sie Überschriften, Listen oder Tabellen nutzen, muss ein Vorleseprogramm erkennen können, dass es Überschriften, Listen oder Tabellen sind. Das geht nicht durch reine Formatierung wie Fettdruck oder Größe, sondern nur durch richtige HTML-Strukturierung. |
geprüft, unauffällig |
| 1.3.2A | Lesereihenfolge muss stimmen
Wenn ein Screenreader (ein Vorleseprogramm für Menschen mit Sehbeeinträchtigung) Ihre Seite vorliest, muss die Reihenfolge einen Sinn ergeben. Wenn ein Menü rechts im Browser steht, aber im Code ganz oben ist, liest der Screenreader es zuerst vor und verwirrt den Nutzer. So prüfen Sie es selbst: Drücken Sie Tab wiederholt, um durch Ihre Website zu springen. Der blaue Fokus-Rahmen zeigt, in welcher Reihenfolge die Elemente navigierbar sind. Springt der Fokus chaotisch umher oder von rechts nach links, ist die Reihenfolge falsch.
Ein Programm kann prüfen, ob die Reihenfolge im HTML-Code sinnvoll ist, aber nicht, ob die Reihenfolge zum Zweck der Seite passt. |
prüfen wir noch nicht |
| 1.3.3A | Anweisungen nicht nur durch Form oder Farbe
Wenn Sie schreiben "der rote Button speichert" oder "klicken Sie auf das Haus-Symbol", verstehen Menschen mit Farbblindheit oder Sehbehinderung nicht, welcher Button gemeint ist. Jede Anweisung braucht auch einen Text-Hinweis. So prüfen Sie es selbst: Lesen Sie Ihre Texte und Anweisungen durch. Suchen Sie nach Formulierungen wie "rote Box", "grüner Knopf" oder "Klick auf das Symbol links oben". Ersetzen Sie diese Stellen durch "Speichern-Button" oder "Menü links oben" als Texthinweis.
Nur ein Mensch kann überprüfen, ob Anweisungen auf Farbe oder Form angewiesen sind oder ob ein alternativer Text-Hinweis vorhanden ist. |
bitte selbst prüfen |
| 1.3.4AA | Seite funktioniert im Hoch- und Querformat
Menschen mit körperlichen Einschränkungen können ihr Gerät oft nicht drehen. Ihre Website muss in Hochformat und Querformat lesbar und nutzbar sein, sonst können sie einfach nicht darauf zugreifen. So prüfen Sie es selbst: Öffnen Sie Ihre Website auf einem Smartphone. Drehen Sie das Gerät in Hochformat (Portrait) und Querformat (Landscape). Die Website sollte in beiden Orientierungen vollständig sichtbar sein und alle Funktionen sollten verfügbar sein. Wenn Text abgeschnitten wird oder Sie horizontal scrollen müssen, ist etwas verkehrt.
Ein Programm kann prüfen, ob die Ausrichtung des Geräts gesperrt ist, aber nicht, ob die Seite in BEIDEN Orientierungen wirklich funktioniert und alle Inhalte verfügbar sind. |
prüfen wir noch nicht |
| 1.3.5AA | Eingabefelder selbsterklärend machen
Formulare sollten im Code deutlich machen, welche Angaben erwartet werden (Name, Telefon, Adresse usw.). Das hilft Menschen mit kognitiven Beeinträchtigungen und Gedächtnisproblemen, da der Browser solche Felder automatisch ausfüllen kann. |
geprüft, unauffällig |
| 1.4.1A | Farbe nicht als einzige Information nutzen
Wenn eine Information nur durch Farbe gezeigt wird (beispielsweise Fehlerfelder nur rot), können Menschen mit Farbblindheit sie nicht erfassen. Es muss zusätzlich ein Symbol, Text oder ein anderes Merkmal die Information vermitteln. |
geprüft, unauffällig |
| 1.4.2A | Automatische Musik steuern können
Wenn Musik oder Videos länger als 3 Sekunden automatisch abspielen, muss ein Pausenknopf gut sichtbar sein. Menschen, die Sprachsoftware (ein Vorleseprogramm) nutzen, können sonst nicht hören, was die Software sagt, weil die Musik dazwischenspielt. |
geprüft, unauffällig |
| 1.4.3AA | Schrift und Hintergrund unterscheiden
Text muss genug Kontrast zum Hintergrund haben (mindestens 4,5-fach dunkel gegen hell, bei größerem Text genügt 3-fach). Menschen mit Sehschwäche, Farbblindheit oder ältere Menschen können sonst Texte nicht lesen. |
geprüft, unauffällig |
| 1.4.4AA | Text auf 200 Prozent vergrößern
Nutzer müssen die Seite auf das Doppelte zoomen können, ohne dass Text überlagert wird oder Inhalte verloren gehen. Menschen mit Sehbehinderung brauchen das zum Lesen. |
geprüft, unauffällig |
| 1.4.5AA | Echte Schrift statt Bild-Schrift nutzen
Text sollte als Schrift im Code stehen, nicht als Bild eingefügt sein. Menschen können echte Schrift vergrößern, kopieren und von Hilfssoftware vorlesen lassen. Bei Bildern geht das nicht. So prüfen Sie es selbst: Klicken Sie mit der rechten Maustaste auf Ihre Überschriften und Slogans auf der Seite. Wenn Sie den Text markieren und kopieren können, ist es echte Schrift. Wenn das nicht funktioniert, besteht die Überschrift wahrscheinlich aus einem Bild. Echte Schrift ist besser: Sie ist vergrößerbar und vorlesbar.
Ein Programm kann Bilder erkennen, aber nicht automatisch feststellen, ob darin Text abgebildet ist. |
prüfen wir noch nicht |
| 1.4.10AA | Keine horizontale Scrollerei beim Zoom
Wenn Nutzer die Seite auf 400 Prozent vergrößern, sollte Text nicht nach rechts verschwinden. Menschen mit Sehbehinderung zoomen oft stark und wollen nicht ständig nach links und rechts scrollen, um eine Zeile zu lesen. |
geprüft, unauffällig |
| 1.4.11AA | Knöpfe und Symbole deutlich sichtbar
Knöpfe, Icons und Grafiken müssen sich vom Hintergrund abheben (mindestens dreifacher Kontrast). Menschen mit Sehschwäche können sonst Steuerelemente nicht finden. |
geprüft, unauffällig |
| 1.4.12AA | Text auch mit mehr Abstand lesbar
Wenn Nutzer mehr Platz zwischen Zeilen und Wörtern einstellen, weil sie besser so lesen können, darf kein Text abgeschnitten oder überlagert werden. Menschen mit Dyslexie und niedriger Sehschärfe brauchen das. |
geprüft, unauffällig |
| 1.4.13AA | Popups nicht zu aufdringlich gestalten
Wenn Menüs oder Tooltips aufpoppen, dürfen sie nicht im Weg stehen und müssen mit der Escape-Taste schließbar sein. Menschen mit Sehbehinderung (vergrößerte Ansicht) oder Menschen mit anderem Mauszeiger brauchen das, um dahinterliegende Inhalte zu sehen. So prüfen Sie es selbst: Falls Ihre Seite Popups oder Tooltips hat: Fahren Sie mit der Maus über Links, die Menüs oder Info-Texte zeigen. Wenn ein Popup auftaucht und Sie dahinter liegende Inhalte brauchen: Können Sie das Popup mit der Escape-Taste schließen, ohne es anzuklicken? Verschwindet das Popup wieder, wenn Sie die Maus wegbewegen?
Ein Programm kann nicht beurteilen, ob ein Popup im Weg steht oder ob Nutzer es leicht schließen können. Das ist Sache menschlicher Bewertung. |
bitte selbst prüfen |
| 2.1.1A | Bedienung über Tastatur möglich
Das Kriterium verlangt, dass alle Funktionen einer Website über die Tastatur bedienbar sind. Dies hilft Menschen mit motorischen Beeinträchtigungen, Blinden und Menschen mit niedriger Sehfähigkeit. |
geprüft, unauffällig |
| 2.1.2A | Tastatur kann nicht gefangen werden
Das Kriterium verlangt, dass die Tastaturnavigation nicht in einem Element stecken bleibt. Dies hilft Tastaturnutzern, die sich sonst nicht aus einer Komponente befreien könnten. So prüfen Sie es selbst: Navigieren Sie mit Tab durch alle interaktiven Elemente. Wenn Sie in einer Komponente steckenbleiben und nicht weiterkommen (auch nicht mit Escape oder Shift+Tab), wird das Kriterium nicht erfüllt.
Ein Programm kann einige Fallen erkennen (etwa fehlende Escape-Taste in Modalen), aber nicht alle Kombinationen in benutzerdefinierten Komponenten. |
prüfen wir noch nicht |
| 2.1.4A | Einzelne Tasten-Befehle gut geschützt
Das Kriterium regelt Tastaturkürzel aus einzelnen Zeichen (wie die S-Taste), die nicht versehentlich ausgelöst werden. Dies hilft Sprachsteuerungsnutzern, bei denen ein gesprochenes Wort ungewollt mehrere Befehle auslösen kann. So prüfen Sie es selbst: Suchen Sie auf der Seite oder in der Hilfe nach Hinweisen auf Tastaturkürzel (einzelne Tasten). Falls erwähnt, prüfen Sie, ob diese Befehle nur bei Fokus auf bestimmten Elementen funktionieren oder ob es eine Möglichkeit gibt, die Kürzel abzuschalten oder umzulegen.
Ob einzelne Tasten Befehle auslösen und diese richtig geschützt sind, kann nur durch gezielte Beobachtung oder Dokumentation festgestellt werden. Eine fehlende Reaktion bedeutet nicht, dass das Kriterium erfüllt ist, sondern nur, dass es keine Kürzel gibt. |
bitte selbst prüfen |
| 2.2.1A | Zeit für Vorgänge verlängerbar
Das Kriterium verlangt, dass Nutzer zeitbasierte Abläufe anpassen können (verlängern oder deaktivieren). Dies hilft Menschen mit Leseschwierigkeiten und motorischen Beeinträchtigungen, die mehr Zeit zum Lesen oder Reagieren brauchen. |
geprüft, unauffällig |
| 2.2.2A | Bewegte Inhalte lassen sich steuern
Das Kriterium verlangt, dass automatisch bewegte oder aktualisierte Inhalte pausierbar oder ausblendbar sind. Dies hilft Menschen mit Aufmerksamkeitsschwierigkeiten und niedriger Sehfähigkeit, die sich konzentrieren möchten. |
geprüft, unauffällig |
| 2.3.1A | Keine gefährlich schnellen Blitze
Das Kriterium verlangt, dass Inhalte nicht mehr als dreimal pro Sekunde aufblitzen. Dies ist kritisch für Menschen mit lichtempfindlichen Anfällen, die durch schnelle Helligkeitswechsel ausgelöst werden können. So prüfen Sie es selbst: Beobachten Sie, ob es schnelle, wiederholte Helligkeitswechsel oder flickernde Übergänge auf der Seite gibt, die unangenehm wirken oder die Augen belasten. Solche Effekte treten selten auf Websites auf. Falls Sie keine sehen, ist das Kriterium erfüllt.
Ein Programm kann CSS-Animationen und Video-Inhalte auf Blitzfrequenz analysieren, aber die genaue Messung von Helligkeitsunterschied und betroffener Fläche erfordert zusätzliche Verifizierung. |
prüfen wir noch nicht |
| 2.4.1A | Wiederholte Blöcke übergehen
Das Kriterium verlangt, dass Nutzer wiederkehrende Navigationselemente (Header, Menüs) überspringen können. Dies hilft Tastaturnutzern und Screenreader-Nutzern, schneller zum Hauptinhalt zu gelangen. |
geprüft, unauffällig |
| 2.4.2A | Jede Seite hat einen aussagekräftigen Titel
Das Kriterium verlangt, dass jede Seite einen Titel hat, der das Thema oder den Zweck beschreibt. Dies hilft allen Nutzern, besonders Menschen mit kognitiven Beeinträchtigungen, schnell zu verstehen, worum es geht. |
geprüft, unauffällig |
| 2.4.3A | Fokus-Reihenfolge ist logisch
Das Kriterium verlangt, dass die Reihenfolge, in der die Tab-Taste durch interaktive Elemente springt, logisch und bedeutungsvoll ist. Dies hilft Tastaturnutzern und Menschen mit Leseschwierigkeiten. So prüfen Sie es selbst: Drücken Sie Tab mehrmals hintereinander und beobachten Sie, in welcher Reihenfolge der blaue Fokusrahmen durch die Seite springt. Die Reihenfolge sollte von oben nach unten und von links nach rechts gehen, ähnlich wie Sie die Seite mit Augen lesen würden.
Die Reihenfolge der Elemente im Code ist erkennbar, aber nur ein Mensch kann beurteilen, ob sie inhaltlich sinnvoll und verständlich ist. |
bitte selbst prüfen |
| 2.4.4A | Link-Zweck ist erkennbar
Das Kriterium verlangt, dass der Zweck eines Links allein aus dem Link-Text oder zusätzlich aus dem umgebenden Text deutlich wird. Dies hilft Screenreader-Nutzern (speziellen Leseprogrammen) und Menschen mit kognitiven Beeinträchtigungen. |
geprüft, unauffällig |
| 2.4.5AA | Navigation auf mehreren Wegen möglich
Das Kriterium verlangt, dass Besucher eine Website auf mindestens zwei verschiedene Arten durchsuchen können, etwa über ein Menü und eine Suchfunktion. Dies hilft Menschen mit Sehbeeinträchtigungen oder kognitiven Beeinträchtigungen, Inhalte leichter zu finden. So prüfen Sie es selbst: Notieren Sie, wie viele unterschiedliche Navigationswege Sie von der Startseite aus kennen, um eine Seite zu finden, die mehrere Ebenen tiefer im Menü liegt. Versuchen Sie die Sitemap, die Suchfunktion und das Navigationsmenü. Wenn Sie mindestens zwei unterschiedliche Wege nutzen konnten, ist das Kriterium erfüllt.
Ein Programm kann das Vorhandensein verschiedener Navigationselemente feststellen, aber nicht beurteilen, ob diese praktisch genug Seiten abdecken und wirklich funktional sind. |
prüfen wir noch nicht |
| 2.4.6AA | Überschriften und Beschriftungen beschreibend
Überschriften und Etiketten von Formularen müssen klar angeben, worum es geht. Dies hilft Menschen mit Sehbeeinträchtigungen oder kognitiven Einschränkungen zu verstehen, welcher Inhalt folgt oder was ein Feld bedeutet. So prüfen Sie es selbst: Öffnen Sie die Startseite Ihrer Website und prüfen Sie jeden Abschnitt: Steht über ihm eine Überschrift, die erklärt, worum es geht? Füllen Sie ein Formular aus und prüfen Sie, dass jedes Eingabefeld ein Etikett hat, das seinen Zweck beschreibt und nicht nur aus Standardtext wie 'Feld 1' oder 'Eingabe' besteht.
Ein Programm kann feststellen, dass Überschrift-Tags oder Formular-Labels existieren, aber nicht, ob der enthaltene Text aussagekräftig ist. |
prüfen wir noch nicht |
| 2.4.7AA | Tastaturfokus jederzeit sichtbar
Wer per Tastatur navigiert, muss jederzeit sehen, welches Element gerade den Fokus hat, etwa durch einen Rahmen oder Farbhervorhebung. Dies ist wesentlich für Menschen, die die Maus nicht nutzen können oder nur die Tastatur verwenden. |
geprüft, unauffällig |
| 2.5.1A | Funktionen auch ohne Mehrfinger-Gesten erreichbar
Funktionen, die mit Mehrfinger-Gesten arbeiten (Pinch zum Zoomen, Wischen mit zwei Fingern), müssen auch durch einfache Klicks oder Tasten erreichbar sein. Dies unterstützt Menschen mit Bewegungseinschränkungen, die komplexe Gesten nicht ausführen können. So prüfen Sie es selbst: Nutzen Sie Ihre Website auf einem mobilen Gerät und versuchen Sie, jede Funktion nur mit einem Finger zu bedienen. Funktionieren Karusselle, Karten-Zooms oder andere Interaktionen auch mit Tasten oder einzelnen Taps, oder sind Mehrfinger-Gesten zwingend erforderlich?
Ein Programm kann Multitouch-Events im Code erkennen, aber nicht prüfen, ob echte Einzel-Pointer-Alternativen implementiert und funktionsfähig sind. |
prüfen wir noch nicht |
| 2.5.2A | Versehentliche Aktivierung vermeidbar
Funktionen, die durch Mausklick oder Touch ausgelöst werden, dürfen nicht auf das Drücken reagieren, sondern auf das Loslassen, damit der Nutzer abbrechen kann. Dies schützt Menschen mit Zittern oder ungenauen Bewegungen vor versehentlichen Fehlern. So prüfen Sie es selbst: Klicken Sie mit der Maus auf einen Button und halten Sie die Maustaste gedrückt. Bewegen Sie dann die Maus weg vom Button, während Sie die Taste noch gedrückt halten. Wenn die Aktion erst beim Loslassen ausgelöst wird und nicht während des Drückens, ist das Kriterium erfüllt.
Nur durch praktisches Testen können Sie feststellen, ob ein Button auf das Drücken oder erst auf das Loslassen reagiert. |
prüfen wir noch nicht |
| 2.5.3A | Sichtbare Beschriftung im Namen enthalten
Die Beschriftung, die ein Nutzer liest (etwa auf einem Knopf), muss auch im programmatischen Namen enthalten sein, damit Nutzer mit Sprachsteuerung die sichtbaren Wörter als Befehle nutzen können. Dies hilft Menschen mit motorischen Beeinträchtigungen und Sprachsteuerungsnutzern. |
geprüft, unauffällig |
| 2.5.4A | Bewegungssteuerung nicht zwingend erforderlich
Funktionen, die durch Gerätebewegung ausgelöst werden (Schütteln, Neigen), müssen auch durch normale Tasten oder Knöpfe erreichbar sein, und Nutzer müssen sie abschalten können. Dies hilft Menschen mit Bewegungsstörungen oder Zittern vor versehentlichen Aktivierungen. So prüfen Sie es selbst: Falls Ihre Website Bewegungsfunktionen nutzt, testen Sie auf einem Mobilgerät, ob dieselbe Funktion auch über einen Knopf oder eine Taste erreichbar ist. Prüfen Sie auch, ob die Website eine Einstellung zum Ausschalten von Bewegungssteuerung bietet.
Ein Programm kann nicht feststellen, ob eine Website auf Gerätebewegung reagiert, da dies nur bei Laufzeitverhalten und bei aktivem Gerätesensor erkannt werden kann. |
bitte selbst prüfen |
| 3.1.1A | Seitensprache technisch gekennzeichnet
Die Sprache einer Seite muss im HTML-Code gekennzeichnet sein (etwa lang="de" für Deutsch), damit Bildschirmleser und Browser die korrekte Aussprache laden können. Dies hilft Menschen mit Sehbeeinträchtigungen, deren Bildschirmleser sonst die falsche Sprache einstellen könnte. |
geprüft, unauffällig |
| 3.1.2AA | Sprachenwechsel im Text gekennzeichnet
Wenn auf einer Seite einzelne Wörter oder Sätze in einer anderen Sprache stehen, müssen diese gekennzeichnet sein, damit Bildschirmleser die Aussprache wechseln. Dies hilft Menschen mit Sehbeeinträchtigungen, fremdsprachige Passagen richtig vorgelesen zu bekommen. |
geprüft, unauffällig |
| 3.2.1A | Fokus löst keine unerwarteten Kontextwechsel
Wenn ein Nutzer mit der Tastatur auf ein Feld fokussiert, darf sich der Kontext nicht überraschend ändern, etwa durch spontanes Öffnen eines Fensters oder Absenden eines Formulars. Dies schützt alle Nutzer, besonders Menschen mit kognitiven Beeinträchtigungen, vor Desorientierung. So prüfen Sie es selbst: Navigieren Sie mit der Tab-Taste durch Ihre Website und achten Sie darauf, dass allein das Fokussieren auf Elemente (Felder, Links) keine Fenster öffnet, Seiten wechselt, Formulare absendet oder den Seiten-Kontext verändert. Dies darf nur beim expliziten Klick oder Drücken der Eingabetaste geschehen.
Ein Programm kann Code für automatische Verhaltensmuster finden. Aber nicht alle Verhaltensweisen lassen sich automatisch als überraschend klassifizieren, deshalb ist ein menschlicher Test nötig. |
prüfen wir noch nicht |
| 3.2.2A | Eingabefeld wechselt Seite nicht unerwartet
Das Ändern von Optionen in einem Formularfeld darf nicht automatisch zu einem Seitenwechsel oder unverhältnismäßiger Inhaltsverschiebung führen, es sei denn, die Nutzerin wurde vorher informiert. Dies schützt Menschen mit kognitiven Beeinträchtigungen und Sehbehinderungen vor Desorientierung. So prüfen Sie es selbst: Öffnen Sie ein Formular, in dem Sie eine Auswahl ändern können (etwa Warenkategorie, Versandland oder Zahlungsart). Ändern Sie die Auswahl bewusst. Beobachten Sie: Springt die Seite unerwartet nach oben oder wird sie neu geladen, oder bleibt die Position stabil und nur der Inhalt unter der Auswahl aktualisiert sich?
Ein Programm kann feststellen, dass ein Handler auf dem Feld reagiert, aber nicht automatisch bestimmen, ob ein Kontextwechsel unerwartet ist oder ob die Nutzerin vorher informiert wurde. |
prüfen wir noch nicht |
| 3.2.3AA | Menü steht auf allen Seiten gleich
Wiederholte Navigationselemente wie Menüs und Navigationsleisten müssen auf jeder Seite an der gleichen Position und in der gleichen Reihenfolge stehen. Menschen mit Sehbeeinträchtigungen nutzen Lupensoftware und verlassen sich darauf, Elemente schnell an vertrauten Orten zu finden. Auch kognitiv beeinträchtigte Menschen profitieren von dieser Vorhersehbarkeit. So prüfen Sie es selbst: Öffnen Sie Ihre Website auf einer beliebigen Seite. Notieren Sie sich, wo das Hauptmenü sitzt (oben links, oben Mitte, oben rechts, oder als seitliche Leiste). Klicken Sie auf mindestens drei verschiedene Seiten oder Produkte. Befindet sich das Menü auf jeder Seite an exakt der gleichen Position, oder verschiebt es sich nach oben, unten oder zur Seite?
Ein Programm kann die HTML-Struktur analysieren, aber ob Navigationselemente visuell an der gleichen Stelle erscheinen, erfordert Bildschirmanalyse oder manuelle Überprüfung mehrerer Seiten. |
prüfen wir noch nicht |
| 3.2.4AA | Gleiche Funktionen heißen überall gleich
Funktionen, die mehrmals auf der Website vorkommen, müssen einheitlich benannt sein. Wenn ein Such-Button auf einer Seite 'Suchen' heißt und auf einer anderen 'Finden', verwirrt das Menschen mit Leseschwächen und Screenreader-Nutzer, die sich auf vertraute Beschriftungen verlassen. So prüfen Sie es selbst: Suchen Sie auf Ihrer Website nach wiederkehrenden Funktionen: etwa einem Such-Button, einem Warenkorb-Symbol, einem 'Mehr'-Link oder einem 'Bestellen'-Button. Erscheint diese Funktion auf mindestens zwei verschiedenen Seiten? Trägt sie überall die gleiche Beschriftung und das gleiche Symbol, oder ändert sich der Name je nach Seite?
Ein Programm kann gleiche Icons oder ähnliche Funktionen automatisch finden, aber nicht ohne Kontextwissen entscheiden, ob zwei Elemente die gleiche Funktion erfüllen oder nur ähnlich aussehen. |
prüfen wir noch nicht |
| 3.3.1A | Formularfehler werden als Text erklärt
Wenn ein Feld fehlerhaft ausgefüllt wurde, muss der Fehler nicht nur durch Farbe oder Symbol gekennzeichnet sein, sondern auch in Textform beschrieben werden. Blinde Menschen und jene mit Farbenblindheit können sonst nicht verstehen, welches Feld betroffen ist und warum. So prüfen Sie es selbst: Füllen Sie ein Formular absichtlich falsch aus, etwa mit einer ungültigen E-Mail-Adresse, einem falschen Datumsformat oder einem leeren Pflichtfeld. Klicken Sie auf 'Absenden'. Wird das fehlerhafte Feld mit einer roten Farbe hervorgehoben? Und steht direkt daneben oder darüber ein beschreibender Text, der genau erklärt, was falsch ist, etwa 'Bitte geben Sie eine gültige E-Mail-Adresse ein'?
Ein Programm kann feststellen, dass ein Fehlertext vorhanden ist, aber nicht beurteilen, ob dieser Text die Ursache des Fehlers verständlich erklärt oder zu allgemein bleibt. |
prüfen wir noch nicht |
| 3.3.2A | Jedes Formularfeld hat eine klare Beschriftung
Jedes Eingabefeld muss eine Beschriftung haben, die klar erklärt, welche Information einzugeben ist. Menschen mit kognitiven Einschränkungen, Lese- und Verständnisschwierigkeiten benötigen diese Hinweise, um Formulare fehlerfrei auszufüllen. |
geprüft, unauffällig |
| 3.3.3AA | Fehler erhalten einen Lösungsvorschlag
Wenn ein Nutzer einen Fehler macht, soll die Website nicht nur sagen, dass etwas falsch ist, sondern auch einen Vorschlag machen, wie es richtig geht. Das hilft Menschen mit kognitiven Beeinträchtigungen und motorischen Einschränkungen, Fehler schneller zu beheben, statt dass sie Formulare frustriert verlassen. So prüfen Sie es selbst: Geben Sie in einem Formularfeld absichtlich einen Fehler ein, etwa eine ungültige Postleitzahl, ein falsches Datumsformat oder eine unvollständige Telefonnummer. Klicken Sie auf 'Absenden'. Zeigt die Fehlermeldung nicht nur an, dass etwas falsch ist, sondern auch ein Beispiel oder eine Anleitung, wie es richtig aussehen soll? Etwa: 'Ungültige Postleitzahl. Bitte verwenden Sie das Format 12345'?
Ein Programm kann nicht automatisch entscheiden, welcher Korrekturvorschlag sinnvoll und sicher ist. Das erfordert Verständnis der Geschäftslogik und möglicher Fehler. |
bitte selbst prüfen |
| 3.3.4AA | Kritische Aktionen überprüfbar oder rückgängig
Bei kritischen Handlungen wie Bestellungen, Zahlungen oder dem Löschen von Daten muss die Website mindestens eine dieser Schutzmaßnahmen bieten: die Aktion wird rückgängig machbar, es gibt eine Überprüfungsstufe, oder eine Bestätigungsfrage erscheint vorher. Dies schützt alle Nutzer, besonders Menschen mit motorischen oder kognitiven Beeinträchtigungen vor fehler- oder versehentlich ausgelösten irreparablen Konsequenzen. So prüfen Sie es selbst: Führen Sie auf Ihrer Website eine kritische Aktion durch: etwa ein Produkt bestellen, bezahlen oder ein Konto löschen. Bevor die Aktion abgeschlossen wird, fragt die Website nach: 'Sind Sie sicher?' oder 'Bitte überprüfen Sie Ihre Eingaben'? Werden die eingegebenen Daten nochmal zum Überprüfen angezeigt? Oder wird die Aktion sofort ausgeführt, ohne die Möglichkeit, sie zu verhindern oder rückgängig zu machen?
Ein Programm kann nicht automatisch entscheiden, welche Aktionen kritisch genug sind und welche Schutzmechanismen angemessen sind. Das ist eine geschäftliche und rechtliche Entscheidung. |
bitte selbst prüfen |
| 4.1.1A | HTML-Code ist korrekt strukturiert
Der HTML-Code einer Website muss nach Spezifikation geschrieben sein, mit vollständigen Start- und End-Tags sowie korrekter Verschachtelung. Dies ermöglicht es Browsern und Screenreadern, die Website korrekt zu interpretieren. |
geprüft, unauffällig |
| 4.1.2A | Bedienelemente nennen ihre Funktion
Jeder Button, jedes Eingabefeld und jeder Link muss so gekennzeichnet sein, dass ein Screenreader seinen Namen und seine Funktion deutlich machen kann. Blinde, Sehbehinderte und Menschen mit motorischen Einschränkungen können sonst nicht verstehen, was ein Element tut. |
geprüft, unauffällig |
| 4.1.3AA | Statusmeldungen werden angekündigt
Wenn sich auf der Website etwas ändert (etwa Ware zum Warenkorb hinzugefügt, ein Fehler behoben, eine Live-Aktualisierung), muss diese Änderung deutlich sichtbar sein und von Screenreadern automatisch mitgeteilt werden können, ohne dass sich der Fokus bewegt. Blinde und Sehbehinderte können sonst nicht mitbekommen, dass sich etwas getan hat. So prüfen Sie es selbst: Öffnen Sie eine Seite mit Produkten oder einem Formular. Führen Sie eine Aktion durch, bei der sich der Inhalt ändert, etwa ein Produkt zum Warenkorb hinzufügen oder ein Formularfeld ausfüllen. Erscheint daraufhin eine Meldung auf dem Bildschirm, die die Änderung ankündigt (etwa »Produkt hinzugefügt« oder »Feld ausgefüllt«)? Oder passiert die Änderung still, ohne dass ein Benutzer mitbekommt, dass sich etwas verändert hat?
Ein Programm kann überprüfen, ob im Code Strukturen für automatische Statusmeldungen vorhanden sind, aber nicht beurteilen, ob diese sinnvoll eingesetzt sind und zur richtigen Zeit ausgelöst werden. |
prüfen wir noch nicht |
§ 12 Nummer 3 BFSGV verlangt, dass Webseiten wahrnehmbar, bedienbar, verständlich und robust sind. Diese vier Begriffe sind die Prinzipien der WCAG, die den Umfang aber nicht selbst festlegt. Konkret wird der Maßstab über die Konformitätsvermutung des § 4 BFSG. Die dafür vorgesehenen harmonisierten Normen aus dem Auftrag M/587 sind noch nicht im Amtsblatt der EU veröffentlicht; die Bundesfachstelle Barrierefreiheit nennt bis dahin die EN 301 549 als maßgebliche Orientierung, deren Webteil die WCAG 2.1 auf Stufe AA übernimmt. Wir messen deshalb an diesem Maßstab und nicht an einer Vorschrift, die es in dieser Form noch nicht gibt.