Qu'est-ce qu'un Accessibility Conformance Report (ACR) ?

Qu'est-ce qu'un Accessibility Conformance Report (ACR) ?

Un Accessibility Conformance Report (ACR) est un document qui déclare dans quelle mesure un produit numérique (site web, application web, application mobile, logiciel, matériel) se conforme aux standards d'accessibilité — principalement WCAG (Web Content Accessibility Guidelines) et Section 508 du US Rehabilitation Act. Les ACR sont typiquement rédigés en utilisant le VPAT (Voluntary Product Accessibility Template) publié par l'Information Technology Industry Council (ITI), qui fournit un format standardisé pour reporter sur chaque critère de succès WCAG.

Un ACR n'est pas une certification ou un audit — c'est une auto-attestation du fournisseur. Le fournisseur liste chaque critère WCAG applicable et rapporte si le produit Supports, Partially Supports, Does Not Support ou Not Applicable. Les ACR honnêtes incluent des notes explicatives sur les cas limites et les problèmes connus. Les ACR pilotés par le marketing revendiquent un support complet sans preuve — et s'effondrent généralement sous de vrais audits.

Pourquoi les ACR existent

Trois moteurs :

• Marchés publics fédéraux US. Section 508 exige que les agences fédérales achètent de la technologie accessible. Les ACR sont la façon standard dont les fournisseurs démontrent la conformité pendant les marchés — exigés par GSA Schedule 70 et la plupart des RFP d'agence.
• Marchés de l'enseignement supérieur et des grandes entreprises. Les universités et les acheteurs Fortune 500 exigent de plus en plus des ACR dans le cadre de leurs réponses RFP. Les équipes de marchés les utilisent comme filtre.
• UE EAA (European Accessibility Act). Effectif depuis juin 2025, l'EAA exige des déclarations d'accessibilité pour de nombreux produits numériques vendus dans l'UE. Les fournisseurs avec des ACR sont pré-positionnés pour répondre aux exigences de l'EAA avec un travail supplémentaire minimal.

Ce que contient un ACR (format VPAT 2.x)

Le format actuel VPAT 2.5 (le plus récent en 2026) couvre quatre standards en un document :

• WCAG 2.1 (Niveaux A et AA). 50+ critères de succès à travers les quatre principes POUR (Perceivable, Operable, Understandable, Robust).
• Section 508 révisée. Standard fédéral de marchés US, harmonisé avec WCAG 2.0 depuis 2018.
• EN 301 549. Standard européen pour l'accessibilité ICT, obligatoire sous l'EAA.
• WCAG 2.2 (dans VPAT 2.5+). Critères de succès plus récents (taille de cible, apparence de focus, etc.).

Pour chaque critère, l'ACR liste :

1. Niveau de conformité (Supports / Partially Supports / Does Not Support / Not Applicable).
2. Remarques et explications — détails concrets sur ce qui a été testé, problèmes connus, contournements et roadmap pour les critères non supportés.

Comment écrire un ACR crédible

Testez avant d'écrire

La plus grosse erreur : écrire l'ACR depuis la documentation des fonctionnalités sans réellement tester. Avant qu'aucun critère ne reçoive "Supports", lancez des scanners automatisés (axe, WAVE) ET des tests manuels avec lecteurs d'écran (NVDA sur Windows, VoiceOver sur Mac/iOS, TalkBack sur Android). Documentez ce que vous avez testé, sur quelles plateformes, avec quelles technologies d'assistance.

Soyez honnête sur "Partially Supports"

Presque tous les produits réels supportent partiellement de nombreux critères. Scénarios courants de support partiel honnête : "la navigation au clavier fonctionne pour les flux principaux mais le widget dropdown sur la page paramètres piège le focus", ou "le texte alt est fourni pour les images de produits mais les graphiques auto-générés n'ont pas d'alternatives texte descriptives". Documenter ces points honnêtement construit la confiance de l'acheteur ; les cacher ressort dans l'audit propre de l'acheteur et tue le deal.

Mettez à jour avec chaque release majeure

Un snapshot ACR d'il y a 18 mois est pire qu'aucun ACR — il induit activement les acheteurs en erreur sur l'état actuel. Re-testez et republiez avec chaque release majeure d'UI.

Obtenez un audit externe pour les deals à fort enjeu

Pour les grands contrats gouvernementaux ou d'enseignement supérieur, les acheteurs peuvent exiger des ACR audités par tiers. Des cabinets spécialisés (Deque, Level Access, TPGi) auditent votre produit contre WCAG et produisent un ACR audité. Plus cher mais plus crédible.

Erreurs courantes d'ACR

• Revendiquer "Supports" sans tester. Les ACR pilotés par les ventes qui disent que tout fonctionne échouent aux audits acheteur et endommagent la réputation.
• Version VPAT obsolète. Les acheteurs s'attendent à VPAT 2.4 ou 2.5 ; soumettre un 2.0 de 2018 paraît négligent.
• Pas de remarques. Lister juste "Supports" sans explication ne fournit aucune information utile. Les acheteurs veulent savoir ce qui a été testé et comment.
• Traiter l'ACR comme du marketing. Un ACR est de la documentation de marché, pas une fiche commerciale. Honnête, technique, basé sur preuve.
• Oublier de mettre à jour. Les ACR obsolètes sont pires que les ACR manquants — ils représentent activement mal l'état actuel.
• Mélanger les plateformes. Si votre produit a une app web + app iOS + app Android + app desktop, chacune peut avoir besoin de son propre ACR (ou un combiné clairement segmenté).

FAQ : Accessibility Conformance Reports

Un ACR est-il la même chose qu'un VPAT ?

Étroitement liés mais techniquement différents. Le VPAT est le template (un formulaire vide). L'ACR est le document rempli (un VPAT complété pour un produit spécifique). En pratique les termes sont souvent utilisés de manière interchangeable — "envoie-moi ton VPAT" signifie habituellement "envoie-moi ton ACR".

Qui écrit l'ACR ?

Typiquement : un lead accessibilité interne ou product manager + des ingénieurs qui ont testé des fonctionnalités spécifiques + parfois un auditeur externe pour vérification. Les grandes entreprises ont des programmes dédiés d'accessibilité ; les plus petites embauchent souvent des spécialistes pour les missions VPAT.

Combien de temps faut-il pour écrire un ACR ?

Pour un petit produit : 2-4 semaines d'effort focalisé, principalement du temps de test. Pour une grande app entreprise : 2-3 mois y compris coordination avec les équipes produit, design et ingénierie. Les ACR audités prennent plus longtemps.

Combien coûte un audit externe ?

10 000-50 000+ $ selon la complexité du produit. Vaut la peine pour les contrats à forte valeur où les acheteurs exigent une vérification indépendante ou où la réputation compte.

Les outils automatisés peuvent-ils générer l'ACR ?

Non — les outils automatisés (axe, WAVE, Pa11y) attrapent peut-être 30-40% des problèmes d'accessibilité. Ils sont utiles pour scanner à l'échelle mais la crédibilité de l'ACR vient des tests manuels avec technologies d'assistance. Les outils augmentent les tests humains ; ils ne les remplacent pas.

Mon SaaS a-t-il besoin d'un ACR si on ne vend pas au gouvernement ?

Recommandé même sans clients gouvernementaux. Enseignement supérieur, entreprises Fortune 500 et clients UE (sous l'EAA depuis juin 2025) demandent de plus en plus des ACR. En avoir un publié sur votre site signale la disponibilité aux marchés et accélère les deals entreprise.

Comment LoadFocus se rapporte aux audits d'accessibilité

Pendant que LoadFocus se concentre sur la performance pas l'accessibilité, les audits d'accessibilité ont souvent aussi besoin de vérification de performance — les pages qui échouent les Core Web Vitals créent des problèmes d'accessibilité pour les utilisateurs sur des réseaux lents ou des appareils bas de gamme. Couplez votre travail VPAT/ACR avec des audits de vitesse LoadFocus à travers les régions pour valider des baselines de performance soutenant l'accessibilité (ex. assurer que les utilisateurs de lecteurs d'écran sur connexions 3G obtiennent toujours des temps raisonnables de chargement de page).