a11yglass · Barrierefreiheits-Check für Websites

Geprüft am 31.8.2026 · https://github.com/?locale=de-de

B
86 / 100
0 kritisch · 2 zu prüfen

Keine kritischen Barrieren im geprüften HTML · 2 Punkte zum Nachprüfen.

Wie kommt der Score zustande? (100 Startpunkte)
1 Schaltfläche(n) ohne Namen im HTML-7
10 doppelte id-Attribute-7
Ergebnis86 / 100
KontrastTextalternativen?Beschriftung (1)StrukturSpracheZoom?Robustheit (1)

Bedienbar

Zu prüfenWCAG 4.1.2 Name, Rolle, Wert

1 Schaltfläche(n) ohne Namen im HTML

Buttons ohne Text und ohne aria-label sind für Screenreader stumm — sofern der Name nicht per JavaScript gesetzt wird.

button

Das solltest du tun: Button-Text ergänzen oder aria-label setzen.

Robust

Zu prüfenWCAG 4.1.1 Parsen (veraltet, aber weiterhin relevant für Zuordnungen)

10 doppelte id-Attribute

z. B. clip0_1_610, clip0_1_688, clip0_43_208, clip0_99_61. Bricht label-for- und aria-Zuordnungen.

[id]

Das solltest du tun: IDs eindeutig vergeben.

Schon richtig gelöst

Nächste Schritte

  1. 1 Schaltfläche(n) ohne Namen im HTML. Button-Text ergänzen oder aria-label setzen.
  2. 10 doppelte id-Attribute. IDs eindeutig vergeben.
Diese Seite automatisch überwachen?

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 github.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, Seiten­titel 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.

Andere Website prüfen