Geprüft am 24.9.2026 · https://citeglass.com/
Keine kritischen Barrieren im geprüften HTML · 1 Punkt zum Nachprüfen.
Seit dem letzten Scan: keine Änderung.
Wie kommt der Score zustande? (100 Startpunkte)
| 1 Formularfeld(er) ohne erkennbare Beschriftung | -7 |
| Ergebnis | 93 / 100 |
Wahrnehmbar
1 Formularfeld(er) ohne erkennbare Beschriftung
Prüfe, ob ein per JavaScript gesetztes aria-label existiert.
<input type="text" name="website">
Das solltest du tun: Jedes Feld mit einem <label for>-Element verbinden oder aria-label / aria-labelledby setzen. Nur ein placeholder reicht nicht.
Schon richtig gelöst
- Sprung-Link zum Inhalt vorhanden
- <main>-Landmark vorhanden
- Kontrast: keine eindeutigen Verstöße im CSS gefunden
Nächste Schritte
- 1 Formularfeld(er) ohne erkennbare Beschriftung. Jedes Feld mit einem <label for>-Element verbinden oder aria-label / aria-labelledby setzen. Nur ein placeholder reicht nicht.
Wöchentlicher Re-Scan, JS-gerendert, E-Mail bei neuen Barrieren — kommt bald.
Barrierefreiheitserklärung erstellen →
Methodik & Grenzen
Geprüft wurde am 24.9.2026 das HTML, das citeglass.com 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