Scanaris
Kostenlos scannen
← Alle Checks
BarrierefreiheitTypische Schwere: Niedrig

Web-Accessibility-Analyse

Prüft Sprache, Alt-Texte der Bilder, Formularbeschriftungen, Viewport und doppelte IDs anhand der WCAG-Regeln.

Was es prüft

Dieser Scanner prüft grundlegende Barrierefreiheits-Aspekte deiner Seite anhand der WCAG-Regeln: die deklarierte Sprache, den Alt-Text der Bilder, die Formular-Labels, das viewport-Tag und doppelte IDs. Er zeigt auf, wo deine Seite Menschen mit Behinderungen die Nutzung erschwert.

Warum es wichtig ist

Eine wenig barrierefreie Seite schließt Menschen aus, die Screenreader oder andere Hilfsmittel nutzen, und in vielen Ländern ist sie auch eine gesetzliche Pflicht. Das zu vernachlässigen verkleinert dein tatsächliches Publikum und kann dich Beschwerden wegen Nichteinhaltung aussetzen.

Wie man es behebt

Füge deinen Bildern beschreibenden Alt-Text hinzu, verknüpfe jedes Formularfeld mit seinem Label und deklariere die Seitensprache im html-Tag. Behebe doppelte IDs und stelle sicher, dass du ein viewport-Tag hast, damit die Seite auf dem Handy gut funktioniert.

Wie diese Prüfung funktioniert

Scanaris analysiert das HTML, das deine Seite ausliefert, ohne JavaScript auszuführen oder einen Browser zu öffnen, und führt acht Barrierefreiheitstests durch, die sich am Code mit Sicherheit entscheiden lassen. Drei haben mittleren Schweregrad: dass das <html>-Tag die Sprache mit lang angibt, dass die <meta name="viewport"> existiert, und dass kein Formularfeld (input, select, textarea, ohne versteckte Felder und Buttons) ohne zugängliche Beschriftung ist, also ein <label for> hat, in einem <label> steht oder aria-label, aria-labelledby oder title trägt. Die anderen fünf haben niedrigen Schweregrad: Bilder ohne alt-Attribut (ein leeres alt="" ist für dekorative gültig; was fehlschlägt, ist das Fehlen des Attributs), Links mit href und Buttons ohne Text, ohne aria-label und ohne Bild mit alt darin, doppelte id-Attribute, Elemente mit tabindex größer als null, und leere Überschriften h1 bis h6. Jeder fehlgeschlagene Test öffnet seinen eigenen Befund mit der Anzahl.

Warum das wichtig ist

Rund 15 % der Bevölkerung haben eine Behinderung, und viel mehr Menschen nutzen das Web in bestimmten Momenten mit Screenreader, nur per Tastatur oder mit maximalem Zoom. Für sie ist ein Bild ohne alt eine Lücke, ein Feld ohne Beschriftung ein Kasten, von dem man nicht weiß, was hineingehört, und ein Button, der nur ein Icon ist, wird als „Schaltfläche" angesagt, mehr nicht. Über die Ethik hinaus ist es Gesetz: Der European Accessibility Act gilt seit Juni 2025 für die meisten digitalen Dienste von Unternehmen, und in den USA gehen die Klagen wegen unzugänglicher Websites jedes Jahr in die Tausende. Und es ist SEO: alt, Sprache und Überschriftenstruktur sind genau das, was Google liest.

So behebst du es

  • Sprache: <html lang="de">. In Nuxt wird es in app.head.htmlAttrs gesetzt oder vom i18n-Modul; in Next.js am <html> des Root-Layouts; in WordPress schreibt es language_attributes() im Theme.
  • Viewport: <meta name="viewport" content="width=device-width, initial-scale=1">. Ohne maximum-scale=1 oder user-scalable=no, die den Zoom blockieren.
  • Formularbeschriftungen: ein <label for="email"> pro Feld mit seiner id, oder das Feld innerhalb des <label>. Zeigt das Design keine sichtbare Beschriftung, aria-label="E-Mail-Adresse". Der placeholder zählt nicht: Er verschwindet beim Tippen.
  • Bilder: beschreibendes alt bei informativen („Umsatzdiagramm drittes Quartal"), alt="" bei dekorativen. Die Bildkomponenten von Nuxt und Next.js verlangen das Attribut.
  • Icon-Links und -Buttons: aria-label="Menü öffnen" oder ein visuell versteckter Text mit einer sr-only-Klasse. Inline-SVG-Icons bekommen aria-hidden="true".
  • Doppelte Ids: stammen meist von wiederholten Komponenten mit fest codierter Id. Leite die Id aus einer Prop ab oder nutze useId().
  • Positive Tabindex: ändere sie auf 0 und ordne die Elemente im HTML in der Reihenfolge, in der sie durchlaufen werden sollen.
  • Leere Überschriften: dienten sie dem Layout, ersetze sie durch ein div; enthalten sie ein Icon, gib ihnen Text.

Prüf, ob es behoben ist

curl -s https://deinedomain.de | grep -oE '<html[^>]*>|<meta name="viewport"[^>]*>'
curl -s https://deinedomain.de | grep -oE '<img[^>]*>' | grep -vc 'alt='

Der erste Befehl sollte lang und den Viewport zeigen; der zweite 0 ergeben. Für den Rest listen dir das Lighthouse-Panel von Chrome (Reiter Barrierefreiheit) oder die Erweiterung axe DevTools jedes Element mit seinem Selektor.

Häufige Fragen

Bedeutet das Bestehen dieser acht Tests, dass meine Seite barrierefrei ist?

Nein. Es sind die acht, die sich ohne Browser mit Sicherheit prüfen lassen. Farbkontrast, sichtbarer Fokus, tatsächliche Lesereihenfolge und mit JavaScript gebaute Komponenten brauchen eine Prüfung mit Browserwerkzeugen und, für etwas Ernsthaftes, ein menschliches Audit. Sie zu bestehen bedeutet aber, dass du die häufigsten und am leichtesten vermeidbaren Fehler nicht machst.

Meine App ist eine SPA und das anfängliche HTML ist fast leer.

Dann sieht die Prüfung wenig, und Google auch. Ein Grund mehr, zumindest den Hauptinhalt serverseitig zu rendern; Inhalt ohne JavaScript erklärt es.

Warum ist ein leeres alt korrekt, ein fehlendes aber nicht?

Weil alt="" dem Screenreader sagt „überspring dieses Bild, es ist dekorativ", während der Reader ohne Attribut den Dateinamen vorliest, der meist so etwas wie IMG_4821.jpg ist. Die Überschriftenstruktur, die die Navigation per Screenreader beeinflusst, prüft auch Überschriften.

Prüf es auf deiner Website

Scanne deine Website kostenlos und sieh, ob dieser und 44 weitere Checks bestehen, mit einem Fix-Prompt für jedes Problem.

Meine Website kostenlos scannen