Geprüft am 31.8.2026 · https://www.amazon.de/
1 kritische Barriere · zusätzlich 1 zu prüfen.
Wie kommt der Score zustande? (100 Startpunkte)
| Kein oder leerer <title> | -18 |
| Keine <h1>-Überschrift im ausgelieferten HTML | -7 |
| Ergebnis | 75 / 100 |
Bedienbar
Kein oder leerer <title>
Der Seitentitel ist die erste Orientierung für Screenreader- und Tab-Nutzer.
<head>
Das solltest du tun: Einen aussagekräftigen, seitenspezifischen <title> vergeben.
Keine <h1>-Überschrift im ausgelieferten HTML
Jede Seite sollte mit genau einer h1 beginnen. Bei per JavaScript aufgebauten Seiten kann die h1 erst im Browser entstehen — dann im gerenderten DOM prüfen.
body
Das solltest du tun: Eine aussagekräftige <h1> als erste Überschrift einfügen (möglichst schon serverseitig).
Nächste Schritte
- Kein oder leerer <title>. Einen aussagekräftigen, seitenspezifischen <title> vergeben.
- Keine <h1>-Überschrift im ausgelieferten HTML. Eine aussagekräftige <h1> als erste Überschrift einfügen (möglichst schon serverseitig).
Wöchentlicher Re-Scan, JS-gerendert, E-Mail bei neuen Barrieren — kommt bald.
Barrierefreiheitserklärung erstellen →
Methodik & Grenzen
Geprüft wurde am 31.8.2026 das HTML, das www.amazon.de beim ersten Aufruf ohne Login ausliefert, plus bis zu vier verlinkte CSS-Dateien derselben Domain. Geprüft: Farbkontrast (aus CSS), Textalternativen, Formular-Beschriftung, Bedienelement-Namen, Überschriften-Struktur, Seitentitel und -sprache, Zoom-Sperre, doppelte IDs, positive tabindex-Werte, Landmarks.
Nicht geprüft: alles, was per JavaScript entsteht, Tastatur-Bedienbarkeit, sichtbarer Fokus, Fokus-Reihenfolge, Screenreader-Ansage, Inhalte hinter Login, Unterseiten. Der automatische Test findet grob 20–35 % der WCAG-Verstöße — der Rest braucht eine manuelle Prüfung. Momentaufnahme, kein Rechtsurteil.
Overlay-Widgets (Barrierefreiheits-Buttons, die Kontrast oder Schrift umschalten) stellen keine Konformität her — die gefundenen Barrieren müssen im Quellcode behoben werden. Warum Overlays nicht helfen