# Un registre de décisions d’accessibilité au format ADR, daté et justifié

> Un choix d'accessibilité non daté ni tracé finit presque toujours par être défait par erreur, des mois plus tard, faute d'un registre consultable et à jour.

- Auteur : Clément Hadrot
- Publié le : 2026-08-31
- Mis à jour le : 2026-08-31
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/registre-decisions-accessibilite-format-adr-date-justifie/

## L’essentiel

- Une entrée ADR numérotée et datée trace une décision précise
- Le statut (accepté, remplacé) évite de suivre une entrée périmée
- Le registre reste distinct de la doc des patrons d'interaction

ADR-0012, daté du 12 mars 2026, statut « accepté » : ce simple en-tête, placé au début d'un fichier texte versionné avec le reste du projet, a suffi à empêcher qu'une équipe de maintenance ne supprime par erreur un attribut `tabindex="-1"` jugé à tort superflu sur une fenêtre modale. Le format ADR, pour Architecture Decision Record, emprunté à l'ingénierie logicielle générale, s'applique tout aussi bien à une décision d'accessibilité qu'à un choix d'architecture technique.

Ce registre ne remplace pas la documentation d'un patron d'interaction réutilisable — la façon dont un menu déroulant ou une fenêtre modale doit se comporter reste un sujet à part entière, traité ailleurs. Il répond à un besoin différent : garder la trace datée d'une décision ponctuelle, avec son contexte et sa justification, pour qu'une équipe future comprenne pourquoi un choix précis a été fait à un moment précis, plutôt que de le redécouvrir par accident.

## Le format ADR, emprunté à l'architecture logicielle

Un ADR classique tient en quelques champs fixes, volontairement courts : un numéro séquentiel, un titre, une date, un statut (proposé, accepté, remplacé par un ADR ultérieur), un contexte qui explique le problème rencontré, la décision elle-même, et les conséquences attendues si elle venait à être annulée sans réflexion. Appliqué à l'accessibilité, ce squelette impose une discipline utile : il oblige à dater précisément chaque choix, ce qu'un simple commentaire de code omet presque toujours.

## Anatomie d'une entrée du registre

```
# ADR-0012 : tabindex sur le conteneur de la modale de réservation

Date : 2026-03-12
Statut : accepté

## Contexte
Le conteneur de la modale de réservation ne recevait pas le focus à l'ouverture,
ce qui empêchait la restitution correcte du focus à la fermeture.

## Décision
Ajouter tabindex="-1" au conteneur, pour permettre un appel de .focus() en
JavaScript sans rendre l'élément atteignable par la tabulation normale.

## Alternative écartée
Placer le focus directement sur le premier champ du formulaire interne,
écartée car un formulaire vide n'a parfois aucun champ focalisable.

## Conséquences si annulée
Le focus reste bloqué sur l'élément actif avant l'ouverture : piège au
clavier, critère WCAG 2.4.3 non respecté.
```

> L'essentiel à retenir : Une entrée ADR numérotée et datée trace une décision précise ; Le statut (accepté, remplacé) évite de suivre une entrée périmée ; Le registre reste distinct de la doc des patrons d'interaction

## Où vit ce registre, et comment il reste consultable

Un dossier `docs/adr/` à la racine du dépôt, un fichier par entrée, numéroté séquentiellement, permet de retrouver une décision par son numéro cité dans un commentaire de code ou dans le message d'un commit. Un simple lien, dans le code concerné, vers le fichier `ADR-0012-tabindex-modale.md` correspondant, suffit à relier la ligne de code à sa justification complète, sans alourdir le fichier source lui-même d'un long commentaire.

- Un fichier par décision, jamais un unique fichier fourre-tout qui grossit sans structure.
- Un numéro séquentiel, jamais réutilisé, même si une décision est plus tard remplacée.
- Un statut mis à jour explicitement, plutôt que la suppression pure et simple d'une entrée devenue obsolète.

## Quand une décision en remplace une autre

Une décision d'accessibilité n'est jamais figée pour toujours : les critères eux-mêmes évoluent, une bibliothèque tierce change de comportement, une nouvelle version du RGAA reformule un critère existant. Plutôt que de modifier discrètement une entrée existante, le format ADR impose de créer une nouvelle entrée qui remplace explicitement la précédente, en changeant le statut de l'ancienne en « remplacé par ADR-0031 » : l'historique complet reste ainsi consultable, y compris les raisons devenues caduques.

> Sur nos projets, une règle simple accompagne ce registre : aucune entrée n'est jamais supprimée, seul son statut change ; l'historique complet d'une décision vaut souvent plus que la décision elle-même.

## Ce que ce registre ne remplace pas

Ce registre documente des décisions ponctuelles, datées, liées à un contexte précis de projet. Il ne se substitue pas à la documentation d'un patron d'interaction accessible destiné à être réutilisé tel quel sur plusieurs composants : cette dernière décrit un comportement générique attendu, indépendant de tout historique de projet, et mérite un traitement séparé, structuré différemment.

## En résumé

Un registre de décisions d'accessibilité au format ADR, daté, numéroté et versionné avec le code, transforme une justification qui autrement vivrait dans la mémoire d'une seule personne en une trace consultable par toute équipe future. La discipline tient en peu de règles : un fichier par décision, un statut toujours à jour, et aucune suppression, seulement des remplacements explicites.