# Rendre accessible un tableau de bord d’admin pour un rédacteur malvoyant

> Un rédacteur malvoyant rejoint l'équipe éditoriale d'un client. Le tableau de bord d'administration personnalisé n'était pas prêt à l'accueillir. Voici comment il l'a été.

- Auteur : Clément Hadrot
- Publié le : 2026-05-28
- Mis à jour le : 2026-05-28
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/tableau-bord-admin-accessible-redacteur-malvoyant/

## L’essentiel

- L'accessibilité du back-office est souvent négligée au profit de celle du site public
- Un widget de tableau de bord personnalisé doit respecter les mêmes règles qu'un composant public
- Le zoom d'écran et les contrastes renforcés doivent être testés directement dans l'admin

L'agence avait construit, pour ce client, un tableau de bord d'administration sur mesure : neuf widgets personnalisés affichant les statistiques de fréquentation, les commandes du jour, les articles en attente de relecture. Quand un rédacteur malvoyant a rejoint l'équipe, l'agence a réalisé que tout ce travail sur mesure n'avait jamais été pensé pour un usage avec zoom d'écran ou lecteur d'écran.

Ce tutoriel détaille comment ce tableau de bord a été repris, widget par widget, pour devenir réellement utilisable par ce rédacteur — sans réécrire tout le back-office depuis zéro.

## Étape 1 — Auditer chaque widget avec le zoom d'écran réel du rédacteur

Première étape, souvent négligée : tester directement avec le niveau de zoom que le rédacteur utilise au quotidien, plutôt qu'un zoom navigateur générique à 150 %. Ici, le rédacteur travaillait à 300 %, un niveau qui a immédiatement révélé des widgets dont le contenu débordait de leur cadre, rendant certains chiffres clés totalement invisibles sans défilement horizontal caché.

## Étape 2 — Corriger la mise en page des widgets en unités relatives

> L'essentiel à retenir : L'accessibilité du back-office est souvent négligée au profit de celle du site public ; Un widget de tableau de bord personnalisé doit respecter les mêmes règles qu'un composant public ; Le zoom d'écran et les contrastes renforcés doivent être testés directement dans l'admin

Les widgets utilisaient des largeurs fixes en pixels pour aligner leurs colonnes de chiffres, une pratique qui casse dès qu'un zoom important est appliqué. La correction est passée par des unités relatives et une disposition qui peut se replier :

```
.widget-tableau-bord-commandes {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
}

.widget-tableau-bord-commandes .chiffre-cle {
  min-width: 8rem;
  flex: 1 1 auto;
}
```

## Étape 3 — Vérifier l'ordre de lecture au clavier et au lecteur d'écran

Le rédacteur utilisant occasionnellement NVDA en complément du zoom, l'ordre de lecture des widgets a été vérifié : trois d'entre eux étaient positionnés visuellement dans un ordre différent de leur ordre dans le DOM, à cause d'un positionnement CSS en grille mal aligné avec la structure HTML. Cet écart rendait la lecture au clavier incohérente avec la lecture visuelle habituelle des autres membres de l'équipe.

## Étape 4 — Donner du sens aux graphiques du widget statistiques

Le widget de fréquentation affichait un graphique en courbes généré en JavaScript, sans aucune alternative textuelle. Pour le rédacteur, ce widget était tout simplement vide de sens. La correction a ajouté un résumé textuel généré à partir des mêmes données, affiché juste après le graphique :

```
<p>
  Résumé : 1 240 visites cette semaine, en hausse de 8 % par rapport à la semaine précédente.
  Le mardi reste le jour le plus consulté.
</p>
```

## Étape 5 — Revoir les contrastes de l'interface d'administration elle-même

Contrairement à une idée reçue, l'interface d'administration de WordPress n'est pas automatiquement irréprochable sur le contraste dès qu'on y ajoute des widgets personnalisés. Les libellés discrets en gris clair utilisés pour les métadonnées secondaires des widgets ont été renforcés pour atteindre le seuil de 4,5:1, exactement comme sur un composant public.

### Étape 6 — Tester en conditions réelles avec le rédacteur concerné

Une fois les corrections déployées, une session de test directe avec le rédacteur a permis de confirmer les progrès et de repérer un dernier point : le bouton de relecture rapide d'un article, positionné en superposition sur le widget d'articles en attente, restait difficile à distinguer même après renforcement du contraste, à cause d'une icône seule sans libellé textuel. Un libellé visible a été ajouté à côté de l'icône.

> L'accessibilité du back-office se traite avec la même rigueur que celle du site public. Un rédacteur qui ne peut pas utiliser confortablement son outil de travail quotidien, c'est un problème d'accessibilité à part entière.

## En résumé

Rendre un tableau de bord d'administration accessible à un rédacteur malvoyant demande de tester avec ses réglages réels — niveau de zoom, lecteur d'écran éventuel —, de corriger les mises en page rigides, de donner une alternative textuelle aux graphiques, et de revoir les contrastes du back-office avec la même exigence que pour le site public. Neuf widgets personnalisés y sont passés, un par un, avant que ce tableau de bord devienne réellement utilisable au quotidien.