Barrierefreiheits-Overlay-Widgets gehören heute zu den meistdiskutierten – und am häufigsten missverstandenen – Werkzeugen im Bereich der Web-Compliance. Dieser Leitfaden erklärt genau, wie Overlay-Widgets unter der Haube funktionieren, welche Probleme sie tatsächlich beheben können, wo ihre Grenzen liegen und wie man sie als Teil einer glaubwürdigen, mehrschichtigen Barrierefreiheitsstrategie einsetzt.
Stellen Sie sich Folgendes vor: Eine Inhaberin eines kleinen Unternehmens erhält ein Abmahnschreiben wegen angeblicher ADA-Nichtkonformität. Ihre Entwickler sind für Wochen ausgebucht, ein vollständiges Audit kostet Tausende, und die Zeit läuft. In solchen Momenten kommen Accessibility-Overlay-Widgets ins Spiel – sie versprechen schnelle Implementierung, messbare Verbesserungen und eine Brücke zu einer inklusiveren Website. Aber was genau sind diese Tools, wie funktionieren sie technisch, und was können sie realistisch beheben? Die Antwort ist nuancierter, als es die meisten Marketingtexte vermuten lassen.
Die Landschaft: Warum Web-Accessibility gerade jetzt dringend ist
Die Weltgesundheitsorganisation schätzt, dass 1,3 Milliarden Menschen – etwa 16% der Weltbevölkerung – mit einer erheblichen Behinderung leben. Für jede dieser Personen ist eine schlecht strukturierte Webseite keine Unannehmlichkeit; sie ist eine verschlossene Tür. Regierungen weltweit haben mit durchsetzbaren rechtlichen Rahmenwerken reagiert. In den Vereinigten Staaten setzen der ADA und Section 508 den Standard. In Kanada schreibt der AODA für die meisten Organisationen die Einhaltung von WCAG 2.0 Level AA vor, während der European Accessibility Act, der 2025 vollständig in Kraft trat, eng an WCAG 2.1 AA angelehnt ist. Das sind keine fernen Regelwerke – sie sind aktiv, werden durchgesetzt und ausgeweitet.
Für Entwickler und Compliance-Verantwortliche erzeugt das echten Druck. Die durchschnittliche Startseite weist 51 WCAG-Verstöße auf – das ist eine Barriere alle 24 Elemente. Die Behebung all dieser Probleme erfordert Arbeiten auf Code-Ebene, oft über Hunderte von Seiten hinweg. In dieser Lücke zwischen dem Handlungsdruck und der Zeit, die eine saubere Umsetzung braucht, sind Overlay-Widgets als Produktkategorie entstanden – und genau hier ist ein klares Verständnis besonders wichtig.
Digitale Barrierefreiheit ist längst kein Schlagwort mehr; sie ist eine Notwendigkeit. Unternehmen, Regierungen und Organisationen weltweit werden zunehmend dazu angehalten – und in vielen Fällen verpflichtet –, ihre digitalen Räume inklusiv und für alle zugänglich zu gestalten. Die Frage ist nicht, ob man in Barrierefreiheit investieren sollte, sondern wie man es effektiv und in der richtigen Reihenfolge tut.
Was genau ist ein Accessibility-Overlay-Widget?
Accessibility-Overlays sind JavaScript-Widgets, die über eine bestehende Website geladen werden und versuchen, Barrierefreiheitsprobleme automatisch zu erkennen und zu beheben oder den Nutzern ein Kontrollpanel anzubieten, in dem sie Anzeigeeinstellungen wie größere Schrift, höheren Kontrast und vereinfachtes Layout anpassen können. Der Begriff „Overlay“ ist weit gefasst, und der Markt umfasst erhebliche Unterschiede darin, was diese Tools tatsächlich leisten.
Die meisten modernen Overlay-Produkte kombinieren zwei unterschiedliche Fähigkeiten. Die erste ist eine Erkennungs-und-Behebungs-Schicht, die versucht, Barrieren auf Code-Ebene mithilfe von KI oder vordefinierten Regeln automatisch zu reparieren – mit dem Anspruch, fehlende Alt-Texte zu ergänzen, die Tastaturnavigation zu verbessern, Farbkontraste zu optimieren und andere WCAG-Kriterien zu adressieren. Die zweite ist ein Benutzer-Kontrollpanel, das Besuchern eine Werkzeugleiste mit Einstellungen bietet, die sie selbst anpassen können: Schriftgröße, Cursorgröße, Farbmodus und Reduktion von Animationen. Diese Tools beheben keine zugrunde liegenden Barrierefreiheitsprobleme; sie geben einzelnen Nutzerinnen und Nutzern Optionen, ihre Erfahrung zu modifizieren.
Ein Accessibility-Overlay erscheint auf einer Website in der Regel als Toolbar, Plugin, App oder Widget. Meist werden sie durch einen Klick auf einen kleinen runden Button aktiviert, der am Rand der Website über dem Inhalt schwebt. Nach einem Klick auf diese Floating Action Button öffnet sich das Accessibility-Overlay. Nutzer können das Overlay dann verwenden, um die Website an ihre Bedürfnisse anzupassen – etwa durch Änderung der Schriftgröße, Anpassung des Farbkontrasts oder Aktivierung von Text-zu-Sprache. Einzelne Funktionen lassen sich per Knopfdruck aktivieren, oder es kann ein „Accessibility-Profil“ gewählt werden, um mehrere Anpassungen gleichzeitig umzusetzen.
Aus technischer Installationsperspektive ist die Implementierung trügerisch einfach. Um ein Accessibility-Overlay zu einer Website hinzuzufügen, kann die Website-Inhaberin ein kurzes JavaScript-Snippet in den Quellcode der Seite einfügen. Ein gut entwickeltes Overlay-SDK wie Accsible ist so konzipiert, dass es framework-agnostisch und CMS-kompatibel ist, sodass es ohne Architekturänderungen in eine WordPress-, Shopify-, React- oder individuell entwickelte Seite integriert werden kann. Diese Integrationsleichtigkeit ist real – und als Teil einer umfassenderen Strategie tatsächlich wertvoll.
Wie Overlay-Widgets unter der Haube funktionieren
Das Verständnis der Mechanik hilft dabei, jedes Overlay-Produkt ehrlich zu bewerten. Wenn eine Seite im Browser eines Nutzers geladen wird, wird das JavaScript des Overlays ausgeführt, nachdem der DOM geparst wurde. Das Skript scannt die Seite, versucht, gängige Barrierefreiheitsprobleme zu identifizieren, und wendet dann schnelle Korrekturen an – wenn beispielsweise einem
-Element ein alt-Attribut fehlt, könnte das Overlay versuchen, eines basierend auf dem Dateinamen des Bildes oder dem umgebenden Kontext zu generieren. Es könnte versuchen, einem Button oder Formularfeld, dem ein korrektes Label fehlt, ein aria-label hinzuzufügen oder ARIA-Rollen oder -Zustände auf nicht-semantische Elemente wie ein als Button verwendetes div anzuwenden.
Fortgeschrittenere Overlay-SDKs legen KI und Machine Learning über diese regelbasierten Korrekturen. Einige Accessibility-Overlays nutzen KI-Automatisierung und Machine Learning, um digitale Barrieren zu identifizieren und in manchen Fällen zu beheben. Diese Echtzeitanalyse hilft, Probleme wie fehlende Alt-Texte und fehlerhafte Überschriftenstruktur zu erkennen, und einige Overlays können sogar Code-Korrekturen empfehlen oder ausführen. Die besten Produkte in dieser Kategorie scannen kontinuierlich neu, wenn sich Inhalte ändern, und erkennen neu eingeführte Probleme, ohne dass eine manuelle Neuimplementierung erforderlich ist.
Das nutzerseitige Panel funktioniert anders – es wendet CSS-Klassenänderungen und DOM-Manipulationen als Reaktion auf die gewählten Nutzerpräferenzen an. Viele Overlays bieten Nutzerinnen und Nutzern Anpassungsoptionen: Besucher können Text vergrößern, die Schriftart ändern, Farben für besseren Kontrast anpassen und Text-zu-Sprache aktivieren. Diese Anpassungen sind real, unmittelbar und für viele Menschen mit leichten bis moderaten Seh- oder kognitiven Beeinträchtigungen tatsächlich hilfreich. Eine Person mit Dyslexie, die auf eine dyslexiefreundliche Schrift umstellt, oder eine Nutzerin mit eingeschränktem Sehvermögen, die den Kontrast auf Maximum erhöht – das sind spürbare Verbesserungen der Nutzbarkeit, kein Theater.
Hier ist eine vereinfachte Illustration, wie eine Widget-Integration auf Code-Ebene aussieht:
Eine Zeile in Ihrem oder vor dem schließenden -Tag reicht aus, um das Widget zu initialisieren, die Scan-Engine zu laden und das nutzerseitige Accessibility-Panel bereitzustellen. Das SDK erledigt den Rest asynchron, sodass das Rendering der Seite nicht blockiert wird.
Was ein Overlay-Widget tatsächlich beheben kann
Der Markt für Accessibility-Overlays hat unter überzogenen Versprechen gelitten, aber die angemessene Reaktion besteht nicht darin, das, was diese Tools tatsächlich gut leisten, abzutun. Es gibt eine Reihe von Problemen, bei denen ein gut gebautes Overlay echten, überprüfbaren Mehrwert bietet:
Farbanpassungen beim Kontrast. Overlays arbeiten in Echtzeit, scannen eine Website nach Barrieren und ändern automatisch die Darstellung von Inhalten – etwa indem sie Kontrastprobleme beheben und Überschriften für Screenreader neu organisieren. High-Contrast- und Dark-Mode-Schalter im Nutzerpanel verschaffen sofortige Erleichterung, ohne auf einen Entwickler-Sprint warten zu müssen.
Text- und Schriftanpassung. Skalierung der Schriftgröße, Zeichenabstand, Zeilenhöhe und der Austausch gegen dyslexiefreundliche Schriften liegen klar im Bereich des Overlays. Diese Anpassungen erscheinen als Toolbar oder Widget und ermöglichen es Nutzerinnen und Nutzern, ihr Surferlebnis zu personalisieren, indem sie verschiedene Anpassungen wie Änderungen der Schriftgröße, des Farbkontrasts und Text-zu-Sprache-Funktionen per Knopfdruck vornehmen.
ARIA-Attribut-Injektion. Overlays können ARIA (Accessible Rich Internet Applications)-Erweiterungen hinzufügen, um die Kompatibilität mit unterstützenden Technologien wie Screenreadern zu verbessern – einschließlich des Hinzufügens fehlender aria-label-, aria-expanded- und Landmark-Rollen zu Elementen, die ohne diese ausgeliefert wurden. Das ist besonders als Übergangslösung hilfreich, wenn sich eine Website mitten in der Überarbeitung befindet.
Fokusindikatoren und Hilfen für Tastaturnavigation. Einige Overlays können sichtbare Fokus-Stile für Tastaturnutzer einfügen und Skip-Navigation-Links hinzufügen, wodurch die Nutzung für Menschen erleichtert wird, die keine Maus verwenden können.
Steuerung von Animationen und Bewegungen. Nutzerinnen und Nutzer mit vestibulären Störungen können Modi mit reduzierter Bewegung aktivieren – eine wertvolle, risikoarme Verbesserung, die mit WCAG 2.1 Erfolgskriterium 2.3.3 im Einklang steht.
Cursor-Vergrößerung. Vergrößerte und kontrastreiche Cursor-Optionen kommen Menschen mit motorischen Einschränkungen oder Sehbeeinträchtigungen zugute und verbessern die Zeigerpräzision.
Accessibility-Erklärungen. Ein hochwertiges Overlay-SDK kann automatisch eine Seite mit einer Accessibility-Erklärung generieren oder bereitstellen – ein zunehmend wichtiges Dokument, um ernsthafte Compliance-Bemühungen unter Gesetzen wie dem EAA zu belegen.
Ein gut implementiertes Overlay-Widget ist am besten als bedeutende erste Schicht der Barrierefreiheitsverbesserung und als Werkzeug zur Nutzerermächtigung zu verstehen – nicht als Ersatz für Quellcode-Überarbeitung, sondern als echte Ergänzung dazu.
Wo Overlay-Widgets an ihre strukturellen Grenzen stoßen
Eine ehrliche Bewertung erfordert ebenso klare Aussagen darüber, was Overlays nicht leisten können. Diese Grenzen sind keine Schwächen einzelner Produkte – sie sind strukturelle Beschränkungen der Technologie selbst.
Ein entscheidendes Merkmal von Overlay-Tools ist, dass sie „oberhalb“ des bestehenden Codebestands einer Website operieren. Sie nehmen Änderungen an der Frontend-Präsentation der Website vor – also an dem, was Nutzer sehen und womit sie interagieren – statt direkte Änderungen am zugrunde liegenden Quellcode der Seite vorzunehmen, etwa an HTML, CSS oder grundlegenden JavaScript-Strukturen. Diese oberflächliche Arbeitsweise ist ein Schlüsselfaktor für ihre inhärenten Grenzen.
Selbst die ausgefeilteste automatische Erkennung kann nur einen Teil der Barrierefreiheitsprobleme identifizieren. Die Forschung des W3C schätzt, dass automatisierte Tools etwa 30–40% der WCAG-Verstöße erfassen. Der Rest – komplexe Tastaturinteraktionen, aussagekräftige Bildbeschreibungen, Qualität von Untertiteln, logische Lesereihenfolge – erfordert menschliches Urteil. Kein Overlay-Produkt kann diese Hürde allein nehmen. Viele WCAG-Kriterien betreffen Design- und Inhaltsentscheidungen, die kein automatisiertes Tool bewerten oder beheben kann: Ergibt die Seitenstruktur logisch Sinn? Vermitteln die Überschriften eine korrekte Hierarchie? Ist der Inhalt in klarer, verständlicher Sprache verfasst? Beschreibt der Linktext das Ziel? Diese Fragen erfordern menschliches Urteil und lassen sich nicht automatisieren.
Es gibt außerdem Inhaltskategorien, die für jedes JavaScript-Overlay schlicht unerreichbar sind. Die automatisierte Reparatur von Feldlabels, Fehlermanagement, Fehlerbehandlung und Fokussteuerung in Formularen ist nicht zuverlässig. Moderne, komponentenbasierte Benutzeroberflächen wie solche mit ReactJS, Angular oder Vue können den Zustand der gesamten oder eines Teils der Seite unabhängig vom Overlay ändern, sodass dieses die JavaScript-gesteuerten Inhaltsänderungen nicht mehr korrigieren kann. Darüber hinaus reparieren Overlays keine Inhalte in Flash, Java, Silverlight, PDF, HTML5 Canvas, SVG oder Mediendateien.
Vielleicht die wichtigste strukturelle Einschränkung betrifft Screenreader. Overlays injizieren JavaScript, das nach dem Laden der Seite ausgeführt wird. Screenreader parsen Ihren HTML-Quellcode, bevor Overlays ausgeführt werden – der Accessibility-Tree ist dann bereits aufgebaut. Overlays können keine korrekten Zuordnungen von Formularlabels herstellen, keine semantische Struktur reparieren und keine Tastaturnavigation durch JavaScript-Injektion beheben. Das bedeutet, dass Nutzerinnen und Nutzer, die auf unterstützende Technologien wie JAWS, NVDA oder VoiceOver angewiesen sind, von den automatischen Korrekturen des Overlays möglicherweise überhaupt nicht profitieren.
Die rechtliche Realität: Was die Daten sagen
Eine der schädlichsten Fehlannahmen über Overlay-Widgets ist die Vorstellung, dass deren Installation einen nennenswerten rechtlichen Schutz bietet. Die Klagedaten zeichnen ein anderes Bild. Berichten zufolge wurden 2023 über 900 Klagen gegen Unternehmen eingereicht, die solche Widgets nutzen, und 2024 verwiesen 25% aller Klagen zur Web-Barrierefreiheit ausdrücklich auf diese Tools als Barrieren statt als Lösungen.
Kein Barrierefreiheitsrahmen – weder WCAG, ADA, AODA noch der EAA – betrachtet ein Overlay als „konform“. Sie verlangen, dass die zugrunde liegenden Inhalte barrierefrei sind. Die ADA-Title-II-Regel vom April 2026 verschärft dies für Websites von Bundesstaaten und Kommunen zusätzlich, indem sie explizit WCAG 2.1 AA-Konformität ohne Overlay-Ausnahmen fordert.
Die International Association of Accessibility Professionals (IAAP) hat erklärt, dass Unternehmen davon absehen sollten zu behaupten, eine Website oder Anwendung könne allein durch die Installation eines Plugins oder Widgets vollständig barrierefrei gemacht werden, ohne zusätzliche Schritte oder Dienstleistungen. Das ist eine vernünftige, ausgewogene Position: Overlays haben eine Rolle, aber diese Rolle besteht nicht darin, als alleinige Compliance-Lösung zu dienen.
Die Risikobetrachtung verschiebt sich, wenn ein Overlay ehrlich positioniert wird – als Schicht zur Nutzerermächtigung, die parallel zu echter Überarbeitungsarbeit eingesetzt wird, nicht an deren Stelle. Gerichte und Aufsichtsbehörden bewerten, ob Menschen mit Behinderungen tatsächlich auf Ihre Inhalte zugreifen können. Während Overlays, die helfen, Probleme zu identifizieren und sie Website-Inhaberinnen und Entwicklern aufzuzeigen, eine legitime Rolle haben, entstehen Probleme bei „Quick-Fix, No-Effort“-Overlays, die Konformität ohne substanzielle Verbesserungen versprechen.
Wie man ein Overlay-Widget als Teil einer echten Accessibility-Strategie einsetzt
Richtig eingesetzt ist ein Overlay-Widget-SDK wie Accsible ein tatsächlich nützliches Element eines mehrschichtigen Barrierefreiheitsprogramms. Entscheidend ist, seinen Platz im Stack zu verstehen. So sollten Sie über eine verantwortungsvolle Implementierung nachdenken:
Beginnen Sie mit einem Audit. Bevor Sie ein Overlay einsetzen, führen Sie einen automatisierten WCAG-Scan durch, um das gesamte Spektrum der Probleme auf Ihrer Website zu verstehen. Auf axe-core basierende Tools zeigen die erkennbaren Verstöße auf. Dokumentieren Sie alles – diese Dokumentation ist wichtig, um guten Willen nachzuweisen.
Setzen Sie das Widget als Schicht zur Nutzerermächtigung ein. Installieren Sie das Accsible-Widget, um Ihren Nutzerinnen und Nutzern sofortige Kontrolle über ihr Erlebnis zu geben: Kontrast, Schriftgröße, Bewegung, Cursor und mehr. Das bietet Menschen mit leichten bis moderaten Bedürfnissen echten Mehrwert, während Ihre tiefgreifendere Überarbeitung voranschreitet.
Nutzen Sie die Scan- und Reporting-Funktionen des Widgets. Ein hochwertiges Overlay-SDK liefert fortlaufend Compliance-Einblicke. Nutzen Sie diese Berichte, um zu priorisieren, welche Quellcode-Korrekturen Ihr Entwicklungsteam zuerst angeht – beginnend mit den schwerwiegendsten Problemen auf den meistbesuchten Seiten.
Sanieren Sie parallel. Arbeiten Sie Ihren Quellcode durch, um semantische Struktur, Formularlabels, Logik der Tastaturnavigation und Überschriftenhierarchie zu verbessern. Widgets können als temporäre Übergangslösung dienen. Wenn Sie gerade ein Accessibility-Audit abgeschlossen haben und eine lange Liste von Korrekturen für Ihr Entwicklungsteam vorliegt, kann ein Widget in der Zwischenzeit eingesetzt werden, um einige der leichter zu behebenden Probleme zu überbrücken, während die komplexere Überarbeitung läuft.
Veröffentlichen Sie eine Accessibility-Erklärung. Das signalisiert Engagement gegenüber Nutzerinnen, Nutzern und Aufsichtsbehörden. Viele Overlay-SDKs, einschließlich Accsible, können eine Erklärungsvorlage generieren, die Sie an Ihren aktuellen Compliance-Status und Ihre Roadmap anpassen können.
Testen Sie mit echten Nutzerinnen und Nutzern. Automatisierte Tools und Overlays erfassen zusammen immer noch nur einen Teil der realen Barrieren. Die Einbindung von Menschen mit Behinderungen in Ihren QA-Prozess bringt Probleme ans Licht, die der Code allein nie finden wird.
Die effektivsten Barrierefreiheitsprogramme behandeln das Overlay-Widget als sichtbares Gesicht eines Engagements, das bis in den Quellcode reicht. Das Widget ist das, was Nutzer sehen; die Überarbeitungsarbeit ist das, was es real macht.
Das richtige Overlay-Widget-SDK auswählen
Nicht alle Overlay-Produkte sind gleich. Bei der Bewertung eines Overlay-SDKs für Ihre Organisation trennen die folgenden Kriterien wirklich nützliche Tools von solchen, die mehr Marketing als Substanz liefern:
Transparenz über den Umfang. Ein glaubwürdiger Overlay-Anbieter ist offen darüber, was sein Produkt behebt und was nicht. Compliance-Widgets sind leistungsstarke Werkzeuge, aber sie sind kein Ersatz für eine gut gestaltete, barrierefreie Website – sie sollten Ihre umfassenderen Barrierefreiheitsbemühungen ergänzen, nicht ersetzen. Jeder Anbieter, der etwas anderes behauptet, ist ein Warnsignal.
Auswirkungen auf die Performance. Das Widget sollte asynchron laden und nur ein vernachlässigbares Gewicht zu Ihrer Seite hinzufügen. Ein aufgeblähtes Overlay, das Ihre Core Web Vitals verlangsamt, ist kontraproduktiv – Performance ist selbst ein Barrierefreiheitsaspekt für Menschen mit langsamen Verbindungen oder leistungsschwachen Geräten.
Anpassbarkeit und Branding. Das Widget sollte sich visuell in Ihre Website einfügen und nicht wie ein generischer Drittanbieter-Fremdkörper wirken. White-Label-SDK-Optionen geben Teams volle Kontrolle über Platzierung, Farbe und Trigger-Design.
Laufende Überwachung. Statische Korrekturen reichen in einer Welt dynamischer Inhalte nicht aus. Suchen Sie nach SDKs, die Ihre Seiten kontinuierlich überwachen und Sie auf neue Verstöße hinweisen, die durch Content-Updates oder Deployments eingeführt werden.
Compliance-Dokumentation. Das SDK sollte helfen, Audit-Trails, Accessibility-Erklärungen und Berichte zu generieren, die den Fortschritt Ihres Programms belegen – Dokumentation, die im Falle einer rechtlichen Auseinandersetzung echten Wert hat.
Abdeckung der WCAG-Versionen. Stellen Sie sicher, dass das Tool mindestens mit WCAG 2.1 AA im Einklang steht und idealerweise WCAG 2.2 unterstützt, wenn die Durchsetzung den neuesten Standard einholt.
Zentrale Erkenntnisse
Overlay-Widgets sind ein echtes Werkzeug, aber keine Wunderwaffe. Sie bieten unmittelbare, messbare Verbesserungen der User Experience – insbesondere bei Farbkontrast, Textskalierung, ARIA-Erweiterungen und Bewegungssteuerung –, operieren aber auf der Präsentationsebene und können zugrunde liegende Codeprobleme ohne begleitende Arbeiten am Quellcode nicht vollständig beheben.
Automatisierte Tools, einschließlich Overlays, erkennen etwa 30–40% der WCAG-Verstöße. Der Rest erfordert menschliches Urteil und saubere Code-Überarbeitung. Setzen Sie Ihr Overlay in dem Wissen ein, dass diese Obergrenze existiert, und planen Sie Ihre Quellcode-Korrekturen entsprechend.
Rechtlicher Schutz entsteht durch echte Barrierefreiheit, nicht durch die Installation eines Widgets. Die Klagedaten sind eindeutig: Overlays, die als Compliance-Abkürzung vermarktet werden, ziehen eher Klagen an, als sie zu verhindern. Positionieren Sie Ihr Overlay korrekt – als Schicht zur Nutzerermächtigung und Ergänzung zur Überarbeitung – und dokumentieren Sie alles.
Ein Overlay-SDK ist am wirkungsvollsten als Teil einer mehrschichtigen Strategie. Führen Sie zuerst ein Audit durch, setzen Sie das Widget für unmittelbare Nutzerwirkung ein, nutzen Sie die Berichte des Widgets zur Priorisierung von Code-Korrekturen und verankern Sie Barrierefreiheit dauerhaft in Ihrem Entwicklungsprozess.
Wählen Sie Ihr SDK nach Substanz, nicht nach Marketingversprechen. Bewerten Sie jedes Overlay-Produkt anhand seines Performance-Footprints, seiner Transparenz über Grenzen, seiner Fähigkeiten zur laufenden Überwachung und der Qualität seiner Compliance-Dokumentation – nicht anhand von Versprechen sofortiger, vollständiger Konformität.
