# Checklist d’audit des rôles ARIA avant de livrer un thème WordPress sur mesure

> Avant chaque livraison de thème sur mesure, notre équipe passe par cette liste de vérification des rôles et attributs ARIA, pensée pour se faire en une demi-journée sans outil coûteux.

- Auteur : Clément Hadrot
- Publié le : 2022-09-27
- Mis à jour le : 2022-09-27
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/checklist-audit-roles-aria-theme-sur-mesure/

## L’essentiel

- Un rôle ARIA mal posé est pire qu'aucun rôle
- Chaque composant interactif a sa propre check-list
- La vérification se fait au clavier, jamais seulement dans le code source

Livrer un thème WordPress sur mesure sans vérifier ses rôles ARIA revient à livrer un site sans jamais l'avoir ouvert dans un second navigateur. Le problème avec ARIA, c'est qu'un attribut mal posé ne provoque aucune erreur visible : le site continue de fonctionner normalement à l'écran, tout en envoyant des informations fausses ou contradictoires aux technologies d'assistance.

Notre équipe a construit, projet après projet, une check-list de douze points que nous passons systématiquement en revue avant chaque livraison de thème sur mesure, qu'il s'agisse d'un thème classique en PHP ou d'un thème basé sur des templates de blocs. Voici cette liste, avec le raisonnement derrière chaque point.

## Première règle : ARIA ne remplace jamais le HTML natif

Avant même de vérifier un rôle, nous vérifions son absence là où elle ne devrait pas être nécessaire. Un `<button role="button">` est redondant ; un `<div role="button">` à la place d'un vrai `<button>` est un choix qui n'apporte que des inconvénients, puisqu'il faut alors recréer manuellement la gestion du focus et de l'activation clavier que l'élément natif offrait gratuitement.

## Les douze points de la check-list

1. Le menu principal utilise-t-il `<nav aria-label="Navigation principale">` et non un simple `<div>` ?
2. Chaque bouton de sous-menu porte-t-il un attribut `aria-expanded` mis à jour dynamiquement ?
3. Les zones répétées sur toutes les pages (en-tête, pied de page) sont-elles balisées avec `<header>`, `<footer>` ou un rôle équivalent ?
4. Le fil d'Ariane utilise-t-il `aria-label="Fil d'Ariane"` sur son élément `<nav>` ?
5. Les onglets personnalisés respectent-ils le motif `role="tablist"`, `role="tab"`, `role="tabpanel"` avec `aria-selected` à jour ?
6. Les fenêtres modales portent-elles `role="dialog"` et `aria-modal="true"` ?
7. Chaque modale a-t-elle un titre référencé par `aria-labelledby` ?
8. Les messages d'erreur de formulaire sont-ils annoncés via `aria-live="polite"` ou associés au champ par `aria-describedby` ?
9. Les icônes purement décoratives portent-elles `aria-hidden="true"` ?
10. Aucun élément ne porte-t-il de rôle ARIA en contradiction avec sa balise native, comme `role="heading"` sur un `<div>` alors qu'un `<h2>` ferait exactement la même chose ?
11. Les régions principales de la page sont-elles identifiables par un lecteur d'écran via `<main>` et non un simple identifiant CSS ?
12. Les attributs `aria-hidden="true"` ne sont-ils jamais posés par erreur sur un ancêtre contenant du contenu focusable ?

> L'essentiel à retenir : Un rôle ARIA mal posé est pire qu'aucun rôle ; Chaque composant interactif a sa propre check-list ; La vérification se fait au clavier, jamais seulement dans le code source

## Le point douze mérite un exemple concret

Ce dernier point du dernier projet audité concernait un panneau de recherche masqué visuellement mais laissé dans le flux du DOM avec `aria-hidden="true"` posé sur son conteneur parent, sans que le champ de recherche à l'intérieur ne soit retiré de l'ordre de tabulation. Résultat : un utilisateur de clavier tombait, via Tab, sur un champ de recherche invisible à l'écran, tandis qu'un lecteur d'écran, respectant l'attribut `aria-hidden`, ignorait purement et simplement ce même champ. Les deux publics rencontraient chacun un bug différent, provoqué par la même erreur.

```
<div aria-hidden="true" class="search-panel">
  <input type="search" tabindex="0">
</div>
```

La correction consistait à retirer également l'input de l'ordre de tabulation, avec `tabindex="-1"`, tant que le panneau reste fermé, puis à restaurer `tabindex="0"` à son ouverture.

## Comment nous appliquons cette check-list

Chaque point est vérifié de deux façons complémentaires : une lecture du code source pour repérer les rôles et attributs posés, puis un passage clavier complet de la page pour confirmer que le comportement réel correspond à ce que le code prétend annoncer. La lecture de code seule ne suffit jamais, car un attribut `aria-expanded` peut très bien exister dans le HTML sans jamais être mis à jour par le JavaScript associé.

> Un rôle ARIA posé et jamais mis à jour dynamiquement ment à l'utilisateur avec autant d'aplomb qu'un mensonge tout court. Un attribut figé est souvent plus dangereux qu'une absence totale d'attribut.

## En résumé

Cette check-list de douze points prend environ une demi-journée à parcourir sur un thème de taille moyenne, et elle a permis de rattraper, projet après projet, des erreurs qu'aucun outil automatisé de type lecteur de code n'aurait détectées seul, faute de pouvoir observer le comportement dynamique réel de la page. Nous la faisons évoluer à chaque nouveau projet lorsqu'un cas inédit apparaît, mais son socle reste stable depuis maintenant plusieurs livraisons consécutives.