Wer seine Website auf Barrierefreiheit testen möchte, landet früher oder später bei axe DevTools.

Das Tool taucht regelmäßig in Empfehlungen für Entwickler, Agenturen und Websitebetreiber auf. Gleichzeitig wirkt es auf den ersten Blick technischer als beispielsweise Lighthouse oder WAVE.

Da stehen Begriffe wie:

„Critical“

„Serious“

„Moderate“

„Minor“

„WCAG“

„ARIA“

„Target“

„Inspect Node“

Für jemanden, der einfach nur wissen möchte, ob die eigene Website größere Barrieren besitzt, kann das zunächst etwas einschüchternd wirken.

Dabei ist der Einstieg gar nicht so kompliziert.

axe DevTools ist im Kern ein automatisiertes Prüfwerkzeug für Webseiten. Du öffnest eine Seite, startest den Scan und bekommst anschließend eine Liste mit erkannten Accessibility-Problemen.

Besonders praktisch ist, dass axe nicht nur sagt:

„Hier stimmt etwas nicht.“

Das Tool zeigt normalerweise auch:

• welches Element betroffen ist,
• warum das problematisch sein kann,
• wie schwerwiegend der Fehler eingeschätzt wird,
• welche Standards betroffen sein können,
• an welcher Stelle im HTML das Problem liegt.

Damit eignet sich axe DevTools besonders gut, wenn du nicht nur Fehler finden, sondern auch verstehen möchtest, wo sie technisch entstehen.

Was ist axe DevTools?

axe DevTools ist eine Sammlung von Werkzeugen zur Prüfung digitaler Barrierefreiheit.

Für normale Websitebetreiber und Webdesigner ist vor allem die Browser-Erweiterung interessant.

Sie integriert sich in die Entwicklertools des Browsers.

Du öffnest also beispielsweise Chrome, rufst deine Website auf und startest anschließend axe DevTools innerhalb der Browser-Entwicklertools.

Dann wird die aktuell geöffnete Seite analysiert.

Dabei sucht das Tool nach automatisch erkennbaren Barrierefreiheitsproblemen.

Was ist der Unterschied zwischen axe und axe DevTools?

Diese Begriffe werden manchmal durcheinandergebracht.

axe-core ist die eigentliche Prüf-Engine.

Sie enthält die Regeln, mit denen Webseiten automatisiert untersucht werden.

axe DevTools verwendet diese Technik und stellt sie in einer benutzerfreundlicheren Oberfläche zur Verfügung.

Vereinfacht gesagt:

axe-core ist der Motor.

axe DevTools ist das Fahrzeug drumherum.

Für einen normalen Website-Test musst du dich mit axe-core nicht direkt beschäftigen.

Die Browser-Erweiterung reicht völlig aus.

Für wen eignet sich axe DevTools?

Das Tool ist besonders interessant für:

• Webentwickler
• WordPress-Agenturen
• Webdesigner
• WooCommerce-Entwickler
• Tester
• Betreiber komplexerer Websites
• technisch interessierte Websitebetreiber

Du musst allerdings kein Programmierer sein, um davon zu profitieren.

Die Ergebnisse sind technischer als bei WAVE, aber mit etwas Übung lassen sie sich gut verstehen.

Für Einsteiger geeignet?

Ja – mit einer kleinen Einschränkung.

Wer noch nie Browser-Entwicklertools geöffnet hat, wird sich an die Oberfläche zunächst gewöhnen müssen.

Nach den ersten zwei oder drei Tests wird es deutlich einfacher.

Für einen kompletten Anfänger ist WAVE vielleicht etwas visueller.

axe DevTools bietet dafür oft mehr technische Details.

Ist axe DevTools kostenlos?

Es gibt eine kostenlose Browser-Erweiterung.

Damit kannst du automatisierte Prüfungen einzelner Seiten durchführen.

Für viele Websitebetreiber reicht das bereits vollkommen aus.

Daneben gibt es eine Pro-Version mit zusätzlichen Funktionen.

Je nach aktuellem Funktionsumfang gehören dazu beispielsweise:

• geführte Tests,
• erweiterte manuelle Prüfungen,
• Speichern von Ergebnissen,
• Export,
• Teamfunktionen,
• umfangreichere Workflows.

Wenn du einfach eine WordPress-Seite, Produktseite oder einen Checkout technisch prüfen möchtest, kannst du zunächst mit der kostenlosen Variante anfangen.

Welche Browser werden unterstützt?

axe DevTools steht für die wichtigsten Desktop-Browser zur Verfügung.

Besonders vollständig sind die Versionen für:

• Google Chrome
• Microsoft Edge

Für Firefox gibt es ebenfalls eine Version, deren Funktionsumfang eingeschränkter sein kann.

Für den Einstieg würde ich Chrome oder Edge verwenden.

axe DevTools installieren

Nach der Installation findest du axe nicht einfach als großes Fenster oben im Browser.

Das Tool integriert sich in die Entwicklertools.

Das bedeutet:

1. Website öffnen.
2. Rechtsklick auf die Seite.
3. „Untersuchen“ auswählen.
4. Entwicklertools öffnen.
5. Dort den Tab „axe DevTools“ auswählen.

Falls du den Tab nicht direkt siehst, kann er sich hinter dem Menü für weitere Tabs befinden.

Danach kannst du mit der Prüfung starten.

Der erste axe-Scan

Öffne eine Seite deiner Website.

Zum Beispiel:

deine Startseite.

Dann axe DevTools öffnen.

Dort findest du eine Funktion zum Scannen beziehungsweise Analysieren der aktuellen Seite.

Nach wenigen Sekunden bekommst du eine Liste mit gefundenen Problemen.

Je nach Website können das sein:

• 0 Probleme
• 5 Probleme
• 20 Probleme
• deutlich mehr

Lass dich von einer hohen Zahl nicht sofort erschrecken.

Oft taucht derselbe Fehler auf mehreren Elementen auf.

Wenn beispielsweise zehn Buttons dasselbe technische Problem besitzen, kann eine einzige Korrektur im Theme zehn Meldungen auf einmal lösen.

Welche Probleme kann axe finden?

axe DevTools erkennt viele typische technische Accessibility-Probleme.

Dazu gehören beispielsweise:

• Bilder ohne Alternativtext
• Buttons ohne zugänglichen Namen
• Links ohne verständlichen Namen
• Formularfelder ohne Label
• Probleme mit ARIA
• unzureichende Farbkontraste
• ungültige HTML-Strukturen
• bestimmte Überschriftenprobleme
• Tabellenprobleme
• fehlende Sprachangaben
• problematische Fokus-Eigenschaften

Das ist bereits eine Menge.

Trotzdem prüft das Tool nicht alles.

Dazu später mehr.

Die Schweregrade verstehen

axe sortiert Probleme nach Auswirkungen.

Typische Kategorien sind:

• Critical
• Serious
• Moderate
• Minor

Diese Einstufung hilft dir bei der Priorisierung.

Critical

Das sind Probleme, die besonders starke Auswirkungen haben können.

Beispielsweise kann ein wichtiges Bedienelement komplett unzugänglich sein.

Solche Fehler solltest du sehr ernst nehmen.

Serious

Auch diese Probleme können Nutzer deutlich behindern.

Sie gehören normalerweise weit nach oben auf die Prioritätenliste.

Moderate

Mittlere Probleme sollten ebenfalls behoben werden, verhindern aber möglicherweise nicht sofort die komplette Nutzung.

Minor

Kleinere Probleme haben meist geringere Auswirkungen.

Sie sollten trotzdem nicht dauerhaft ignoriert werden.

Muss ich immer zuerst „Critical“ beheben?

Normalerweise ist das sinnvoll.

Trotzdem sollte man nicht nur auf die technische Einstufung schauen.

Ein reales Beispiel:

axe meldet einen Serious-Fehler auf einem Element, das fast niemand verwendet.

Gleichzeitig funktioniert dein Bestellbutton mit Tastatur überhaupt nicht, wird aber durch den automatischen Scan nicht vollständig erkannt.

Für einen Shop ist der Bestellbutton natürlich wichtiger.

Deshalb gilt:

Technische Priorität + reale Nutzerwirkung zusammen betrachten.

Ein Problem im Detail öffnen

Wenn du einen gefundenen Fehler anklickst, bekommst du normalerweise weitere Informationen.

Dazu gehören häufig:

• Beschreibung des Problems
• betroffene Elemente
• HTML-Ausschnitt
• CSS-Selektor
• mögliche Lösung
• betroffene Accessibility-Regel

Das macht axe besonders nützlich für Entwickler.

Du kannst sehr schnell erkennen:

Welches Element erzeugt den Fehler?

Beispiel

Das Tool meldet:

Button does not have an accessible name

Dann kannst du das betroffene Element anzeigen.

Vielleicht ist es:

ein Suchsymbol.

Optisch sieht das korrekt aus.

Technisch fehlt aber ein verständlicher Name.

Ein Screenreader würde möglicherweise nur:

„Button“

vorlesen.

Dann weißt du genau, was behoben werden muss.

Beispiel: Button ohne Namen

Angenommen, deine Website besitzt oben rechts ein Lupensymbol.

Der HTML-Code enthält nur einen Button mit einem Icon.

Ein sehender Nutzer erkennt:

Suche öffnen.

Ein Screenreader möglicherweise nicht.

axe kann das melden.

Die Lösung kann je nach Umsetzung beispielsweise darin bestehen, dem Button einen verständlichen zugänglichen Namen zu geben.

Zum Beispiel:

„Suche öffnen“

Das ist wesentlich hilfreicher als:

„Icon Button“

Beispiel: Bild ohne Alt-Text

Ein Produktbild besitzt keinen Alternativtext.

axe erkennt:

Bild ohne zugängliche Alternative.

Dann solltest du prüfen:

Ist das Bild informativ?

Wenn ja:

passenden Alt-Text ergänzen.

Wenn das Bild rein dekorativ ist:

entsprechend dekorativ behandeln.

Wichtig:

axe kann erkennen, dass ein Alt-Text fehlt.

Es kann aber nicht zuverlässig entscheiden, ob ein vorhandener Alt-Text gut ist.

Beispiel: Schlechter Alt-Text

Alt-Text:

„Produktbild“

Technisch vorhanden.

axe:

möglicherweise kein Fehler.

Für den Nutzer:

kaum hilfreich.

Ein besserer Alt-Text wäre beispielsweise:

„Schwarzer Trekkingrucksack mit orangefarbenen Reißverschlüssen und zwei Seitentaschen.“

Das zeigt bereits eine wichtige Grenze automatischer Tools.

Formularfelder mit axe prüfen

Formulare gehören zu den wichtigsten Prüfbereichen.

axe kann beispielsweise erkennen, wenn Eingabefelder keine korrekt zugeordneten Beschriftungen besitzen.

Das betrifft:

• Kontaktformular
• Newsletter
• Login
• Registrierung
• Checkout
• Buchungsformular

Optisch kann ein Formular vollkommen normal aussehen.

Technisch kann ein Screenreader trotzdem nicht erkennen, was in ein Feld gehört.

Beispiel Formular

Auf der Seite steht:

E-Mail

Darunter:

Eingabefeld.

Für einen sehenden Nutzer klar.

Aber technisch wurde der sichtbare Text nicht mit dem Eingabefeld verbunden.

axe kann ein entsprechendes Problem erkennen.

Das ist besonders praktisch bei:

WordPress-Formularplugins.

Denn dort sieht man im Backend häufig nur den visuellen Aufbau.

axe und ARIA

ARIA ist ein wichtiger Bereich bei axe.

Viele moderne Webseiten nutzen ARIA für:

• Menüs
• Dialoge
• Akkordeons
• Tabs
• dynamische Inhalte
• benutzerdefinierte Buttons

axe erkennt verschiedene fehlerhafte ARIA-Verwendungen.

Zum Beispiel:

ungültiges Attribut.

falscher Wert.

fehlende notwendige Eigenschaft.

Vorsicht bei ARIA

Wenn axe einen ARIA-Fehler meldet, sollte man nicht einfach zufällig neue Attribute hinzufügen.

Eine falsche ARIA-Lösung kann schlimmer sein als gar keine.

Wenn du technisch nicht sicher bist, sollte die konkrete Komponente sauber untersucht werden.

Besonders bei Themes und Plugins kann der Fehler aus der Erweiterung selbst stammen.

Farbkontrast mit axe prüfen

axe kann auch bestimmte Farbkontrastprobleme erkennen.

Typische Beispiele:

hellgraue Schrift auf weiß.

weiße Schrift auf hellblau.

sehr dezenter Text in Formularen.

Das Tool kann dir anzeigen, welche Kombination problematisch ist.

Trotzdem manuell prüfen

Nicht jeder visuelle Zustand lässt sich perfekt automatisieren.

Zum Beispiel:

• Hover
• Fokus
• Hintergrundbilder
• Farbverläufe
• Overlays
• dynamische Zustände

Deshalb sollte der Kontrast zusätzlich praktisch überprüft werden.

axe und Überschriften

Eine Website sollte eine sinnvolle Überschriftenstruktur besitzen.

Zum Beispiel:

H1

H2

H2

H3

H3

axe kann bestimmte strukturelle Auffälligkeiten erkennen.

Aber auch hier gilt:

Das Tool kann nicht vollständig beurteilen, ob eine Überschrift inhaltlich sinnvoll gewählt wurde.

Beispiel:

Technisch H2.

Text:

„Mehr erfahren“

Das kann trotzdem eine schlechte Überschrift sein.

axe und Links

Links ohne zugänglichen Namen können automatisch erkannt werden.

Ein klassischer Fehler ist ein Icon-Link.

Zum Beispiel:

Instagram-Symbol.

Kein sichtbarer Text.

Kein zugänglicher Name.

Screenreader:

„Link.“

axe kann darauf hinweisen.

Was axe nicht vollständig beurteilt

Link:

„Hier klicken“

Technisch besitzt er einen Namen.

Automatisch möglicherweise kein Fehler.

Inhaltlich ist der Text trotzdem wenig hilfreich.

Besser:

„Preisliste herunterladen“

oder:

„Mehr über unsere Leistungen erfahren“

Wie unterscheidet sich axe von Lighthouse?

Diese Frage kommt häufig.

Beide Tools führen automatisierte Accessibility-Prüfungen durch.

Der Unterschied liegt eher in Oberfläche, Zielgruppe und Detailtiefe.

Lighthouse

Sehr gut für:

• schnellen Überblick
• Score
• einfache Integration in Chrome
• erste technische Prüfung

axe DevTools

Sehr gut für:

• detaillierte Fehleranalyse
• Entwickler
• konkrete HTML-Elemente
• technische Ursachen
• Priorisierung

Ich würde nicht entscheiden:

axe oder Lighthouse

sondern:

axe und Lighthouse

Wie unterscheidet sich axe von WAVE?

WAVE ist stärker visuell.

Es legt Symbole direkt über die Website.

Das ist für Einsteiger sehr angenehm.

axe arbeitet stärker innerhalb der Entwicklertools.

Dadurch wirkt es technischer.

WAVE

Gut für:

• visuelle Orientierung
• Alt-Texte
• Struktur
• schnelle Kontrolle

axe

Gut für:

• technische Fehleranalyse
• Entwickler
• HTML
• ARIA
• konkrete Reparaturhinweise

Auch diese beiden Tools ergänzen sich hervorragend.

Kann axe eine Website automatisch reparieren?

Nein.

Die kostenlose Erweiterung findet Probleme.

Sie behebt deine Website nicht automatisch.

Das ist auch gut so.

Wenn ein Theme einen fehlerhaften Button erzeugt, muss die eigentliche Ursache behoben werden.

Nicht einfach eine zusätzliche Schicht darübergelegt werden.

Kann axe feststellen, ob meine Website barrierefrei ist?

Nein.

Das ist wahrscheinlich die wichtigste Aussage dieses Artikels.

axe DevTools kann automatisiert erkennbare Probleme finden.

Es kann nicht vollständig beurteilen:

• ob die Tab-Reihenfolge logisch ist,
• ob ein Alt-Text sinnvoll formuliert ist,
• ob eine Fehlermeldung verständlich ist,
• ob ein kompletter Checkout funktioniert,
• ob ein Popup gut bedienbar ist,
• ob Inhalte leicht verständlich sind.

Deshalb gilt:

0 axe-Fehler bedeutet nicht automatisch barrierefrei.

Kann axe WCAG-Konformität bestätigen?

Nicht alleine.

axe verwendet Prüfregeln, die sich auf gängige Accessibility-Standards beziehen.

Aber viele WCAG-Kriterien benötigen manuelle Prüfung.

Deshalb kann ein automatischer Scan keine vollständige WCAG-Konformität bestätigen.

Kann axe BFSG-Konformität bestätigen?

Auch nicht.

BFSG ist eine rechtliche Anforderung.

axe kann technische Accessibility-Probleme finden.

Aber:

0 axe-Fehler = BFSG-konform

ist keine zulässige Schlussfolgerung.

Für eine umfassende Bewertung müssen deutlich mehr Aspekte geprüft werden.

Welche Probleme erkennt axe besonders gut?

axe ist sehr gut bei eindeutig technischen Problemen.

Zum Beispiel:

• fehlende zugängliche Namen
• fehlende Labels
• bestimmte ARIA-Fehler
• ungültige Strukturen
• fehlende Alt-Attribute
• bestimmte Kontrastprobleme

Diese Dinge lassen sich maschinell vergleichsweise zuverlässig prüfen.

Welche Probleme brauchen einen Menschen?

Sehr viele.

Alt-Texte

axe:

Alt-Text vorhanden.

Mensch:

Ist er sinnvoll?

Tastatur

axe:

Element fokussierbar.

Mensch:

Ist die Reihenfolge logisch?

Formular

axe:

Label vorhanden.

Mensch:

Ist die Fehlermeldung verständlich?

Navigation

axe:

technisch strukturiert.

Mensch:

Kann ich mich tatsächlich orientieren?

Checkout

axe:

einzelne Elemente korrekt.

Mensch:

Kann ich wirklich bestellen?

axe mit Tastaturtest kombinieren

Nach jedem automatischen Scan solltest du einen manuellen Tastaturtest durchführen.

Maus weglegen.

Dann:

Tab.

Shift + Tab.

Enter.

Leertaste.

Escape.

Teste:

• Navigation
• Dropdowns
• Buttons
• Formulare
• Popups

Bei einem Online-Shop zusätzlich:

• Varianten
• Warenkorb
• Checkout
• Zahlungsart

Das findet Probleme, die axe alleine nicht zuverlässig erkennen kann.

axe mit Screenreader kombinieren

Ein Screenreader-Test ergänzt axe ebenfalls sehr gut.

axe sagt:

Button besitzt zugänglichen Namen.

Screenreader sagt:

„Button Weiter.“

Dann merkst du:

Technisch korrekt.

Inhaltlich vielleicht zu unklar.

Oder:

axe meldet kein Bildproblem.

Screenreader liest:

„IMG final 2025 webp.“

Dann weißt du:

Der Alt-Text muss verbessert werden.

axe mit Browser-Zoom kombinieren

Vergrößere die Seite auf etwa 200 Prozent.

Prüfe:

• überlappen Inhalte?
• verschwinden Buttons?
• funktioniert das Menü?
• bleibt der Checkout sichtbar?
• ist das Cookie-Banner noch bedienbar?

Solche Layoutprobleme werden nicht vollständig durch einen axe-Scan abgedeckt.

axe DevTools bei WordPress

Für WordPress ist axe besonders hilfreich.

Denn viele technische Probleme entstehen durch:

• Theme
• Pagebuilder
• Plugins
• Formulare
• Menüs
• Cookie-Tools

Du musst den Fehler nicht selbst programmiert haben.

axe zeigt dir trotzdem:

welches Element im fertigen Frontend problematisch ist.

axe mit Elementor

Bei Elementor würde ich besonders prüfen:

• Buttons
• Icon-Elemente
• Formulare
• Tabs
• Akkordeons
• Popups
• Navigation

Gerade individuell angepasste Widgets können technische Auffälligkeiten erzeugen.

axe mit Divi

Bei Divi sind ähnliche Bereiche relevant:

• Menü
• Slider
• Toggle
• Akkordeons
• Kontaktformular
• Buttons
• Icons

Nach jedem größeren Layout-Umbau lohnt sich ein erneuter Scan.

axe bei WooCommerce

WooCommerce sollte nicht nur auf der Startseite geprüft werden.

Teste mehrere Seitentypen.

Kategorie

Prüfe:

• Filter
• Sortierung
• Produktlinks

Produktseite

Prüfe:

• Bilder
• Varianten
• Buttons
• Preis
• Galerie

Warenkorb

Prüfe:

• Mengensteuerung
• Entfernen
• Gutscheine

Checkout

Prüfe:

• Labels
• Fehlermeldungen
• Zahlungsarten

Kundenkonto

Prüfe:

• Login
• Navigation
• Downloads

Dynamische Inhalte erneut scannen

Ein wichtiger Praxistipp:

Führe den Scan nicht nur im Ausgangszustand durch.

Beispiel:

Produktseite öffnen.

axe scannen.

Dann:

Variante auswählen.

Popup öffnen.

Filter aktivieren.

Warenkorb öffnen.

Erneut scannen.

Warum?

Weil sich der HTML-Zustand verändern kann.

Ein Fehler existiert vielleicht erst, nachdem ein Dialog geöffnet wurde.

Cookie-Banner mit axe testen

Öffne deine Website in einem privaten Fenster.

Cookie-Banner erscheint.

Jetzt axe starten.

Prüfe:

• Buttons
• Schalter
• Beschriftungen
• ARIA
• Dialogstruktur

Danach:

Maus weglegen.

Denn axe kann nicht vollständig beurteilen, ob die Fokussteuerung im echten Ablauf sinnvoll ist.

Modale Fenster testen

Popups und modale Dialoge sind besonders wichtig.

Ein Dialog sollte beispielsweise:

• korrekt angekündigt werden,
• sinnvoll fokussiert werden,
• mit Tastatur bedienbar sein,
• wieder geschlossen werden können.

axe kann einige technische Fehler finden.

Die tatsächliche Fokussteuerung solltest du trotzdem praktisch testen.

Problemhafte Treffer verstehen

Manchmal zeigt axe einen Fehler in einem Element, das aus einem Plugin stammt.

Zum Beispiel:

div.some-plugin-widget

Dann weißt du:

Der Fehler liegt wahrscheinlich nicht direkt in deinem normalen Seiteninhalt.

Mögliche Lösungen:

• Plugin-Einstellungen prüfen
• Plugin aktualisieren
• Theme-Anpassung
• Entwickler kontaktieren
• alternative Erweiterung wählen

Das ist wesentlich zielgerichteter, als einfach irgendwo CSS zu ändern.

Nicht jeden Fehler sofort selbst programmieren

Wenn axe technischen Code anzeigt, entsteht schnell der Wunsch:

„Dann füge ich einfach ein aria-label hinzu.“

Vorsicht.

Nicht jede schnelle Änderung ist korrekt.

Beispielsweise kann ein falsch eingesetztes ARIA-Attribut zu widersprüchlichen Informationen führen.

Bei komplexen Komponenten sollte die Ursache sauber gelöst werden.

Fehler nach Komponenten gruppieren

Angenommen, axe zeigt:

15 Fehler.

Auf den ersten Blick viel.

Dann stellst du fest:

12 davon kommen aus demselben Menü.

Das bedeutet:

Du hast nicht 12 völlig unabhängige Probleme.

Du hast möglicherweise einen Fehler im Menü-Template.

Ein Fix kann alle 12 Meldungen gleichzeitig lösen.

Deshalb lohnt sich die technische Gruppierung.

Probleme dokumentieren

Bei größeren Websites würde ich eine einfache Tabelle anlegen.

Seite	Problem	Schweregrad	Ursache	Status
Startseite	Button ohne Namen	Serious	Theme	Offen
Kontakt	Feld ohne Label	Critical	Formularplugin	Offen
Produkt	Kontrast Preis	Serious	CSS	Erledigt
Checkout	ARIA-Fehler	Moderate	Payment-Plugin	Offen

So behältst du den Überblick.

Welche Seiten zuerst testen?

Nicht 500 Seiten wahllos scannen.

Beginne mit Seitentypen.

Für eine Firmenwebsite:

• Startseite
• Leistungsseite
• Kontakt
• Formular
• Blogartikel

Für einen Shop:

• Startseite
• Kategorie
• Produktseite
• Warenkorb
• Checkout
• Kundenkonto

Damit findest du viele wiederkehrende Probleme.

axe während der Entwicklung verwenden

Am besten findet man Accessibility-Probleme nicht erst kurz vor dem Launch.

Wenn du selbst entwickelst:

Neue Komponente bauen.

axe starten.

Fehler beheben.

Weiterbauen.

Das ist effizienter, als am Ende 80 Seiten nachzubessern.

axe nach Plugin-Updates erneut nutzen

WordPress-Plugins verändern sich.

Ein Update kann:

• HTML ändern
• ARIA verändern
• neue Buttons erzeugen
• Fokusverhalten anpassen

Deshalb lohnt sich nach größeren Updates ein erneuter Test.

Besonders bei:

• WooCommerce
• Checkout-Plugins
• Consent-Tools
• Formularplugins
• Pagebuildern

Was bedeuten 0 axe-Issues?

Das ist ein gutes Ergebnis.

Es bedeutet:

axe hat bei seinen automatisierten Prüfungen aktuell keine entsprechenden Probleme gefunden.

Das ist positiv.

Aber:

Es bedeutet nicht:

Website vollständig barrierefrei.

Danach folgen noch:

• Tastaturtest
• Screenreader
• Zoom
• mobile Prüfung
• manuelle Inhaltsbewertung

Was tun bei 50 oder mehr Fehlern?

Nicht in Panik geraten.

Sortiere zuerst nach:

1. Critical
2. Serious
3. wiederkehrenden Komponenten
4. wichtigen Nutzerwegen

Dann behebe systematisch.

Beispiel:

20 Fehler kommen aus dem Header.

15 aus dem Formularplugin.

10 aus Produktkarten.

5 Einzelprobleme.

Dann hast du eigentlich nur wenige Hauptbaustellen.

axe und Barrierefreiheits-Plugins

Ein Accessibility-Plugin kann bestimmte Funktionen ergänzen.

axe prüft dagegen den tatsächlichen technischen Zustand.

Das sind unterschiedliche Dinge.

Ein Plugin-Menü mit:

• Schrift vergrößern
• Kontrast wechseln

repariert nicht automatisch:

• fehlende Labels
• leere Buttons
• falsches ARIA
• unbedienbare Komponenten

Deshalb ist ein echter Test wichtiger als das bloße Vorhandensein eines Accessibility-Widgets.

axe und Overlays

Ähnliches gilt für sogenannte Accessibility-Overlays.

Ein Overlay kann möglicherweise bestimmte Oberflächeneinstellungen anbieten.

Es behebt aber nicht automatisch sämtliche strukturellen Probleme.

axe kann deshalb auch auf einer Website mit Overlay weiterhin Fehler finden.

Das sollte niemand überraschen.

axe und Lighthouse kombinieren

Mein praktischer Workflow:

Schritt 1

Lighthouse.

Schneller Überblick.

Schritt 2

axe DevTools.

Technische Detailanalyse.

Schritt 3

WAVE.

Visuelle Kontrolle.

Schritt 4

Tastatur.

Praktische Bedienung.

Schritt 5

Zoom.

Layout überprüfen.

Schritt 6

Screenreader.

Nutzerperspektive anhören.

Das ist deutlich aussagekräftiger als ein einzelner Score.

Ein einfacher axe-Test in 10 Minuten

Wenn du wenig Zeit hast:

Minute 1

Seite öffnen.

Minute 2

axe DevTools starten.

Minute 3

Scan durchführen.

Minute 4 bis 6

Critical und Serious Issues ansehen.

Minute 7

Betroffene Elemente identifizieren.

Minute 8 bis 10

Maus weglegen und dieselbe Seite mit Tab bedienen.

Damit bekommst du bereits einen sehr brauchbaren ersten Eindruck.

Ein 30-Minuten-Test für einen Online-Shop

5 Minuten

Produktseite mit axe.

5 Minuten

Warenkorb.

5 Minuten

Checkout.

5 Minuten

Cookie-Banner.

5 Minuten

Tastaturtest.

5 Minuten

Zoom und Smartphone.

Damit findest du häufig bereits eine große Zahl wichtiger Probleme.

Typische axe-Fehler in der Praxis

Besonders oft begegnen dir:

Button ohne zugänglichen Namen

Icon-Button ohne Text.

Link ohne Namen

Leerer oder nur grafischer Link.

Bild ohne Alt-Information

Produktbild ohne Alternativtext.

Formularfeld ohne Label

Input technisch nicht beschriftet.

ARIA-Fehler

Ungültiges oder unvollständiges Attribut.

Kontrastproblem

Text hebt sich nicht ausreichend ab.

Strukturproblem

Bestimmte HTML-Elemente falsch eingesetzt.

Was axe nicht ersetzt

axe ersetzt nicht:

• echte Screenreader-Nutzer
• Tastaturtests
• manuelle WCAG-Prüfung
• verständliche Sprache
• redaktionelle Qualität
• rechtliche Bewertung

Das sollte bei jeder Nutzung im Hinterkopf bleiben.

Praktische Checkliste für axe DevTools

Wenn du eine Seite mit axe prüfst:

• Scan durchführen
• Critical Issues zuerst ansehen
• Serious Issues prüfen
• betroffene Elemente öffnen
• HTML-Ursache identifizieren
• wiederkehrende Komponenten erkennen
• Problem sinnvoll beheben
• Seite neu laden
• erneut scannen
• danach Tastatur testen
• Fokus kontrollieren
• Alt-Texte inhaltlich prüfen
• Formulare praktisch verwenden
• Fehlermeldungen auslösen
• Browser vergrößern
• Screenreader testen
• mobile Ansicht prüfen

Wie sollte man Ergebnisse priorisieren?

Meine Reihenfolge wäre:

Priorität 1: Nutzer kann Funktion nicht verwenden

Zum Beispiel:

• Button ohne Namen
• Formular nicht zugänglich
• Checkout blockiert

Priorität 2: wichtige Information fehlt

Zum Beispiel:

• Produktbild ohne Alt-Text
• Formular ohne Label

Priorität 3: Orientierung erschwert

Zum Beispiel:

• Struktur
• Kontrast
• unklare Semantik

Priorität 4: kleinere technische Verbesserungen

Danach weitere Hinweise.

axe DevTools als Teil eines regelmäßigen Checks

Barrierefreiheit ist keine einmalige Aufgabe.

Websites ändern sich.

Neue:

• Seiten
• Produkte
• Plugins
• Formulare
• Popups
• Zahlungsarten

kommen hinzu.

Deshalb lohnt sich ein regelmäßiger Scan.

Zum Beispiel:

nach größeren Updates.

vor einem Relaunch.

nach einem neuen Checkout.

nach einem Theme-Wechsel.

Fazit: axe DevTools ist technisch – aber nicht kompliziert

axe DevTools wirkt beim ersten Öffnen etwas technischer als Lighthouse oder WAVE.

Das ist aber gleichzeitig seine Stärke.

Das Tool zeigt nicht nur:

„Es gibt ein Problem.“

Sondern meistens auch:

„Dieses konkrete Element verursacht es.“

Gerade für Entwickler, Agenturen und WordPress-Nutzer, die technische Fehler genauer verstehen möchten, ist das sehr hilfreich.

Der beste Ablauf lautet:

Scan starten.

Critical und Serious Probleme prüfen.

Ursache verstehen.

Problem beheben.

Erneut testen.

Danach kommt der Teil, den kein automatisches Tool ersetzen kann:

Maus weglegen.

Mit Tastatur navigieren.

Website vergrößern.

Screenreader einschalten.

Formulare tatsächlich verwenden.

Denn axe DevTools kann technische Barrieren hervorragend sichtbar machen.

Ob sich eine Website für einen echten Menschen gut benutzen lässt, zeigt am Ende trotzdem nur der praktische Test.

Deshalb würde ich axe nicht als Konkurrenz zu WAVE oder Lighthouse sehen.

Sondern als einen weiteren wichtigen Baustein.

Lighthouse für den schnellen Überblick.

WAVE für die visuelle Kontrolle.

axe DevTools für die technische Detailanalyse.

Tastatur und Screenreader für die reale Nutzung.

In dieser Kombination bekommst du bereits ein sehr gutes Bild davon, wo deine Website noch verbessert werden sollte.

Hinweis: axe DevTools unterstützt bei der technischen Prüfung digitaler Barrierefreiheit, ersetzt jedoch keine vollständige fachliche Accessibility-Prüfung und keine individuelle rechtliche Bewertung hinsichtlich BFSG, WCAG oder anderer Anforderungen.