Chapitre 11.7 — Accessibilité & i18n avancée

⏱️ TL;DR — Un produit pro est accessible (WCAG : contrastes, clavier, ARIA, HTML sémantique, focus visible) et global (i18n complète, y compris côté JavaScript via @wordpress/i18n, et support RTL pour l’arabe/l’hébreu). WordPress exige l’accessibilité pour le cœur et le recommande fortement partout (obligatoire pour publier sur wp.org, ch. 11.8). L’accessibilité n’est pas une option morale « en plus » : c’est de la qualité, souvent légalement requise, et un argument de vente.

🎯 Objectifs

Appliquer les bases d’accessibilité (WCAG) à un thème/plugin/bloc.
Étendre l’i18n au JavaScript des blocs.
Gérer le RTL et les locales.
Situer l’a11y comme critère de qualité et légal.

Viser au minimum WCAG 2.1 AA :

HTML sémantique : bons éléments (<button> pour une action, <nav>, <main>, titres hiérarchisés) — pas des <div> cliquables.
Contrastes suffisants (texte/fond) — vérifiables (outils, theme.json cohérent).
Navigation au clavier : tout doit être atteignable et actionnable au clavier ; focus visible.
ARIA avec parcimonie : des rôles/labels quand le HTML natif ne suffit pas (pas d’ARIA « décoratif » qui aggrave).
Textes alternatifs des images (ch. 2.3), labels de formulaires, messages d’erreur explicites.
Mouvement : respecter prefers-reduced-motion.

⚠️ Piège n°1 — la <div> cliquable. Un <div onclick> n’est ni focusable ni actionnable au clavier et n’est pas annoncé comme bouton. Utilisez un <button> (ou <a> pour un lien). L’accessibilité vient d’abord du bon élément HTML, avant tout ARIA.

Vos blocs (Partie 8) doivent être accessibles côté éditeur et côté front :

Composants @wordpress/components : déjà accessibles (labels, focus, clavier) — les utiliser plutôt que du HTML brut.
Labels sur tous les contrôles (label des *Control).
Annonces pour l’éditeur : speak() (@wordpress/a11y) pour notifier les lecteurs d’écran d’un changement dynamique.
Front : HTML sémantique dans save/render.php, contrastes issus de theme.json.

WordPress fournit @wordpress/a11y (annonces vocales) et suit des standards d’accessibilité internes — s’y aligner facilite l’acceptation (wp.org) et la qualité.

3. i18n côté JavaScript

L’i18n PHP (ch. 7.8) a un pendant JavaScript pour les blocs, via @wordpress/i18n :


import { __, sprintf, _n } from '@wordpress/i18n';
 
const label = __( 'Choisir un livre', 'wpr-books' );
const msg = sprintf(
    /* translators: %d = nombre */
    _n( '%d livre', '%d livres', count, 'wpr-books' ),
    count
);

Pour que ces chaînes JS soient traduisibles, on charge les traductions du script :


// Après l'enqueue du script du bloc (ou via register_block_type qui le gère)
wp_set_script_translations( 'wpr-livre-une-editor-script', 'wpr-books', plugin_dir_path( __FILE__ ) . 'languages' );

Et on génère les fichiers JS de traduction (wp i18n make-json). Ainsi, l’interface éditeur de vos blocs est traduite comme le PHP.

⚠️ Piège n°2 — chaînes JS non traduites. Oublier wp_set_script_translations() (ou les fichiers .json de traduction) laisse l’UI des blocs en anglais même sur un site traduit. L’i18n JS demande cette étape supplémentaire par rapport à l’i18n PHP.

4. RTL (droite-à-gauche)

Pour les langues RTL (arabe, hébreu, persan), l’interface s’inverse. À prévoir :

CSS logique : préférer margin-inline-start/padding-inline-end aux left/right (s’adaptent au sens) ; ou fournir une feuille -rtl.css.
@wordpress/scripts peut générer les fichiers RTL automatiquement au build.
Tester avec une locale RTL (WordPress ajoute la classe rtl au <body>).

5. Pourquoi ça compte (au-delà de la morale)

Légal : de nombreux pays/secteurs imposent l’accessibilité (services publics, grandes entreprises). Un site non accessible peut être hors-la-loi.
Public : ~15-20 % des utilisateurs ont un handicap ; l’a11y élargit l’audience.
Qualité & SEO : HTML sémantique = meilleur pour les moteurs et la maintenance.
Vente : « accessible WCAG AA » et « prêt pour la traduction/RTL » sont des arguments (marchés publics, international, marketplace).

💡 Pour un dev React — Vos réflexes a11y React s’appliquent : HTML sémantique, gestion du focus, ARIA parcimonieux, prefers-reduced-motion, tests au clavier/lecteur d’écran. Nouveauté WordPress : l’i18n PHP + JS (avec wp_set_script_translations), le RTL, et l’exigence d’accessibilité pour publier. Un produit accessible + traduisible + RTL touche un marché mondial (et respecte les obligations légales) — un différenciateur commercial concret (Partie 13).

✏️ Exercices

Pourquoi préférer <button> à une <div> cliquable ?
Quelle étape spécifique rend les chaînes JavaScript de vos blocs traduisibles ?
Citez deux raisons non morales de soigner l’accessibilité.

✅ Solution

Un <button> est focusable, actionnable au clavier et annoncé comme bouton par les lecteurs d’écran ; une <div onclick> n’a rien de tout ça. L’accessibilité commence par le bon élément HTML, avant l’ARIA.
Appeler wp_set_script_translations( handle, text_domain, chemin_languages ) (et fournir les fichiers .json générés via wp i18n make-json). Sans cela, l’UI des blocs reste en anglais malgré un site traduit.
Par exemple : c’est souvent légalement requis (services publics, grandes entreprises) et cela élargit l’audience (~15-20 % des utilisateurs) ; bonus SEO/qualité et argument de vente.

🧠 Quiz de révision

1. Quel niveau WCAG viser au minimum ?

WCAG 2.1 AA (contrastes, clavier, sémantique, focus visible…).

2. Comment traduire l’UI JS d’un bloc ?

Avec @wordpress/i18n (__, _n, sprintf) + wp_set_script_translations() et les fichiers .json.

3. Que faut-il prévoir pour les langues RTL ?

Du CSS logique (margin-inline-*) ou une feuille -rtl.css (générable par @wordpress/scripts), et tester en locale RTL.

4. Pourquoi l’a11y est-elle parfois obligatoire ?

De nombreux pays/secteurs l’imposent légalement (services publics, grandes entreprises).

5. Quel composant utiliser plutôt que du HTML brut dans un bloc ?

Les composants @wordpress/components (déjà accessibles), et @wordpress/a11y pour les annonces.

Chapitre suivant : Publier sur wp.org.