Barrierefreiheitszertifikat – Startseite
Kostenlos prüfen Menü

Für Entwickler

Befunde, mit denen Sie direkt weiterarbeiten können

Keine pauschale Note, sondern Kriterium, Fundstelle, Screenshot und Hinweis zur Behebung. Dazu kostenlose Werkzeuge, mit denen Sie vor dem Audit selbst testen.

Kostenlos prüfenAudit anfragen

Was Sie aus unserem Bericht herausholen

Jeder Befund nennt das WCAG-Kriterium, die Seite, das betroffene Element und einen Screenshot. Dazu ein Hinweis, wie sich der Fehler beheben lässt. Sie müssen nicht raten, was gemeint ist.

Wir prüfen, was im Browser ankommt. Welches Framework Sie nutzen, spielt keine Rolle. Entscheidend sind das ausgelieferte HTML, die Rollen und Namen im Barrierefreiheitsbaum und das Verhalten mit Tastatur und Screenreader.

Eine Schnittstelle für Ihre Build-Pipeline und einen Export nach Jira oder GitHub gibt es derzeit nicht.

So testen Sie selbst, bevor wir kommen

Fünf Tests, für die Sie nur Ihren Browser brauchen.

Nur Tastatur

Maus weglegen, mit Tab, Umschalt+Tab, Enter, Leertaste und Pfeiltasten durch die Seite. Sehen Sie immer, wo der Fokus ist? Der Tastatur-Test zeigt die Fokus-Spur.

200 Prozent Zoom und 320 Pixel

Browser auf 200 Prozent zoomen, Fenster schmal ziehen. Nichts darf abgeschnitten werden oder seitlich herausragen.

Kontraste

Textfarben und Rahmen von Bedienelementen gegen den Hintergrund messen. Der Kontrast-Checker schlägt die nächste passende Farbe vor.

Barrierefreiheitsbaum

In den Entwicklerwerkzeugen des Browsers sehen Sie Rolle und Namen jedes Elements. Eine Schaltfläche ohne Namen fällt dort sofort auf.

Screenreader

NVDA unter Windows oder VoiceOver unter macOS. Schon fünf Minuten zeigen, ob Überschriften, Formulare und Dialoge verständlich angesagt werden.

Wer im Team was beiträgt

Barrierefreiheit entsteht nicht am Ende im Test, sondern in jeder Rolle. Typische Kriterien je Rolle:

Kriterien, die im Code entschieden werden

  • 4.1.2Name, Rolle, Wert

    Eigene Komponenten brauchen Name, Rolle und Zustand. Nutzen Sie native Elemente, wo es geht.

  • 2.1.1Tastatur

    Alles, was mit der Maus geht, muss mit der Tastatur gehen. Ein div mit Klick-Handler reicht nicht.

  • 2.4.7Fokus sichtbar

    Den Fokusrahmen nicht entfernen, sondern gestalten, etwa mit :focus-visible.

  • 1.3.1Info und Beziehungen

    Struktur gehört ins Markup: Überschriften, Listen, Tabellen, Fieldsets, Landmarks.

  • 4.1.3Statusmeldungen

    Statusmeldungen über eine Live-Region ansagen, ohne den Fokus zu verschieben.

  • 2.5.8Zielgröße (Minimum)

    Neu in WCAG 2.2: Klickziele mindestens 24 mal 24 CSS-Pixel oder ausreichend Abstand.

Vom Befund zum bestandenen Kriterium

  1. Bericht lesen

    Befunde nach Kriterium sortiert, mit Fundstelle und Screenshot.

  2. Vorlagen zuerst

    Ein Fehler im Header steckt in jeder Seite. Beheben Sie ihn einmal in der Vorlage.

  3. Selbst gegenprüfen

    Mit Tastatur, Zoom und Screenreader, wie oben beschrieben.

  4. Nachprüfung

    Wir prüfen die durchgefallenen Kriterien erneut und entscheiden neu.

Häufige Fragen

Welche automatischen Regeln nutzen Sie?

axe-core auf jeder Seite, dazu eigene Messungen für Tastatur, Umbruch, Zoom und Textabstände. Details stehen in der Prüfmethode.

Wir haben in unseren eigenen Tests keine Fehler. Warum fällt trotzdem etwas durch?

Automatische Tests finden nur einen Teil der Probleme. Ob ein Alternativtext passt, die Reihenfolge Sinn ergibt oder ein Fehlertext hilft, sieht nur ein Mensch.

Gibt es eine Schnittstelle oder eine CI-Anbindung?

Derzeit nicht. Bis dahin finden Sie auf dieser Seite Prüfungen, die Sie selbst in Ihre Abläufe einbauen können.

Wo finde ich Erklärungen zu einzelnen Kriterien?

In der Übersicht aller 55 Kriterien, jeweils mit Erklärung und Beispielen.

Passend dazu