Fortlaufende Prüfung von Barrierefreiheit, Leistung, SEO und technischer Qualität
Prüfbericht
www.w3.org
Automatisierte Prüfung vom 14.10.2026 um 09:45 Uhr
Bericht erstellt am 15.10.2026 um 20:02 Uhr
· W3C-Demo (Beispielbericht)
Leistung
97
gut
SEO
81
verbesserungsbedürftig
Technische Qualität
87
verbesserungsbedürftig
Leitzahl
Barrierefreiheit
17von 100
schwach
Seit dem letzten Lauf
Erster Lauf – es gibt noch nichts zu vergleichen. Ab dem zweiten Lauf steht hier,
was neu ist, was behoben wurde und was zurückgekehrt ist.
Die drei dringendsten Maßnahmen
1
kritischAlternativtexte für Bilder ergänzen
Bilder tragen oft die Kernbotschaft. Geht sie verloren, bricht der Besuch häufiger ab – Suchmaschinen fehlt derselbe Text.
Barrierefreiheit
· 4 Stellen auf allen 4 URLs
· zuständig: Redaktion und Frontend-Entwicklung
2
kritischAuswahllisten beschriften
Auswahllisten stehen in Bestellung, Filter und Kontaktformular – eine falsche Wahl kostet dort Zeit oder den Abschluss.
Barrierefreiheit
· 4 Stellen auf allen 4 URLs
· zuständig: Frontend-Entwicklung
3
kritischFormularfelder mit sichtbaren Beschriftungen verbinden
Formulare sind der Ort, an dem Anfragen entstehen. Was hier nicht bedienbar ist, kostet unmittelbar Aufträge.
Barrierefreiheit
· 1 Stelle auf 1 von 4 URLs
· zuständig: Frontend-Entwicklung
Was dieser Bericht ist — und was nicht
Er beruht ausschließlich auf automatisierten Prüfungen. Diese decken nur einen Teil
der WCAG-Kriterien ab. Der Bericht zeigt Handlungsbedarf und dessen Entwicklung über
die Zeit; er ist keine Konformitätsbewertung und ersetzt keine
manuelle Prüfung durch Menschen.
Barrierefreiheit · Leistung · SEO · Technische Qualität
WCAG 2.0 A · WCAG 2.0 AA · WCAG 2.1 A · WCAG 2.1 AA · WCAG 2.2 AA · bewährte Praxis (keine WCAG-Anforderung)
Automatisierte Prüfung, keine Konformitätsbewertung — die vollständige Einordnung steht
auf dem Deckblatt.
Bewertung
Vier Werte von 0 bis 100 nach Formel
v2.
90 bis 100 gut, 50 bis 89 verbesserungsbedürftig, unter 50 schwach.
Die Leitzahl ist die Barrierefreiheit.
Bewertung je Bereich mit Einordnung und Veränderung zum Vorlauf
Bereich
Wert
Einordnung
zum Vorlauf
Barrierefreiheit
17
schwach
—
Leistung
97
gut
—
SEO
81
verbesserungsbedürftig
—
Technische Qualität
87
verbesserungsbedürftig
—
Veränderung seit dem vorherigen Lauf
Erster Lauf – es gibt noch nichts zu vergleichen. Ab dem zweiten Lauf steht hier,
was neu ist, was behoben wurde und was zurückgekehrt ist.
Technik-Kontext
Aus Meta-Angaben, Antwort-Headern, geladenen Dateien und globalen JavaScript-Objekten
abgeleitet. Er bestimmt, wo eine Korrektur ansetzt – im Theme, im Template
oder in der Komponente.
Messung
Matomo
wahrscheinlich
Selbst gehostet und datensparsam konfigurierbar - die datenschutzfreundliche Alternative.
Server und CDN
Cloudflare
wahrscheinlich
Priorisierte Maßnahmen
32 Maßnahmen, nach Dringlichkeit geordnet.
Bei gleicher Schwere steht Barrierefreiheit vorn. Messwerte stehen im eigenen Abschnitt,
weil sie von Lauf zu Lauf schwanken.
Sofort beheben
(3 Maßnahmen)
Diese Probleme blockieren Nutzer und wiegen rechtlich am schwersten.
kritisch
4von 4
betroffene URLs
4 Stellen
Alternativtexte für Bilder ergänzen
Barrierefreiheit
Regel image-alt
· seit 1 Tag offen
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Hintergrund
Screenreader lesen bei einem Bild ohne alt-Attribut den Dateinamen vor oder überspringen es. Nutzer mit Sehbehinderung erfahren nicht, was auf dem Bild zu sehen ist.
Betroffene Nutzergruppen
Blinde Nutzer und Nutzer mit Sehbehinderungen
Geschäftliche Wirkung
Bilder tragen oft die Kernbotschaft. Geht sie verloren, bricht der Besuch häufiger ab – Suchmaschinen fehlt derselbe Text.
So beheben Sie das
Ergänzen Sie für informative Bilder einen knappen, kontextbezogenen alt-Text. Rein dekorative Bilder bekommen ein leeres alt="".
So prüfen Sie die Korrektur
Prüfen Sie jedes markierte img-Element im veröffentlichten DOM und lassen Sie die Seite von einem Screenreader vorlesen.
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Hintergrund
Eine Auswahlliste (select) hat keinen zugänglichen Namen. Screenreader nennen den gewählten Eintrag, aber nicht, wofür die Auswahl ist – Land, Größe oder Anrede.
Betroffene Nutzergruppen
Screenreader-Nutzer, Nutzer von Sprachsteuerung
Geschäftliche Wirkung
Auswahllisten stehen in Bestellung, Filter und Kontaktformular – eine falsche Wahl kostet dort Zeit oder den Abschluss.
So beheben Sie das
Verknüpfen Sie die Liste mit einem sichtbaren label. Nur wo kein sichtbarer Text möglich ist, genügt ein aria-label.
So prüfen Sie die Korrektur
Fokussieren Sie die Liste mit einem Screenreader und prüfen Sie, dass ihr Zweck angesagt wird.
Formularfelder mit sichtbaren Beschriftungen verbinden
Barrierefreiheit
Regel label
· seit 1 Tag offen
Wo diese Regel sitzt — 2 Bausteine:
input
— 1 von 1 Stellen, auf 1 von 4 URLs
input.align
— 1 von 1 Stellen, auf 1 von 4 URLs
Gruppiert nach Element und Klassen — gleiches Markup heißt in der Regel
derselbe Baustein. Die Zeilen summieren sich nicht: eine Stelle steht in
mehreren, wenn ihr Markup zwischen den Seiten abweicht. Ein Hinweis,
kein Beweis.
Hintergrund
Ein Feld ohne verknüpftes label wird vom Screenreader nur als "Eingabefeld" angesagt. Ein einziges fehlendes Label kann ein ganzes Formular unbenutzbar machen.
Betroffene Nutzergruppen
Screenreader-Nutzer, Nutzer mit kognitiven Beeinträchtigungen
Geschäftliche Wirkung
Formulare sind der Ort, an dem Anfragen entstehen. Was hier nicht bedienbar ist, kostet unmittelbar Aufträge.
So beheben Sie das
Verknüpfen Sie jedes Formularfeld mit einem sichtbaren label und verbinden Sie Hinweise sowie Fehlermeldungen programmatisch.
So prüfen Sie die Korrektur
Fokussieren Sie jedes markierte Feld mit einem Screenreader und prüfen Sie Name, Anweisung und Fehlerzustand.
Empfohlene Zuständigkeit
Frontend-Entwicklung
Zugehörige WCAG-Kriterien
1.3.1 Info und Beziehungen (A) · 3.3.2 Beschriftungen oder Anweisungen (A) · 4.1.2 Name, Rolle, Wert (A)
Diese Probleme beeinträchtigen das Benutzererlebnis erheblich.
ernst
2von 4
betroffene URLs
11 Stellen
Farbkontrast von Text erhöhen
Barrierefreiheit
Regel color-contrast
· seit 1 Tag offen
Wo diese Regel sitzt — 2 Bausteine:
font
— 9 von 11 Stellen, auf 1 von 4 URLs
b
— 2 von 11 Stellen, auf 1 von 4 URLs
Gruppiert nach Element und Klassen — gleiches Markup heißt in der Regel
derselbe Baustein. Die Zeilen summieren sich nicht: eine Stelle steht in
mehreren, wenn ihr Markup zwischen den Seiten abweicht. Ein Hinweis,
kein Beweis.
Hintergrund
Der Text hebt sich zu wenig vom Hintergrund ab. Für viele Menschen ist er dadurch schwer oder gar nicht lesbar – auch bei Sonnenlicht oder auf schlechten Bildschirmen.
Betroffene Nutzergruppen
Menschen mit Sehbehinderungen, einschließlich Farbenblindheit; alle Nutzer bei ungünstigem Licht
Geschäftliche Wirkung
Unzureichende Kontraste gehören zu den häufigsten Barrierefreiheitsproblemen im Web und sind einer der ersten Punkte, die eine Prüfstelle beanstandet.
So beheben Sie das
Erhöhen Sie das Kontrastverhältnis auf mindestens 4,5:1 für normalen und 3:1 für großen Text. Passen Sie die Farbwerte in der gemeinsamen Komponente an, nicht einzeln.
So prüfen Sie die Korrektur
Messen Sie jedes betroffene Farbpaar erneut und prüfen Sie Normal-, Hover-, Fokus- und deaktivierte Zustände.
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Wo diese Regel sitzt — 2 Bausteine:
a.report
— 8 von 9 Stellen, auf allen 4 URLs
a
— 1 von 9 Stellen, auf 1 von 4 URLs
Gruppiert nach Element und Klassen — gleiches Markup heißt in der Regel
derselbe Baustein. Die Zeilen summieren sich nicht: eine Stelle steht in
mehreren, wenn ihr Markup zwischen den Seiten abweicht. Ein Hinweis,
kein Beweis.
Hintergrund
Kleine Schaltflächen und Links sind auf Touchgeräten schwer zu treffen – besonders mit eingeschränkter Feinmotorik.
Betroffene Nutzergruppen
Menschen mit motorischen Beeinträchtigungen, mobile Nutzer
Geschäftliche Wirkung
Fehlklicks auf schmalen Zielen sind eine der häufigsten Abbruchursachen auf dem Smartphone.
So beheben Sie das
Vergrößern Sie die Zielfläche auf mindestens 24 mal 24 CSS-Pixel oder schaffen Sie ausreichenden Abstand.
So prüfen Sie die Korrektur
Prüfen Sie die Zielgrößen in schmalen Viewports und bedienen Sie die Elemente per Touch.
Empfohlene Zuständigkeit
Design und Frontend-Entwicklung
Zugehörige WCAG-Kriterien
2.5.8 Zielgröße (Minimum) (AA)
So sieht die Stelle aus – /WAI/demos/bad/before/home.html
(Desktop)
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Hintergrund
Die Seite ist breiter als der Bildschirm. Wer stark vergrößert oder ein schmales Telefon nutzt, muss für jede einzelne Zeile hin- und herschieben – Lesen wird zur Arbeit, und am rechten Rand verschwinden Inhalte aus dem Blick.
Betroffene Nutzergruppen
Menschen mit Sehbehinderung, die stark vergrößern; alle Nutzer schmaler Geräte
Geschäftliche Wirkung
Der Prüffall, den jede Konformitätsprüfung als Erstes aufruft – und einer der wenigen Verstöße, die auch ohne Fachwissen sofort auffallen.
So beheben Sie das
Suchen Sie das Element, das über den Rand ragt. Bewährte Reihenfolge:
1. Kästen in Flex- oder Grid-Layouts brauchen min-width: 0 – sonst schrumpfen sie nicht unter ihre Inhaltsbreite.
2. Breite Tabellen und Codeblöcke gehören in einen eigenen Bereich mit overflow-x:auto, tabindex="0" und zugänglichem Namen. Ein Bereich, der FÜR SICH scrollt, ist erlaubt.
3. Wächst nur das Dokument, nicht body: dann hängt ein absolut positionierter Kasten am initial containing block. Klassischer Fall ist sr-only ohne positionierten Vorfahren – dem umgebenden Bereich position:relative geben.
4. Dekorative Elemente mit negativen Rändern gehören in einen Vorfahren mit overflow-hidden.
5. Nennt der Befund kein Element, ragt kein Kasten der Seite heraus — dann steckt die Ursache fast immer in einem ::before oder ::after. Solche Pseudo-Elemente lassen sich nicht aufzählen; suchen Sie im Stylesheet nach negativen Werten für right, left, margin oder translate.
So prüfen Sie die Korrektur
Schmalen Sie das Fenster auf 320 Pixel oder messen Sie im Browser document.documentElement.scrollWidth gegen clientWidth. Beide Werte müssen gleich sein.
Erklärung zur Barrierefreiheit veröffentlichen und verlinken
Technische Qualität
Regel legal-accessibility
· seit 1 Tag offen
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Hintergrund
Das Barrierefreiheitsstärkungsgesetz verlangt von vielen Anbietern eine eigene Erklärung zur Barrierefreiheit – mit Angaben zum Stand, zu bekannten Einschränkungen und zu einem Meldeweg für Betroffene.
Betroffene Nutzergruppen
Menschen mit Behinderungen, Aufsichtsbehörden
Geschäftliche Wirkung
Von allen Pflichtangaben ist diese die am häufigsten fehlende. Sie ist zugleich die, nach der eine Marktüberwachungsbehörde zuerst fragt.
So beheben Sie das
Legen Sie eine Seite „Erklärung zur Barrierefreiheit" an und verlinken Sie sie aus der Fußzeile. Inhalt: Stand der Vereinbarkeit, nicht barrierefreie Inhalte mit Begründung, Datum der letzten Prüfung, Kontaktweg für Rückmeldungen und Hinweis auf das Durchsetzungsverfahren.
So prüfen Sie die Korrektur
Rufen Sie eine beliebige Unterseite auf und prüfen Sie, ob die Erklärung aus der Fußzeile erreichbar ist.
Ein Bild wird größer angezeigt, als seine Auflösung hergibt – bezogen auf die Pixeldichte des Bildschirms. Auf hochauflösenden Displays wirkt es unscharf.
Betroffene Nutzergruppen
Alle Besucher mit hochauflösenden Bildschirmen, die meisten Smartphones
Geschäftliche Wirkung
Unscharfe Bilder schwächen den Eindruck von Produkten und Marke.
So beheben Sie das
Stellen Sie mit srcset mehrere Auflösungen bereit, damit der Browser die passende wählt.
So prüfen Sie die Korrektur
Prüfen Sie das Bild auf einem hochauflösenden Bildschirm und scannen Sie die Seite erneut.
Ein Bild wird in einem anderen Seitenverhältnis dargestellt, als es hat. Es erscheint gestaucht oder gestreckt.
Betroffene Nutzergruppen
Alle Besucher
Geschäftliche Wirkung
Verzerrte Produkt- oder Personenbilder wirken unprofessionell – gerade dort, wo das Bild überzeugen soll.
So beheben Sie das
Geben Sie in width und height die tatsächlichen Maße an und passen Sie die Darstellung mit object-fit an, statt Breite und Höhe unabhängig festzulegen.
So prüfen Sie die Korrektur
Vergleichen Sie das angezeigte Bild mit dem Original und scannen Sie die Seite erneut.
Regel network-dependency-tree-insight
· seit 1 Tag offen
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Hintergrund
Wichtige Ressourcen werden erst geladen, nachdem andere geladen wurden – eine Kette, in der jedes Glied auf das vorige wartet.
Betroffene Nutzergruppen
Alle Besucher
Geschäftliche Wirkung
Lange Ketten verzögern die erste Darstellung, auch wenn jede einzelne Datei klein ist.
So beheben Sie das
Binden Sie kritische Ressourcen direkt ein statt über andere Dateien, bauen Sie Verbindungen zu wichtigen Servern mit preconnect vorab auf und laden Sie Unkritisches später.
So prüfen Sie die Korrektur
Vergleichen Sie im nächsten Scan Länge und Dauer der längsten Kette.
Wirkung begrenzt – sinnvoll, wenn die Stufen darüber leer sind.
mittel
4von 4
betroffene URLs
20 Stellen
Alle Inhalte einem Seitenbereich zuordnen
Barrierefreiheit
Regel region
· seit 1 Tag offen
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Wo diese Regel sitzt — 10 Bausteine:
div.inaccessible
— 4 von 20 Stellen, auf allen 4 URLs
h1.subhead
— 4 von 20 Stellen, auf allen 4 URLs
p
— 4 von 20 Stellen, auf allen 4 URLs
p.subline
— 4 von 20 Stellen, auf allen 4 URLs
div
— 2 von 20 Stellen, auf 2 von 4 URLs
… und 5 weitere
Gruppiert nach Element und Klassen — gleiches Markup heißt in der Regel
derselbe Baustein. Die Zeilen summieren sich nicht: eine Stelle steht in
mehreren, wenn ihr Markup zwischen den Seiten abweicht. Ein Hinweis,
kein Beweis.
Hintergrund
Inhalt, der in keinem Landmark liegt, ist für Screenreader-Nutzer schwer auffindbar. Sie springen von Bereich zu Bereich – was dazwischen liegt, finden sie nur, wenn sie die ganze Seite linear durchgehen.
Betroffene Nutzergruppen
Screenreader-Nutzer, Tastatur-Nutzer
Geschäftliche Wirkung
Betrifft meist das Seitenlayout und damit alle Seiten gleichzeitig – eine Korrektur im Layout behebt viele Befunde auf einmal.
So beheben Sie das
Verpacken Sie den Hauptinhalt in ein main-Element und ordnen Sie Kopf-, Navigations- und Fußbereich header, nav und footer zu. Freistehende Abschnitte kommen in ein section mit aria-label oder in das umgebende Landmark.
So prüfen Sie die Korrektur
Lassen Sie die Landmark-Liste eines Screenreaders anzeigen und prüfen Sie, dass kein sichtbarer Inhalt außerhalb liegt.
Empfohlene Zuständigkeit
Frontend-Entwicklung
Zugehörige WCAG-Kriterien
1.3.1 Info und Beziehungen (A)
So sieht die Stelle aus – /WAI/demos/bad/before/home.html
(Desktop)
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Hintergrund
Ohne Festlegung übermittelt der Browser beim Verlassen der Seite die vollständige Herkunfts-URL an fremde Server – samt Suchbegriffen und Kennungen im Pfad.
Betroffene Nutzergruppen
Alle Besucher
Geschäftliche Wirkung
Auch eine Datenschutzfrage – Sie geben ungefragt Nutzungsdaten an Dritte weiter.
So beheben Sie das
Referrer-Policy: strict-origin-when-cross-origin
So prüfen Sie die Korrektur
Antwort-Header prüfen und einen ausgehenden Link testen.
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Hintergrund
Ein Bild ohne Größenangabe hat vor dem Laden keinen Platz. Der Text darunter springt in dem Moment nach unten, in dem das Bild ankommt — oft genau dann, wenn jemand zu lesen beginnt oder auf einen Verweis zielt.
Betroffene Nutzergruppen
Alle Besucher; besonders auf langsamen Verbindungen und für Menschen mit motorischen Einschränkungen, die einen springenden Knopf verfehlen.
Geschäftliche Wirkung
Springende Inhalte sind die häufigste Ursache für Fehlklicks und gehen unmittelbar in die Bewertung der Ladeerfahrung ein.
So beheben Sie das
Setzen Sie width und height am img-Element auf die tatsächlichen Maße der Bilddatei; die Darstellungsgröße bestimmt weiterhin das CSS. Bei Hintergrundbildern hilft aspect-ratio.
So prüfen Sie die Korrektur
Laden Sie die Seite mit gedrosselter Verbindung. Der Text darunter darf sich nicht mehr bewegen, wenn das Bild erscheint.
Der Lesbarkeitsindex LIX misst Satzlänge und Anteil langer Wörter. Über 60 gilt im Deutschen als schwer verständlich – Behördendeutsch, Fachtexte, Schachtelsätze.
Betroffene Nutzergruppen
Menschen mit kognitiven Beeinträchtigungen, Leseschwäche oder Deutsch als Fremdsprache
Geschäftliche Wirkung
Verständlichkeit ist ein BFSG-Thema und zugleich der günstigste Hebel für mehr Anfragen – wer nicht versteht, fragt nicht an.
So beheben Sie das
Kürzen Sie Sätze auf durchschnittlich unter 20 Wörter, ersetzen Sie zusammengesetzte Substantive durch Verben, und schreiben Sie im Aktiv.
So prüfen Sie die Korrektur
Lassen Sie den Text nach der Überarbeitung erneut messen – der LIX sollte unter 60 liegen.
Eine leere Kopfzelle lässt Screenreader-Nutzer raten, was eine Spalte oder Zeile enthält – die Zuordnung der Werte geht verloren.
Betroffene Nutzergruppen
Screenreader-Nutzer
Geschäftliche Wirkung
Preis-, Leistungs- und Vergleichstabellen werden unverständlich – genau die Stellen, an denen entschieden wird.
So beheben Sie das
Geben Sie jeder th-Zelle einen aussagekräftigen Text. Ist die Zelle keine Überschrift, verwenden Sie td; soll der Text nicht sichtbar sein, blenden Sie ihn nur visuell aus.
So prüfen Sie die Korrektur
Lassen Sie die Tabelle mit einem Screenreader zellenweise vorlesen und prüfen Sie, dass zu jedem Wert die passende Überschrift genannt wird.
Trifft jede geprüfte URL — vermutlich eine gemeinsame Vorlage.
Einmal beheben wirkt überall.
Hintergrund
Ohne og:title, og:description und og:image entscheidet das jeweilige Netzwerk selbst, wie ein geteilter Link aussieht – meist mit einem beliebigen Textausschnitt und ohne Bild.
Betroffene Nutzergruppen
Alle, die Ihre Seite in sozialen Netzwerken oder Messengern geteilt bekommen
Geschäftliche Wirkung
Ein Link ohne Vorschaubild wird deutlich seltener geklickt als einer mit.
So beheben Sie das
Ergänzen Sie og:title, og:description und ein og:image von mindestens 1200 mal 630 Pixeln, dazu twitter:card mit summary_large_image.
So prüfen Sie die Korrektur
Teilen Sie die URL testweise in einem Messenger und prüfen Sie die Vorschau.
10 Stellen,
an denen die
automatische Prüfung nicht entscheiden konnte, ob ein Problem vorliegt.
Das ist weder ein Fehler noch eine Freigabe – es ist eine Arbeitsliste für einen
Menschen. Diese Punkte senken die Bewertung nicht.
unentschieden
Farbkontrast von Text erhöhen
7 Stellen auf allen 4 URLs
Der Text hebt sich zu wenig vom Hintergrund ab. Für viele Menschen ist er dadurch schwer oder gar nicht lesbar – auch bei Sonnenlicht oder auf schlechten Bildschirmen.
Warum unentschieden: Der Text liegt auf einem Hintergrundbild. Der Kontrast hängt davon ab, welcher Bildbereich gerade dahinter liegt – das ist maschinell nicht entscheidbar.
Zu tun: Messen Sie jedes betroffene Farbpaar erneut und prüfen Sie Normal-, Hover-, Fokus- und deaktivierte Zustände.
unentschieden
Links im Fließtext nicht nur über die Farbe kennzeichnen
2 Stellen auf 2 von 4 URLs
Ein Link mitten im Text muss sich auch ohne Farbwahrnehmung vom Umfeld abheben – sonst ist er für viele Menschen schlicht nicht als Link erkennbar.
Warum unentschieden: Das Element verdeckt teilweise ein anderes.
Zu tun: Betrachten Sie den Absatz in Graustufen und prüfen Sie, ob der Link noch erkennbar ist.
unentschieden
Berührungsziele ausreichend groß gestalten
1 Stelle auf 1 von 4 URLs
Kleine Schaltflächen und Links sind auf Touchgeräten schwer zu treffen – besonders mit eingeschränkter Feinmotorik.
Zu tun: Prüfen Sie die Zielgrößen in schmalen Viewports und bedienen Sie die Elemente per Touch.
Messwerte
Diese Werte schwanken von Lauf zu Lauf um ihre Schwelle. Sie tragen Empfehlungen,
lösen aber bewusst keine „neu"- und „behoben"-Meldungen aus.
ernst
Größtes Inhaltselement schneller anzeigen
auf allen 4 URLs
· aktuell 1,1 s
Das größte sichtbare Element – meist ein Bild oder eine Überschrift – erscheint zu spät. Besucher sehen länger eine leere oder unvollständige Seite.
Maßnahme: Identifizieren Sie das LCP-Element, optimieren Sie dessen Bild oder Schrift, laden Sie es mit hoher Priorität und niemals per Lazy Loading.
mittel
Längste Eingabeverzögerung senken
auf 2 von 4 URLs
· aktuell 130 ms
Die längste zusammenhängende Aufgabe auf dem Hauptthread bestimmt, wie lange ein Klick im unglücklichsten Fall unbeantwortet bleibt.
Maßnahme: Zerlegen Sie lange Aufgaben und verschieben Sie geeignete Arbeit in Web Worker.
gering
Ersten sichtbaren Inhalt früher darstellen
auf allen 4 URLs
· aktuell 0,9 s
Der erste sichtbare Seiteninhalt erscheint zu spät. Bis dahin wirkt die Seite tot, obwohl im Hintergrund geladen wird.
Maßnahme: Verkürzen Sie Serverzeit und render-blockierende CSS- oder Schriftanfragen vor dem ersten Inhalt.
gering
Sichtbaren Seitenaufbau beschleunigen
auf allen 4 URLs
· aktuell 0,9 s
Wichtige Informationen erscheinen schrittweise und lassen die Seite träge wirken.
Maßnahme: Priorisieren Sie Inhalte oberhalb der Falz und reduzieren Sie blockierende Ressourcen sowie große Bilder.
gering
Seite früher bedienbar machen
auf 1 von 4 URLs
· aktuell 1,4 s
Die Seite sieht fertig aus, reagiert aber noch nicht zuverlässig auf Eingaben.
Maßnahme: Reduzieren Sie die Menge an JavaScript beim Start und verschieben Sie alles Nichtkritische.
Bewertung je URL und Prüfdimension
Bewertung jeder geprüften URL, aufgeschlüsselt nach Prüfdimension
URL
Dimension
Barrierefreiheit
Leistung
SEO
Technische Qualität
Befunde
/WAI/demos/bad/before/home.html
Mobil
18
—
—
—
38
/WAI/demos/bad/before/home.html
Dunkelmodus
18
—
—
—
37
/WAI/demos/bad/before/home.html
400 % Zoom
17
—
—
—
40
/WAI/demos/bad/before/home.html
Firefox auf Android (Firefox)
17
—
—
—
39
/WAI/demos/bad/before/home.html
Safari auf iPhone (WebKit)
17
—
—
—
41
/WAI/demos/bad/before/home.html
Desktop
18
95
75
88
52
/WAI/demos/bad/before/news.html
Desktop
20
97
83
88
44
/WAI/demos/bad/before/news.html
Mobil
20
—
—
—
32
/WAI/demos/bad/before/news.html
Dunkelmodus
20
—
—
—
31
/WAI/demos/bad/before/news.html
400 % Zoom
19
—
—
—
33
/WAI/demos/bad/before/news.html
Firefox auf Android (Firefox)
19
—
—
—
32
/WAI/demos/bad/before/news.html
Safari auf iPhone (WebKit)
19
—
—
—
33
/WAI/demos/bad/before/survey.html
Desktop
15
97
83
85
54
/WAI/demos/bad/before/survey.html
Mobil
15
—
—
—
43
/WAI/demos/bad/before/survey.html
Dunkelmodus
15
—
—
—
41
/WAI/demos/bad/before/survey.html
400 % Zoom
15
—
—
—
42
/WAI/demos/bad/before/survey.html
Firefox auf Android (Firefox)
15
—
—
—
42
/WAI/demos/bad/before/survey.html
Safari auf iPhone (WebKit)
15
—
—
—
42
/WAI/demos/bad/before/tickets.html
Desktop
18
97
83
88
52
/WAI/demos/bad/before/tickets.html
Mobil
18
—
—
—
42
/WAI/demos/bad/before/tickets.html
Dunkelmodus
18
—
—
—
40
/WAI/demos/bad/before/tickets.html
400 % Zoom
17
—
—
—
41
/WAI/demos/bad/before/tickets.html
Firefox auf Android (Firefox)
16
—
—
—
42
/WAI/demos/bad/before/tickets.html
Safari auf iPhone (WebKit)
16
—
—
—
42
Kernmetriken je URL und Prüfdimension
Leistung wird einmal je URL gemessen — in der primären Dimension. In den
übrigen Dimensionen wird die Barrierefreiheit geprüft, nicht die Ladezeit;
dort steht deshalb „—“.
Gemessene Ladezeiten je URL und Prüfdimension
URL
Dimension
LCP
FCP
CLS
TBT
Ladezeit
HTTP
/WAI/demos/bad/before/home.html
Mobil
—
—
—
—
759 ms
200
/WAI/demos/bad/before/home.html
Dunkelmodus
—
—
—
—
752 ms
200
/WAI/demos/bad/before/home.html
400 % Zoom
—
—
—
—
754 ms
200
/WAI/demos/bad/before/home.html
Firefox auf Android (Firefox)
—
—
—
—
733 ms
200
/WAI/demos/bad/before/home.html
Safari auf iPhone (WebKit)
—
—
—
—
941 ms
200
/WAI/demos/bad/before/home.html
Desktop
1,4 s
0,9 s
0
0 ms
781 ms
200
/WAI/demos/bad/before/news.html
Desktop
1,2 s
0,9 s
0
0 ms
766 ms
200
/WAI/demos/bad/before/news.html
Mobil
—
—
—
—
761 ms
200
/WAI/demos/bad/before/news.html
Dunkelmodus
—
—
—
—
751 ms
200
/WAI/demos/bad/before/news.html
400 % Zoom
—
—
—
—
757 ms
200
/WAI/demos/bad/before/news.html
Firefox auf Android (Firefox)
—
—
—
—
702 ms
200
/WAI/demos/bad/before/news.html
Safari auf iPhone (WebKit)
—
—
—
—
978 ms
200
/WAI/demos/bad/before/survey.html
Desktop
1,1 s
0,9 s
0
0 ms
790 ms
200
/WAI/demos/bad/before/survey.html
Mobil
—
—
—
—
764 ms
200
/WAI/demos/bad/before/survey.html
Dunkelmodus
—
—
—
—
743 ms
200
/WAI/demos/bad/before/survey.html
400 % Zoom
—
—
—
—
770 ms
200
/WAI/demos/bad/before/survey.html
Firefox auf Android (Firefox)
—
—
—
—
698 ms
200
/WAI/demos/bad/before/survey.html
Safari auf iPhone (WebKit)
—
—
—
—
892 ms
200
/WAI/demos/bad/before/tickets.html
Desktop
1,1 s
0,9 s
0,011
30 ms
767 ms
200
/WAI/demos/bad/before/tickets.html
Mobil
—
—
—
—
755 ms
200
/WAI/demos/bad/before/tickets.html
Dunkelmodus
—
—
—
—
783 ms
200
/WAI/demos/bad/before/tickets.html
400 % Zoom
—
—
—
—
759 ms
200
/WAI/demos/bad/before/tickets.html
Firefox auf Android (Firefox)
—
—
—
—
727 ms
200
/WAI/demos/bad/before/tickets.html
Safari auf iPhone (WebKit)
—
—
—
—
917 ms
200
WCAG 2.2 – was geprüft wurde und was nicht
Ein guter Wert in der Bewertung heißt: die automatisch prüfbaren Regeln sind erfüllt.
Er heißt nicht „barrierefrei". Diese Übersicht macht den Unterschied sichtbar.
Kriterien
55
Verstöße
7
unentschieden
1
automatisch geprüft
20
nur manuell
27
28 von 55 Kriterien
(51 %) sind überhaupt automatisch prüfbar.
Bei 54 Kriterien bleibt auch nach einem sauberen Scan eine
manuelle Prüfung nötig.
Kriterien mit Beanstandung
Kriterien mit Verstößen oder unentschiedenen Prüfungen
Kriterium
Stufe
Stand
Stellen
1.1.1 Nicht-Text-Inhalt
A
Verstöße gefunden
4
1.4.1 Ohne Farbe nutzbar
A
unentschieden
2
1.4.3 Kontrast (Minimum)
AA
Verstöße gefunden
11
1.4.10 Reflow
AA
Verstöße gefunden
4
2.4.4 Linkzweck (im Kontext)
A
Verstöße gefunden
4
2.5.8 Zielgröße (Minimum)
AA
Verstöße gefunden
9
3.1.1 Sprache der Seite
A
Verstöße gefunden
4
4.1.2 Name, Rolle, Wert
A
Verstöße gefunden
9
Manuelle Prüfliste
54 Kriterien, die eine Automatik nicht oder nur teilweise
beurteilen kann. Zum Ausdrucken und Abhaken – jede Zeile ist eine konkrete Handlung.
1.1.1 Nicht-Text-Inhalt
(A)bereits beanstandet
Prüfen Sie, ob jeder Alternativtext den Zweck des Bildes tatsächlich wiedergibt. Ob ein alt-Attribut vorhanden ist, kann die Automatik sehen - ob „grafik1.jpg“ darin steht, ebenfalls, aber nicht, ob „Team beim Sommerfest“ zutrifft.
1.4.10 Reflow
(AA)bereits beanstandet
Bei 320 Pixeln Breite (400 Prozent Zoom) darf kein horizontales Scrollen nötig sein - außer bei Tabellen, Karten und Diagrammen. Diese Prüfdimension läuft automatisch mit.
1.4.3 Kontrast (Minimum)
(AA)bereits beanstandet
Prüfen Sie zusätzlich Zustände, die die Automatik nicht erreicht: Hover, Fokus, deaktiviert, sowie Text auf Bildern und Farbverläufen.
Lassen Sie sich die Linkliste eines Screenreaders vorlesen. Ist bei jedem Link ohne umgebenden Text klar, wohin er führt?
2.5.8 Zielgröße (Minimum)
(AA)bereits beanstandet
Neu in WCAG 2.2. Bedienelemente brauchen mindestens 24 mal 24 Pixel oder ausreichenden Abstand. Prüfen Sie besonders Symbolleisten und eng gesetzte Links.
4.1.2 Name, Rolle, Wert
(A)bereits beanstandet
Prüfen Sie eigene Steuerelemente mit einem Screenreader: Werden Name, Rolle und aktueller Zustand angesagt, und ändern sich Zustände hörbar?
1.2.1 Nur-Audio und Nur-Video (aufgezeichnet)
(A)
Für jede reine Audiodatei ein Transkript, für jedes Video ohne Ton eine Beschreibung bereitstellen. Prüfen Sie, ob beides vorhanden und auffindbar ist.
1.2.2 Untertitel (aufgezeichnet)
(A)
Jedes aufgezeichnete Video mit Ton braucht Untertitel. Prüfen Sie Vorhandensein, Synchronität und ob sie korrekt und nicht automatisch generiert unbrauchbar sind.
1.2.3 Audiodeskription oder Medienalternative (aufgezeichnet)
(A)
Für Videos mit wesentlichen visuellen Informationen eine Audiodeskription oder ein vollständiges Textalternativ bereitstellen.
1.2.4 Untertitel (live)
(AA)
Live-Übertragungen mit Ton brauchen Live-Untertitel. Betrifft Sie nur, wenn Sie live senden.
1.2.5 Audiodeskription (aufgezeichnet)
(AA)
Aufgezeichnete Videos brauchen eine Audiodeskription, die wesentliche visuelle Vorgänge beschreibt.
1.3.1 Info und Beziehungen
(A)
Die Automatik prüft Überschriften, Listen, Tabellen und Landmarks technisch. Prüfen Sie zusätzlich, ob die Struktur den sichtbaren Aufbau abbildet - etwa ob ein optisch hervorgehobener Absatz auch eine Überschrift ist.
1.3.2 Bedeutungstragende Reihenfolge
(A)
Schalten Sie das Stylesheet ab oder lesen Sie die Seite mit einem Screenreader linear. Ergibt die Reihenfolge noch Sinn?
1.3.3 Sensorische Eigenschaften
(A)
Suchen Sie nach Formulierungen wie „der Button rechts“, „das grüne Feld“, „siehe unten“. Anweisungen dürfen sich nicht allein auf Form, Größe, Position oder Farbe stützen.
1.3.4 Ausrichtung
(AA)
Drehen Sie ein Mobilgerät. Die Seite darf nicht auf Hoch- oder Querformat festgelegt sein, außer die Ausrichtung ist zwingend nötig.
1.3.5 Eingabezweck erkennen
(AA)
Formularfelder für persönliche Angaben brauchen passende autocomplete-Werte. Prüfen Sie, ob die Werte inhaltlich stimmen.
1.4.1 Ohne Farbe nutzbar
(A)unentschieden
Betrachten Sie die Seite in Graustufen. Sind Links im Text, Pflichtfeldmarkierungen, Diagrammlegenden und Fehlermeldungen noch erkennbar?
1.4.11 Nicht-Text-Kontrast
(AA)
Prüfen Sie Ränder von Eingabefeldern, Schaltflächenflächen, Fokusrahmen, Symbole und Diagrammfarben auf mindestens 3:1 gegen ihre Umgebung.
1.4.12 Textabstand
(AA)
Erhöhen Sie per Benutzerstylesheet Zeilenhöhe auf das 1,5-fache, Absatzabstand auf das 2-fache, Buchstabenabstand auf 0,12em. Nichts darf abgeschnitten werden.
1.4.13 Inhalt bei Hover oder Fokus
(AA)
Eingeblendete Tooltips und Menüs müssen mit Escape schließbar, mit der Maus erreichbar und dürfen nicht von selbst verschwinden.
1.4.2 Audio-Steuerelement
(A)
Startet Ton automatisch und dauert länger als drei Sekunden, muss es eine Möglichkeit zum Stoppen geben - erreichbar am Seitenanfang.
1.4.4 Textgröße ändern
(AA)
Zoomen Sie im Browser auf 200 Prozent. Bleibt aller Text lesbar, ohne dass Inhalte abgeschnitten werden oder sich überlagern?
1.4.5 Bilder eines Textes
(AA)
Text darf nicht als Bild ausgeliefert werden, außer er ist Teil eines Logos oder wesentlich für die Darstellung. Prüfen Sie Grafiken mit Beschriftungen.
2.1.1 Tastatur
(A)
Bedienen Sie die gesamte Seite ausschließlich mit Tabulator, Pfeiltasten, Enter und Leertaste. Jede Funktion muss erreichbar sein - besonders Menüs, Karussells, Karten und eigene Steuerelemente.
2.1.2 Keine Tastaturfalle
(A)
Tabben Sie in jedes eingebettete Element und wieder heraus - Videoplayer, Karten, Dialoge, iframes. Nirgends darf der Fokus feststecken.
2.1.4 Zeichentastenkürzel
(A)
Gibt es Tastenkürzel aus einzelnen Buchstaben, müssen sie abschaltbar oder umbelegbar sein.
2.2.1 Zeiteinteilung anpassbar
(A)
Zeitlimits in Formularen, Sitzungen und Warenkörben müssen verlängerbar, abschaltbar oder mit ausreichender Vorwarnung versehen sein.
2.2.2 Pausieren, Stoppen, Ausblenden
(A)
Karussells, Laufschriften, Animationen und automatische Aktualisierungen brauchen eine Pausetaste.
2.3.1 Grenzwert von dreimaligem Blitzen
(A)
Kein Inhalt darf öfter als dreimal pro Sekunde blitzen. Prüfen Sie Videos und Animationen.
2.4.1 Blöcke umgehen
(A)
Drücken Sie auf einer frisch geladenen Seite Tabulator. Erscheint ein sichtbarer Sprunglink, und führt er tatsächlich zum Hauptinhalt?
2.4.11 Fokus nicht verdeckt (Minimum)
(AA)
Neu in WCAG 2.2. Das fokussierte Element darf nicht vollständig von Sticky-Kopfzeilen, Cookie-Bannern oder Chat-Fenstern verdeckt werden.
2.4.2 Seite mit Titel versehen
(A)
Prüfen Sie zusätzlich, ob der Titel den Seiteninhalt beschreibt und sich von anderen Seiten unterscheidet.
2.4.3 Fokus-Reihenfolge
(A)
Tabben Sie die Seite von oben nach unten durch. Folgt der Fokus dem sichtbaren Verlauf, auch in Dialogen und ausgeklappten Menüs?
2.4.5 Verschiedene Möglichkeiten
(AA)
Jede Seite muss auf mindestens zwei Wegen erreichbar sein - etwa Navigation und Suche oder Sitemap.
2.4.6 Überschriften und Beschriftungen
(AA)
Die Automatik sieht, ob Überschriften vorhanden und nicht leer sind. Prüfen Sie, ob sie den folgenden Abschnitt tatsächlich beschreiben.
2.4.7 Fokus sichtbar
(AA)
Tabben Sie durch die Seite. Ist der Fokus an jeder Stelle deutlich sichtbar - auch auf farbigen Flächen, in Menüs und auf Schaltflächen?
2.5.1 Zeigergesten
(A)
Alles, was Wischen, Ziehen oder Mehrfingergesten erfordert, muss auch mit einem einfachen Tippen bedienbar sein.
2.5.2 Zeigerabbruch
(A)
Eine Aktion darf nicht schon beim Drücken ausgelöst werden - erst beim Loslassen, und ein Wegziehen muss abbrechen.
2.5.3 Beschriftung im Namen
(A)
Der sichtbare Text einer Schaltfläche muss im zugänglichen Namen enthalten sein, sonst funktioniert Sprachsteuerung nicht.
2.5.4 Betätigung durch Bewegung
(A)
Funktionen, die durch Schütteln oder Kippen ausgelöst werden, brauchen eine Alternative und müssen abschaltbar sein.
2.5.7 Ziehbewegungen
(AA)
Neu in WCAG 2.2. Alles, was gezogen wird - Schieberegler, sortierbare Listen, Karten - braucht eine Alternative ohne Ziehen.
3.1.2 Sprache von Teilen
(AA)
Fremdsprachige Zitate, Fachbegriffe und Produktnamen brauchen ein eigenes lang-Attribut, sonst liest der Screenreader sie falsch aus.
3.2.1 Bei Fokus
(A)
Das bloße Fokussieren eines Elements darf nichts auslösen - keine Navigation, kein Öffnen eines Dialogs, kein Absenden.
3.2.2 Bei Eingabe
(A)
Eine Auswahl in einem Dropdown darf nicht automatisch die Seite wechseln oder das Formular absenden.
3.2.3 Konsistente Navigation
(AA)
Die Navigation muss auf allen Seiten in derselben Reihenfolge erscheinen.
3.2.4 Konsistente Erkennung
(AA)
Gleiche Funktionen brauchen überall dieselbe Bezeichnung und dasselbe Symbol - nicht einmal „Suchen“ und einmal „Finden“.
3.2.6 Konsistente Hilfe
(A)
Neu in WCAG 2.2. Hilfeangebote wie Kontaktdaten oder Chat müssen auf allen Seiten an derselben Stelle stehen.
3.3.1 Fehlererkennung
(A)
Senden Sie Formulare fehlerhaft ab. Wird der Fehler in Textform benannt und das betroffene Feld eindeutig bezeichnet?
3.3.2 Beschriftungen oder Anweisungen
(A)
Jedes Feld braucht eine sichtbare Beschriftung. Prüfen Sie zusätzlich, ob Formatvorgaben und Pflichtfelder erkennbar sind.
3.3.3 Fehlerempfehlung
(AA)
Fehlermeldungen müssen sagen, wie es richtig geht - nicht nur, dass etwas falsch ist.
Neu in WCAG 2.2. Anmeldung darf keinen kognitiven Test verlangen - kein Rätsel-Captcha, kein Abtippen aus dem Gedächtnis. Einfügen aus dem Passwortmanager muss erlaubt sein.
4.1.3 Statusmeldungen
(AA)
Lösen Sie Meldungen aus - „In den Warenkorb gelegt“, „3 Treffer“, Fehlerhinweise. Werden sie vom Screenreader angesagt, ohne dass der Fokus springt?
Nachweis und Reproduzierbarkeit
Nach einem Engine- oder Regelupdate ändern sich Werte. Ohne diese Angaben wäre das
nicht erklärbar.
Lauf
5629a8f1-51fc-4bb1-901c-4e4b66db16f5
Bewertungsformel
v2
Fingerabdruck
fp-v1
axe-core
4.13.0
Lighthouse
13.4.1
Chromium
151.0.7922.34
Regelsatz
WCAG 2.0 A, WCAG 2.0 AA, WCAG 2.1 A, WCAG 2.1 AA, WCAG 2.2 AA, bewährte Praxis (keine WCAG-Anforderung)
Seitenauswahl
eigene Adressen
Erklärtexte vorhanden
100 % der aufgetretenen Regeln
Datensparsamkeit. Die Belege in diesem Bericht sind automatisch
geschwärzt: E-Mail-Adressen, Telefonnummern, Bankverbindungen und Anschriften werden
vor dem Speichern durch Platzhalter ersetzt. Die Erkennung arbeitet mit Mustern und
ist keine Anonymisierung – frei stehende Personennamen erkennt sie nicht.
Belege und Berichte werden nach 13 Monaten
gelöscht; Läufe, Bewertungen und die Problemhistorie bleiben erhalten.
Bildausschnitte folgen der kürzeren Frist von
90 Tagen – ein Bild lässt sich im Gegensatz
zu Text nicht schwärzen. Erzeugt werden sie für diese Website:
nur strukturelle Befunde.
