Auditer l’accessibilité d’un outil numérique avant de l’adopter

Distinguer repérage rapide, test de parcours et audit de conformité

Un repérage rapide cherche des obstacles évidents sur quelques pages : titre, structure, contraste, clavier, zoom, libellés et alternatives. Les Easy Checks du W3C sont conçus comme une première revue ; ils ne couvrent pas tous les problèmes et ne suffisent pas à conclure qu’un service est conforme.

Un test de parcours vérifie qu’un profil accomplit une tâche réelle dans des conditions déterminées. Il apporte une preuve d’utilisabilité bornée, précieuse pour une décision d’adoption, mais ne mesure pas à lui seul tous les critères d’un référentiel sur un échantillon représentatif.

Un audit formel définit le référentiel, la version, le périmètre, l’échantillon, les technologies et la méthode. Il examine chaque critère applicable, conserve les preuves et produit un taux ou un état selon les règles du cadre retenu. Écrivez toujours lequel de ces trois niveaux a réellement été réalisé.

Qualifier le cadre applicable avant de promettre une conformité

WCAG 2.2 est une recommandation technique internationale organisée autour de principes, recommandations et critères de succès. Le RGAA français fournit une méthode opérationnelle de vérification dans son champ. Une organisation peut aussi relever d’obligations sectorielles, contractuelles ou européennes différentes. Ces références sont liées, mais elles ne sont pas interchangeables.

Le champ dépend notamment de la nature de l’organisme, du service, du public et parfois de seuils ou d’exemptions. Depuis le 28 juin 2025, la transposition de la directive européenne sur l’accessibilité concerne certains produits et services, dont certains services de commerce électronique, avec des règles de transition et des exemptions. Une simple présence en ligne ne suffit pas à déduire le régime exact.

Avant la décision, consignez l’entité responsable, le service étudié, les utilisateurs visés, le territoire, la date, les contrats et l’avis juridique ou réglementaire obtenu si nécessaire. Même lorsqu’une obligation précise ne s’applique pas, les obstacles restent des risques d’exclusion, de support, de réputation et de continuité d’usage.

Partir des personnes, des tâches et des stratégies d’usage

Listez les profils réels : visiteur, client, agent, administrateur, intervenant externe ou bénéficiaire. Pour chacun, choisissez une tâche fréquente, une tâche critique et une situation d’erreur. Ne réduisez pas les besoins à une catégorie médicale ; notez aussi la stratégie d’usage : clavier seul, lecteur d’écran, agrandissement, commande vocale, sous-titrage, langage simplifié ou limitation des mouvements.

Les handicaps peuvent être permanents, temporaires ou situationnels. Un bras immobilisé, un écran ébloui, un environnement bruyant ou une connexion lente révèlent parfois les mêmes dépendances qu’un besoin durable. Cette observation n’efface pas l’expertise des personnes handicapées ; elle aide l’équipe à comprendre que l’accessibilité concerne le fonctionnement ordinaire du service.

Invitez des utilisateurs concernés quand le risque ou le périmètre le justifie. Leur test révèle la compréhension, l’effort, les stratégies et les contournements. Il complète l’évaluation technique sans la remplacer : une personne ne peut représenter tous les usages ni certifier seule un référentiel complet.

Construire un échantillon qui contient les états difficiles

L’échantillon ne se limite pas aux pages les plus visitées. Incluez l’accueil, la connexion, la récupération d’accès, la recherche, une liste, une fiche, un formulaire long, une erreur, une confirmation, un document, l’aide, les paramètres et le départ du service. Ajoutez les gabarits singuliers, les contenus riches et les composants tiers.

Pour une application, testez les états vides, chargés, lents, invalides, expirés et interdits. Ouvrez une modale, déclenchez une notification, utilisez un tableau, filtrez, changez de page et revenez en arrière. Les défauts surgissent souvent après une action alors qu’une analyse statique ne voit que l’état initial.

La méthodologie RGAA prévoit, pour un audit de site, un échantillon représentatif comprenant des pages obligatoires et des pages choisies selon le service. Pour une revue d’acquisition plus courte, documentez les écarts à cette méthode et interdisez-vous d’appeler le résultat un audit RGAA complet.

Fixer les environnements, versions et aides techniques

Notez système, navigateur, version de l’outil, taille d’écran, zoom, langue et technologie d’assistance. Les résultats doivent pouvoir être rejoués. Un échec observé dans une combinaison reste un fait ; il ne devient pas automatiquement une incompatibilité universelle.

Utilisez au moins les configurations annoncées comme supportées par le fournisseur et les environnements réellement déployés dans l’organisation. Si l’application mobile, le web adaptatif et un document exporté font partie de la promesse, chacun reçoit son contrôle propre.

Les outils automatiques accélèrent la détection de certains problèmes de code, mais ne comprennent pas l’intention, la qualité d’un texte alternatif, l’ordre logique ou la clarté d’une erreur. Conservez leur rapport comme indice, puis vérifiez manuellement le composant et le parcours.

Réaliser le parcours essentiel au clavier seul

Rangez la souris. Rechargez la page, puis utilisez Tab, Maj+Tab, Entrée, Espace, flèches et Échap selon le composant. Chaque action essentielle doit être atteignable et activable, sans piège qui retient le focus. L’ordre suit le sens visuel et la logique de la tâche.

Le focus reste visible sur tous les fonds et ne disparaît pas sous un bandeau fixe. Un lien d’évitement permet de contourner les blocs répétés. Les menus, onglets, listes déroulantes, calendriers, tableaux interactifs et éditeurs utilisent des commandes cohérentes avec leur rôle.

Dans une fenêtre modale, le focus entre au bon endroit, reste dans la boîte tant qu’elle est ouverte, puis retourne au déclencheur. Après suppression, ajout ou changement de page, il rejoint une position utile au lieu de repartir silencieusement en haut.

Agrandir sans perdre le contenu, l’action ou le contexte

Testez le zoom du navigateur jusqu’à 200 %, puis le réagencement attendu à forte amplification selon le critère visé. Le texte doit rester lisible sans chevauchement, troncature ni bouton caché. Une barre horizontale peut être légitime pour un plan, une carte ou un tableau complexe ; elle ne devrait pas être imposée à chaque paragraphe et formulaire.

Augmentez aussi l’espacement du texte avec une feuille ou un outil de test : hauteur de ligne, paragraphes, lettres et mots. Les cartes, boutons et champs doivent absorber l’agrandissement sans supprimer une information. Ne considérez pas une infobulle au survol comme unique moyen d’obtenir un libellé complet.

Sur écran étroit, vérifiez que le menu, les actions persistantes et les messages restent accessibles lorsque le clavier virtuel est ouvert. Une interface qui exige de dézoomer pour confirmer exclut précisément l’usage que le zoom devait permettre.

Vérifier structure, langue, titres et ordre de lecture

Chaque page possède un titre informatif et une langue principale correcte. Les changements de langue significatifs sont identifiés. Les titres forment un plan compréhensible sans dépendre de leur taille visuelle ; les listes, tableaux, citations et groupes de champs utilisent une structure correspondant à leur fonction.

Les régions principales — en-tête, navigation, contenu, complément et pied — permettent de se déplacer rapidement. Plusieurs navigations ou régions de même type reçoivent un nom distinct. Le contenu lu dans l’ordre du code conserve le sens de l’interface affichée.

Supprimez les instructions fondées uniquement sur la position ou l’apparence, comme “cliquez sur le bouton vert à droite”. Le nom visible d’une action doit correspondre au nom annoncé, afin qu’une personne utilisant la commande vocale puisse la cibler.

Contrôler nom, rôle, valeur et changement d’état au lecteur d’écran

Parcourez les titres, régions, liens, boutons et champs avec une technologie d’assistance représentative. Un contrôle doit annoncer un nom utile, son rôle, son état et sa valeur lorsque ces informations existent. Une icône seule, un faux bouton construit avec un élément neutre ou un lien intitulé “ici” rend l’action ambiguë.

Déclenchez les mises à jour dynamiques : recherche, ajout au panier, validation, erreur, progression, chargement et fin de traitement. L’information importante doit être annoncée sans déplacer le focus de façon inattendue ni relire toute la page.

Ne multipliez pas les attributs ARIA pour corriger une structure HTML inadéquate. Un élément natif bien choisi fournit souvent le clavier, le rôle et les états attendus. Quand un composant personnalisé est indispensable, testez son comportement complet, pas seulement son nom accessible.

Remplir, invalider, corriger et confirmer chaque formulaire

Chaque champ reçoit un libellé persistant relié techniquement. Le texte indicatif dans le champ ne remplace pas le libellé : il disparaît pendant la saisie et peut être peu contrasté. Les groupes de choix partagent une question, les formats attendus sont indiqués avant l’erreur et l’autocomplétion est utilisée lorsque le contexte le permet.

Soumettez le formulaire vide puis avec plusieurs valeurs invalides. Le résumé d’erreurs indique le nombre et permet de rejoindre chaque champ. À proximité du champ, le message explique le problème et la manière de le corriger ; couleur, icône ou contour peuvent renforcer ce texte sans être l’unique signal.

Pour une action juridique, financière ou difficile à annuler, vérifiez la possibilité de relire, corriger ou confirmer les données. Après validation, une confirmation explicite et retrouvable remplace la disparition silencieuse du formulaire. Le tutoriel formulaires du W3C fournit des modèles pour libellés, instructions, validation et notifications.

Tester contraste, couleur et perception des états

Mesurez le contraste du texte, des icônes utiles, des contours de champs et du focus selon le critère et la taille applicables. Testez les états normal, survolé, actif, sélectionné, désactivé et en erreur. Une capture du thème clair ne couvre pas le thème sombre ni les couleurs configurables.

Une couleur peut renforcer une information, mais pas la porter seule. Ajoutez texte, symbole, motif ou position explicite aux statuts, graphiques, disponibilités et erreurs. Vérifiez que le symbole est expliqué et que la légende reste lisible sans perception des couleurs.

Les images contenant du texte résistent mal au zoom, à la traduction et aux préférences de contraste. Réservez-les aux cas indispensables, fournissez une alternative et évitez d’y enfermer une instruction ou un prix qui devrait être du texte réel.

Donner aux images et icônes une alternative adaptée à leur fonction

Une image informative reçoit une alternative qui transmet l’information utile dans le contexte, pas une description mécanique de tous les pixels. Une image décorative est ignorée par les technologies d’assistance afin d’éviter le bruit. Une image-lien ou un bouton icône annonce l’action ou la destination.

Un graphique complexe demande une synthèse courte et un accès aux données ou à une description détaillée. La tendance, l’échelle, les unités et l’incertitude doivent être compréhensibles sans couleur seule. Une carte propose au besoin une recherche ou une liste exploitable indépendamment du geste cartographique.

Vérifiez les contenus ajoutés par les utilisateurs : l’outil permet-il de saisir une alternative, d’identifier une image décorative ou de publier une légende ? Une interface d’auteur inaccessible produit durablement des contenus inaccessibles même si son propre écran est conforme.

Évaluer audio, vidéo, animation et contenu temporel

Une vidéo préenregistrée importante dispose de sous-titres synchronisés et, selon le contenu et le niveau visé, d’une audiodescription ou d’une alternative équivalente. Un fichier audio propose une transcription. Le lecteur permet pause, reprise, volume et navigation au clavier sans démarrage sonore inattendu.

Les sous-titres automatiques sont relus : noms propres, nombres et vocabulaire métier sont des sources fréquentes d’erreur. La transcription identifie les locuteurs et les sons nécessaires à la compréhension, sans recopier des éléments purement décoratifs.

Les clignotements dangereux sont évités. Les carrousels, animations et mises à jour automatiques peuvent être arrêtés lorsqu’ils durent ou perturbent la lecture. La préférence de réduction des mouvements doit supprimer les transitions non essentielles sans rendre l’état incompréhensible.

Supprimer les délais inutiles et permettre la reprise

Repérez expirations de session, compte à rebours, réservations temporaires, quiz, notifications éphémères et renouvellements de code. Lorsque le délai n’est pas strictement nécessaire, la personne doit pouvoir le désactiver, l’ajuster ou le prolonger avant l’expiration.

Prévenez suffisamment tôt et expliquez l’effet de l’expiration. Une prolongation conserve la saisie déjà autorisée. Après reconnexion, le retour mène au bon contexte sans répéter une opération sensible ni exposer les données à un autre compte.

Mesurez le temps réel requis avec lecteur d’écran, agrandissement et navigation séquentielle. Un délai confortable à la souris peut devenir impossible lorsqu’il faut écouter chaque option ou zoomer plusieurs zones.

Tester tactile, orientation et adaptations mobiles

Les cibles tactiles doivent être suffisamment grandes ou espacées pour limiter les activations accidentelles selon le critère visé. Un geste complexe — pincement, glissement multipoint, dessin d’un trajet — possède une alternative simple lorsque ce geste n’est pas essentiel.

Testez portrait et paysage, sauf nécessité intrinsèque documentée. Le contenu ne doit pas disparaître lorsque l’appareil pivote. Les actions déclenchées au relâchement permettent d’annuler un contact commencé par erreur.

Vérifiez clavier externe, lecteur d’écran mobile, grossissement, ordre d’exploration et annonce des états. Une interface web correcte sur ordinateur peut échouer sur une couche native, un menu hamburger ou un sélecteur de date mobile.

Suivre le parcours à travers authentification, CAPTCHA et paiement tiers

L’organisation reste confrontée à l’obstacle même si le composant appartient à un fournisseur. Testez la bannière de consentement, la fédération d’identité, le CAPTCHA, le code à usage unique, la signature, le paiement, la carte et le support. Notez la frontière contractuelle sans arrêter le scénario à cette frontière.

L’authentification ne devrait pas imposer une épreuve cognitive sans alternative adaptée. Les gestionnaires de mots de passe, le collage et les mécanismes d’aide doivent fonctionner quand la sécurité le permet. Un code temporaire annonce sa durée et accepte une méthode de remplacement accessible.

Demandez au fournisseur la documentation de conformité, le périmètre audité, la date, les défauts connus et le plan de correction. Une déclaration commerciale ou un modèle volontaire d’accessibilité ne remplace pas le test du composant effectivement intégré et configuré.

Inclure PDF, exports, e-mails et documents téléchargés

Un parcours peut se terminer par un contrat PDF, une facture, un billet, un rapport ou un message électronique. Ouvrez ces sorties avec clavier et lecteur d’écran. Vérifiez titre, langue, ordre de lecture, titres, listes, tableaux, liens, alternatives, champs et protection compatible avec l’usage prévu.

Un PDF image issu d’un scan ne devient pas accessible parce que le texte semble visible. La reconnaissance de caractères aide, mais la structure, les libellés et l’ordre doivent encore être contrôlés. Lorsque le document n’est pas indispensable, une version HTML bien structurée peut offrir un accès plus robuste.

Testez aussi l’outil de génération. Les modèles, styles et contrôles doivent aider l’auteur à produire un résultat accessible. Un export corrigé manuellement après chaque émission n’est pas une solution durable pour un document fréquent.

Décrire chaque défaut par une preuve reproductible

Une fiche de défaut indique page ou écran, version, environnement, profil, état initial, étapes, résultat observé, résultat attendu, critère ou règle associée et preuve courte. Elle ne contient ni secret ni donnée personnelle réelle. Une vidéo peut montrer un comportement, mais du texte reste nécessaire pour rechercher et rejouer le cas.

Classez la priorité selon l’impact sur la tâche, le nombre de profils, la fréquence et l’existence d’un contournement sûr. Un défaut qui bloque la connexion, la validation ou la récupération mérite une priorité supérieure à une gêne cosmétique, même s’il apparaît sur une page moins visitée.

Séparez non-conformité technique, obstacle d’usage, amélioration et question non tranchée. Cette distinction évite de minimiser un obstacle parce qu’aucun critère n’a encore été cité, ou d’annoncer une violation certaine sans analyse suffisante.

Corriger la cause puis rejouer le contrôle qui a échoué

Corrigez d’abord le composant partagé lorsque plusieurs écrans héritent du même défaut, mais vérifiez les variantes réellement utilisées. Un correctif de focus peut modifier l’ordre clavier ailleurs ; un texte ajouté peut créer un débordement au zoom. La portée du retest suit donc la portée technique du changement.

Rejouez le scénario exact, dans l’environnement exact, puis les parcours directement touchés. Conservez la preuve avant/après et l’identifiant de la version. Ne fermez pas un défaut parce que le code semble conforme ou qu’un outil automatique ne le détecte plus.

Quand la correction dépend d’un fournisseur, documentez le contournement accessible, l’échéance, le responsable et la condition de sortie. Un contournement caché dans le support ne rend pas le parcours principal équivalent ; il limite seulement le dommage temporaire.

Transformer les résultats en décision d’achat ou d’adoption

Définissez avant l’essai les obstacles rédhibitoires : impossibilité d’authentification, de saisir une demande, de corriger une erreur, d’effectuer une action métier ou de recevoir une preuve. Un score moyen ne doit pas masquer un blocage complet sur un parcours critique.

Pour chaque écart accepté temporairement, demandez une correction vérifiable, une date, un responsable, un accès au suivi et une conséquence contractuelle proportionnée. La feuille de route du fournisseur n’est pas une preuve tant que la version corrigée n’a pas été testée.

Prévoyez dans le contrat le référentiel et sa version, le périmètre, les livrables, la maintenance, le signalement, les délais de correction, l’accès aux audits, la responsabilité des composants tiers et la réversibilité. Les clauses doivent correspondre au service livré, pas à une offre générique du catalogue.

Publier une déclaration et un plan seulement sur un périmètre qualifié

Dans le champ du RGAA, la déclaration d’accessibilité s’appuie sur une évaluation effective et expose notamment l’état de conformité, les résultats, les contenus non accessibles, les dérogations éventuelles, les technologies, les environnements de test et les voies de contact. Ne publiez pas “totalement conforme” à partir d’un scan automatique ou d’un test de quelques pages.

Le schéma pluriannuel et les plans d’action décrivent la politique, la gouvernance, les ressources, la formation, les audits, la prise en compte des contenus et la programmation des améliorations lorsqu’ils sont requis. Ils doivent rester reliés à des responsables, échéances et preuves, pas devenir une liste d’intentions générale.

Le référentiel français évolue. Le site officiel indique que le RGAA 4.1.2 reste la version en vigueur et que la version 5 est prévue pour la fin de 2026. Cette évolution ne justifie pas de suspendre les corrections actuelles : conservez la version auditée, suivez la publication officielle et planifiez l’écart quand le nouveau référentiel devient applicable.

Maintenir l’accessibilité après la décision

Intégrez des contrôles aux composants, modèles, contenus et recettes ordinaires. Une nouvelle modale, une bibliothèque mise à jour, un thème, une traduction ou un fournisseur peut réintroduire un défaut. Les tests automatiques ciblés préviennent certaines régressions, mais les parcours manuels et les utilisateurs restent nécessaires.

Formez selon les rôles : conception, développement, achat, rédaction, support et contribution de documents n’ont pas les mêmes gestes. Donnez une procédure courte pour signaler un obstacle, le qualifier, répondre à la personne et prioriser la correction.

Réexaminez l’échantillon après changement majeur et selon la fréquence du cadre applicable. Mesurez surtout la fermeture des obstacles critiques, la durée de résolution et la réussite des parcours ; le nombre brut de tests exécutés n’est pas un résultat utilisateur.

Checklist avant de retenir un outil numérique

• Cadre, référentiel, version, périmètre et niveau de preuve nommés.
• Profils, aides techniques, tâches critiques et situations d’erreur définis.
• Échantillon incluant connexion, formulaires, états dynamiques, documents et tiers.
• Clavier, focus, zoom, reflow, structure et lecteur d’écran contrôlés.
• Erreurs, délais, mouvements, médias, couleur, tactile et orientation vérifiés.
• Authentification, CAPTCHA, paiement et composants externes testés de bout en bout.
• Chaque blocage possède une preuve, une sévérité, un responsable et un retest prévu.
• Les promesses contractuelles correspondent à la version et au service réellement évalués.
• Déclaration ou plan publiés uniquement si leur champ et leurs preuves sont qualifiés.
• Maintenance, signalement et participation des utilisateurs prévus après l’adoption.

Limites et responsabilité éditoriale

Ce guide propose une méthode de préparation et de décision. Il ne certifie aucun outil, ne couvre pas toutes les situations de handicap et ne constitue pas un conseil juridique. Les pages officielles, le référentiel complet, sa méthodologie et les textes applicables priment pour une évaluation de conformité.

Les sources ont été vérifiées le 20 septembre 2026. Les versions des référentiels, obligations, seuils, exemptions et calendriers peuvent évoluer. Contrôlez la date et le champ auprès de la source officielle avant de publier une déclaration, signer un marché ou conclure à une conformité.

La rédaction DOHM maintient ce contenu comme ressource indépendante d’un produit. Toute correction factuelle doit être reliée à une source de référence et datée lors de la prochaine révision.