Das Remediation Evidence Package

Das Remediation Evidence Package ist ein datierter Nachweis darüber, was in Ihrem Shop geprüft wurde, was gefunden und geändert wurde und was ein Verifizierungsscan bestätigt hat. Es belegt eine Prüfung und die durchgeführten Arbeiten zur Behebung, ist aber kein Zertifikat.

Kostenlosen Check anfordern So läuft ein Projekt ab

Zuletzt aktualisiert: 20. Oktober 2026

Auf dieser Seite: 11 Antworten

Was enthält das Paket?

Das Remediation Evidence Package hat 7 Abschnitte, immer in derselben Reihenfolge. Validiscan erstellt es aus dem Ausgangsscan oder einem späteren vollständigen Scan Ihres Shops, aus dem Verifizierungsscan nach den Korrekturen, sofern es einen gibt, und aus den Ergebnissen der manuellen Prüfungen.

Die sieben Abschnitte eines Remediation Evidence Package, mit den Titeln, die im Paket stehen

Remediation Evidence Package

1 Über dieses Paket
2 Umfang und Methodik
3 Zusammenfassung der Ergebnisse
4 Befunde im Detail
5 Manuelle Prüfung und ausgeschlossene Befunde
6 Restrisiko und Empfehlungen
7 Entwurf der Erklärung zur Barrierefreiheit

Konformität mit den Erfolgskriterien von WCAG 2.1 Stufe AA und WCAG 2.2 Stufe AA, geprüft auf den aufgeführten Seiten zu den angegebenen Daten.

Dieses Paket belegt eine Prüfung und die durchgeführten Arbeiten zur Behebung. Es ist kein Zertifikat und trifft keine Aussage über die Einhaltung gesetzlicher Vorgaben.

Details: woraus das Paket erstellt wird und in welchen Sprachen es verfasst ist

Das Remediation Evidence Package hat sieben Abschnitte, immer in derselben Reihenfolge. Validiscan erstellt es aus dem Ausgangsscan oder einem späteren vollständigen Scan Ihres Shops, aus dem Verifizierungsscan nach den Korrekturen, sofern es einen gibt, und aus den Ergebnissen der manuellen Prüfungen. Die Gliederung unten verwendet die Abschnittstitel genau so, wie sie im Paket stehen.

Jedes Paket ist in einer Sprache verfasst, die bei der Erstellung gewählt wird: Englisch, Deutsch, Dänisch, Französisch oder Spanisch.

1. Über dieses Paket

Der erste Abschnitt sagt, was das Paket abdeckt, und identifiziert es. Er nennt die Website und ihre Adresse, Ihre Organisation, das Shopsystem und die Paketversion. Er gibt Datum und Uhrzeit der Erstellung des Pakets an, in UTC und in der Zeitzone Ihrer Organisation, sowie die Sprache des Dokuments. Außerdem enthält er den SHA-256-Wert der JSON-Daten des Pakets (unten bei den Prüfsummen erklärt), die Kontaktdaten von Validiscan, das das Paket erstellt hat, sowie den Namen und die Version der Software, die es erzeugt hat.

Ein Kasten mit dem Titel „Was dieses Paket aussagt“ enthält die Aussage zum Umfang und den Satz, dass das Paket kein Zertifikat ist. Beide sind unten unter „Was sagt das Paket aus?“ zitiert.

2. Umfang und Methodik

Der zweite Abschnitt hält genau fest, was geprüft wurde und wie. Er führt jede Seite auf, die die Scans geprüft haben, mit ihrer Adresse, ihrem Seitentyp (in einem englischen Paket „template“), den Bildschirmgrößen, in denen sie geprüft wurde (Desktop, mobil oder beides), ihrem HTTP-Status und dem Ergebnis. Er hält die Crawl-Konfiguration jedes Scans fest: das Seitenlimit, die Zahl der Seiten, die je Seitentyp als Stichprobe geprüft wurden, den Umgang mit dem Cookie-Banner, ob robots.txt beachtet wurde, ob Analyse- und Werbetracker blockiert wurden und welche Einkaufsabläufe durchlaufen wurden, etwa das Hinzufügen zum Warenkorb oder der erste Schritt im Checkout.

Danach nennt er die Tool-Versionen je Scan: axe-core, Playwright, den Validiscan-Scanner und einen Hash des Regelsatzes, berechnet aus den Regel-IDs des Katalogs und ihren Korrekturstufen je Plattform. Eine Tabelle nennt die Normen, auf die sich das Paket bezieht, mit ihren Versionen, ihren Datumsangaben und ihrem Status. Die Methodik folgt in vier Sätzen: wie jede Seite in jeder Bildschirmgröße in einem echten Browser geladen und mit axe-core sowie mit eigenen Prüfungen von Validiscan auf Barrieren geprüft wurde, die für Onlineshops typisch sind; wie Befunde nach Regel und Elementmuster gruppiert werden, sodass ein Fehler, der sich auf vielen Seiten wiederholt, ein einziger Befund mit der Anzahl seiner Vorkommen ist; wie die Erfolgskriterien, die sich automatisiert nicht vollständig nachweisen lassen, von Hand geprüft wurden; und wie der Verifizierungsscan die Korrekturen geprüft hat.

Der Abschnitt endet mit den Einschränkungen. Vier stehen immer darin: Automatisierte Tests finden nur einen Teil aller Barrieren; die Seiten werden als Stichprobe je Seitentyp geprüft; die Ergebnisse beschreiben den Shop zum Zeitpunkt der Scans; und Inhalte in Frames anderer Herkunft (Cross-Origin) und in geschlossenem Shadow DOM, etwa Zahlungsfelder und einige Einwilligungstools, werden nicht automatisch geprüft. Weitere stehen darin, wenn sie zutreffen, zum Beispiel dass der Checkout nur bis zu seinem ersten Schritt geprüft wurde, ohne eine Bestellung aufzugeben und ohne Zahlungsdaten einzugeben.

3. Zusammenfassung der Ergebnisse

Der dritte Abschnitt gibt die Ergebnisse in Zahlen wieder. Er zeigt die Befunde nach Auswirkung und Status in einer Tabelle, ohne Befunde zur guten Praxis. Er zeigt den Fortschritt der Behebung mit seiner Formel und der Rechnung dahinter, wie unten erklärt. Und er enthält zwei Konformitätstabellen, eine für WCAG 2.1 Stufe AA und eine für WCAG 2.2 Stufe AA, mit einer Zeile je Erfolgskriterium: seiner Stufe, seinem Abschnitt der EN 301 549, seiner Konformität, der Grundlage dieser Konformität und den Befunden dahinter.

Jedes Kriterium erhält einen von fünf Konformitätsgraden. Die Regel zu jedem Grad steht im Paket nach den Tabellen:

Konformitätsgrade im Remediation Evidence Package, mit den Regeln, wie sie im Paket stehen
Konformitätsgrad	Regel, wie sie im Paket steht
Unterstützt	Automatisierte Tests decken das Kriterium vollständig ab und haben keinen nicht behobenen Verstoß gefunden, oder eine manuelle Prüfung wurde bestanden.
Teilweise unterstützt	Nicht behobene Verstöße auf höchstens der Hälfte der gescannten Seitentypen, Korrekturen mit ausstehender Verifizierung oder eine nicht bestandene manuelle Prüfung, wo automatisierte Tests nichts gefunden haben.
Nicht unterstützt	Nicht behobene Verstöße auf mehr als der Hälfte der gescannten Seitentypen oder ohne Seitenbezug, oder eine nicht bestandene manuelle Prüfung.
Nicht anwendbar	Die manuelle Prüfung hat keine Inhalte gefunden, für die das Kriterium gilt.
Nicht geprüft	Automatisierte Tests können das Kriterium nicht nachweisen, und es liegt noch kein manuelles Ergebnis vor.

Trifft eine nicht bestandene manuelle Prüfung auf zwei Zeilen zu, ergibt sie „Teilweise unterstützt“ nur dann, wenn eine ausgeführte Regel das Kriterium testet und kein nicht behobener Verstoß gefunden wurde; ohne eine solche Regel oder bei einem nicht behobenen Verstoß ergibt sie „Nicht unterstützt“. „Ohne Seitenbezug“ bezeichnet einen Befund, der die gesamte Website betrifft und nicht einzelne Seiten, etwa einen Befund aus einer manuellen Prüfung. Ein Befund mit dem Status „Wird nicht behoben“ bleibt eine Barriere und zählt in diesen Tabellen als Verstoß. Falsch positive Befunde und Befunde zur guten Praxis zählen nie.

Ein Kriterium gilt als vollständig von automatisierten Tests abgedeckt, wenn eine Regel, die der Scanner ausführt, es testet und die manuelle Checkliste keinen Punkt dazu enthält. Bei solchen Kriterien, darunter 1.1.1 Non-text Content und 2.4.4 Link Purpose (In Context), beruht das Ergebnis „Unterstützt“ allein auf automatisierten Tests: Es zeigt, dass keine Regel einen Verstoß gefunden hat, nicht aber, dass das Kriterium erfüllt ist. Die Kriterienmatrix zeigt für jedes Kriterium die Regeln, die es testen, und ob die Checkliste einen Punkt dazu enthält.

4. Befunde im Detail

Der vierte Abschnitt hat einen Eintrag je Befund, der nicht ausgeschlossen wurde, die schwerwiegendsten zuerst. Jeder Eintrag nennt die Kennung des Befunds, die Regel, die Auswirkung, den Status, die Korrekturstufe (AUTO, ASSISTED oder MANUAL), die WCAG-Erfolgskriterien, die Abschnitte der EN 301 549 und wie viele Vorkommen der Scan und der Verifizierungsscan auf wie vielen Seiten gefunden haben. Unter „Was das für Kundinnen und Kunden bedeutet“ erklärt er die Barriere in einfacher Sprache.

Bis zu drei Beispielvorkommen zeigen die Seite, das Element und die Beanstandung. Bis zu zwei Screenshots je Befund zeigen eine Seite vor der Korrektur. Zu jedem kann ein Screenshot nach der Korrektur gehören, wenn der Verifizierungsscan dieselbe Seite in derselben Bildschirmgröße geladen hat. Die Screenshots zeigen derzeit den ersten Bildschirmausschnitt einer Seite; ein Element weiter unten auf der Seite ist im Bild daher unter Umständen nicht zu sehen.

Eine Tabelle führt die Korrekturen zum Befund auf: ihre Kennung, ihren Status und ihr Vorgehen, ob sie durch ein Rezept erstellt, mit KI entworfen oder von Hand bearbeitet wurden, wie sie ausgeliefert wurden (als GitHub-Pull-Request, als unveröffentlichte Kopie eines Shopify-Themes oder als gepatchtes Theme in einem ZIP-Archiv) und wann sie ausgeliefert und übernommen wurden. Befunde zur guten Praxis folgen am Ende des Abschnitts. Sie sind keine WCAG-Verstöße und zählen nie bei der Konformität oder beim Fortschritt der Behebung.

5. Manuelle Prüfung und ausgeschlossene Befunde

Der fünfte Abschnitt behandelt die Prüfungen, die eine Person von Hand durchgeführt hat. Die manuelle Checkliste von Validiscan hat 35 Punkte für Kriterien, die eine Person prüfen muss, etwa die Bedienung des Shops mit der Tastatur, die Nutzung mit einem Screenreader und das Vergrößern. Für jedes Erfolgskriterium der Checkliste hält das Paket das Ergebnis fest (bestanden, nicht bestanden, nicht anwendbar oder noch nicht geprüft), das Datum, wer geprüft hat, Notizen und eine etwaige Nachweisdatei, die im ZIP-Archiv enthalten ist.

Der zweite Teil führt die ausgeschlossenen Befunde mit ihrer Begründung auf. Ein falsch positiver Befund ist ein Befund, den der Scanner für ein Element gemeldet hat, das das Kriterium erfüllt. Ein Befund mit dem Status „Wird nicht behoben“ ist eine echte Barriere, die nach Ihrer Entscheidung vorerst nicht behoben wird. Das Paket gibt an, wo die jeweilige Begründung erfasst wurde, oder dass keine erfasst wurde.

6. Restrisiko und Empfehlungen

Der sechste Abschnitt sagt, was noch ein Risiko birgt und was als Nächstes zu tun ist. Er bewertet das Restrisiko als „Hoch“, „Mittel“ oder „Niedrig“ und nennt die Regel hinter der Bewertung: „Hoch“ bei einem nicht behobenen kritischen Befund oder einem Kriterium von WCAG 2.1 Stufe AA, das nicht unterstützt wird; „Mittel“ bei einem nicht behobenen schwerwiegenden Befund, einem Kriterium von WCAG 2.1 Stufe AA, das teilweise unterstützt wird oder auf eine manuelle Prüfung wartet, einer Lücke bei einem Kriterium, das WCAG 2.2 hinzugefügt hat, oder bei Korrekturen, die auf Verifizierung warten; „Niedrig“ in allen anderen Fällen. Nicht behoben heißt: Status „Offen“, „Korrektur vorgeschlagen“, „Korrektur ausgeliefert“ oder „Wird nicht behoben“.

Empfehlungen folgen in der Reihenfolge ihrer Priorität, zum Beispiel die ausgelieferten Korrekturen zu übernehmen, einen Verifizierungsscan durchzuführen, die manuelle Prüfung abzuschließen oder den Regressionsschutz zu aktivieren. Der Abschnitt schließt mit dem Datum, bis zu dem der nächste Verifizierungsscan fällig ist, früher, solange noch Arbeiten offen sind, und mit dem nächsten Durchlauf des Regressionsschutzes, falls einer geplant ist.

7. Entwurf der Erklärung zur Barrierefreiheit

Der siebte Abschnitt ist der Entwurf einer Erklärung zur Barrierefreiheit für Ihren Shop, erstellt aus den Ergebnissen des Pakets. Er steht in der Sprache des Pakets, also auf Englisch, Deutsch, Dänisch, Französisch oder Spanisch. Er folgt dem Aufbau der EU-Mustererklärung zur Barrierefreiheit im Durchführungsbeschluss (EU) 2018/1523 der Kommission, die für öffentliche Stellen verfasst wurde, und passt sie für einen Onlineshop an den European Accessibility Act (EAA) an. Er ist als „Entwurf zur rechtlichen Prüfung“ gekennzeichnet: in einem Kasten vor der Erklärung, in einem Stempel neben ihrem Titel und in der Kopfzeile jeder Seite der Erklärung im Word-Dokument.

Der Entwurf gibt in der Formulierung der EU-Mustererklärung den Stand der Vereinbarkeit des Shops mit den Anforderungen an (vollständig, teilweise oder nicht vereinbar), abgeleitet aus den Konformitätsergebnissen, und sagt, dass dieser Stand die Konformität beschreibt, wie sie auf den Seiten und an den Tagen geprüft wurde, die der Entwurf nennt. Er führt die nicht barrierefreien Inhalte auf, in einfacher Sprache je Erfolgskriterium. Er beschreibt, wie die Erklärung erstellt wurde: als Selbstbewertung durch Ihre Organisation, auf Grundlage einer Prüfung durch Validiscan, und nicht als Zertifizierung. Danach folgen die Kontaktangaben für Rückmeldungen und das Durchsetzungsverfahren. Für eine Organisation in Deutschland nennt der Entwurf als Marktüberwachungsbehörde die MLBF und als Schlichtungsstelle die Schlichtungsstelle BGG, jeweils mit der zugehörigen Vorschrift im BFSG; für andere Länder ist die Behörde ein Feld, das Sie ausfüllen. Der nächste Teil enthält die Informationen über die Dienstleistung, die Anhang V des EAA verlangt: was die Dienstleistung ist, wie sie genutzt wird und wie sie die Barrierefreiheitsanforderungen erfüllt. Es folgt ein Teil mit weiteren Informationen, und ein Kasten mit dem Titel „Vor der Veröffentlichung“ schließt den Abschnitt mit den Schritten, die aus dem Entwurf eine veröffentlichte Erklärung machen.

Text in eckigen Klammern kennzeichnet Angaben, die nur Ihre Organisation machen kann, etwa die E-Mail-Adresse für Rückmeldungen zur Barrierefreiheit. Jedes dieser Felder muss vor der Veröffentlichung der Erklärung ausgefüllt oder, wo es optional ist, gelöscht werden. Validiscan leistet keine Rechtsberatung. Ihre Rechtsberatung muss die Erklärung prüfen, bevor Sie sie veröffentlichen, und ob, wo und in welchen Sprachen sie veröffentlicht werden muss, hängt vom Recht ab, das für Sie gilt. Der Ratgeber Was die Erklärung zur Barrierefreiheit eines Onlineshops enthalten muss erklärt die Anforderungen.

Was sagt das Paket aus?

Das Remediation Evidence Package gibt für jedes Erfolgskriterium von WCAG 2.1 Stufe AA und WCAG 2.2 Stufe AA die Konformität an, wie sie auf den Seiten und an den Tagen geprüft wurde, die es aufführt: unterstützt, teilweise unterstützt, nicht unterstützt, nicht anwendbar oder nicht geprüft. Es stellt dem Shop kein Zertifikat aus.

Details: die Aussage zum Umfang und der Satz, dass das Paket kein Zertifikat ist, wie das Paket sie ausgibt, und wo sie sonst stehen

Das Paket gibt für jedes Erfolgskriterium von WCAG 2.1 Stufe AA und WCAG 2.2 Stufe AA die Konformität an, wie sie auf den Seiten und an den Tagen geprüft wurde, die es aufführt: unterstützt, teilweise unterstützt, nicht unterstützt, nicht anwendbar oder nicht geprüft. Es stellt dem Shop kein Zertifikat aus. Im ersten Abschnitt beginnt seine Aussage zum Umfang mit diesem Satz: „Konformität mit den Erfolgskriterien von WCAG 2.1 Stufe AA und WCAG 2.2 Stufe AA, geprüft auf den aufgeführten Seiten zu den angegebenen Daten.“

Im selben Kasten steht: „Dieses Paket belegt eine Prüfung und die durchgeführten Arbeiten zur Behebung. Es ist kein Zertifikat und trifft keine Aussage über die Einhaltung gesetzlicher Vorgaben.“

Beide Sätze stehen auch, auf Englisch, in der README-Datei im ZIP-Archiv.

Wann gilt ein Befund als verifiziert?

Ein behobener Befund gilt als verifiziert, wenn der Verifizierungsscan des Pakets jede Seite lädt, auf der der Befund auftrat, und ihn nicht mehr findet. Sein Status wechselt dann zu „Verifiziert“, sobald das Paket ausgestellt wird; niemand setzt diesen Status von Hand.

Das Paket verifiziert einen behobenen Befund, wenn drei Bedingungen erfüllt sind

Der Befund hatte Vorkommen in dem vollständigen Scan, aus dem das Paket erstellt wird.
Der Verifizierungsscan hat keines gefunden.
Der Verifizierungsscan hat jede Seite geladen, auf der der Befund auftrat, und zwar in jeder Bildschirmgröße ohne Fehler.

Details: wann ein Befund behoben ist, die drei Bedingungen und ein Paket ohne Verifizierungsscan

Ein behobener Befund gilt als verifiziert, wenn der Verifizierungsscan des Pakets jede Seite lädt, auf der der Befund auftrat, und ihn nicht mehr findet. Sein Status wechselt dann von Behoben zu Verifiziert, sobald das Paket ausgestellt wird. Niemand setzt den Status „Verifiziert“ von Hand.

Ein Befund ist behoben, wenn für ihn eine Korrektur ausgeliefert wurde und ein späterer Scan, der jede Seite geladen hat, auf der der Befund auftrat, ihn nicht mehr findet. Das Paket verifiziert einen behobenen Befund, wenn drei Bedingungen erfüllt sind:

Der Befund hatte Vorkommen in dem vollständigen Scan, aus dem das Paket erstellt wird.
Der Verifizierungsscan hat keines gefunden.
Der Verifizierungsscan hat jede Seite geladen, auf der der Befund auftrat, und zwar in jeder Bildschirmgröße ohne Fehler.

Jeder verifizierte Befund trägt im Abschnitt zu den Befunden den Vermerk „Verifiziert durch dieses Paket“. Ein behobener Befund, den das Paket auf diese Weise nicht verifizieren kann, bleibt behoben und wird als Befund mit ausstehender Verifizierung aufgeführt, mit der Empfehlung, einen Verifizierungsscan durchzuführen. Ein Paket, das ohne Verifizierungsscan erstellt wurde, verifiziert keine Korrektur, und das steht in seinen Einschränkungen.

Wie wird der Fortschritt der Behebung berechnet?

Der Fortschritt der Behebung ist die Summe der Gewichte der behobenen, verifizierten oder extern behobenen Befunde, geteilt durch die Summe der Gewichte aller Befunde, ohne falsch positive Befunde, Befunde mit dem Status „Wird nicht behoben“ und Befunde zur guten Praxis. Er ist die einzige zusammenfassende Zahl im Paket; einen Prozentwert für die Konformität gibt es nicht.

Gewicht jeder Auswirkung im Fortschritt der Behebung
Auswirkung	Gewicht
Kritisch	10
Schwerwiegend	5
Mittel	2
Gering	0,5

Details: die Formel, wie das Paket sie ausgibt, warum je Befund gezählt wird, und zwei Punkte, die man leicht übersieht

Der Fortschritt der Behebung ist der Anteil der Arbeit, der erledigt ist, gewichtet danach, wie stark jedes Problem die Kundinnen und Kunden betrifft. Er ist die einzige zusammenfassende Zahl im Paket: Einen Prozentwert für die Konformität gibt es nicht.

Jeder Befund zählt mit dem Gewicht seiner Auswirkung. Der Fortschritt der Behebung ist die Summe der Gewichte der Befunde, die behoben, verifiziert oder extern behoben sind, geteilt durch die Summe der Gewichte aller Befunde. Befunde mit dem Status „Falsch positiv“ oder „Wird nicht behoben“ und Befunde zur guten Praxis bleiben in beiden Summen außen vor. Im Paket lautet die Formel: Σ Gewicht(Auswirkung) der behobenen, verifizierten oder extern behobenen Befunde ÷ Σ Gewicht(Auswirkung) aller Befunde, ohne Befunde mit dem Status „Falsch positiv“ oder „Wird nicht behoben“ und ohne Befunde zur guten Praxis.

Der Fortschritt wird je Befund gezählt, nicht je Vorkommen: Eine fehlende Beschriftung, die sich auf vielen Produktseiten wiederholt, ist ein Befund mit einer Korrektur. Ein kritischer Befund hat ein höheres Gewicht als ein geringer, daher verändert die Behebung eines kritischen Befunds die Zahl stärker als die eines geringen. Neben dem Prozentwert nennt das Paket die erledigten gewichteten Befunde und die Gesamtzahl, damit sich die Zahl von Hand nachrechnen lässt. Das Kundenportal zeigt dieselbe Zahl, mit einer eigenen Erklärung, wie sie berechnet wird.

Zwei Punkte übersieht man leicht. Ein behobener Befund zählt als erledigt, bevor er verifiziert ist, während in den Konformitätstabellen eine Korrektur mit ausstehender Verifizierung verhindert, dass ihr Kriterium als unterstützt zählt. Und ein Befund mit dem Status „Wird nicht behoben“ bleibt im Fortschritt der Behebung außen vor, zählt bei der Konformität aber weiter als Verstoß, denn eine Barriere, die bleibt, ist weiterhin eine Barriere.

Warum bewertet das Paket sowohl WCAG 2.1 Stufe AA als auch WCAG 2.2 Stufe AA?

Das Remediation Evidence Package bewertet jedes Erfolgskriterium einmal und gibt die Ergebnisse für beide an: WCAG 2.2 Stufe AA ist das Ziel jedes Befunds und jeder Korrektur, und WCAG 2.1 Stufe AA ist die Stufe, die die EN 301 549 V3.2.1 in ihren Anforderungen an Webinhalte übernimmt.

Versionen der EN 301 549, Stand 6. Oktober 2026
Version	Übernommene WCAG	Fundstelle im Amtsblatt der EU
EN 301 549 V3.2.1	WCAG 2.1 Stufe AA, in ihren Anforderungen an Webinhalte	Veröffentlicht zur Richtlinie (EU) 2016/2102 über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen, durch den Durchführungsbeschluss (EU) 2021/1339 der Kommission
EN 301 549 V4.1.1, im September 2026 von ETSI veröffentlicht	WCAG 2.2, laut AccessibleEU	Von Validiscan keine gefunden

Quelle: W3C, WCAG 2.2; Durchführungsbeschluss (EU) 2021/1339 der Kommission; ETSI, EN 301 549 V4.1.1; AccessibleEU

Details: was WCAG 2.2 hinzufügt und streicht, der Status der EN 301 549, Stand 6. Oktober 2026, und wie jedes Paket die Normen festhält

Das Paket bewertet jedes Erfolgskriterium einmal und gibt die Ergebnisse sowohl für WCAG 2.1 Stufe AA als auch für WCAG 2.2 Stufe AA an. WCAG 2.2 Stufe AA ist das Ziel jedes Befunds und jeder Korrektur. WCAG 2.1 Stufe AA ist die Stufe, die die EN 301 549 V3.2.1 in ihren Anforderungen an Webinhalte übernimmt. Auf den Stufen A und AA fügt WCAG 2.2 gegenüber WCAG 2.1 sechs Erfolgskriterien hinzu und streicht eines, 4.1.1 Parsing, daher unterscheiden sich die beiden Tabellen.

Stand 6. Oktober 2026:

Die EN 301 549 V3.2.1 ist die Version, deren Fundstelle im Amtsblatt der EU veröffentlicht ist, und zwar im Rahmen der Richtlinie (EU) 2016/2102 über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen, durch den Durchführungsbeschluss (EU) 2021/1339 der Kommission.
ETSI hat die EN 301 549 V4.1.1 im September 2026 veröffentlicht. Laut AccessibleEU, einer Initiative der Europäischen Kommission, übernimmt sie WCAG 2.2. Validiscan hat im Amtsblatt keine Fundstelle der V4.1.1 gefunden.

Jedes Paket hält die Normen mit ihren Versionen und ihrem Status so fest, wie sie bei seiner Erstellung waren. Ändert sich der Status einer Norm später, ändert das nichts an dem, was ein ausgestelltes Paket sagt. Welche Norm und welches Gesetz für Ihren Shop gelten, ist eine Rechtsfrage. Der Ratgeber zum European Accessibility Act für Onlineshops behandelt sie.

Aus welchen Dateien besteht das Paket?

Das Remediation Evidence Package besteht aus vier Dateien: einem PDF-Bericht, einem Word-Dokument, einer JSON-Datendatei und einem ZIP-Archiv mit den drei anderen, dem JSON-Schema, den Screenshots und Nachweisdateien der manuellen Prüfungen, auf die der Bericht verweist, einer README-Datei und der Prüfsummendatei SHA256SUMS.

Die vier Dateien eines Remediation Evidence Package
Datei	Wozu sie dient	Einzelheiten
PDF-Bericht	Der Bericht zum Lesen, Drucken und Weitergeben.	A4. Ein getaggtes PDF, von Chromium erzeugt, mit gesetzter Dokumentsprache, gesetztem Titel und Lesezeichen. Konformität mit PDF/UA wird nicht beansprucht.
Word-Dokument (DOCX)	Derselbe Bericht zum Bearbeiten, zum Beispiel für die Erklärung zur Barrierefreiheit.	Jeder Abschnitt beginnt auf einer neuen Seite. Auf den Seiten des Entwurfs der Erklärung wiederholt die Kopfzeile „Entwurf zur rechtlichen Prüfung“.
Datendatei (JSON)	Die Daten hinter dem Bericht, für Ihr Entwicklungsteam oder für ein Audit.	Codes, Kennungen, Anzahlen, Zeiten in UTC und die im Projekt erfassten Texte; keine Bezeichnungen und keine formatierten Datumsangaben. Sie folgt dem veröffentlichten JSON-Schema.
Komplettarchiv (ZIP)	Alles in einer Datei.	Das PDF, das Word-Dokument und die JSON-Datei, das JSON-Schema, die Screenshots und die Nachweisdateien der manuellen Prüfungen, auf die der Bericht verweist, eine README-Datei und die Prüfsummendatei SHA256SUMS.

Details: die Einträge des ZIP-Archivs in ihrer Reihenfolge und was geschieht, wenn eine Datei fehlt

Das ZIP-Archiv enthält diese Einträge, in dieser Reihenfolge:

README.txt: was das Paket ist, was jede Datei enthält und wie es sich prüfen lässt, auf Englisch.
Der PDF-Bericht.
Das Word-Dokument.
Die JSON-Datendatei.
schema.json: das JSON-Schema, dem die Datendatei folgt.
assets/: die Screenshots und die Nachweisdateien der manuellen Prüfungen, auf die der Bericht verweist.
SHA256SUMS: die SHA-256-Prüfsumme jeder anderen Datei im ZIP-Archiv.

Fehlt beim Erstellen des Pakets ein Screenshot oder eine Nachweisdatei, wird die Datei nicht ins ZIP-Archiv aufgenommen, und die README-Datei führt sie unter der Überschrift FILES NOT INCLUDED auf. Anstelle eines fehlenden Screenshots zeigt der Bericht eine Textbeschreibung.

Wie können Sie prüfen, ob eine Datei verändert wurde?

Durch den Vergleich von SHA-256-Prüfsummen, Fingerabdrücken, die sich ändern, sobald sich ein einziges Byte einer Datei ändert. Das Kundenportal zeigt neben jeder Datei des Remediation Evidence Package ihre Prüfsumme an, und die Datei SHA256SUMS im ZIP-Archiv führt die Prüfsummen der Dateien darin auf. Eine passende Prüfsumme zeigt nicht, wer die Datei erstellt hat.

Wie Sie die entpackten Dateien prüfen
System	Befehl	Ergebnis
Linux	`sha256sum -c SHA256SUMS`	Jede Zeile muss auf „OK“ enden.
macOS	`shasum -a 256 -c SHA256SUMS`	Jede Zeile muss auf „OK“ enden.
Windows PowerShell	`Get-FileHash -Algorithm SHA256`, für jede Datei	Vergleichen Sie das Ergebnis mit der Zeile dieser Datei in `SHA256SUMS`.

Details: die drei Stellen, an denen Prüfsummen verwendet werden, die Befehle und was eine Prüfsumme nicht zeigt

Jede Datei des Pakets hat eine SHA-256-Prüfsumme: einen Fingerabdruck, der sich ändert, sobald sich ein einziges Byte der Datei ändert. Das Paket verwendet Prüfsummen an drei Stellen.

Jede Datei. Das PDF, das Word-Dokument, die JSON-Datei und das ZIP-Archiv haben jeweils einen eigenen SHA-256-Wert, der beim Erstellen des Pakets festgehalten wurde und im Kundenportal neben jedem Download angezeigt wird.
Im ZIP-Archiv. Die Datei SHA256SUMS führt den SHA-256-Wert jeder anderen Datei im ZIP-Archiv auf. Ein ZIP-Archiv kann seine eigene Prüfsumme nicht enthalten; das Archiv selbst wird daher anhand der Prüfsumme geprüft, die neben seinem Download steht.
Die Daten. Der erste Abschnitt des Pakets gibt den SHA-256-Wert des Inhalts der JSON-Datei an. Er wird über das kanonische JSON dieser Datei berechnet (RFC 8785, das JSON Canonicalization Scheme), wobei dieses eine Feld ausgelassen wird. Kanonisches JSON hängt weder von Leerraum noch von der Reihenfolge der Schlüssel ab, sodass jede Person, die die JSON-Datei hat, denselben Wert berechnen kann.

Um die entpackten Dateien zu prüfen, öffnen Sie ein Terminal im Ordner der Dateien. Unter Linux führen Sie aus:

sha256sum -c SHA256SUMS

Unter macOS führen Sie aus:

shasum -a 256 -c SHA256SUMS

Jede Zeile muss auf „OK“ enden. In Windows PowerShell führen Sie diesen Befehl für jede Datei aus und vergleichen das Ergebnis mit der Zeile dieser Datei in SHA256SUMS:

Get-FileHash -Algorithm SHA256

Eine Prüfsumme zeigt, dass eine Datei genau die ist, die beim Erstellen des Pakets festgehalten wurde. Sie zeigt nicht, wer die Datei erstellt hat: Das Paket trägt keine digitale Signatur und keinen Zeitstempel von dritter Seite.

Welchem JSON-Schema folgt die Datendatei?

Die JSON-Datendatei des Remediation Evidence Package folgt einem veröffentlichten JSON-Schema (Draft 2020-12), das auch in jedem ZIP-Archiv als schema.json liegt. Das Schema ist streng: Ein Schlüssel, den es nicht kennt, lässt die Validierung fehlschlagen, außer in einem offenen Feld für die Versionen weiterer Tools.

Details: wo das Schema zu finden ist und wie sich seine Version ändert

Die JSON-Datendatei folgt einem veröffentlichten JSON-Schema (Draft 2020-12): dem JSON-Schema des Pakets. Dasselbe Schema liegt in jedem ZIP-Archiv als schema.json, sodass sich ein Paket auch ohne diese Website prüfen lässt. Jeder JSON-Schema-Validator, der Draft 2020-12 unterstützt, kann eine Datendatei damit prüfen.

Das Schema ist streng: Ein Schlüssel, den es nicht kennt, lässt die Validierung fehlschlagen, außer in einem offenen Feld für die Versionen weiterer Tools. Validiscan erstellt ein Paket nur aus Daten, die die Validierung gegen das Schema bestehen und mit dem SHA-256-Wert übereinstimmen, der in seinem ersten Abschnitt festgehalten ist. Das Schema hat die Version 1. Eine Änderung, die ein älteres Leseprogramm ablehnen würde, erhält eine neue Versionsnummer, und ein ausgestelltes Paket bleibt in seiner Version lesbar.

Kann ein Paket nach der Ausstellung geändert werden?

Nein. Ein fertiges Remediation Evidence Package ändert sich nie: Muss etwas korrigiert werden, erstellt Validiscan eine neue Version, und die früheren Versionen bleiben aufgeführt. Sobald ein Paket fertig ist, lehnt die Datenbank jede Änderung an seinen Dateipfaden, Prüfsummen, seiner Version, seiner Sprache, seinen Angaben zu den Normen und seinem Erstellungsdatum ab.

Details: wie Versionen nummeriert werden und welche Änderungen die Datenbank ablehnt

Pakete werden je Shop nummeriert: Version 1, Version 2 und so weiter. Jedes Paket, das Validiscan für Ihren Shop aus den Scans und in der dafür gewählten Sprache erstellt, ist die nächste Version. Nur ein fertiges Paket gelangt ins Kundenportal.

Sobald ein Paket fertig ist, lehnt die Datenbank jede Änderung an seinen Dateipfaden, seinen Prüfsummen, seiner Version, seiner Sprache, seinen Angaben zu den Normen und seinem Erstellungsdatum ab. Weil die Prüfsummen feststehen, würde eine Datei, die danach verändert wird, nicht mehr zu der Prüfsumme passen, die für sie festgehalten ist.

Was behauptet das Paket nicht?

Das Remediation Evidence Package ist ein Nachweis darüber, was geprüft, gefunden, geändert und verifiziert wurde, und behauptet nicht mehr. Es ist kein Zertifikat und trifft keine Aussage über die Einhaltung gesetzlicher Vorgaben: Ob Ihr Shop die Anforderungen des EAA, des BFSG oder eines anderen Gesetzes erfüllt, ist eine rechtliche Bewertung, die Sie gemeinsam mit Ihrer Rechtsberatung treffen.

Was das Paket nicht behauptet

Es ist kein Zertifikat.
Es trifft keine Aussage über die Einhaltung gesetzlicher Vorgaben.
Es prüft nicht alles automatisch.
Es beschreibt den Shop zum Zeitpunkt der Scans.
Es erhebt keinen Anspruch auf PDF/UA-Konformität.
Der Entwurf der Erklärung ist nicht veröffentlichungsreif.

Details: jeder Punkt im Einzelnen

Das Paket ist ein Nachweis darüber, was geprüft, gefunden, geändert und verifiziert wurde. Mehr behauptet es nicht.

Es ist kein Zertifikat. Es belegt eine Prüfung und die durchgeführten Arbeiten zur Behebung.
Es trifft keine Aussage über die Einhaltung gesetzlicher Vorgaben. Ob Ihr Shop die Anforderungen des EAA, des BFSG oder eines anderen Gesetzes erfüllt, ist eine rechtliche Bewertung, die Sie gemeinsam mit Ihrer Rechtsberatung treffen. Der Stand der Vereinbarkeit im Entwurf der Erklärung ist ein Entwurf in der Formulierung der EU-Mustererklärung, gedacht für diese Prüfung.
Es prüft nicht alles automatisch. Automatisierte Tests finden nur einen Teil aller Barrieren. Kriterien mit einem Punkt auf der manuellen Checkliste werden von Hand geprüft oder bis dahin als „Nicht geprüft“ ausgewiesen. Ein Kriterium ohne Punkt auf der Checkliste, etwa 1.1.1 Non-text Content, gilt allein aufgrund automatisierter Tests als unterstützt, obwohl eine Regel nicht beurteilen kann, ob eine Textalternative ihr Bild beschreibt. Die Seiten werden als Stichprobe je Seitentyp geprüft, nicht einzeln.
Es beschreibt den Shop zum Zeitpunkt der Scans. Spätere Änderungen an Theme, Apps oder Inhalten sind nicht erfasst. Der Regressionsschutz prüft sie in festen Abständen.
Es erhebt keinen Anspruch auf PDF/UA-Konformität. Das PDF ist getaggt, mit echten Überschriften und Textalternativen, doch Validiscan behauptet nicht, dass es PDF/UA entspricht.
Der Entwurf der Erklärung ist nicht veröffentlichungsreif. Er braucht die Angaben Ihrer Organisation und eine Prüfung durch Ihre Rechtsberatung.

Die Methode, die Standards und die Grenzen automatisierter Tests

Wie erhalten Sie das Paket?

Sie erhalten das Remediation Evidence Package im Kundenportal: Sobald ein Paket fertig ist, schickt Validiscan Ihnen eine E-Mail mit einem Link dorthin, und die E-Mail enthält nie eine Datei. Das Kundenportal führt jede Version auf, die neueste zuerst, mit jeder Datei und ihrer SHA-256-Prüfsumme.

Die E-Mail: Ein Link zum Kundenportal, nie eine Datei
Versionen: Jede Version aufgeführt, die neueste zuerst, mit dem Datum ihrer Ausstellung
Download-Links: Beim Klicken erzeugt; jeder läuft nach einer Minute ab und wird nicht gespeichert
Archivierte Websites: Ihre Pakete bleiben aufgeführt und herunterladbar
Entwurf der Erklärung: Eine Seite im Kundenportal mit dem Entwurf aus Ihrem neuesten Paket, zum Kopieren oder zum Herunterladen als HTML-Datei

Details: die Versionsliste im Kundenportal, Download-Links, archivierte Websites und die Seite mit dem Entwurf der Erklärung

Im Kundenportal ist jede Version des Pakets aufgeführt, die neueste zuerst, mit dem Datum ihrer Ausstellung. Für jede Version können Sie den PDF-Bericht, das Word-Dokument, die JSON-Datendatei und das ZIP-Archiv herunterladen. Jede Datei wird mit ihrer SHA-256-Prüfsumme angezeigt, die Sie kopieren können. Ein Download-Link wird beim Klicken erzeugt und läuft nach einer Minute ab; gespeichert wird er nicht. Wird die Website Ihres Shops später archiviert und aus dem Kundenportal entfernt, bleiben ihre Pakete aufgeführt und herunterladbar. Das Kundenportal hat außerdem eine Seite mit dem Entwurf der Erklärung zur Barrierefreiheit aus Ihrem neuesten Paket, den Sie kopieren oder als HTML-Datei herunterladen können.

Bewahren Sie jede Version für Ihre Unterlagen auf. Das Remediation Evidence Package gehört zu jedem Projekt; was ein Projekt sonst noch umfasst, steht auf der Seite zum Ablauf eines Projekts.

Quellen

7 Quellen, alle für diese Seite geprüft am 6. Oktober 2026.

EU-Recht 3

Durchführungsbeschluss (EU) 2021/1339 der Kommission vom 11. August 2021 · EUR-Lex · 11. August 2021 · geprüft am 6. Oktober 2026
Durchführungsbeschluss (EU) 2018/1523 der Kommission vom 11. Oktober 2018 · EUR-Lex · 11. Oktober 2018 · geprüft am 6. Oktober 2026
Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates vom 17. April 2019 über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen · EUR-Lex · 17. April 2019 · geprüft am 6. Oktober 2026

Standards 4

EN 301 549 V4.1.1 (2026-09) · ETSI · geprüft am 6. Oktober 2026
The European accessibility standard EN 301 549 has been updated · AccessibleEU (European Commission) · 7. September 2026 · geprüft am 6. Oktober 2026
Web Content Accessibility Guidelines (WCAG) 2.2 · W3C · geprüft am 6. Oktober 2026
RFC 8785: JSON Canonicalization Scheme (JCS) · RFC Editor · geprüft am 6. Oktober 2026

Beginnen Sie mit einem kostenlosen Check Ihres Shops.

Senden Sie die Adresse Ihres Shops. Validiscan scannt ihn und antwortet mit jedem Fehler, den der Scan nachweisen kann, jeweils mit der Seite und dem Code.

Kostenlosen Check anfordern

Oder schreiben Sie an info@validiscan.com.

Was der kostenlose Check umfasst und was nicht

Sie senden: die Adresse Ihres Shops
Gescannte Seiten: bis zu 15
Sie erhalten: jeden Fehler, den der Scan nachweisen kann, mit Seite und Code
In Ihrem Shop: nur öffentliche Seiten; keine Anmeldung, nichts gekauft, kein Formular abgeschickt
Was er nicht ist: ein vollständiges Audit