Pour commencer, il faut comprendre une problématique de base en terme d’accessibilité : la distinction entre les images décoratives et les images porteuses de sens. Pour comprendre cette distinction et son importance, je vous recommande vivement la lecture d’«Accessibilité web» par Armony Altinier. Comme souvent lorsque nous parlons d’accessibilité web, il s’agit de bon sens : une image porteuse de sens doit être restituée à tous les utilisateurs, tandis qu’une image décorative ne doit être montrée qu’aux utilisateurs disposant d’un affichage graphique complet.

Les limites de WordPress

Tout le monde n’est pas sensible à ces questions, même s’il le faudrait : WordPress ne fait pas exception. Il donne cependant la possibilité à ses utilisateurs de servir des images de façon tout à fait correcte, en proposant de base pour tous les fichiers la capacité d’adjoindre un texte alternatif — ce qui remplit le critère principal des bonnes pratiques d’OpQuast et permet de satisfaire la plupart des critères de niveau Bronze d’Accessiweb.

Pour autant WordPress ne va pas plus loin :

  • Dans le cas d’une image décorative, il l’ajoute dans une balise <img /> et conserve l’attribut alt vide s’il n’est pas renseigné. C’est une bonne façon de procéder, car l’image n’est pas vocalisée par un lecteur d’écran et n’a aucun poids sémantique.
  • Dans le cas d’une image qui véhicule une information ( ce que je suppose être le cas si la légende est renseignée ), il encadre cette image d’une <div> et y intègre la description dans un <p> ( cf :  le code source du shortcode ). C’est problématique car il n’existe aucun lien sémantique entre l’image et sa description, et le balisage est neutre.

Certes, c’est du fignolage. Mais c’est à priori dans les détails que l’on améliore sensiblement la qualité d’un site web.

Les images porteuses de sens

Le cas des images véhiculant des informations demande donc quelques efforts : il faut intercepter le shortcode afin de le ré-interpréter avant qu’il ne soit renvoyé côté client. Voici ce à quoi j’ai pu aboutir : 

  /* == @section Remplace le code généré par [caption] ==================== */
  /**
 * @note : Le contenu est filtré pour remplacer le html généré pour les caption par du html5 sémantique. Astuce trouvée sur Reverie.
 * @author : Zhen Huang
 * @see : https://themefortress.com/reverie/
 * @see : https://github.com/milohuang/reverie/blob/master/lib/clean.php#LC151
 * @note : On y ajoute les microdonnées qui vont bien.
 * @author : Joost Kiens ( @joostkiens )
 * @see : https://gist.github.com/JoostKiens/4477366
 * @note : Et j’y ajoute les roles et attributs Aria nécessaires
 * @see : https://www.kloh.ch/craw2013-html5-aria-et-accessibilite-web-479
 */
  add_filter( ’img_caption_shortcode’, ’ffeeeedd__caption’, 10, 3 );
  function ffeeeedd__caption( $output, $attr, $content ) {
  if ( is_feed() ) {
  return $output;
  }
  $defaults = array(
  ’id’ => ’’,
  ’align’ => ’alignnone’,
  ’width’ => ’’,
  ’caption’ => ’’
  );
  $attr = shortcode_atts( $defaults, $attr );
  if ( 1 > (int) $attr[’width’] || empty( $attr[’caption’] ) ) {
  return $content;
  }
  $content = str_replace( ’<img’, ’<img id="’ . $attr[’id’] . ’" itemprop="contentURL" aria-describedby="wp-caption--’ . $attr[’id’] . ’"’, $content );
  $attributes = ’ class="wp-caption inbl ’ . esc_attr( $attr[’align’] ) . ’"’;
  $output = ’<figure’ . $attributes .’ role="group" itemscope itemtype="https://schema.org/ImageObject">’;
  $output .= do_shortcode( $content );
  $output .= ’<figcaption class="wp-caption-text pt1 small" id="wp-caption--’ . $attr[’id’] . ’" itemprop="description">’ . $attr[’caption’] . ’</figcaption>’;
  $output .= ’</figure>’;
  return $output;
  }

L’intervention détaillée

La structure d’origine est conservée ; je détaille ce qui a été fait :

  • Une couche sémantique HTML5 est appliquée en lieu et place du balisage «neutre» précédent : figure et figcaption ;
  • Une couche ARIA améliore la compréhension de ce balisage parfois défaillant dans les technologies d’assistance, comme me l’a appris le compte-rendu d’un atelier de Jean-Pierre Vilain à la CRAW2013 rédigé par Luc. Dans notre cas, le role="group".[1]
  • Et finalement une dernière couche est ajoutée : les micro-données.[2]

Ce code n’est probablement pas parfait, car je ne l’ai pas testé avec un lecteur d’écran : il va falloir que je le fasse. Mais je pense que c’est un premier pas en avant vers une meilleure qualité des sites WordPress que je produis.

Les commentaires, conseils et indications supplémentaires seront grandement appréciés :) .

Mises à jour

Suite à un bref échange avec Johan Ramon, je dois préciser un point important : l’alternative textuelle de l’image doit également mentionner la légende attenante, pour les technologies d’assistance qui ne prendraient pas en compte l’attribut aria-describedby. Voici les ressources utiles 

Comme souvent, cette dernière contrainte repose entièrement sur le contributeur qui doit être informé et éduqué à cette responsabilité.

  1. En savoir plus sur le rôle «group» : https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_group_role ↩︎

  2. Découvrir les micro-données pour enrichir les objets images : https://schema.org/ImageObject ↩︎

Article rédigé par . Modifié le .