Développement accessible : éviter les régressions

Résumer le contenu avec l’IA :

L’accessibilité numérique ne se joue pas uniquement au moment de l’audit RGAA. Elle se construit, se teste et se maintient tout au long du projet web. Pour une collectivité ou une destination touristique, le vrai risque n’est pas seulement de découvrir des non-conformités en fin de projet. Le risque le plus fréquent est de corriger une fois, puis de voir les mêmes erreurs revenir quelques semaines plus tard lors d’une évolution, d’une mise à jour ou d’un nouveau développement.

Un formulaire de contact corrigé peut redevenir inaccessible après l’ajout d’un champ. Un menu testé au clavier peut être dégradé par une nouvelle version du thème. Une page de réservation touristique peut perdre sa cohérence si un script tiers modifie l’ordre de tabulation. Une carte interactive peut être mise en ligne sans alternative textuelle. Ces régressions ne sont pas toujours spectaculaires, mais elles peuvent empêcher un usager, un citoyen ou un visiteur de finaliser une démarche essentielle.

C’est précisément pour éviter cette situation que les critères d’acceptation et la Definition of Done deviennent indispensables. Ils permettent de transformer les exigences d’accessibilité en règles de livraison concrètes, compréhensibles et vérifiables. L’objectif n’est pas de demander à chaque développeur de devenir auditeur RGAA. L’objectif est plus réaliste : faire en sorte qu’une fonctionnalité ne soit pas considérée comme terminée tant que les points d’accessibilité essentiels n’ont pas été contrôlés.

Pourquoi les régressions d’accessibilité sont si fréquentes ?

Dans beaucoup de projets web, l’accessibilité est traitée comme une étape finale. On réalise une refonte, on produit des maquettes, on développe, on recette, puis un audit vient mesurer le niveau de conformité. Cette logique peut sembler rationnelle, mais elle crée un problème : l’accessibilité arrive trop tard dans la chaîne de production.

Lorsqu’une anomalie est détectée à la fin, sa correction coûte souvent plus cher. Il faut reprendre le composant, modifier le design, ajuster le HTML, corriger les scripts, revalider le comportement au clavier et parfois réviser la logique fonctionnelle. Dans une collectivité ou un office de tourisme, ces reprises se heurtent vite à des contraintes de planning, de budget ou de disponibilité du prestataire.

Les régressions apparaissent aussi parce qu’un site web n’est jamais figé. Après la mise en ligne, les équipes publient de nouvelles pages, ajoutent des documents PDF, créent des actualités, intègrent des vidéos, installent des modules, modifient des formulaires ou lancent des campagnes événementielles. Chaque intervention peut introduire une nouvelle barrière.

Pour une destination touristique, cela peut concerner une page d’agenda, une fiche randonnée, un module de réservation, un moteur de recherche d’hébergements ou une carte des points d’intérêt. Pour une collectivité, cela peut toucher une démarche administrative, une inscription scolaire, une demande de rendez-vous ou un formulaire de signalement. Dans tous les cas, les parcours concernés sont souvent des parcours utiles, voire indispensables.

La prévention des régressions repose donc sur une idée simple : l’accessibilité doit être intégrée aux conditions de livraison, et non vérifiée uniquement après coup.

Qu’est-ce qu’un critère d’acceptation en accessibilité ?

Un critère d’acceptation décrit les conditions à remplir pour considérer qu’une fonctionnalité répond au besoin attendu. Dans un projet agile, il sert à vérifier qu’une user story est réellement terminée. Dans un projet plus classique, il peut être intégré à un cahier de recette, à une spécification fonctionnelle ou à un procès-verbal de validation.

En accessibilité, un critère d’acceptation traduit une exigence générale en vérification concrète. Il ne suffit pas d’écrire : « Le formulaire doit être conforme au RGAA. » Cette formulation est trop large pour guider efficacement un développeur, un chef de projet ou une équipe de recette. Un bon critère d’acceptation doit être observable, testable et lié à une fonctionnalité précise.

Pour un formulaire, un critère plus utile serait : « Chaque champ possède un libellé visible et correctement associé dans le code ; les erreurs sont indiquées textuellement ; le formulaire peut être rempli et envoyé au clavier ; le message de confirmation est perceptible par les technologies d’assistance. ».

Cette formulation permet de savoir quoi vérifier. Elle donne aussi une base de dialogue entre le prestataire, le chef de projet et le référent accessibilité. Elle évite les interprétations floues du type « on verra à l’audit » ou « l’outil automatique ne remonte rien, donc c’est bon ».

Un critère d’acceptation accessibilité ne remplace pas le RGAA. Il sert à rendre le RGAA exploitable dans le quotidien du projet.

Definition of Done : pourquoi l’accessibilité doit en faire partie

La Definition of Done, souvent appelée DoD, correspond à la définition commune de ce qui permet de considérer un développement comme terminé. Elle formalise les conditions minimales de livraison. Par exemple : le code est relu, les tests sont passés, la documentation est mise à jour, la fonctionnalité est validée en recette.

Si l’accessibilité n’est pas intégrée à cette définition, elle devient secondaire. Elle dépend alors de la sensibilité d’une personne, de la disponibilité d’un expert ou d’un audit réalisé plus tard. C’est une fragilité organisationnelle.

Dans un projet accessible, la Definition of Done devrait intégrer des exigences simples mais systématiques. Une fonctionnalité ne devrait pas être close si elle n’est pas utilisable au clavier, si le focus n’est pas visible, si les champs de formulaire ne sont pas correctement nommés ou si les messages d’erreur ne sont pas compréhensibles.

Cette logique est particulièrement utile pour les collectivités et destinations touristiques, car leurs dispositifs numériques reposent souvent sur plusieurs intervenants. Une agence conçoit le site, un autre prestataire assure la maintenance, des agents publient les contenus, des modules tiers sont ajoutés au fil du temps. Sans règle commune, chacun peut penser que l’accessibilité relève de quelqu’un d’autre.

La Definition of Done évite cette dilution des responsabilités. Elle ne dit pas seulement « il faut faire de l’accessibilité ». Elle indique à quel moment, par qui et selon quelles conditions un développement peut être livré.

Transformer le RGAA en critères utilisables par les équipes projet

Le RGAA constitue le référentiel français de référence pour évaluer l’accessibilité numérique. Mais dans un projet opérationnel, il peut sembler dense pour des équipes non expertes. Le rôle d’un chef de projet, d’un AMO ou d’un référent accessibilité consiste alors à traduire ce référentiel en exigences projet.

Cette traduction doit rester fidèle au référentiel, sans le simplifier à l’excès. Il ne s’agit pas de créer un « mini-RGAA » approximatif. Il s’agit d’identifier les critères applicables à une fonctionnalité et de les exprimer sous forme de conditions de recette.

Prenons l’exemple d’un menu principal. Les points à vérifier ne concernent pas uniquement son apparence. Il faut contrôler que le menu est atteignable au clavier, que chaque élément reçoit le focus dans un ordre logique, que les sous-menus peuvent être ouverts et fermés sans souris, que le focus reste visible et que le comportement est compréhensible avec une technologie d’assistance.

Pour une modale, les critères seront différents. Il faudra vérifier que le focus est envoyé dans la fenêtre à son ouverture, qu’il ne part pas derrière la modale, qu’un bouton permet de fermer la fenêtre, que la touche Échap fonctionne si ce comportement est prévu, et que le focus retourne à l’élément déclencheur après fermeture.

Pour un formulaire, l’attention portera sur les libellés, les aides à la saisie, les erreurs, les champs obligatoires et les confirmations. Pour une carte touristique, l’enjeu sera de prévoir une alternative équivalente pour les personnes qui ne peuvent pas utiliser l’interaction visuelle ou la souris.

Le principe est toujours le même : partir de l’usage réel, puis rattacher cet usage aux exigences d’accessibilité.

Exemple de Definition of Done accessibilité

Une Definition of Done accessibilité doit rester assez courte pour être utilisée, mais assez précise pour éviter les angles morts. Elle peut varier selon la maturité de l’équipe, le type de site et le niveau de criticité des parcours. Pour un site de collectivité ou de destination touristique, une base réaliste pourrait être la suivante :

Une fonctionnalité peut être considérée comme terminée lorsque les éléments interactifs sont utilisables au clavier, que le focus est visible, que l’ordre de navigation est logique, que les libellés et noms accessibles décrivent correctement les actions, que les messages d’erreur et de confirmation sont compréhensibles, que l’information ne dépend pas uniquement de la couleur, que les contrastes ont été contrôlés, que les images porteuses d’information disposent d’une alternative pertinente, que les tests automatiques ne remontent pas d’erreur critique et qu’une vérification manuelle minimale a été réalisée.

Cette définition ne garantit pas à elle seule une conformité RGAA complète. Elle constitue plutôt un filet de sécurité. Elle permet de réduire les défauts les plus fréquents avant la livraison. Elle limite également l’accumulation de dette accessibilité, c’est-à-dire l’ensemble des problèmes qui devront être corrigés plus tard, souvent dans l’urgence.

Il est préférable d’avoir une Definition of Done simple, réellement utilisée à chaque livraison, plutôt qu’une checklist très complète mais jamais appliquée. L’accessibilité progresse rarement grâce à des documents théoriques. Elle progresse lorsque les règles sont intégrées aux gestes quotidiens du projet.

Des critères d’acceptation par type de fonctionnalité

Toutes les fonctionnalités ne présentent pas les mêmes risques. Une page éditoriale, un formulaire, un menu, un accordéon, une carte interactive ou un moteur de recherche ne mobilisent pas les mêmes vérifications. Il est donc utile de préparer des critères types par famille de composants.

Pour un formulaire administratif ou touristique, les critères d’acceptation doivent porter sur les libellés, les champs obligatoires, les aides à la saisie, les messages d’erreur et la confirmation d’envoi. Un usager doit pouvoir comprendre ce qui est attendu, corriger ses erreurs et finaliser sa demande sans perdre les informations déjà saisies. Ce point est essentiel pour les démarches publiques, mais aussi pour les demandes de documentation, les inscriptions à une visite ou les formulaires de réservation.

Pour un menu de navigation, la vérification doit porter sur l’usage au clavier, l’ordre de tabulation, la visibilité du focus et la cohérence des intitulés. Le menu ne doit pas devenir un piège. L’utilisateur doit pouvoir entrer, parcourir les choix et sortir du menu sans difficulté.

Pour les composants dynamiques, l’attention doit être renforcée. Les modales, accordéons, onglets, carrousels, filtres et autocomplétions sont souvent sources de régressions. Ils peuvent sembler fonctionnels à la souris tout en étant inutilisables au clavier ou incompréhensibles avec un lecteur d’écran. Chaque état doit être correctement restitué : ouvert, fermé, sélectionné, désactivé, développé ou réduit.

Pour les contenus éditoriaux, les critères concernent la hiérarchie des titres, les liens explicites, les alternatives d’images, les vidéos sous-titrées et les documents téléchargeables. Dans une collectivité ou un office de tourisme, ce point est particulièrement sensible, car les contenus sont souvent publiés par plusieurs contributeurs. Une page techniquement accessible peut devenir problématique si le contenu ajouté ne respecte pas les règles de base.

Enfin, pour les pages à fort enjeu, les critères doivent être renforcés. Une page de démarche administrative, une page « accessibilité », une fiche d’établissement, une page de transport, un agenda ou une page de réservation doit faire l’objet de contrôles plus poussés. Toutes les pages n’ont pas le même impact, mais les pages critiques doivent être surveillées avec rigueur.

Exemple de matrice de recette accessibilité

Pour faciliter le travail des équipes, il est utile de créer une matrice de recette. Cette matrice peut être intégrée dans un tableur, un outil de gestion de projet ou un modèle de ticket.

Zone à contrôler	Question de recette	Type de vérification
Navigation clavier	Peut-on atteindre et activer tous les éléments interactifs sans souris ?	Test manuel
Focus	Le focus est-il visible et placé dans un ordre logique ?	Test manuel
Structure HTML	Les titres, boutons, listes, champs et tableaux sont-ils balisés selon leur rôle réel ?	Inspection du code
Formulaires	Les champs disposent-ils de libellés, d’aides et de messages d’erreur accessibles ?	Test manuel et lecteur d’écran
Composants dynamiques	Les changements d’état sont-ils perceptibles par les technologies d’assistance ?	Test manuel spécialisé
Couleurs	L’information ne dépend-elle pas uniquement de la couleur ?	Revue visuelle
Contrastes	Les contrastes texte / fond sont-ils suffisants ?	Outil de mesure
Images	Les images porteuses d’information ont-elles une alternative pertinente ?	Revue éditoriale
Médias	Les vidéos disposent-elles de sous-titres ou de transcriptions lorsque nécessaire ?	Revue de contenu
Responsive et zoom	Le parcours reste-t-il utilisable en mobile et avec agrandissement ?	Test manuel

Cette matrice ne doit pas être perçue comme une contrainte administrative supplémentaire. Elle sert à rendre la recette plus fiable. Elle permet aussi de conserver une trace des contrôles réalisés, ce qui facilite les échanges avec les prestataires et les arbitrages internes.

Intégrer les critères d’acceptation dans les marchés publics et les refontes

Dans un projet public ou institutionnel, l’accessibilité doit être cadrée dès le marché. Il ne suffit pas d’indiquer dans un CCTP que le site devra respecter le RGAA. Cette mention est nécessaire, mais elle reste insuffisante si elle n’est pas accompagnée de modalités concrètes de contrôle.

Les critères d’acceptation peuvent être intégrés dans les spécifications fonctionnelles, les exigences de recette, les livrables attendus et les clauses de maintenance. Par exemple, le marché peut demander que chaque composant livré soit documenté avec ses comportements clavier, ses états, ses règles de nommage accessible et les tests réalisés.

Cette exigence évite une accessibilité « cosmétique », présente dans le discours commercial mais absente de la production réelle. Elle permet aussi de mieux objectiver la relation avec le prestataire. Une fonctionnalité n’est pas validée parce qu’elle « semble fonctionner », mais parce qu’elle respecte des critères définis à l’avance.

Pour les collectivités, ce cadrage est particulièrement utile lors des refontes de sites municipaux, intercommunaux ou départementaux. Pour les destinations touristiques, il l’est tout autant lors de la création d’un site de destination, d’un portail d’activités, d’un espace pro ou d’un dispositif de réservation.

L’enjeu n’est pas de complexifier le marché. L’enjeu est de clarifier les responsabilités et les preuves attendues.

Organiser la recette sans bloquer le projet

Une objection revient souvent : « Si l’on teste tout, le projet va prendre trop de temps. » Cette crainte est compréhensible, mais elle repose sur une mauvaise représentation de la démarche. Intégrer l’accessibilité dans la recette ne signifie pas réaliser un audit complet à chaque ticket.

Une organisation réaliste repose sur trois niveaux.

Le premier niveau correspond aux tests automatiques. Ils permettent d’identifier rapidement certaines erreurs : absence d’alternative, contraste insuffisant, mauvaise structure, attribut manquant, problème de nom accessible. Ces tests sont utiles, mais ils ne suffisent jamais.

Le deuxième niveau correspond aux tests manuels ciblés. Ils vérifient les points que les outils ne peuvent pas interpréter correctement : navigation clavier, pertinence des alternatives, logique du focus, compréhension des messages, cohérence du parcours.

Le troisième niveau correspond aux audits périodiques. Ils permettent d’évaluer plus largement la conformité du site, sur un échantillon représentatif de pages et de fonctionnalités. Ces audits restent nécessaires, mais ils sont plus efficaces lorsque les équipes ont déjà limité les erreurs en amont.

Cette organisation évite de choisir entre rapidité et qualité. Elle permet surtout de corriger plus tôt, donc plus simplement.

Le rôle des différents acteurs dans la prévention des régressions

L’accessibilité ne peut pas reposer uniquement sur le développeur. Elle dépend d’une chaîne d’acteurs.

Le chef de projet doit intégrer les exigences dans les tickets, vérifier que les critères sont bien pris en compte et arbitrer les priorités. Il joue un rôle central, car il relie les besoins métiers, les contraintes techniques et les obligations réglementaires.

Le designer doit prévoir des composants lisibles, cohérents et utilisables. Les contrastes, les états de focus, les messages d’erreur, les variations d’état et les comportements des composants doivent être pensés dès la maquette.

Le développeur doit produire un code robuste, utiliser le HTML de manière sémantique, éviter les surcharges ARIA inutiles, contrôler les interactions clavier et tester les composants dynamiques. Il doit aussi documenter ce qui est livré.

Le contributeur éditorial doit respecter les règles de contenu : titres structurés, liens explicites, alternatives pertinentes, documents accessibles, langage clair. Dans les sites publics et touristiques, cette contribution éditoriale est déterminante.

Le référent accessibilité ou l’AMO doit sécuriser la méthode. Il aide à transformer le RGAA en règles projet, accompagne les équipes, relit les critères sensibles et organise les contrôles périodiques.

Cette répartition évite que l’accessibilité soit vécue comme un sujet isolé. Elle devient une compétence collective.

Comment maintenir l’accessibilité après la mise en ligne ?

La mise en ligne n’est pas la fin du sujet. Elle marque plutôt le début de la maintenance accessibilité. Un site conforme peut se dégrader rapidement si aucune routine n’est prévue.

Les causes sont multiples : publication de nouveaux contenus, ajout de documents PDF, installation de plugins, intégration de scripts de réservation, modification d’un thème, ajout d’une vidéo, création d’une campagne événementielle. Chaque évolution doit être regardée comme une occasion possible de régression.

Pour limiter ce risque, il est utile de mettre en place un contrôle trimestriel des pages critiques. Ce contrôle peut porter sur les parcours les plus importants : accueil, contact, recherche, démarches, réservation, agenda, accessibilité, informations pratiques. Il ne remplace pas un audit complet, mais il permet de détecter tôt les erreurs visibles.

Il est également recommandé de tenir un backlog accessibilité. Chaque anomalie identifiée doit être documentée, priorisée et suivie. Les anomalies bloquantes doivent être corrigées rapidement, surtout lorsqu’elles empêchent l’accès à un service ou à une information essentielle.

Enfin, la formation des contributeurs reste un levier majeur. Beaucoup de régressions viennent des contenus : mauvais niveaux de titres, liens non explicites, images sans alternative, PDF non accessibles, tableaux mal structurés. Une courte formation peut éviter un grand nombre d’erreurs répétitives.

Quels indicateurs suivre pour piloter la qualité accessibilité ?

Les indicateurs ne doivent pas servir à produire un reporting décoratif. Ils doivent aider à piloter les efforts. Pour une collectivité ou une destination touristique, quelques indicateurs simples peuvent déjà améliorer la situation.

Il est possible de suivre le nombre de régressions détectées à chaque mise en production, le nombre de tickets bloqués pour motif accessibilité, le délai moyen de correction des anomalies critiques, le nombre de composants documentés, le pourcentage de pages critiques contrôlées chaque trimestre ou encore l’évolution du taux de conformité lors des audits.

Ces indicateurs permettent de sortir d’une approche uniquement déclarative. Ils montrent si l’accessibilité progresse réellement dans le temps. Ils permettent aussi de mieux dialoguer avec les élus, les directions, les prestataires et les équipes internes.

Le plus important reste de distinguer les indicateurs de production et les indicateurs de conformité. Les premiers servent à éviter les régressions au quotidien. Les seconds servent à mesurer le niveau global du site. Les deux sont complémentaires.

Une méthode pragmatique pour les collectivités et destinations touristiques

Les collectivités et destinations touristiques n’ont pas toujours les moyens de mettre en place une organisation très sophistiquée. Ce n’est pas une raison pour attendre. Une démarche simple peut déjà produire des effets concrets.

La priorité consiste à identifier les parcours critiques. Pour une mairie, il peut s’agir des démarches administratives, de la prise de contact, des actualités importantes et des formulaires. Pour un office de tourisme, il peut s’agir de la recherche d’hébergement, de l’agenda, des fiches d’activités, des informations d’accès et des demandes de documentation.

Ensuite, il faut définir une checklist courte pour ces parcours. Cette checklist doit couvrir les points essentiels : clavier, focus, libellés, erreurs, contrastes, alternatives, structure des titres, liens explicites et documents. Elle peut être utilisée à chaque évolution.

Enfin, il faut désigner une personne responsable du suivi. Cette personne n’a pas besoin d’être experte RGAA dès le départ. Elle doit surtout être capable de porter la méthode, d’organiser les contrôles et de faire remonter les arbitrages nécessaires.

Cette approche progressive est souvent plus efficace qu’un grand plan inaccessible à mettre en œuvre. L’accessibilité numérique se maintient par des habitudes, pas seulement par des audits.

Conclusion : une fonctionnalité inaccessible n’est pas terminée

Le développement accessible repose sur une idée simple : une fonctionnalité ne peut pas être considérée comme terminée si elle exclut une partie des utilisateurs. Pour éviter les régressions, cette idée doit être traduite dans les critères d’acceptation, la Definition of Done, les tickets de développement, la recette et la maintenance.

Pour les collectivités et destinations touristiques, cette démarche présente un double avantage. Elle sécurise les parcours essentiels pour les citoyens, les visiteurs et les professionnels. Elle permet aussi de mieux piloter les prestataires, en s’appuyant sur des critères concrets plutôt que sur des intentions générales.

L’accessibilité ne doit pas être un correctif permanent. Elle doit devenir une condition normale de livraison. C’est à cette condition qu’un site peut rester utilisable, robuste et conforme dans la durée.

FAQ

Qu’est-ce qu’une Definition of Done accessibilité ?

Une Definition of Done accessibilité est une liste de conditions minimales à respecter avant de considérer une fonctionnalité comme terminée. Elle inclut par exemple la navigation clavier, le focus visible, les libellés accessibles, les messages d’erreur compréhensibles, les contrastes suffisants et les tests manuels nécessaires.

Quelle différence entre un critère RGAA et un critère d’acceptation ?

Un critère RGAA appartient au référentiel officiel d’accessibilité numérique. Un critère d’acceptation traduit cette exigence dans le contexte d’une fonctionnalité précise. Il permet à l’équipe projet de vérifier concrètement si un formulaire, un menu, une modale ou une page respecte les exigences attendues.

Les tests automatiques suffisent-ils pour éviter les régressions ?

Non. Les tests automatiques sont utiles pour détecter certaines erreurs, mais ils ne couvrent pas toute l’expérience utilisateur. La navigation clavier, la logique du focus, la pertinence des alternatives, la compréhension des messages ou l’usage avec lecteur d’écran nécessitent des vérifications manuelles.

Faut-il intégrer des critères d’accessibilité dans tous les tickets ?

Il faut au minimum intégrer des critères d’accessibilité dans tous les tickets qui créent ou modifient une interface utilisateur. Cela concerne les formulaires, menus, composants dynamiques, pages éditoriales, moteurs de recherche, cartes interactives, tunnels de réservation et documents publiés.

Comment appliquer cette méthode avec un budget limité ?

La meilleure approche consiste à prioriser les parcours critiques, à utiliser une checklist courte, à tester systématiquement les composants récurrents et à former les contributeurs sur les erreurs les plus fréquentes. Cette méthode limite les corrections tardives, souvent plus coûteuses.

Qui doit valider les critères d’acceptation accessibilité ?

La validation doit être partagée. Le développeur vérifie les aspects techniques, le chef de projet contrôle la recette, le contributeur sécurise les contenus, et le référent accessibilité ou l’AMO vérifie les points sensibles. L’accessibilité est plus fiable lorsqu’elle repose sur une responsabilité collective.

Comment éviter les régressions après la mise en ligne ?

Il faut prévoir des contrôles réguliers, suivre les anomalies dans un backlog, tester les composants critiques avant chaque mise en production et former les équipes éditoriales. Une vérification trimestrielle des pages stratégiques permet déjà de détecter une grande partie des régressions courantes.

Développement accessible : critères d’acceptation pour éviter les régressions