Die Webanwendung von VeriSwarm ist so gebaut und wird fortlaufend so getestet, dass sie den Web Content Accessibility Guidelines (WCAG) 2.2, Level AA entspricht — dem Maßstab, auf den sich die ADA und Section 508 beziehen. Diese Seite legt unser Konformitätsziel offen dar, zeigt, was wir tatsächlich überprüft haben, und was noch zu tun ist. Wir behaupten hier keine vollständige oder zertifizierte Konformität — wir geben an, was wir getestet haben, und listen auf, was noch nicht abgeschlossen ist.
Zuletzt überprüft: 27. August 2026.
Unser Ziel ist WCAG 2.2 Level AA für die gesamte Website veriswarm.ai. Dieses Ziel wird in unserer eigenen Delivery-Pipeline durchgesetzt, nicht nur angestrebt: Automatisierte Barrierefreiheitsprüfungen laufen bei jeder Änderung, bevor sie gemergt wird, und repräsentative Seiten durchlaufen zusätzlich manuelle Audits und eine Verifizierung mit Screenreadern. Es ist keine einmalige Zertifizierung — es ist eine Prüfung, die wir fortlaufend erneut durchführen, während sich die Website weiterentwickelt.
Diese Erklärung deckt die Webanwendung veriswarm.ai ab — die Marketing-Website, die Dokumentation, den Blog, die Preisseite, den Anmeldevorgang sowie die authentifizierten Konto- und Admin-Konsolen. Sie deckt nicht Websites Dritter ab, auf die wir verlinken, oder Inhalte, die unsere Kunden über die Plattform veröffentlichen (zum Beispiel von Agenten generierte Seiten).
Konkrete Kontrollen und Prüfungen, die heute tatsächlich laufen, keine Roadmap.
Die jsx-a11y-Regeln von ESLint laufen bei jedem Commit, und automatisierte axe-core-Seiten-Scans laufen bei jeder Änderung gegen repräsentative Routen. Beide sind blockierende Prüfungen, keine bloßen Hinweise.
Über die automatisierte Prüfung hinaus haben wir manuelle, codebasierte Audits über repräsentative Seitentypen hinweg durchgeführt — Landingpages, Doku-/Lerninhalte, Preisseite, Blog, Authentifizierung, Dashboard und Admin-Bereich — und dabei Überschriftenstruktur, Landmarks, Erreichbarkeit per Tastatur und ARIA-Korrektheit von Hand geprüft.
Jede Seite verwendet eine einzige Landmark-Struktur — ein Header/Nav, ein Main und ein Footer — mit einer korrekten Überschriftenhierarchie, und ein “Skip to content”-Link ist das erste fokussierbare Element auf jeder Seite.
Interaktive Steuerelemente sind allein über die Tastatur erreichbar und bedienbar, mit einem sichtbaren Fokusindikator auf jedem fokussierbaren Element. Individuelle Widgets wie Modals implementieren eine korrekte Fokusfalle, ein Schließen mit Escape und die Rückgabe des Fokus an das auslösende Element.
Animationen und Bewegungen berücksichtigen die Einstellung für reduzierte Bewegung des Betriebssystems (prefers-reduced-motion).
Text- und UI-Farben werden gegen die Kontrastverhältnisse aus WCAG 1.4.3 geprüft (4.5:1 für normalen Text, 3:1 für großen Text und UI-Grenzen), berechnet mit der tatsächlichen relativen Leuchtdichteformel statt nach Augenmaß.
Diagramme und Score-Visualisierungen stellen ihre zugrunde liegenden Daten als Text bereit (Beschriftungen, Tabellen oder barrierefreie Beschreibungen), statt sich allein auf Farbe oder Form zu verlassen.
Formularfelder haben programmatisch zugeordnete Labels, und Validierungsfehler werden mit aria-invalid und aria-describedby angezeigt, statt allein über Farbe.
Wir behaupten keine vollständige oder zertifizierte Konformität. Hier ist, was unseres Wissens noch Arbeit braucht, und warum wir keinen Fix ausgeliefert haben, den wir nicht verifizieren konnten.
Das Konto-Dashboard und die Admin-Konsole haben gründliche codebasierte Audits durchlaufen (Überschriftenstruktur, Landmark-Nutzung, ARIA-Korrektheit, Fokusverwaltung), aber da diese Bereiche eine aktive Anmeldesitzung erfordern, läuft die Verifizierung mit einem echten Screenreader und ein rein tastaturbasierter Durchgang durch die tatsächlich gerenderte Ausgabe noch. Wir betrachten ein codebasiertes Audit als notwendig, aber nicht allein ausreichend.
Einige Tab-Bereiche in den Konto- und Admin-Konsolen (zum Beispiel die Kontonavigation und die Cortex/Governance-Unterreiter) verwenden derzeit Standard-Buttons, die den sichtbaren Inhalt wechseln, statt des vollständigen ARIA-Tab-Musters (role="tablist"/tab/tabpanel mit Pfeiltasten-Navigation). Ein früherer Versuch, teilweise ARIA-Rollen ohne das vollständige Muster hinzuzufügen, wurde zurückgenommen, weil ein halb fertiges Tab-Widget für assistive Technologien schlechter ist als ein einfaches Set von Buttons — es kündigt eine Tab-Interaktion an, die die Seite tatsächlich nicht unterstützt. Einfache Buttons bleiben in der Zwischenzeit vollständig über Tastatur und Maus bedienbar; ein umfassenderes, vollständig verdrahtetes Tab-Interface-Muster für diese Bereiche ist als zukünftige Arbeit geplant.
Wenn Sie auf veriswarm.ai auf etwas stoßen, das sich mit Tastatur, Screenreader oder anderer assistiver Technologie schwer bedienen lässt, teilen Sie uns das mit. Geben Sie nach Möglichkeit die Seiten-URL an, was Sie versucht haben zu tun, und welche assistive Technologie oder welchen Browser Sie verwendet haben.
support@veriswarm.ai