Refonte web : intégrer l’accessibilité avant la recette

Mis à jour le 1er octobre 2026 · Rédaction : Plein Accès

Définir l’exigence avant les maquettes

Une refonte donne l’occasion de modifier les causes partagées des obstacles. Elle peut aussi introduire des défauts si l’accessibilité n’est examinée qu’après livraison. Commencez par décrire les fonctions que les utilisateurs doivent accomplir et les exigences du contrat. Nommez les références et leurs versions. Identifiez les personnes qui valideront le design, le code et les contenus. L’équipe doit savoir quels éléments seront vérifiés à chaque étape.

Le guide du cahier des charges aide à écrire des livrables et des critères de réception. La qualification réglementaire se prépare dans le guide RGAA et EAA. Une exigence contractuelle peut aller au-delà d’un cadre légal identifié ; elle doit rester explicitement distinguée dans les résultats. Aucun taux de conformité d’une maquette ne doit être présenté comme celui du service final.

Examiner les décisions de conception

Les maquettes peuvent révéler des difficultés de contraste, d’identification des actions ou d’organisation de l’information. Le contrôle doit porter sur les états prévus : erreur, contenu long, absence de résultat et interaction active. Demandez comment un composant sera décrit et utilisé, pas uniquement son aspect dans une capture. Les décisions de comportement doivent être consignées pour les développeurs.

La navigation et les formulaires gagnent à être discutés avec les métiers. Un champ doit avoir une fonction claire et des instructions utiles. Une fenêtre doit préciser le retour au parcours. Une information affichée seulement par une couleur doit être réexaminée selon sa fonction. Les observations de design sont un moyen de prévenir les défauts ; leur validation ne dispense pas de tester la mise en œuvre réelle.

Construire et tester les composants partagés

Le système de design peut conserver des exemples de boutons, dialogues, champs et messages. Pour chaque composant, documentez le résultat attendu et les scénarios de test. Une version démonstrative permet d’observer les interactions avant de les multiplier dans les pages. Les états difficiles doivent être inclus, car une correction tardive du composant peut affecter de nombreuses interfaces déjà assemblées.

Le guide de remédiation explique comment transformer un obstacle en tâche. Dans une refonte, cette logique peut s’appliquer avant la recette finale. Les composants livrés doivent être versionnés et leurs comportements rester compréhensibles pour l’équipe. Une documentation qui ne correspond plus au code risque de diffuser le même défaut dans les nouvelles pages.

Préparer la migration des contenus

Les contenus anciens ne deviennent pas accessibles parce qu’ils changent de thème. Inventoriez les images, tableaux, vidéos et documents qui seront repris. Définissez les instructions de saisie et les contrôles avant publication. Un import automatique peut conserver des structures inadaptées ; prévoyez des vérifications sur des exemples représentatifs. La responsabilité éditoriale doit apparaître dans le projet, avec les accès et les moyens nécessaires.

Les documents demandent une décision propre : correction, nouvelle production ou alternative pertinente. Le guide des PDF aide à cadrer ce travail. Pour les pages structurées, préparez les titres et les liens utiles au lecteur. Ne recopiez pas un texte sans vérifier les informations et les destinations. Les dates de contrôle et les personnes chargées de validation doivent être connues dans votre organisation.

Organiser l’audit de la version testable

La recette finale doit porter sur une version stabilisée avec des contenus et des parcours représentatifs. Préparez l’échantillon, les données fictives et les accès. Le prestataire doit pouvoir atteindre les erreurs et les confirmations. Une démonstration du seul chemin idéal ne couvre pas les états qui bloquent une action. La liste des composants validés en amont aide à préparer l’évaluation, mais ne remplace pas les tests des pages assemblées.

Le contrat doit distinguer la réception du travail d’audit et la réception des corrections. Si l’intégrateur et l’auditeur sont différents, prévoyez leur échange sur les preuves. Les désaccords doivent être documentés et résolus avec la méthode retenue. Gardez la version effectivement testée avec les résultats. Une livraison ultérieure peut demander une vérification complémentaire si elle modifie la couverture ou le comportement.

Questions sur la refonte

Peut-on commencer avant que le site existe ?

Oui, pour examiner les besoins, les maquettes et les composants. L’évaluation du service final demande ensuite une version testable et un périmètre représentatif.

Un système de design accessible garantit-il les pages ?

Les assemblages, les états et les contenus peuvent modifier le résultat. Les composants aident à prévenir les défauts ; les parcours livrés doivent être vérifiés.

Qui reçoit les corrections de l’agence ?

Le contrat doit désigner les responsables et les preuves attendues. L’auditeur peut vérifier le comportement, tandis que l’organisation accepte la livraison selon ses règles de projet.

Sources vérifiées le 1er octobre 2026

DINUM : référentiel et obligations