Refonte accessible : traiter le sujet avant la maquette
Une refonte est la meilleure occasion de régler l'accessibilité, et la plus souvent gâchée. Le scénario classique : le sujet apparaît en recette, trois semaines avant la mise en ligne, sous forme d'un audit qui arrive trop tard pour changer quoi que ce soit. Le surcoût est alors maximal.
Pris en amont, le même sujet coûte une fraction — et évite le chantier de correction décrit sur la page mise en conformité.
Le coût selon le moment
| Phase | Exemple de décision | Coût relatif |
|---|---|---|
| Cahier des charges | Exiger le référentiel, le taux visé et la livraison du rapport | Quasi nul |
| Conception | Choisir des couleurs conformes, définir les états de focus | Faible |
| Développement | Utiliser les éléments natifs plutôt que des composants simulés | Faible |
| Recette | Corriger les composants livrés | Élevé |
| Après mise en ligne | Reprendre les gabarits en production | Très élevé |
Au cahier des charges
Quatre exigences suffisent, et leur absence explique la plupart des livraisons non conformes.
- Le référentiel et sa version — « RGAA 4.1.2 », et non « conforme WCAG ».
- Le taux visé, et la mention correspondante à publier.
- La livraison du rapport d'audit par un tiers, à la charge du prestataire.
- Le contre-audit de validation avant réception définitive.
Conditionner le paiement du solde à la fourniture d'un rapport d'audit attestant du taux contractuel. Sans cela, l'exigence d'accessibilité reste une intention que rien ne vient vérifier.
En conception
Trois décisions prises en maquette évitent l'essentiel des reprises : des jetons de couleur conformes dès le départ, des états de focus spécifiés au même titre que les états de survol, et une hiérarchie de titres documentée pour chaque gabarit.
Ces trois points se consignent dans le système de design — voir le design system accessible.
En développement
La règle la plus économique tient en une phrase : utiliser les éléments natifs du langage. Un bouton natif est focalisable, activable au clavier et annoncé correctement sans une ligne de code supplémentaire. Un élément neutre transformé en bouton demande un rôle, un index de tabulation, des gestionnaires d'événements — et échoue presque toujours sur un point.
Voir quand utiliser ARIA, et quand s'en passer.
En recette
- Un audit intermédiaire sur les trois premiers gabarits livrés, pas à la fin.
- Une vérification clavier à chaque nouveau composant.
- Des tests automatisés bloquants dans la chaîne d'intégration — voir axe DevTools.
- Un audit de conformité complet avant mise en ligne, pas après.
L'audit sur les premiers gabarits est le point le plus rentable : il révèle des erreurs qui allaient être répétées sur l'ensemble du site, à un moment où les corriger coûte encore peu.
Ne pas rouvrir la dette
Une refonte migre des contenus. Si les alternatives textuelles, les hiérarchies de titres et les documents joints sont repris tels quels, le nouveau site naît avec les non-conformités de l'ancien. La reprise éditoriale fait partie du projet, pas de l'exploitation.
Poursuivre
Pour le cas d'une refonte sous WordPress, voyez rendre un site WordPress conforme.