Déclaration d’accessibilité

1. Notre engagement

AUDACT AI LIMITED (Irlande, CRO 822514) s’engage à rendre son site web accessible au public le plus large possible, y compris aux utilisateurs en situation de handicap. La présente déclaration s’applique à audact.ai et à toutes ses sous-routes.

Nous visons à satisfaire aux exigences de l’Acte européen sur l’accessibilité (directive (UE) 2019/882) et de la norme harmonisée EN 301 549 V3.2.1, qui renvoie aux Web Content Accessibility Guidelines (WCAG) 2.1 au niveau de conformité AA.

2. État de conformité

Le site web d’Audact est partiellement conforme aux WCAG 2.1 niveau AA. Partiellement conforme signifie que certaines parties du contenu ne sont pas entièrement conformes à la norme d’accessibilité.

Ce qui le maintient à ce niveau partiel est nommé à la section 3 : le formulaire de contact entreprise ne signale pas le champ à l’origine d’une erreur, des indications de saisie automatique manquent dans les listes de sélection et dans la variante sans JavaScript du formulaire de candidature des agences, et aucun test avec un lecteur d’écran n’a été réalisé. Aucun audit par un tiers n’a été réalisé non plus.

Nous traitons activement les problèmes connus énumérés ci-dessous et visons une conformité complète d’ici le T4 2026. Ce qui a été mesuré, contrôle par contrôle, figure sur la page d’accessibilité courte ; cette page et la présente disent la même chose.

3. Problèmes connus

• Le formulaire de contact entreprise signale une erreur dans un message unique et ne marque pas le champ qui en est à l’origine. Mesuré le 27 août 2026 à 1440 px : envoyer /for-enterprise avec ses champs obligatoires vides ne laisse aucun champ porteur de aria-invalid et aucun champ renvoyant à un message par aria-describedby. Quatre autres formulaires de ce site marquent le champ, dont le formulaire de candidature des agences depuis aujourd’hui, ce qui fait de celui-ci une lacune plutôt qu’une convention interne.
• Des indications de saisie automatique sont présentes sur les champs de texte — le nom de l’agence, l’adresse e-mail et, sur le formulaire entreprise, le nom du contact — et absentes des listes de sélection. La variante sans JavaScript du formulaire de candidature n’en comporte aucune.
• Aucun test avec un lecteur d’écran n’a été réalisé. L’état déplié et replié du menu mobile, des groupes de navigation et de la partie repliable du formulaire de candidature est défini et change bien — mesuré dans Chromium — mais le fait que chaque lecteur d’écran l’annonce n’a pas été testé.
• Sept locales déclaraient une langue qu’elles n’affichaient pas (mesuré les 24 et 25 septembre 2026).
• Le premier arrêt au clavier après le lien d’évitement pouvait se trouver derrière l’en-tête fixe (mesuré les 24 et 25 septembre 2026).

Quatre points qui figuraient sur cette liste ne sont plus d’actualité. Ils sont consignés ici plutôt que supprimés, afin que le changement soit visible et daté.

Résolu — le formulaire de candidature des agences marque désormais le champ à l’origine de l’erreur. Mesuré le 27 août 2026 dans Chromium à 1440 et 390 px, en anglais, en allemand et en néerlandais : envoyer le formulaire avec le nom de l’agence, l’e-mail professionnel ou le secteur laissé vide laisse chacun de ces trois champs porteur de aria-invalid, renvoyant par aria-describedby à son propre message, qui s’affiche avec role=alert et aria-live=assertive ; le focus se déplace vers le premier d’entre eux. Une saisie qui n’est pas une adresse e-mail produit le second message plutôt que le premier ; les deux branches ont donc été mesurées. La lecture a d’abord été éprouvée sur l’inscription à Compliance Pulse, un formulaire qui la possédait déjà, et cette même lecture ne signale rien sur le formulaire de contact entreprise, où se situe désormais cette lacune dans la liste ci-dessus.

Résolu — annonces par régions live sur le formulaire de candidature des agences. Cette liste indiquait qu’elles étaient en cours d’ajout ; elles étaient déjà là. Une erreur s’affiche avec role=alert et aria-live=assertive, et la confirmation avec role=status et aria-live=polite.

Résolu — une alternative statique pour les visiteurs qui préfèrent un mouvement réduit. Sous prefers-reduced-motion: reduce, chacun des cinq canevas de la page d’accueil présente deux états en 1,8 seconde : vide, puis final. Sans cette préférence, deux d’entre eux passent par cinq et par sept, ce qui donne tout son sens au premier chiffre.

Résolu — contraste du petit texte courant. La palette a été révisée. 176 pages en anglais à 1440 px, et 17 pages en trois langues à 1440 et 390 px, ne montrent aucun texte en dessous de son seuil de contraste. Cette mesure ne couvre pas le tableau de bord de la plateforme, et elle ne couvre pas séparément les sept locales qui reviennent à l’anglais. Nouvelle mesure le 28 août 2026 : elle avait laissé échapper un point. Lighthouse a trouvé trois couleurs sous le seuil sur /en/demos, une page qui faisait partie de ces 176. La palette n’était pas en cause : une couche d’opacité de 40 % sur les lignes pas encore atteintes de deux chronologies de démonstration ramenait #7C8DA6 à #384357 (1,87:1), #B2B9C4 à #4D5563 (2,48:1) et #E2E8F0 à #606875 (3,32:1). Le balayage précédent lisait la couleur définie sur le texte et non la couleur que l’écran affiche, et son contrôle positif était une ligne injectée à faible contraste, qui ne porte aucune opacité au-dessus d’elle et n’aurait donc jamais pu détecter cela. L’opacité a disparu ; ces lignes sont désormais atténuées par la seule couleur, à #7C8DA6 sur #0A1223, soit 5,53:1. À partir du 28 août 2026, le contraste est mesuré en composant l’opacité de chaque élément ancêtre.

4. Retours et contact

Si vous rencontrez un obstacle d’accessibilité sur notre site web ou avez une question sur cette déclaration, écrivez à accessibility@audact.ai.

Nous visons à accuser réception de votre message dans un délai de 5 jours ouvrables et à y apporter une réponse sur le fond dans un délai de 30 jours.

5. Procédure de recours

Si notre réponse ne vous satisfait pas, vous pouvez déposer une plainte auprès de l’autorité de contrôle de votre État membre de l’UE. En Allemagne, il s’agit de la Schlichtungsstelle nach dem Behindertengleichstellungsgesetz. Aux Pays-Bas, le College voor de Rechten van de Mens traite les plaintes relatives à l’accessibilité.

6. Spécifications techniques

L’accessibilité du site web d’Audact repose sur les technologies suivantes : HTML, WAI-ARIA, CSS et JavaScript. La conformité aux normes d’accessibilité utilisées repose sur ces technologies.

7. Méthode d’évaluation

Audact évalue l’accessibilité de ce site web par des mesures dans le navigateur et par une revue manuelle au regard des critères WCAG de niveau AA : contraste mesuré par rapport à l’arrière-plan réellement affiché derrière chaque texte, visibilité du focus pour chaque élément actionnable, structure des repères et du lien d’évitement, association des libellés pour chaque champ de formulaire, et images d’animation comptées avec les deux préférences de mouvement. Lighthouse est exécuté sur la version de production.

axe-core, WAVE et Pa11y figurent dans le plan d’audit de la section 8 et ne sont pas utilisés aujourd’hui : ils ne sont pas des dépendances de ce site.

Il s’agit d’une auto-évaluation. Aucun audit par un tiers n’a été réalisé et aucun auditeur n’a été mandaté ; le premier est prévu pour le T4 2026 et le plan est présenté ci-dessous.

8. Feuille de route de l’audit formel WCAG 2.2 AA

Nous faisons évoluer notre objectif d’accessibilité des WCAG 2.1 AA vers les WCAG 2.2 AA, avec un programme d’audit formel par un tiers.

• Achèvement visé : T4 2026 (conformité complète aux WCAG 2.2 AA pour le site marketing ; le portail client suit au T1-T2 2027).
• Périmètre : d’abord un échantillon représentatif de 10 à 15 pages (page d’accueil, /for-agencies, /pricing, /trust, /receipt-explorer, le formulaire de candidature des agences, ainsi que des pages clés de /compliance et /legal), puis un élargissement à un audit complet de toutes les routes publiques.
• Outils automatisés d’abord : axe-core (intégration CI), WAVE, Pa11y et audits d’accessibilité Lighthouse avant la revue manuelle.
• Tests manuels avec lecteur d’écran : NVDA (Windows / Firefox), JAWS (Windows / Chrome) et VoiceOver (macOS / Safari et iOS) sur le parcours de conversion principal.
• Balayages de non-régression au clavier seul et en mouvement réduit à chaque version.

Nous publierons sur cette page la synthèse de chaque rapport d’audit une fois celui-ci terminé.