L'application web de VeriSwarm est conçue pour être conforme, et testée en continu par rapport, aux Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — la référence citée par l'ADA et la Section 508. Cette page indique clairement notre objectif de conformité, ce que nous avons réellement vérifié, et ce qui reste à faire. Nous n'affirmons pas ici une conformité complète ou certifiée — nous indiquons ce que nous avons testé et listons ce que nous n'avons pas encore terminé.
Dernière révision : 27 août 2026.
Notre objectif est le niveau WCAG 2.2 Level AA sur l'ensemble de veriswarm.ai. Cet objectif est appliqué dans notre propre pipeline de livraison, pas seulement visé : des contrôles d'accessibilité automatisés s'exécutent à chaque changement avant sa fusion, et les pages représentatives font en plus l'objet d'audits manuels et d'une vérification au lecteur d'écran. Ce n'est pas une certification ponctuelle — c'est un contrôle que nous relançons en continu à mesure que le site évolue.
Cette déclaration couvre l'application web veriswarm.ai — le site marketing, la documentation, le blog, les tarifs, le flux d'authentification, ainsi que les consoles de compte et d'administration authentifiées. Elle ne couvre pas les sites tiers vers lesquels nous créons des liens, ni le contenu que nos clients publient via la plateforme (par exemple des pages générées par des agents).
Des contrôles et vérifications concrets qui fonctionnent réellement aujourd'hui, pas une feuille de route.
Les règles jsx-a11y d'ESLint s'exécutent à chaque commit, et des analyses automatisées de pages avec axe-core s'exécutent sur des routes représentatives à chaque changement. Les deux sont des contrôles bloquants, pas de simples avertissements.
Au-delà de l'analyse automatisée, nous avons mené des audits manuels au niveau du code sur des archétypes de pages représentatifs — landing, contenu de documentation/apprentissage, tarifs, blog, authentification, tableau de bord et administration — en vérifiant à la main la structure des titres, les landmarks, l'accessibilité au clavier et la correction des attributs ARIA.
Chaque page utilise une structure de landmarks unique — un header/nav, un main et un footer — avec une hiérarchie de titres appropriée, et un lien “Skip to content” est le premier élément pouvant recevoir le focus sur chaque page.
Les contrôles interactifs sont accessibles et utilisables au clavier seul, avec un indicateur de focus visible sur chaque élément pouvant recevoir le focus. Les widgets personnalisés comme les modales implémentent un piège à focus correct, une fermeture par Échap, et un retour du focus vers l'élément déclencheur.
Les animations et les mouvements respectent la préférence de mouvement réduit du système d'exploitation (prefers-reduced-motion).
Les couleurs du texte et de l'interface sont vérifiées par rapport aux ratios de contraste de WCAG 1.4.3 (4.5:1 pour le texte normal, 3:1 pour le texte large et les limites d'interface), calculés avec la véritable formule de luminance relative plutôt qu'à l'œil.
Les graphiques et les visualisations de score exposent leurs données sous-jacentes sous forme de texte (libellés, tableaux ou descriptions accessibles) plutôt que de reposer uniquement sur la couleur ou la forme.
Les champs de formulaire ont des libellés associés de manière programmatique, et les erreurs de validation sont signalées avec aria-invalid et aria-describedby plutôt que par la seule couleur.
Nous n'affirmons pas une conformité complète ou certifiée. Voici ce que nous savons devoir encore travailler, et pourquoi nous n'avons pas livré de correctif que nous n'aurions pas pu vérifier.
Le tableau de bord de compte et la console d'administration ont fait l'objet d'audits approfondis au niveau du code (structure des titres, utilisation des landmarks, correction des attributs ARIA, gestion du focus), mais comme ces interfaces nécessitent une session de connexion active, la vérification avec un vrai lecteur d'écran et un parcours au clavier seul sur le rendu réellement affiché est encore en cours. Nous considérons un audit au niveau du code comme nécessaire, mais pas suffisant à lui seul.
Quelques sections à onglets dans les consoles de compte et d'administration (par exemple la navigation du compte et les sous-onglets Cortex/Governance) utilisent actuellement des boutons standard qui changent le contenu visible, plutôt que le motif complet des onglets ARIA (role="tablist"/tab/tabpanel avec navigation par les touches fléchées). Une tentative précédente d'ajouter des rôles ARIA partiels sans le motif complet a été annulée, car un widget d'onglets partiellement câblé est pire pour les technologies d'assistance qu'un simple ensemble de boutons — il annonce une interaction d'onglets que la page ne prend en réalité pas en charge. Les boutons simples restent entièrement utilisables au clavier et à la souris en attendant ; un motif d'interface à onglets plus abouti et entièrement câblé pour ces sections est un travail futur prévu.
Si vous rencontrez sur veriswarm.ai quoi que ce soit de difficile à utiliser avec un clavier, un lecteur d'écran ou une autre technologie d'assistance, dites-le-nous. Indiquez l'URL de la page, ce que vous essayiez de faire, et la technologie d'assistance ou le navigateur que vous utilisiez, si possible.
support@veriswarm.ai