Se connecter | Créer un compte

Blog/Accessibilité RGAA, Guide

Logiciel RGAA : les critères à vérifier avant de choisir votre solution

Quels résultats demander à un logiciel RGAA avant de s’équiper ? Une grille de comparaison, un scénario de démonstration et une méthode pour examiner le coût d’usage.
Partagez cet article

Recevez notre newsletter

abo newsletter compact FR

Un logiciel RGAA doit vous aider à identifier les obstacles, à préparer les corrections et à vérifier leur résolution. Pour le choisir, demandez des résultats que votre équipe peut examiner et utiliser : ce qui a été contrôlé, sur quelles pages, avec quelle méthode, et ce qu’il reste à valider.

Que vous soyez responsable digital, référent accessibilité ou directeur technique, votre décision engage aussi du temps de travail. Une solution intéressante sur le papier doit trouver sa place entre vos équipes, vos prestataires et vos mises en production. Voici une méthode pour comparer les offres, préparer une démonstration et décider sur des éléments concrets.

1. Définir le travail que vous voulez faciliter

Avant de comparer les logiciels, rédigez une demande courte : les services concernés, les parcours importants, les personnes qui examineront les résultats et celles qui corrigeront le site. Précisez la fréquence de vos évolutions et les difficultés actuelles : contrôles trop longs, résultats difficiles à interpréter, corrections peu vérifiées ou informations dispersées.

Ajoutez les particularités qui peuvent changer le choix : espace connecté, formulaire en plusieurs étapes, contenus dynamiques, documents téléchargeables, environnement de recette. Demandez ensuite au fournisseur de préciser ce que sa solution peut effectivement évaluer dans ce contexte et les conditions nécessaires pour y accéder.

Pour une évaluation de conformité, le RGAA prévoit un échantillon représentatif du service, comprenant notamment les étapes des processus. La liste de pages utilisée pendant une démonstration commerciale sert à essayer le produit ; elle ne constitue pas automatiquement cet échantillon.

2. Demander une couverture explicite des contrôles

La question utile est : « Pour mon périmètre, que vérifiez-vous et comment le résultat est-il établi ? » Un nombre de pages analysées, de règles exécutées ou d’anomalies détectées décrit des choses différentes. Demandez la version du référentiel utilisée, la correspondance avec ses critères et tests, ainsi que les limites du contrôle.

Le référentiel détaille des tests associés à chaque critère. Vérifier une seule condition ne permet pas nécessairement de conclure sur tout le critère. Par exemple, constater qu’une image possède une alternative textuelle ne suffit pas à établir que cette alternative restitue correctement son information dans la page.

Pour comparer deux solutions, demandez de distinguer trois éléments :

  • les contrôles exécutés automatiquement et leur résultat ;
  • les appréciations ou vérifications que votre équipe doit compléter ;
  • les contenus ou situations qui n’ont pas pu être évalués.

Le W3C rappelle que certains tests nécessitent une intervention humaine. Un logiciel utile rend cette répartition compréhensible. Un point non vérifié doit rester identifiable jusqu’à sa résolution ; il ne doit pas être interprété comme un résultat favorable.

3. Vérifier que le résultat peut devenir une correction

Choisissez un problème dans la démonstration et demandez à votre développeur, intégrateur ou responsable de contenu ce qu’il en comprend. Peut-il retrouver la page, l’état concerné et l’élément à examiner ? Sait-il quelle règle est en jeu et comment vérifier la correction ?

Cette lecture à deux révèle le travail qui restera à votre charge. Une anomalie compréhensible doit permettre d’organiser une action, d’identifier qui peut la traiter et de définir une vérification finale. Demandez également comment conserver le raisonnement lorsqu’un résultat nécessite une appréciation ou une précision.

La fiabilité se regarde aussi dans le temps. Pour des contrôles déterministes, refaites un essai avec le même contenu, le même état de page, le même environnement, le même périmètre et la même version du moteur. Les résultats doivent être reproductibles. Si un résultat évolue, vous devez pouvoir examiner ce qui a changé avant d’en déduire un progrès ou une régression.

4. Utiliser une grille commune pour comparer les offres

Adressez les mêmes questions à chaque fournisseur. Complétez la dernière colonne avec une réponse écrite, une observation pendant la démonstration ou un point restant à vérifier. Les exigences ci-dessous sont une grille d’achat à adapter à votre organisation.

De la promesse commerciale à la preuve attendue
Point à comparerQuestion à poserÉlément à obtenir
PérimètreNos pages et leurs différents états peuvent-ils être évalués ?Conditions d’accès, limites et essai pertinent.
CouvertureQuels critères et tests sont traités, et de quelle manière ?Correspondance documentée et validations à compléter.
RésultatsNotre équipe sait-elle retrouver et analyser un problème ?Résultat examiné avec la personne qui corrigera.
RecontrôleComment vérifier une correction et comparer les résultats ?Essai avant et après, avec contexte documenté.
Prise en mainQui prépare, lance, examine et complète les contrôles ?Répartition des tâches et accompagnement prévu.
DonnéesQuelles informations sont traitées et dans quelles conditions ?Documentation sur les accès, la conservation et l’hébergement.
BudgetQu’est-ce qui fait évoluer le prix ?Devis précisant périmètre, limites, services et engagement.
Fin de contratComment conserver les informations utiles à notre démarche ?Modalités prévues et données effectivement récupérables.

Le guide du W3C consacré au choix des outils complète cette réflexion selon les utilisateurs, les produits évalués et les environnements de travail. Pour votre décision, classez chaque besoin comme indispensable, utile ou secondaire. Une fonction indispensable non vérifiée doit rester un point à résoudre avant l’achat.

5. Préparer une démonstration qui permet de décider

Proposez un scénario précis au fournisseur. Choisissez quelques pages représentatives de votre besoin, dans un environnement autorisé, avec des données de test. Convenez à l’avance des accès nécessaires et des actions permises.

  1. Définir le périmètre. Notez les pages, les états à atteindre et les éléments effectivement évalués.
  2. Examiner les résultats. Retrouvez un contrôle automatique, une validation à compléter et la façon de traiter une situation non évaluée.
  3. Préparer une correction. Demandez à votre équipe d’expliquer le problème et le résultat attendu à partir des informations présentées.
  4. Recontrôler. Après une modification autorisée en recette, refaites la vérification dans le même contexte. Si cette étape demande une seconde séance, planifiez-la.
  5. Mesurer le travail restant. Relevez le temps de préparation, d’analyse et de validation humaine, ainsi que l’aide nécessaire.

Il s’agit d’un protocole d’essai à convenir, sans présumer des fonctions de chaque solution. Il permet de répondre à une question d’achat simple : votre équipe dispose-t-elle des informations et des moyens nécessaires pour utiliser le logiciel régulièrement ?

6. Comparer le coût d’usage sur une année

Demandez un chiffrage correspondant à votre périmètre et à votre rythme de contrôle. Ajoutez au prix du logiciel la prise en main, la préparation des évaluations, l’examen des résultats et les validations complémentaires. Distinguez aussi le budget de correction du site : identifier un problème et le résoudre mobilisent des tâches différentes.

Pour estimer un gain de temps, comparez la même opération, sur le même périmètre et avec un niveau de validation comparable. Notez les hypothèses et les observations de l’essai. Vous pourrez ainsi établir votre propre estimation, puis la vérifier après le démarrage. Notre article sur le budget RGAA et le suivi sur douze mois détaille les postes à examiner.

Comment examiner appYaccess avec cette méthode ?

appYaccess est conçu pour automatiser une grande partie des vérifications RGAA, structurer les résultats et renouveler les contrôles. Les informations par page, critère et élément concerné, ainsi que les validations à compléter, constituent une base de travail pour vos équipes.

Pendant une démonstration, demandez à voir cette chaîne complète : comprendre un résultat, préparer la correction et organiser son recontrôle. Pour répartir les rôles, consultez notre guide sur l’évaluation RGAA en interne. Lorsque vous disposez aussi de données d’usage, elles peuvent aider à organiser les corrections selon leur gravité et les parcours concernés.

Voyez si appYaccess répond à votre besoin

Présentez votre périmètre et vos contraintes. Nous vous montrerons les contrôles, les résultats exploitables par votre équipe et les validations à compléter pour avancer dans votre démarche.

Demander une démonstration d’appYaccess

Sources et repères