Praktisches Barrierefreiheits-Audit: Tools & Workflow

Mariusz Szatkowski

DE

5.00 /5 - (11 Stimmen )

Zuletzt überprüft: 1. Mai 2026

29Min. Lesezeit

Leitfaden

500+ WP-Projekte

Die EAA-Frist vom 28. Juni 2025 ist verstrichen. Wer WordPress-Seiten für Mandanten betreut, die in der EU an Verbraucher verkaufen (E-Commerce, Banken, Verkehr, Ticketing, E-Books), trägt jetzt unmittelbar die Haftung des Mandanten weiter, wenn die Seite nicht WCAG 2.2 AA erfüllt. Das Audit ist kein “nettes Beratungs-Add-on” mehr, sondern das Dokument, das die Rechtsabteilung verlangt, sobald die erste Beschwerde eingeht.

In Deutschland ist der Rahmen vertraut: das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EAA seit dem 28. Juni 2025 für den Privatsektor um, ergänzend zur seit Jahren bestehenden Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) für die öffentliche Hand. Die Bundesfachstelle Barrierefreiheit prüft öffentliche Stellen, die Marktüberwachungsbehörden der Länder ziehen die BFSG-Verstöße im Privatsektor ein. DSGVO und Barrierefreiheit greifen ineinander, sobald ein Mandant Kontaktformulare oder Konten anbietet.

Dieser Text ist der Workflow, den wir auf WordPress-Projekten tatsächlich fahren: mit welchen automatisierten Tools man beginnt, wo sie aufhören nützlich zu sein, und wie man die Teile von WCAG 2.2 abdeckt, die nur ein Mensch mit Tastatur und NVDA verifizieren kann.

#Wo die Haftung tatsächlich sitzt

Eine nützliche Klammer, bevor man irgendein Tool öffnet: die EAA betrifft nicht nur “den öffentlichen Sektor”. Sie betrifft verbraucherorientierte Dienste. Private Mandanten, die wir in den letzten zwölf Monaten auditiert haben und die im Anwendungsbereich lagen: ein polnischer E-Book-Shop, ein deutscher Möbel-E-Commerce und eine kleine EU-weite Buchungsplattform auf WooCommerce. Keiner hat es bemerkt, bis der eigene Compliance-Beauftragte den Punkt aufrief.

Einer dieser Mandanten (ein WooCommerce-Shop, der nach Deutschland und Frankreich verkauft) erhielt zwei Monate nach Launch eine schriftliche Beschwerde. Auslöser war ein angepasster Checkout-Schritt, bei dem der “weiter zur Zahlung”-Auslöser als <div onclick="..."> statt als Button gebaut war. Tastatur-Nutzer konnten ihn nicht erreichen, NVDA meldete im Fokus nichts. Die Korrektur war klein (Ersatz durch <button type="button">, native Fokus-Behandlung wiederherstellen, den Schrittwechsel mit aria-live="polite" ankündigen), aber der juristische Schriftverkehr verschlang etwa eine Woche Agenturzeit. So sieht das Risiko aus: keine spektakuläre Klage, sondern langsame, teure Korrespondenz, die man durch ein Audit vor dem Launch und bei jedem PR mit DOM-Änderung vermeidet.

WCAG 2.2 selbst bringt drei Kriterien, die eng auf typische WordPress- und WooCommerce-Schwächen abbilden:

2.4.11 Fokus nicht verdeckt (AA) und 2.4.13 Fokus-Aussehen (AAA) - Sticky-Header, Cookie-Banner und Chat-Widgets verdecken regelmäßig das fokussierte Element. Auf jedem Template prüfen.
2.5.7 Ziehbewegungen (AA) - jede Drag-only-Interaktion (Slider-Toggles, Kanban-artiges Sortieren in Admin-UIs, Bildvergleichs-Slider im Frontend) braucht eine Single-Pointer-Alternative wie Plus-/Minus-Buttons oder Tastatureingabe.
2.5.8 Zielgröße Minimum (AA) - interaktive Ziele müssen mindestens 24×24 CSS-Pixel groß sein. Theme-Footer, Pagination-Links und Social-Icon-Streifen scheitern hier auf Mobile fast immer.

Der WordPress-Kern ist beim Block-Editor und den Frontend-Navigationsprimitiven solide barrierefrei. Was wir in Audits finden, sitzt fast immer an drei Stellen: Custom-ACF-Blöcken (die nichts von Gutenbergs ARIA-Verdrahtung erben), Theme-Komponenten-Overrides und Drittanbieter-Page-Buildern. Plane das Audit darum herum, nicht um den Kern.

#WCAG 2.2 verstehen: Die Grundlage des Barrierefreiheits-Audits

Bevor wir in Tools und Workflows eintauchen, müssen Auditoren das Framework der Web Content Accessibility Guidelines (WCAG) 2.2 verstehen. Veröffentlicht im Oktober 2023, baut WCAG 2.2 auf früheren Versionen auf und führt neun neue Erfolgskriterien ein, die sich auf kognitive und motorische Barrierefreiheit konzentrieren.

#Die vier Prinzipien der Barrierefreiheit

WCAG 2.2 organisiert Barrierefreiheits-Anforderungen um vier grundlegende Prinzipien, die gemeinhin durch das Akronym POUR (Perceivable, Operable, Understandable, Robust) zusammengefasst werden:

#1. Wahrnehmbar (Perceivable)

Informationen und Komponenten der Benutzeroberfläche müssen den Nutzern in einer Weise präsentiert werden, dass sie diese wahrnehmen können. Dieses Prinzip umfasst:

Textalternativen für Nicht-Text-Inhalte (Bilder, Videos, Audio)
Untertitel und Transkripte für Multimedia
Farbkontrast und Textvergrößerungsmöglichkeiten
Inhalte, die sich nicht ausschließlich auf sensorische Merkmale stützen

#2. Bedienbar (Operable)

Komponenten der Benutzeroberfläche und Navigation müssen von allen Nutzern bedienbar sein. Wichtige Anforderungen umfassen:

Vollständige Tastatur-Zugänglichkeit
Ausreichende Zeitlimits mit Möglichkeit zur Verlängerung
Vorbeugung von Anfällen und physischen Reaktionen
Klare Navigation und Orientierung

#3. Verständlich (Understandable)

Informationen und die Bedienung der Benutzeroberfläche müssen verständlich sein:

Lesbarer und verständlicher Textinhalt
Vorhersehbare Funktionalität und Navigation
Eingabehilfe und Fehlervermeidung
Konsistente Identifizierung und Beschriftung

#4. Robust (Robust)

Inhalte müssen robust genug sein, um mit aktuellen und zukünftigen Hilfstechnologien zu funktionieren:

Valides, wohlgeformtes HTML
Kompatibilität mit Hilfstechnologien
Prinzipien der progressiven Verbesserung
Standardkonformes Markup

#WCAG 2.2 Konformitätsstufen

WCAG 2.2 definiert drei Stufen der Konformität, die jeweils auf der vorherigen aufbauen:

Stufe	Beschreibung	Typischer Anwendungsfall
A	Minimale Barrierefreiheits-Anforderungen; behandelt die kritischsten Barrieren	Grundlegende Konformität, selten allein ausreichend
AA	Industriestandard; behandelt wichtige Barrierefreiheits-Barrieren	Von den meisten Gesetzen gefordert (EAA, ADA, AODA)
AAA	Erweiterte Barrierefreiheit; die höchste Konformitätsstufe	Spezialisierte Anwendungen, aspiratives Ziel

Die meisten gesetzlichen Anforderungen schreiben die WCAG 2.2 Level AA-Konformität vor. Dieser Artikel konzentriert sich auf das Erreichen und Aufrechterhalten der Level AA-Konformität.

#Neu in WCAG 2.2

WCAG 2.2 führt neun neue Erfolgskriterien ein, die Auditoren verstehen müssen:

2.4.11 Fokus nicht verdeckt (AA): Fokus-Indikatoren dürfen nicht von anderem Inhält verdeckt werden
2.4.12 Fokus nicht verdeckt (Erweitert) (AAA): Strengere Anforderungen an die Fokus-Sichtbarkeit
2.4.13 Fokus-Aussehen (AAA): Spezifische Anforderungen an Größe und Kontrast des Fokus-Indikators
2.5.7 Ziehbewegungen (AA): Alternativen zu Ziehbewegungen für Zeigereingaben
2.5.8 Zielgröße (Minimum) (AA): Minimale Zielgröße von 24×24 CSS-Pixeln
3.2.6 Konsistente Hilfe (A): Hilfemechanismen an konsistenten Positionen
3.3.7 Redundante Eingabe (A): Vermeidung der erneuten Eingabe bereits eingegebener Informationen
3.3.8 Barrierefreie Authentifizierung (Minimum) (AA): Keine kognitiven Funktionstests für die Authentifizierung erforderlich
3.3.9 Barrierefreie Authentifizierung (Erweitert) (AAA): Keine kognitiven Funktionstests mit Alternativen

#Automatisierte Tools: was sie tatsächlich finden

Sei ehrlich gegenüber dem Mandanten: automatisierte Barrierefreiheits-Tools decken grob 30 bis 40 Prozent der WCAG-Erfolgskriterien ab. Sie erkennen fehlende Alt-Attribute, fehlende Formular-Labels, unzureichenden Kontrast bei statischem Text, fehlende Sprachattribute, doppelte IDs und offensichtlich kaputtes ARIA. Sie sagen dir nicht, ob dein Alt-Text aussagekräftig ist, ob die Fokus-Reihenfolge sinnvoll ist, ob ein Screenreader eine Zustandsänderung ankündigt oder ob dein Custom-Carousel ohne Maus funktioniert. Die restlichen 60 bis 70 Prozent brauchen einen Menschen mit Tastatur, Screenreader und Geduld.

Lass die automatischen Prüfungen zuerst laufen, weil sie billig sind und die offensichtlichen Treffer wegräumen, bevor du Zeit ins manuelle Testen steckst. Beginne mit axe DevTools (Deque) als Browser-Erweiterung während der Entwicklung - die WCAG-2.2-Tags landen direkt im Audit-Bericht, und die Trennung von “muss überprüft werden” und definitiven Verstößen hält die False-Positive-Rate nahe Null. Scanne pro distinkten Templates (Startseite, Archiv, Single, Produkt, Checkout, Kontakt, Login, Suchergebnisse), nicht pro URL - die meisten WordPress-Seiten haben unter zehn distinkte Templates, auch wenn sie tausende Seiten ausliefern. WebAIM WAVE taugt als zweite Meinung und ist stark in der visuellen Darstellung der Überschriften-Struktur, wenn ein Redakteur “h4 weil es richtig aussieht” verbaut hat. Pa11y in GitHub Actions oder Bitbucket Pipelines fängt Regressionen im PR ab, wo sie am billigsten zu reparieren sind. Tenon-API rechnet sich erst, wenn fünf oder sechs Mandantenseiten unter einem Agentur-Dach liegen.

#Browser-Erweiterungen für sofortiges Feedback

#axe DevTools

Entwickelt von Deque Systems, ist axe DevTools der Industriestandard für browserbasierte Barrierefreiheits-Tests. Die kostenlose Browser-Erweiterung bietet:

Keine falschen Positiven: axe wurde entwickelt, um nur Probleme zu melden, die es verifizieren kann, um Rauschen zu minimieren
WCAG 2.2 Abdeckung: Umfassende Unterstützung für alle WCAG 2.2-Erfolgskriterien
Intelligentes Testen: Unterscheidet zwischen “muss überprüft werden” und definitiven Verstößen
Bereit für Integration: Ergebnisse können für die Dokumentation exportiert werden

Installation und grundlegende Verwendung:

Installieren Sie die axe DevTools-Erweiterung aus dem Chrome Web Store oder Firefox Add-ons
Navigieren Sie zur Seite, die Sie testen möchten
Öffnen Sie die Browser-DevTools (F12) und wählen Sie den Tab “axe DevTools”
Klicken Sie auf “Scan all of my page” für eine umfassende Analyse
Überprüfen Sie die Ergebnisse nach Schweregrad kategorisiert: Kritisch, Ernsthaft, Moderat, Geringfügig

Interpretation der axe-Ergebnisse:

Kritisch: Blockiert assistive Technologien vollständig
  Beispiel: Fehlende Formular-Labels, leere Buttons

Ernsthaft: Verursacht erhebliche Barrieren für einige Nutzer
  Beispiel: Unzureichender Farbkontrast, fehlender Alt-Text

Moderat: Verursacht Frustration oder langsameren Aufgabenabschluss
  Beispiel: Mehrdeutiger Link-Text, übersprungene Überschriften-Ebenen

Geringfügig: Geringfügige Unannehmlichkeit oder Verstoß gegen Best Practices

#WAVE (Web Accessibility Evaluation Tool)

WAVE, entwickelt von WebAIM, bietet einen visuellen Ansatz für Barrierefreiheits-Tests:

Visuelle Überlagerungen: Probleme werden direkt auf der Seite hervorgehoben
Symbole und Indikatoren: Farbcodierte Symbole zeigen Fehlertypen auf einen Blick
Keine Registrierung erforderlich: Vollständig kostenlos, kein Konto nötig
Detail-Panel: Detaillierte Erklärungen neben visuellen Indikatoren

Effektive Nutzung von WAVE:

Installieren Sie die WAVE-Browser-Erweiterung oder verwenden Sie die Online-Version unter wave.webaim.org
Klicken Sie auf das WAVE-Symbol, um die Bewertung zu aktivieren
Überprüfen Sie das Zusammenfassungspanel mit Fehlern, Warnungen, Funktionen, Strukturelementen und ARIA
Klicken Sie auf ein beliebiges Symbol auf der Seite, um detaillierte Informationen zu sehen
Verwenden Sie den Tab “Reference”, um die WCAG-Anforderungen zu verstehen

#Accessibility Insights for Web

Microsofts Accessibility Insights bietet zwei Testmodi:

FastPass: Schnelle automatisierte Prüfungen (2 Minuten)
Assessment: Umfassender manueller Test mit geführtem Workflow (30+ Minuten)

Das Tool ist besonders wertvoll für Teams, die bereits Microsoft-Entwicklungstools verwenden, und integriert sich gut in Azure DevOps.

#WordPress-spezifische Barrierefreiheits-Plugins

#WP Accessibility

WP Accessibility behandelt häufige WordPress-Barrierefreiheits-Probleme, ohne dass Code-Änderungen erforderlich sind:

Funktionen:

Entfernt target-Attribute von Links (verhindert unerwartete neue Fenster)
Fügt Skip-Links für die Tastatur-Navigation hinzu
Erzwingt Alt-Attribute auf Bildern (mit Fallback-Handling)
Fügt Labels zu Standard-WordPress-Formularen hinzu
Bietet Toolbar mit Schriftgrößen- und Kontrast-Steuerungen

Best Practices für die Konfiguration:

// Empfohlene WP Accessibility-Einstellungen für die Audit-Vorbereitung
// Einstellungen → WP Accessibility

// Aktivieren: Skip-Links zum Theme hinzufügen
// Aktivieren: Landmark-Rollen zu HTML5-Strukturelementen hinzufügen
// Aktivieren: Alt-Attribute auf Bildern erzwingen
// Aktivieren: Beitragstitel zu "Weiterlesen"-Links hinzufügen
// Deaktivieren: title-Attribute entfernen (kann mit einigen Themes kollidieren)

#Accessibility Checker von Equalize Digital

Dieses Plugin bietet Echtzeit-Barrierefreiheits-Prüfung innerhalb des WordPress-Admin:

Editor-Integration: Scannt Inhalte während der Erstellung
Frontend-Scanning: Prüft veröffentlichte Seiten aus Besucherperspektive
Detaillierte Berichte: Zeigt den genauen Code, der Probleme verursacht
Bulk-Scanning: Auditieren Sie ganze Websites automatisch

Pro-Version-Funktionen:

Vollständige automatisierte Website-Scans
PDF-Berichtsgenerierung
Problem-Priorisierung
Behebungs-Anleitungen

#One Click Accessibility

Ein leichtgewichtiges Plugin für schnelle Barrierefreiheits-Verbesserungen:

Skip to content Link
Outline-Fokus für Tastatur-Navigation
Schriftgrößen-Steuerungen
Graustufen-Modus für Tests
Hell- und Hochkontrast-Modi

#CI/CD-Integration für kontinuierliche Barrierefreiheit

Automatisierte Barrierefreiheits-Tests sollten Teil Ihrer Continuous-Integration-Pipeline sein, um Regressionen zu verhindern.

#axe-core mit GitHub Actions

# .github/workflows/accessibility.yml
name: Barrierefreiheits-Tests

on: [push, pull_request]

jobs:
  accessibility:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Node.js einrichten
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Abhängigkeiten installieren
        run: npm install @axe-core/cli http-server

      - name: Website bauen
        run: npm run build

      - name: Server starten
        run: npx http-server ./dist -p 8080 &

      - name: axe Barrierefreiheits-Tests ausführen
        run: |
          npx axe http://localhost:8080 \
            --tags wcag2a,wcag2aa,wcag22aa \
            --exit

#Pa11y für automatisiertes Scanning

Pa11y ist ein Kommandozeilen-Tool, das in jede CI/CD-Pipeline integriert werden kann:

# Pa11y installieren
npm install -g pa11y

# Barrierefreiheits-Test auf einer einzelnen Seite ausführen
pa11y https://example.com --standard WCAG2AA

# Mit Aktionen ausführen (Elemente klicken, auf Inhalte warten)
pa11y https://example.com --actions "click element #menu-toggle"

# JSON-Bericht für CI-Integration generieren
pa11y https://example.com --reporter json --standard WCAG2AA > accessibility-report.json

#Lighthouse CI für Performance und Barrierefreiheit

Google’s Lighthouse CI kann Barrierefreiheits-Scores über Zeit verfolgen:

// lighthouserc.json
{
  "ci": {
    "collect": {
      "url": [
        "http://localhost:8080/",
        "http://localhost:8080/about/",
        "http://localhost:8080/contact/"
      ],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:accessibility": ["error", {"minScore": 0.9}]
      }
    }
  }
}

#Automatisiertes vs. manuelles Testen im Vergleich

Aspekt	Automatisiertes Testen	Manuelles Testen
Abdeckung	~30% der WCAG-Kriterien	~100% mit korrekter Methodik
Geschwindigkeit	Minuten für die gesamte Website	Stunden für umfassenden Audit
Kosten	Niedrig (Tools sind oft kostenlos)	Höher (erfordert Fachwissen)
Konsistenz	Hoch reproduzierbar	Hängt von Tester-Fähigkeiten ab
Falsche Positive	Minimal mit Qualitäts-Tools	Keine
Falsche Negative	Signifikant (~70% werden verpasst)	Minimal bei gründlichem Testen
Am besten geeignet für	Grundlinien-Konformität, Regressionsschutz	Umfassende Audits, rechtliche Konformität
Häufigkeit	Jede Bereitstellung	Quartalsweise oder bei Hauptversionen

#Manuelles Testen: Tastatur, Screenreader, Kontrast

Hier liegt der Großteil der Audit-Zeit, und hier sitzen auch die Kriterien, die im Beschwerdefall tatsächlich entscheiden: Tastatur-Bedienbarkeit, Screenreader-Ausgaben, Fokus-Management und Kontrast. Drei Werkzeuge in drei Sitzungen, in dieser Reihenfolge.

Maus weg. Tab durch jedes distinkte Template vom Seitenkopf bis in den Footer, dann mit Shift+Tab zurück. Jeden interaktiven Treffer mit Enter oder Leertaste auslösen. Die Fragen, die du beantwortest: Kommst du an alles, auch an Inhalte, die per Hover sichtbar werden (Mega-Menüs, Tooltips, “mehr anzeigen”)? Ist der Fokus-Indikator immer sichtbar - auf dunklen Hintergründen verschwindet der Browser-Default-Outline gerne, und 2.4.13 verlangt mindestens 2 CSS-Pixel mit 3:1 Kontrast zur Umgebung? Wird der Fokus von Sticky-Header, Cookie-Banner oder Chat-Widget verdeckt (2.4.11, der häufigste WCAG-2.2-Fund auf vor 2024 gebauten Seiten)? Gibt es Drag-only-Interaktion (Bildvergleichs-Slider, Range-Inputs als Drag-Griff, Reorder-Controls im Backend) - die brauchen unter 2.5.7 eine Single-Pointer-Alternative? Sind interaktive Ziele mindestens 24×24 CSS-Pixel groß (2.5.8) - Pagination, Footer-Social-Icons und inline “x” zum Schließen reißen das am häufigsten.

#Das Tastatur-Test-Protokoll

Schritt 1: Grundlegende Navigation

Trennen Sie Ihre Maus oder deaktivieren Sie Ihr Trackpad
Drücken Sie Tab, um durch interaktive Elemente zu navigieren (Links, Buttons, Formularfelder)
Drücken Sie Shift+Tab, um rückwärts zu navigieren
Verwenden Sie Enter, um Links und Buttons zu aktivieren
Verwenden Sie Leertaste, um Buttons und Checkboxen zu aktivieren
Verwenden Sie Pfeiltasten für Radio-Buttons, Selects und benutzerdefinierte Widgets

Schritt 2: Fokus-Sichtbarkeits-Tests

Verifizieren Sie, dass Fokus-Indikatoren klar sichtbar sind:

/* Sicherstellen, dass Fokus-Indikatoren sichtbar sind */
/* WCAG 2.2 erfordert, dass Fokus-Indikatoren mindestens 2px dick sind */

/* Gut: Klarer Fokus-Indikator */
a:focus,
button:focus,
input:focus {
  outline: 3px solid #0056b3;
  outline-offset: 2px;
}

/* Schlecht: Kein Fokus-Indikator oder unzureichender Kontrast */
a:focus {
  outline: none; /* Entfernt Fokus-Indikator vollständig */
}

Schritt 3: Logische Tab-Reihenfolge

Die Tab-Reihenfolge sollte der visuellen Lesereihenfolge folgen (typischerweise von links nach rechts, von oben nach unten). Prüfen Sie auf:

Tab-Fallen (kann nicht mit Tab weg von einem Element navigieren)
Übersprungene Elemente, die fokussierbar sein sollten
Unlogische Sprünge in der Fokus-Reihenfolge
Versteckte Elemente, die Fokus erhalten

Schritt 4: Interaktive Element-Tests

Testen Sie alle interaktiven Komponenten:

Element	Tastatur-Bedienung	Erwartetes Verhalten
Links	Tab, Enter	Zum Ziel navigieren
Buttons	Tab, Enter, Leertaste	Aktion aktivieren
Checkboxen	Tab, Leertaste	Auswahl umschalten
Radio-Buttons	Tab, Pfeiltasten	Auswahl innerhalb der Gruppe ändern
Select-Dropdowns	Tab, Pfeiltasten, Enter/Leertaste	Öffnen und Optionen auswählen
Modal-Dialoge	Tab (eingefangen), Escape	Fokus eingefangen, schließen bei Escape
Akkordeon	Tab, Enter/Leertaste, Pfeiltasten	Panels ein-/ausklappen
Tabs	Tab, Pfeiltasten, Enter	Zwischen Tab-Panels wechseln

#Häufige Tastatur-Probleme in WordPress

Problem: Fehlende Fokus-Stile in Themes

/* Fix: Sichtbare Fokus-Stile zum Theme hinzufügen */
/* Hinzufügen zu style.css oder Customizer zusätzliches CSS */

*:focus {
  outline: 2px solid #007cba;
  outline-offset: 2px;
}

/* Erweiterter Fokus für hohen Kontrast */
@media (prefers-contrast: high) {
  *:focus {
    outline: 3px solid currentColor;
    outline-offset: 3px;
  }
}

Problem: Benutzerdefinierte Dropdowns nicht tastatur-zugänglich

<!-- Schlecht: Benutzerdefiniertes Dropdown ohne Tastatur-Unterstützung -->
<div class="dropdown">
  <span class="dropdown-trigger">Menü</span>
  <div class="dropdown-content">
    <a href="#">Element 1</a>
    <a href="#">Element 2</a>
  </div>
</div>

<!-- Gut: Barrierefreies Dropdown mit ARIA -->
<div class="dropdown">
  <button
    class="dropdown-trigger"
    aria-expanded="false"
    aria-haspopup="true"
    id="menu-button"
  >
    Menü
  </button>
  <div
    class="dropdown-content"
    role="menu"
    aria-labelledby="menu-button"
    hidden
  >
    <a href="#" role="menuitem">Element 1</a>
    <a href="#" role="menuitem">Element 2</a>
  </div>
</div>

#Screenreader-Tests

Screenreader konvertieren visuelle Inhalte in Audio oder Braille. Tests mit Screenreadern decken Probleme auf, die automatisierte Tools nicht erkennen können.

#Screenreader-Optionen

Screenreader	Plattform	Kosten	Am besten geeignet für
NVDA	Windows	Kostenlos	Primäres Windows-Testing, am beliebtesten
JAWS	Windows	Bezählt (95$/Jahr)	Enterprise-Konformitäts-Testing
VoiceOver	macOS/iOS	Integriert	Apple-Ökosystem-Testing
TalkBack	Android	Integriert	Mobiles Android-Testing
Narrator	Windows	Integriert	Schnelles Windows-Testing

#NVDA Test-Workflow

NVDA (NonVisual Desktop Access) ist der am weitesten verbreitete Screenreader und unerlässlich für Windows-Barrierefreiheits-Tests.

Installation:

Download von nvaccess.org
Installer ausführen (portable Version verfügbar)
Starten mit Strg+Alt+N

Wichtige NVDA-Befehle für Tests:

Grundlegende Navigation:
- Tab: Zum nächsten fokussierbaren Element
- Umschalt+Tab: Zum vorherigen fokussierbaren Element
- H: Nächste Überschrift
- 1-6: Nächste Überschriften-Ebene 1-6
- L: Nächste Liste
- I: Nächstes Listenelement
- T: Nächste Tabelle
- F: Nächstes Formularfeld
- G: Nächste Grafik
- D: Nächstes Landmark

Lesebefehle:
- Einfügen+Pfeil nach unten: Kontinuierliches Lesen starten
- Strg: Lesen stoppen
- Einfügen+Pfeil nach oben: Aktuelle Zeile lesen
- Einfügen+Tab: Aktuellen Fokus lesen

Modus-Umschaltung:
- Einfügen+Leertaste: Zwischen Browse- und Fokus-Modus umschalten

Worauf Sie achten sollten:

Bedeutungsvolle Ansagen: Verkündet der Screenreader den Zweck jedes Elements?
Kontext: Sind Formularfelder ordnungsgemäß beschriftet?
Struktur: Werden Überschriften mit ihren Ebenen angekündigt?
Zustandsänderungen: Werden dynamische Updates angekündigt (Live-Regionen)?
Navigation: Können Sie nach Überschriften, Landmarks und Listen navigieren?

#VoiceOver-Tests auf macOS

VoiceOver ist in macOS integriert und unerlässlich für Tests auf Apple-Geräten.

Aktivierung von VoiceOver:

Cmd+F5 drücken (oder dreifach auf Touch ID auf neueren Macs klicken)
Oder: Systemeinstellungen → Bedienungshilfen → VoiceOver

Wichtige VoiceOver-Befehle:

Grundlegende Navigation:
- Cmd+F5: VoiceOver umschalten
- Strg+Option+Pfeil rechts/links: Zum nächsten/vorherigen Element navigieren
- Strg+Option+Umschalt+Pfeil nach unten: Element betreten/interagieren
- Strg+Option+Umschalt+Pfeil nach oben: Element verlassen

Web-Navigation:
- Strg+Option+Cmd+H: Nächste Überschrift
- Strg+Option+Cmd+L: Nächster Link
- Strg+Option+Cmd+J: Nächste Formular-Steuerung
- Strg+Option+Cmd+T: Nächste Tabelle

Lesen:
- Strg+Option+A: Lesen starten
- Strg: Lesen stoppen

#Mobile Screenreader-Tests

Mobile Barrierefreiheit ist kritisch, da der mobile Traffic weiter wächst.

iOS VoiceOver-Tests:

Einstellungen → Bedienungshilfen → VoiceOver → Ein
Einen Finger nach rechts wischen, um zu navigieren
Doppeltippen, um zu aktivieren
Mit drei Fingern wischen, um zu scrollen

Android TalkBack-Tests:

Einstellungen → Bedienungshilfen → TalkBack → Ein
Einen Finger nach rechts wischen, um zu navigieren
Doppeltippen, um zu aktivieren
Mit zwei Fingern wischen, um zu scrollen

#Farbkontrast-Verifizierung

WCAG 2.2 erfordert spezifische Kontrastverhältnisse für Text und UI-Komponenten.

#Kontrast-Anforderungen

Inhaltstyp	Stufe A	Stufe AA	Stufe AAA
Normaler Text (<18pt oder <14pt fett)	3:1	4.5:1	7:1
Großer Text (≥18pt oder ≥14pt fett)	3:1	3:1	4.5:1
UI-Komponenten & Grafiken	3:1	3:1	3:1
Fokus-Indikatoren (WCAG 2.2)	3:1	3:1	4.5:1

#Test-Tools

Browser DevTools:

Moderne Browser enthalten Kontrastprüfung in den DevTools:

Rechtsklick auf Element → Untersuchen
Im Styles-Panel auf Farbfeld klicken
Angezeigtes Kontrastverhältnis überprüfen
Auf grünen Haken (bestanden) oder Warnsymbol (nicht bestanden) achten

WebAIM Contrast Checker:

WebAIMs Online-Tool bietet detaillierte Analyse:

webaim.org/resources/contrastchecker/ besuchen
Vordergrund- und Hintergrundfarben eingeben
Bestanden/Nicht bestanden-Status für jede Stufe überprüfen
Helligkeitsregler verwenden, um bestehende Alternativen zu finden

Sim Daltonism:

Testen Sie, wie Ihre Website für Nutzer mit Farbsehschwächen aussieht:

macOS: Verfügbar im App Store
Windows: ColorVeil oder ähnliche Tools
Online: Colorblindly Browser-Erweiterung

#Häufige Kontrast-Probleme in WordPress

Problem: Hellgrauer Text auf weißem Hintergrund

/* Schlecht: Unzureichender Kontrast */
.text-muted {
  color: #999999; /* 2.8:1 Kontrast - FAILT WCAG AA */
}

/* Gut: Ausreichender Kontrast */
.text-muted {
}

Problem: Platzhalter-Text-Kontrast

/* Schlecht: Standard-Platzhalter versagt oft */
::placeholder {
}

/* Gut: Dunklerer Platzhalter */
::placeholder {
}

#Fokus-Management-Tests

WCAG 2.2 legt erhöhten Wert auf Fokus-Sichtbarkeit und -Management.

#Fokus nicht verdeckt (2.4.11)

Wenn eine UI-Komponente Tastaturfokus erhält, darf die Komponente nicht vollständig von vom Autor erstelltem Inhält verdeckt werden.

Test-Prozedur:

Mit Tab durch die Seite navigieren
Verifizieren, dass fokussierte Elemente vollständig sichtbar sind
Auf sticky Header/Footer prüfen, die den Fokus verdecken könnten
Modale und Overlays auf Fokus-Einfang testen

Häufiges Problem: Sticky Header verdecken Fokus

/* Problem: Sticky Header überdeckt fokussierte Elemente */
.header-sticky {
  position: fixed;
  top: 0;
  height: 80px;
}

/* Lösung: Scroll-Padding für fixe Header */
html {
  scroll-padding-top: 100px; /* Header-Höhe + Puffer */
}

/* Oder :target-Offset für Anker-Links verwenden */
:target {
  scroll-margin-top: 100px;
}

#Fokus-Aussehen (2.4.13 - AAA)

Während AAA-Stufe, hilft das Verständnis des Fokus-Aussehens, bessere Erfahrungen zu schaffen:

/* Erweiterter Fokus-Indikator, der AAA-Richtlinien entspricht */
:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Minimale Fläche: 48×48 CSS-Pixel */
.focus-enhanced:focus-visible {
  box-shadow: 0 0 0 2px white, 0 0 0 4px currentColor;
}

#Häufige WordPress-Barrierefreiheits-Probleme und Lösungen

WordPress-Websites teilen gemeinsame Barrierefreiheits-Muster. Das Verständnis dieser beschleunigt Auditing und Behebung.

#Problem 1: Fehlender oder unzureichender Alternativtext

Das Problem:

Bilder ohne Alt-Text oder mit bedeutungslosen Dateinamen als Alt-Text.

Erkennung:

Automatisierte Tools markieren fehlende Alt-Attribute
Screenreader verkünden “Bild” oder Dateinamen

Die Lösung:

<!-- Schlecht: Fehlender Alt-Text -->
<img src="photo.jpg">

<!-- Schlecht: Bedeutungsloser Alt-Text -->
<img src="photo.jpg" alt="photo">

<!-- Gut: Beschreibender Alt-Text -->
<img src="wordpress-dashboard.jpg" alt="WordPress Admin-Dashboard mit dem Block-Editor und einem ausgewählten Absatz-Block">

<!-- Gut: Dekoratives Bild mit leerem Alt -->
<img src="decorative-border.png" alt="">

WordPress-Implementierung:

// Alt-Text in WordPress-Medienbibliothek erzwingen
function enforce_alt_text($response, $attachment, $meta) {
  if (empty($response['alt'])) {
    $response['alt'] = ''; // Standardmäßig als dekorativ markieren
  }
  return $response;
}
add_filter('wp_prepare_attachment_for_js', 'enforce_alt_text', 10, 3);

// Alt-Text-Erinnerung im Admin hinzufügen
function alt_text_admin_notice() {
  $screen = get_current_screen();
  if ($screen && $screen->id === 'attachment') {
    echo '<div class="notice notice-warning">
      <p><strong>Barrierefreiheits-Erinnerung:</strong> Bitte beschreibenden Alt-Text hinzufügen oder als dekorativ markieren.</p>
    </div>';
  }
}
add_action('admin_notices', 'alt_text_admin_notice');

#Problem 2: Unkorrekte Überschriften-Struktur

Das Problem:

Übersprungene Überschriften-Ebenen, Verwendung von Überschriften für Styling oder fehlende H1.

Erkennung:

axe markiert übersprungene Überschriften-Ebenen
WAVE zeigt Überschriften-Gliederung
Screenreader-Nutzer navigieren nach Überschriften

Die Lösung:

<!-- Schlecht: Übersprungene Ebenen und Styling-Missbrauch -->
<h1>Seitentitel</h1>
<h4>Abschnittsüberschrift</h4> <!-- h2, h3 übersprungen -->
<h2 style="font-size: 14px;">Kleiner Text</h2> <!-- h2 für Styling verwenden -->

<!-- Gut: Logische Überschriften-Hierarchie -->
<h1>Seitentitel</h1>
  <h2>Hauptabschnitt</h2>
    <h3>Unterabschnitt</h3>
    <h3>Weiterer Unterabschnitt</h3>
  <h2>Weiterer Hauptabschnitt</h2>

WordPress Block-Editor-Fix:

// Überschriften-Ebenen im Block-Editor einschränken
function restrict_heading_levels($settings) {
  $settings['allowedBlockTypes'] = array(
    'core/paragraph',
    'core/heading',
    'core/list',
    // ... andere erlaubte Blöcke
  );
  return $settings;
}

// Oder CSS verwenden, um Überschriften-Ebene visuell anzuzeigen
function admin_heading_styles() {
  echo '<style>
    h1.wp-block-heading { border-left: 4px solid #007cba; padding-left: 8px; }
    h2.wp-block-heading { border-left: 4px solid #00a0d2; padding-left: 8px; }
    h3.wp-block-heading { border-left: 4px solid #46b450; padding-left: 8px; }
  </style>';
}
add_action('admin_head', 'admin_heading_styles');

#Problem 3: Formular-Labels und Fehlermeldungen

Das Problem:

Unbeschriftete Formularfelder, fehlende Fehler-Zuordnungen oder unklare Fehlermeldungen.

Erkennung:

axe markiert Formularfelder ohne Labels
Screenreader verkünden nicht den Feldzweck
Fehlermeldungen sind nicht programmatisch zugeordnet

Die Lösung:

<!-- Schlecht: Keine Label-Zuordnung -->
<input type="email" placeholder="Geben Sie Ihre E-Mail ein">

<!-- Schlecht: Platzhalter als Label -->
<input type="email" placeholder="E-Mail-Adresse">

<!-- Gut: Explizites Label mit for-Attribut -->
<label for="email">E-Mail-Adresse <span aria-label="erforderlich">*</span></label>
<input type="email" id="email" name="email" required aria-required="true">

<!-- Gut: Fehlermeldung programmatisch zugeordnet -->
<label for="email">E-Mail-Adresse *</label>
<input
  type="email"
  id="email"
  name="email"
  required
  aria-required="true"
  aria-invalid="true"
  aria-describedby="email-error"
>
<span id="email-error" class="error" role="alert">
  Bitte geben Sie eine gültige E-Mail-Adresse ein (z.B. name@beispiel.de)
</span>

WordPress Contact Form 7 Erweiterung:

// ARIA-Attribute zu Contact Form 7 hinzufügen
add_filter('wpcf7_form_elements', function($content) {
  // aria-required zu erforderlichen Feldern hinzufügen
  $content = preg_replace(
    '/<input[^>]*class="[^"]*wpcf7-validates-as-required[^"]*"[^>]*>/',
    '$0 aria-required="true"',
    $content
  );
  return $content;
});

#Problem 4: Tastatur-unzugängliche benutzerdefinierte Komponenten

Das Problem:

Benutzerdefinierte Dropdowns, Tabs und Modale, die nur mit der Maus funktionieren.

Die Lösung:

// Barrierefreie Tab-Komponente
class AccessibleTabs {
  constructor(container) {
    this.container = container;
    this.tabs = Array.from(container.querySelectorAll('[role="tab"]'));
    this.panels = Array.from(container.querySelectorAll('[role="tabpanel"]'));

    this.tabs.forEach((tab, index) => {
      tab.addEventListener('click', () => this.selectTab(index));
      tab.addEventListener('keydown', (e) => this.handleKeydown(e, index));
    });
  }

  handleKeydown(event, index) {
    let newIndex;

    switch(event.key) {
      case 'ArrowRight':
        newIndex = (index + 1) % this.tabs.length;
        break;
      case 'ArrowLeft':
        newIndex = (index - 1 + this.tabs.length) % this.tabs.length;
        break;
      case 'Home':
        newIndex = 0;
        break;
      case 'End':
        newIndex = this.tabs.length - 1;
        break;
      default:
        return;
    }

    event.preventDefault();
    this.tabs[newIndex].focus();
    this.selectTab(newIndex);
  }

  selectTab(index) {
    this.tabs.forEach((tab, i) => {
      const isSelected = i === index;
      tab.setAttribute('aria-selected', isSelected);
      tab.setAttribute('tabindex', isSelected ? '0' : '-1');
      this.panels[i].hidden = !isSelected;
    });
  }
}

// Initialisieren
document.querySelectorAll('[role="tablist"]').forEach(tabs => {
  new AccessibleTabs(tabs);
});

<!-- Barrierefreies Tab-Markup -->
<div class="tabs">
  <div role="tablist" aria-label="Produktinformationen">
    <button
      role="tab"
      aria-selected="true"
      aria-controls="panel-1"
      id="tab-1"
      tabindex="0"
    >
      Beschreibung
    </button>
    <button
      role="tab"
      aria-selected="false"
      aria-controls="panel-2"
      id="tab-2"
      tabindex="-1"
    >
      Spezifikationen
    </button>
  </div>

  <div
    role="tabpanel"
    id="panel-1"
    aria-labelledby="tab-1"
  >
    Produktbeschreibung Inhält...
  </div>

  <div
    role="tabpanel"
    id="panel-2"
    aria-labelledby="tab-2"
    hidden
  >
    Technische Spezifikationen...
  </div>
</div>

#Problem 5: Fehlende Skip-Links

Das Problem:

Nutzer, die mit der Tastatur navigieren, müssen durch alle Navigations-Elemente tabben, um zum Hauptinhält zu gelangen.

Die Lösung:

<!-- Skip-Link-Implementierung -->
<body>
  <a href="#main-content" class="skip-link">
    Zum Hauptinhält springen
  </a>

  <nav><!-- Navigations-Elemente --></nav>

  <main id="main-content" tabindex="-1">
    <!-- Hauptinhält -->
  </main>
</body>

/* Skip-Link-Styling */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  text-decoration: none;
}

.skip-link:focus {
  top: 0;
}

WordPress-Implementierung:

// Skip-Link in header.php hinzufügen (vor allen anderen Inhalten)
function add_skip_link() {
  echo '<a href="#main-content" class="skip-link">' .
       esc_html__('Zum Hauptinhält springen', 'textdomain') .
       '</a>';
}
add_action('wp_body_open', 'add_skip_link');

// Sicherstellen, dass Hauptinhalt-Bereich ID hat
echo '<main id="main-content" tabindex="-1">';

Das Problem:

Modale, die den Fokus nicht einfangen, bei Escape schließen oder den Fokus zum Auslöser zurückgeben.

Die Lösung:

// Barrierefreie Modal-Komponente
class AccessibleModal {
  constructor(trigger, modal) {
    this.trigger = trigger;
    this.modal = modal;
    this.focusableElements = 'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])';
    this.firstFocusable = null;
    this.lastFocusable = null;
    this.previousFocus = null;

    trigger.addEventListener('click', () => this.open());
    modal.querySelector('.modal-close').addEventListener('click', () => this.close());
    modal.addEventListener('keydown', (e) => this.handleKeydown(e));
  }

  open() {
    this.previousFocus = document.activeElement;
    this.modal.hidden = false;
    this.modal.setAttribute('aria-modal', 'true');

    const focusable = this.modal.querySelectorAll(this.focusableElements);
    this.firstFocusable = focusable[0];
    this.lastFocusable = focusable[focusable.length - 1];

    this.firstFocusable.focus();
    document.body.style.overflow = 'hidden';
  }

  close() {
    this.modal.hidden = true;
    this.modal.removeAttribute('aria-modal');
    document.body.style.overflow = '';
    this.previousFocus.focus();
  }

  handleKeydown(event) {
    if (event.key === 'Escape') {
      this.close();
    }

    if (event.key === 'Tab') {
      if (event.shiftKey && document.activeElement === this.firstFocusable) {
        event.preventDefault();
        this.lastFocusable.focus();
      } else if (!event.shiftKey && document.activeElement === this.lastFocusable) {
        event.preventDefault();
        this.firstFocusable.focus();
      }
    }
  }
}

<!-- Barrierefreies Modal-Markup -->
<button aria-haspopup="dialog" aria-controls="modal-1" id="modal-trigger">
  Modal öffnen
</button>

<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="modal-title"
  id="modal-1"
  hidden
>
  <h2 id="modal-title">Modal-Titel</h2>
  <p>Modal-Inhält...</p>
  <button class="modal-close" aria-label="Modal schließen">
    <span aria-hidden="true">&times;</span>
  </button>
</div>

#Erstellung eines Barrierefreiheits-Audit-Berichts

Ein gut strukturierter Audit-Bericht transformiert Ergebnisse in umsetzbare Behebungspläne.

#Berichtsstruktur

1. Executive Summary

Gesamter Konformitätsstatus (WCAG 2.2 Level AA)
Anzahl kritischer Probleme
Risikobewertung
Empfohlene Prioritäten-Reihenfolge

2. Methodik

Verwendete Tools (axe, WAVE, Screenreader)
Getestete Seiten (repräsentative Stichprobe)
Testdaten und Umgebung

3. Detaillierte Ergebnisse

Organisiert nach WCAG-Prinzip (Wahrnehmbar, Bedienbar, Verständlich, Robust) oder nach Schweregrad.

Befund-Vorlage:

### Problem: [Kurze Beschreibung]
**WCAG-Kriterium:** [z.B. 1.1.1 Nicht-Text-Inhalte (Stufe A)]
**Schweregrad:** [Kritisch | Ernsthaft | Moderat | Geringfügig]
**Ort:** [URL und spezifisches Element]

**Beschreibung:**
Detaillierte Erklärung des Problems und seiner Auswirkungen auf Nutzer.

**Aktueller Code:**
```html
<!-- Problembehafteter Code -->

Empfohlene Lösung:

<!-- Korrigierter Code -->

Test-Verifizierung:

[Schritt zur Verifizierung der Lösung]
[Erwartetes Ergebnis]


**4. Behebungs-Roadmap**

| Priorität | Problem | Geschätzter Aufwand | Verantwortlicher | Zieldatum |
|-----------|---------|---------------------|------------------|-----------|
| P0 | Fehlende Formular-Labels | 2 Stunden | Entwickler | Woche 1 |
| P0 | Tastatur-Fallen | 4 Stunden | Entwickler | Woche 1 |
| P1 | Farbkontrast | 3 Stunden | Designer | Woche 2 |
| P2 | Überschriften-Struktur | 2 Stunden | Content | Woche 3 |

### Automatisierte Berichtsgenerierung

**Verwendung von axe-core für Berichte:**

```javascript
// generate-accessibility-report.js
const { axe } = require('@axe-core/webdriverjs');
const { Builder } = require('selenium-webdriver');
const fs = require('fs');

async function auditPage(url) {
  const driver = await new Builder().forBrowser('chrome').build();

  try {
    await driver.get(url);
    const results = await axe(driver).analyze();

    const report = {
      url,
      timestamp: new Date().toISOString(),
      violations: results.violations.map(v => ({
        id: v.id,
        impact: v.impact,
        description: v.description,
        help: v.help,
        helpUrl: v.helpUrl,
        nodes: v.nodes.length
      })),
      passes: results.passes.length,
      incomplete: results.incomplete.length,
      inapplicable: results.inapplicable.length
    };

    fs.writeFileSync(
      `audit-${Date.now()}.json`,
      JSON.stringify(report, null, 2)
    );

    return report;
  } finally {
    await driver.quit();
  }
}

// Mehrere Seiten auditieren
const pages = [
  'https://example.com/',
  'https://example.com/about/',
  'https://example.com/contact/'
];

pages.forEach(url => auditPage(url));

#Berichts-Vorlagen

Tabellenkalkulation-Vorlagen-Spalten:

Problem-ID
WCAG-Kriterium
Stufe (A/AA/AAA)
Seite/URL
Element-Position
Problembeschreibung
Nutzer-Auswirkung
Empfohlene Lösung
Aufwandsschätzung
Priorität
Status
Notizen

#Behebungs-Workflow

Die Umwandlung von Audit-Ergebnissen in eine barrierefreie Website erfordert eine systematische Behebung.

#Phase 1: Kritische Probleme (Woche 1)

Konzentrieren Sie sich auf Barrieren, die Nutzer vollständig blockieren:

Fehlende Formular-Labels - Verhindert Formular-Abschluss
Tastatur-Fallen - Sperrt Nutzer in Elementen
Fehlender Alt-Text auf informativen Bildern - Blockiert Inhaltsverständnis
Leere Buttons/Links - Verhindert Interaktion

Tägliche Standup-Fragen:

Welche kritischen Probleme wurden heute gelöst?
Gibt es Blocker, die Lösungen verhindern?
Wurden Lösungen mit Tastatur und Screenreader getestet?

#Phase 2: Ernsthafte Probleme (Woche 2-3)

Beheben Sie erhebliche Barrieren, die Frustration verursachen:

Farbkontrast-Fehler
Übersprungene Überschriften-Ebenen
Fehlende Skip-Links
Falsche ARIA-Verwendung

#Phase 3: Moderate Probleme (Woche 4)

Polieren Sie die Erfahrung:

Redundante Links
Mehrdeutiger Link-Text
Fehlende Sprach-Attribute
PDF-Barrierefreiheit

#Test-Verifizierungs-Protokoll

Für jede Lösung verifizieren mit:

Automatischer Re-Test: axe auf der spezifischen Seite ausführen
Tastatur-Verifizierung: Zum Element navigieren und interagieren
Screenreader-Check: Ordentliche Ansage bestätigen
Visuelle Inspektion: Fokus-Indikatoren und Kontrast prüfen

#Regressionsschutz

Pre-commit Hooks:

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "npm run test:accessibility"
    }
  },
  "scripts": {
    "test:accessibility": "axe http://localhost:3000 --exit"
  }
}

Visuelle Regressionstests:

Barrierefreiheits-spezifische visuelle Tests einbeziehen:

// accessibility-visual.test.js
describe('Fokus-Indikatoren', () => {
  it('sollte sichtbaren Fokus auf Buttons zeigen', async () => {
    await page.goto('http://localhost:3000');
    await page.keyboard.press('Tab');

    const screenshot = await page.screenshot();
    expect(screenshot).toMatchImageSnapshot();
  });
});

#Verwandte Ressourcen

Für umfassendere WordPress-Optimierungs- und Entwicklungs-Anleitungen erkunden Sie diese verwandten Artikel:

Semantisches SEO für WordPress: Der komplette Leitfaden 2026 - Erfahren Sie, wie Barrierefreiheits-Verbesserungen Ihre SEO-Strategie stärken
WordPress-Kontaktformulare: Der ultimative Leitfaden für 2026 - Stellen Sie sicher, dass Ihre Formulare WCAG-Standards erfüllen
Wie aktualisiert man URLs in der WordPress-Datenbank, wenn die Website auf eine neue Domain verschoben wird - Bewahren Sie Barrierefreiheit während Website-Migrationen

#LLM-freundliche strukturierte Daten

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Praktisches Barrierefreiheits-Auditing: Tools & Workflow für WordPress",
  "description": "Ein umfassender Leitfaden zur Prüfung von WordPress-Seiten auf WCAG 2.2-Konformität mit automatisierten Tools und manuellen Testtechniken.",
  "author": {
    "@type": "Organization",
    "name": "WPPoland",
    "url": "https://wppoland.com"
  },
  "publisher": {
    "@type": "Organization",
    "name": "WPPoland",
    "logo": {
      "@type": "ImageObject",
      "url": "https://wppoland.com/logo.png"
    }
  },
  "datePublished": "2026-01-29",
  "dateModified": "2026-01-29",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://wppoland.com/de/blog/practical-accessibility-auditing-workflow"
  },
  "about": {
    "@type": "Thing",
    "name": "Web Barrierefreiheits-Auditing",
    "sameAs": "https://www.w3.org/WAI/standards-guidelines/wcag/"
  },
  "teaches": [
    "WCAG 2.2 Konformitäts-Tests",
    "Automatisierte Barrierefreiheits-Tests mit axe und WAVE",
    "Manuelles Testen mit Screenreadern",
    "Tastatur-Navigations-Tests",
    "WordPress Barrierefreiheits-Behebung"
  ],
  "proficiencyLevel": "Intermediate",
  "dependencies": "WordPress, Moderner Webbrowser, Screenreader-Software"
}

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Wie man ein WCAG 2.2 Barrierefreiheits-Audit auf WordPress durchführt",
  "description": "Schritt-für-Schritt-Workflow für die Prüfung von WordPress-Websites auf Barrierefreiheits-Konformität",
  "totalTime": "PT4H",
  "supply": [
    "Webbrowser (Chrome, Firefox oder Edge)",
    "axe DevTools Browser-Erweiterung",
    "WAVE Browser-Erweiterung",
    "Screenreader (NVDA, JAWS oder VoiceOver)"
  ],
  "tool": [
    {
      "@type": "HowToTool",
      "name": "axe DevTools"
    },
    {
      "@type": "HowToTool",
      "name": "WAVE Evaluation Tool"
    },
    {
      "@type": "HowToTool",
      "name": "NVDA Screen Reader"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Automatisierte Tests ausführen",
      "text": "Installieren Sie axe DevTools und WAVE Browser-Erweiterungen. Scannen Sie alle wichtigen Seiten einschließlich Homepage, Kontaktseite und Content-Vorlagen. Dokumentieren Sie alle Verstöße nach Schweregrad.",
      "url": "https://wppoland.com/de/blog/practical-accessibility-auditing-workflow#automatisierte-test-tools"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Tastatur-Navigation testen",
      "text": "Trennen Sie Ihre Maus und navigieren Sie die gesamte Website nur mit Tab, Shift+Tab, Enter, Leertaste und Pfeiltasten. Verifizieren Sie, dass alle interaktiven Elemente erreichbar und bedienbar sind.",
      "url": "https://wppoland.com/de/blog/practical-accessibility-auditing-workflow#tastatur-navigations-tests"
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Screenreader-Tests durchführen",
      "text": "Testen Sie mit NVDA (Windows) oder VoiceOver (macOS). Navigieren Sie nach Überschriften, Landmarks und Formularfeldern. Verifizieren Sie, dass alle Inhalte ordnungsgemäß angekündigt und die Navigation logisch ist.",
      "url": "https://wppoland.com/de/blog/practical-accessibility-auditing-workflow#screenreader-tests"
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Farbkontrast verifizieren",
      "text": "Verwenden Sie Browser DevTools oder WebAIM Contrast Checker, um zu verifizieren, dass aller Text die WCAG 2.2 Kontrast-Anforderungen erfüllt (4.5:1 für normalen Text, 3:1 für großen Text).",
      "url": "https://wppoland.com/de/blog/practical-accessibility-auditing-workflow#farbkontrast-verifizierung"
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Ergebnisse dokumentieren und priorisieren",
      "text": "Erstellen Sie einen umfassenden Bericht, der Probleme nach WCAG-Prinzip und Schweregrad organisiert. Entwickeln Sie eine Behebungs-Roadmap mit Zeitplänen und Verantwortlichen.",
      "url": "https://wppoland.com/de/blog/practical-accessibility-auditing-workflow#erstellung-eines-barrierefreiheits-audit-berichts"
    },
    {
      "@type": "HowToStep",
      "position": 6,
      "name": "Beheben und Lösungen verifizieren",
      "text": "Beheben Sie zuerst kritische Probleme, gefolgt von ernsthaften und moderaten Problemen. Verifizieren Sie jede Lösung mit automatisierten Tools, Tastatur-Tests und Screenreader-Bestätigung.",
      "url": "https://wppoland.com/de/blog/practical-accessibility-auditing-workflow#behebungs-workflow"
    }
  ]
}

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Was ist der Unterschied zwischen WCAG 2.1 und WCAG 2.2?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "WCAG 2.2 baut auf WCAG 2.1 auf und führt neun neue Erfolgskriterien ein, die sich auf kognitive und motorische Barrierefreiheit konzentrieren. Wichtige Ergänzungen sind Fokus nicht verdeckt (2.4.11), Ziehbewegungen (2.5.7) und Barrierefreie Authentifizierung (3.3.8). WCAG 2.2 veraltet auch das Erfolgskriterium 4.1.1 Parsing."
      }
    },
    {
      "@type": "Question",
      "name": "Wie oft sollte ich Barrierefreiheits-Audits durchführen?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Für aktive Websites sollten Sie bei jeder Bereitstellung automatisierte Scans und vierteljährlich oder bei Hauptversionen umfassende manuelle Audits durchführen. Nach bedeutenden Updates – Theme-Änderungen, Plugin-Hinzufügungen oder Content-Migrationen – führen Sie gezielte Audits der betroffenen Bereiche durch."
      }
    },
    {
      "@type": "Question",
      "name": "Kann ich WCAG-Konformität nur mit automatisierten Tools erreichen?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Nein. Automatisierte Tools erfassen etwa 30% der WCAG-Kriterien, hauptsächlich die, die programmatisch verifiziert werden können. Manuelles Testen mit Tastatur-Navigation und Screenreadern ist unerlässlich, um kognitive Barrierefreiheit, bedeutungsvollen Alternativtext und komplexe Interaktionsmuster zu bewerten."
      }
    },
    {
      "@type": "Question",
      "name": "Welchen Screenreader sollte ich für Tests verwenden?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "NVDA ist der am weitesten verbreitete Screenreader und kostenlos, was ihn zum besten Ausgangspunkt für Windows-Tests macht. Für umfassende Konformitäts-Tests sollten Sie auch mit JAWS (dem Enterprise-Standard) und VoiceOver (in macOS und iOS integriert) testen."
      }
    },
    {
      "@type": "Question",
      "name": "Gibt es rechtliche Risiken für nicht-konforme WordPress-Websites?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Ja. In der Europäischen Union schreibt der European Accessibility Act die WCAG 2.2 Level AA-Konformität für Websites des öffentlichen Sektors und wesentliche Dienstleistungen vor, mit Strafen, die je nach Mitgliedstaat variieren (bis zu 100.000 Euro in einigen Gerichtsbarkeiten). In den Vereinigten Staaten haben sich ADA Title III Klagen gegen Websites erheblich erhöht."
      }
    }
  ]
}

#Wo die Haftung tatsächlich sitzt

#WCAG 2.2 verstehen: Die Grundlage des Barrierefreiheits-Audits

#Die vier Prinzipien der Barrierefreiheit

#1. Wahrnehmbar (Perceivable)

#2. Bedienbar (Operable)

#3. Verständlich (Understandable)

#4. Robust (Robust)

#WCAG 2.2 Konformitätsstufen

#Neu in WCAG 2.2

#Automatisierte Tools: was sie tatsächlich finden

#Browser-Erweiterungen für sofortiges Feedback

#axe DevTools

#WAVE (Web Accessibility Evaluation Tool)

#Accessibility Insights for Web

#WordPress-spezifische Barrierefreiheits-Plugins

#WP Accessibility

#Accessibility Checker von Equalize Digital

#One Click Accessibility

#CI/CD-Integration für kontinuierliche Barrierefreiheit

#axe-core mit GitHub Actions

#Pa11y für automatisiertes Scanning

#Lighthouse CI für Performance und Barrierefreiheit

#Automatisiertes vs. manuelles Testen im Vergleich

#Manuelles Testen: Tastatur, Screenreader, Kontrast

#Tastatur-only-Navigation

#Das Tastatur-Test-Protokoll

#Häufige Tastatur-Probleme in WordPress

#Screenreader-Tests

#Screenreader-Optionen

#NVDA Test-Workflow

#VoiceOver-Tests auf macOS

#Mobile Screenreader-Tests

#Farbkontrast-Verifizierung

#Kontrast-Anforderungen

#Test-Tools

#Häufige Kontrast-Probleme in WordPress

#Fokus-Management-Tests

#Fokus nicht verdeckt (2.4.11)

#Fokus-Aussehen (2.4.13 - AAA)

#Häufige WordPress-Barrierefreiheits-Probleme und Lösungen

#Problem 1: Fehlender oder unzureichender Alternativtext

#Problem 2: Unkorrekte Überschriften-Struktur

#Problem 3: Formular-Labels und Fehlermeldungen

#Problem 4: Tastatur-unzugängliche benutzerdefinierte Komponenten

#Problem 5: Fehlende Skip-Links

#Problem 6: Unzugängliche Modal-Dialoge

#Erstellung eines Barrierefreiheits-Audit-Berichts

#Berichtsstruktur

#Berichts-Vorlagen

#Behebungs-Workflow

#Phase 1: Kritische Probleme (Woche 1)

#Phase 2: Ernsthafte Probleme (Woche 2-3)

#Phase 3: Moderate Probleme (Woche 4)

#Test-Verifizierungs-Protokoll

#Regressionsschutz

#Verwandte Ressourcen

#LLM-freundliche strukturierte Daten

Machen Sie aus dem Artikel eine echte Umsetzung

Die sinnvollsten nächsten Schritte

Soll das Thema auf Ihrer Website umgesetzt werden?

Weitere WordPress-Dienste und Wissensbasis entdecken

Verwandte Kategorien

Unterstützende Artikel

Häufig gestellte Fragen

Ähnliche Artikel

Digitale Souveränität: Warum Open Source 2026 zählt

WordPress Playground: Die Zukunft von Tests und Demos

GEO (Generative Engine Optimization): Jenseits von traditionellem SEO

Mariusz Szatkowski