Rudra Analyzer

Kostenloser Barrierefreiheits-Checker

Lassen Sie die Barrierefreiheits-Engine axe-core in einem echten Browser über Ihre Seite laufen, um häufige Barrieren zu finden – etwa Formularfelder ohne Beschriftung, geringen Farbkontrast, Bilder ohne Textalternative und ARIA-Fehler – und erfahren Sie, wie Sie sie beheben.

Geben Sie eine Seite ein, zum Beispiel https://ihrewebsite.de oder https://ihrewebsite.de/preise.

Was dieses Tool prüft

  • Textalternativen

    Bilder, Bild-Schaltflächen und andere Nicht-Text-Inhalte ohne Textalternative, die ein Screenreader vorlesen kann.

  • Formularbeschriftungen

    Eingabefelder, Kontrollkästchen und Auswahllisten ohne zugängliche Beschriftung, sodass Hilfstechnologien nicht sagen können, wofür sie da sind.

  • Farbkontrast

    Text, dessen Farbe dem Hintergrund zu ähnlich ist, um die WCAG-AA-Kontrastverhältnisse zu erfüllen.

  • Namen für Links und Schaltflächen

    Links und Schaltflächen ohne lesbaren Namen – oft reine Symbol-Schaltflächen.

  • ARIA

    ARIA-Rollen und -Attribute, die ungültig sind, auf diesem Element nicht erlaubt sind oder denen erforderliche Teile fehlen.

  • Seitenstruktur

    Eine Seitensprache, ein Seitentitel, Landmarks und weitere Strukturregeln aus WCAG und den Best Practices von axe-core.

  • Wie viele Elemente betroffen sind

    Für jedes Problem (bis zu 25 Arten), wie viele Elemente betroffen sind, und ein Beispiel, wo eines zu finden ist.

So funktioniert die Prüfung

Wir laden Ihre Seite in Headless-Chromium, fügen die axe-core-Bibliothek hinzu und wenden ihren Standard-Regelsatz auf die gerenderte Seite an – per JavaScript hinzugefügte Inhalte werden also ebenfalls getestet. Der Standardsatz umfasst WCAG 2.x-Regeln der Stufen A und AA plus die Best Practices von axe-core.

Jede nicht bestandene Regel senkt die Bewertung je nach Auswirkung: 15 Punkte für kritisch, 10 für schwerwiegend, 5 für mittel und 2 für gering. Der Abzug erfolgt pro Regel, nicht pro Element – eine fehlende Beschriftung kostet also genauso viel wie zwanzig; das Problem zeigt Ihnen, wie viele Elemente betroffen sind.

Automatische Tests finden nur einen Teil der Barrierefreiheitsprobleme, die eine Seite haben kann. Viele muss ein Mensch beurteilen – ob Alt-Texte wirklich aussagekräftig sind, ob die Tastaturreihenfolge sinnvoll ist, ob Inhalte verständlich sind. Betrachten Sie diese Prüfung als Ausgangspunkt, nicht als Zertifikat.

Häufige Probleme, die wir finden

  • Text mit geringem Kontrast

    Hellgrauer Text, Text auf farbigen Schaltflächen und Platzhaltertext anstelle einer Beschriftung.

  • Bilder ohne Alt-Text

    Logos, Produktfotos und Bilder, die als Links dienen.

  • Formularfelder ohne Beschriftung

    Suchfelder und Newsletter-Anmeldungen, die sich nur auf Platzhaltertext verlassen.

  • Reine Symbol-Schaltflächen und -Links

    Menü-, Schließen-, Social-Media- und Warenkorb-Symbole ohne Text für Screenreader.

  • Fehlende Seitensprache

    Kein lang-Attribut am html-Element, sodass Screenreader möglicherweise die falsche Aussprache verwenden.

  • Falsch eingesetztes ARIA

    Rollen auf den falschen Elementen oder Verweise auf IDs, die nicht existieren.

So beheben Sie sie

  1. Text abdunkeln oder Hintergründe aufhellen

    Streben Sie ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text an. Ein Kontrastprüfer in den Entwicklertools Ihres Browsers zeigt das Verhältnis an.

  2. Alt-Text hinzufügen, der sagt, wofür das Bild da ist

    Beschreiben Sie, was im Zusammenhang wichtig ist – „Preisliste herunterladen“ für einen Symbol-Link, nicht „Symbol“. Verwenden Sie alt="" für rein dekorative Bilder.

  3. Jedem Feld eine sichtbare Beschriftung geben

    Verwenden Sie ein label-Element, das mit dem Eingabefeld verknüpft ist. Wenn ein Design wirklich keines zeigen kann, verwenden Sie aria-label – sichtbare Beschriftungen helfen aber allen.

  4. Symbol-Schaltflächen benennen

    Fügen Sie visuell verborgenen Text oder ein aria-label hinzu, zum Beispiel aria-label="Menü öffnen".

  5. Natives HTML ARIA vorziehen

    Ein echtes button- oder link-Element ist von Haus aus zugänglich. Fügen Sie ARIA nur hinzu, wenn es kein natives Element für die Aufgabe gibt.

  6. Auch von Hand testen

    Versuchen Sie, die Seite nur mit der Tastatur und mit einem Screenreader wie NVDA oder VoiceOver zu bedienen, um zu finden, was automatische Regeln nicht erkennen.

Häufig gestellte Fragen

Wenn ich diese Prüfung bestehe, ist meine Website dann WCAG-konform?

Nein. Bestehen heißt, dass die automatischen Regeln keine Probleme gefunden haben. Viele WCAG-Anforderungen kann nur ein Mensch prüfen, daher erfordert Konformität auch eine manuelle Prüfung.

Testet es Tastaturnavigation oder Screenreader?

Nein. axe-core untersucht den Code und die berechneten Stile der Seite. Es kann nicht beurteilen, ob die Tab-Reihenfolge sinnvoll ist oder wie ein Screenreader die Seite tatsächlich vorliest – testen Sie das von Hand.

Welche WCAG-Version und -Stufe wird verwendet?

Der Standard-Regelsatz von axe-core: WCAG 2.x-Regeln der Stufen A und AA plus Best-Practice-Regeln. Regeln der Stufe AAA sind nicht enthalten.

Warum hat das Beheben eines Elements meine Bewertung nicht verändert?

Die Bewertung sinkt einmal pro nicht bestandener Regel, unabhängig von der Anzahl der Elemente. Eine Regel zählt erst dann nicht mehr gegen Sie, wenn jedes markierte Element behoben ist.

Kann es Seiten hinter einem Login prüfen?

Nein. Wir können nur Seiten testen, die ohne Anmeldung öffentlich laden.

Hilfreiche Ratgeber

Ähnliche kostenlose Tools

Soll lieber jemand anderes es beheben?

Diese Prüfungen sind kostenlos, ebenso die Ratgeber. Wenn ein Mensch die Änderungen vornehmen soll, bietet unser Team kostenpflichtige Hilfe an.

Professionelle Hilfsangebote ansehenSo testen und bewerten wirAlle kostenlosen Tools