readonly public string $couleurFocus; — cette simple déclaration, rendue possible par PHP 8.1 sorti fin novembre 2021, change la façon de concevoir un objet de configuration. Une propriété readonly ne peut être initialisée qu’une seule fois, depuis l’intérieur de la classe qui la déclare ; toute tentative de modification ultérieure déclenche une erreur. Appliquée aux réglages d’accessibilité d’un thème, cette garantie du langage remplace une discipline jusque-là purement conventionnelle.
Avant cette évolution, un thème sur mesure de taille moyenne dispersait typiquement ses choix d’accessibilité dans plusieurs fichiers : une constante de couleur de focus dans functions.php, un identifiant de cible de lien d’évitement défini dans le fichier d’en-tête, une préférence de mouvement par défaut codée en dur dans une feuille de style. Rien n’empêchait qu’une extension ou qu’un futur développeur modifie l’une de ces valeurs à la volée, sans traçabilité ni garde-fou.
L’arborescence retenue
wp-content/themes/mon-theme/
├── inc/
│ └── class-reglages-accessibilite.php (la classe immuable)
├── functions.php (instanciation unique)
├── templates/
│ └── header.php (lecture seule des réglages)
└── assets/
└── css/
└── focus.css (valeurs générées côté PHP)
Un seul fichier porte désormais la définition de la classe, un seul point d’entrée l’instancie, et tous les gabarits qui ont besoin d’une valeur d’accessibilité la lisent depuis cet objet unique, jamais depuis une constante locale redéfinie ailleurs.
La classe centrale
final class ReglagesAccessibilite {
public function __construct(
public readonly string $couleurFocus = '#1a5fb4',
public readonly int $epaisseurContourFocus = 3,
public readonly string $idLienEvitement = 'contenu-principal',
public readonly bool $respecterReductionMouvement = true,
) {}
public static function pourTheme(): self {
return new self();
}
}
Le constructeur promu, une syntaxe déjà disponible avant PHP 8.1 mais combinée ici avec le mot-clé readonly, réduit la classe à sa plus simple expression : aucune méthode de modification, aucun setter, uniquement des valeurs fixées une fois pour toutes à la construction de l’objet.
L’instanciation unique dans functions.php
function mon_theme_reglages_accessibilite(): ReglagesAccessibilite {
static $reglages = null;
if ($reglages === null) {
$reglages = ReglagesAccessibilite::pourTheme();
}
return $reglages;
}
Cette fonction d’accès garantit qu’une seule instance existe pour toute la durée du chargement de la page, un motif proche du singleton mais sans la complexité habituelle de cette approche, puisque l’immutabilité de l’objet rend inutile toute synchronisation entre plusieurs instances potentielles.
La lecture depuis les gabarits
<?php $reglages = mon_theme_reglages_accessibilite(); ?>
<a href="#<?php echo esc_attr( $reglages->idLienEvitement ); ?>" class="lien-evitement">
Aller au contenu principal
</a>
Chaque gabarit qui a besoin d’un identifiant, d’une couleur ou d’un réglage booléen appelle la même fonction d’accès, sans jamais redéfinir sa propre constante locale. Un changement de couleur de focus, par exemple, se fait à un seul endroit du code, avec l’assurance qu’aucun fichier oublié ne continue de référencer une ancienne valeur codée en dur.
Pourquoi readonly change vraiment quelque chose
Avant PHP 8.1, rien n’empêchait techniquement un développeur, ou une extension tierce via un filtre mal utilisé, de modifier une propriété publique d’un objet de configuration après sa création. La discipline reposait entièrement sur des conventions de code et sur la vigilance des relecteurs. Avec readonly, cette garantie devient une contrainte du langage lui-même : toute tentative d’écriture après construction lève une erreur fatale, détectée immédiatement en développement plutôt que découverte des mois plus tard en production sous la forme d’un comportement incohérent.
$reglages = mon_theme_reglages_accessibilite();
$reglages->couleurFocus = '#ff0000'; // Erreur : impossible de modifier
// une propriété readonly déjà initialisée
Permettre la surcharge par un thème enfant
L’immutabilité ne signifie pas rigidité totale : un thème enfant peut fournir ses propres valeurs en filtrant la construction plutôt qu’en modifiant l’objet existant.
add_filter( 'mon_theme_reglages_accessibilite_defaut', function ( array $valeurs ): array {
$valeurs['couleurFocus'] = '#0a3d91';
return $valeurs;
} );
Le thème parent applique ce filtre avant de construire l’objet final, ce qui laisse au thème enfant un point d’extension propre, sans jamais autoriser de modification après coup de l’objet déjà instancié.
Ce que cette architecture ne couvre pas
Cette centralisation ne dispense en rien d’un audit RGAA du résultat final : un objet de configuration bien conçu garantit la cohérence des valeurs utilisées dans le code, il ne garantit pas que ces valeurs elles-mêmes respectent les critères de contraste ou de visibilité du focus attendus par les référentiels. Ce contrôle reste un sujet distinct, traité par ailleurs.
Un principe de conception à généraliser au-delà de l’accessibilité : toute valeur qui ne devrait jamais changer après le chargement de la page mérite d’être portée par une propriété readonly plutôt que par une simple constante globale, plus difficile à tracer et à faire évoluer proprement.
