WordPress et accessibilité : bien structurer les modèles de pages de son thème

La conception d’un thème WordPress passe par plusieurs étapes. Dans ce premier article, nous allons nous pencher sur la structure des fichiers modèles (templates) qui composent le thème, c’est-à-dire son squelette. Il y a plusieurs points importants à vérifier et/ou à mettre en œuvre pour l’accessibilité.

Balises HTML5 + landmarks

Un thème WordPress est souvent construit sur la même base. On a généralement :

• un en-tête de page principal ;
• une navigation principale et d’éventuelles navigations secondaires ;
• le contenu principal ;
• un moteur de recherche ;
• un pied de page qui contient des informations légales ou autres.

Ces zones sont souvent faciles à identifier visuellement, mais il faut aussi les identifier précisément dans le code HTML. On va pour cela utiliser des balises HTML5 (si le thème est déclaré avec un doctype HTML5) et des propriétés ARIA précises, qui sont faites pour ça, via l’attribut role. Cela va créer des points de repère (landmarks) pour les personnes qui ont recours à certaines technologies d’assistance comme les lecteurs d’écran. Je vais reparler des gains utilisateurs dans un instant. Pour permettre aux technologies d’assistance d’identifier les grandes régions de votre site, veillez donc à utiliser dans vos modèles de pages les balises et attributs suivants :

• header[role="banner"] pour l’en-tête de la page. On peut trouver plusieurs balises header, mais le role="banner" doit être unique dans la page. C’est a priori dans le fichier header.php que vous allez pouvoir gérer ce header-ci ;
• nav[role="navigation"] pour la navigation principale, et les éventuelles navigations secondaires (comme un système de pagination par exemple). Dans un thème WordPress, la navigation principale se gère généralement dans le fichier header.php ;
• main[role="main"] pour la zone de contenu principale. La balise main et le role="main" doivent être uniques dans la page. Cette balise est souvent insérée dans les gabarits de page tels que single.php, page.php, front-page.php, archive.php, search.php, etc. ;
• footer[role="contentinfo"] pour le pied de page principal. On peut trouver plusieurs balises footer, mais le role="contentinfo" doit être unique dans la page. C’est dans le fichier footer.php que vous pouvez modifier le pied de page principal de votre thème ;
• un attribut [role="search"] unique dans la page autour du moteur de recherche s’il y en a un.

À noter :

• les rôles ARIA banner, main, contentinfo et search doivent être uniques dans la page ;
• le rôle ARIA navigation est réservé aux zones de navigations principales et secondaires ;
• bien sûr, si vous utilisez un autre doctype que le doctype HTML5, utilisez les rôles ARIA sans les balises HTML5 associées (exemple : <div role="main"></div> pour le conteneur principal).

Cette structuration va aider les personnes aveugles ou très malvoyantes à se représenter mentalement la structure de la page, à identifier les grandes zones du document et à y naviguer plus rapidement, grâce à une liste de ces landmarks et à des raccourcis spécifiques fournis par leur lecteur d’écran.

Ces utilisateurs vont ainsi pouvoir éviter facilement les zones répétées d’une zone à l’autre, notamment l’en-tête de page et la navigation principale. Les landmarks peuvent également aider les personnes handicapées moteurs qui naviguent exclusivement au clavier et dont certaines ont recours à des outils ou à des navigateurs leur permettant de naviguer de landmark en landmarks (exemple : Landmarks pour Firefox – source). Attention, Twenty Nineteen, le thème par défaut actuel de WordPress, n’implémente pas les rôles ARIA sur les balises HTML5 concernées. Aussi, si vous utilisez ce thème sur un site, et que vous voulez être conforme RGAA 3, il va falloir les ajouter.

Précision sur les avertissements du validateur W3C

Si vous implémentez les landmarks et que vous validez votre code source (ce qui est une bonne pratique recommandée par l’équipe WordPress), vous serez peut-être surpris·e par les avertissements remontés par le validateur du W3C à propos des couples balises HTML5/rôles ARIA.

Ne tenez pas compte de ces avertissements. Ce sont des alertes données à titre d’information, pas des erreurs. En réalité, les balises HTML5 ont déjà des rôles implicites correspondant à ces propriétés (par exemple, banner est le rôle implicite de la balise header). L’avertissement signifie donc que l’utilisation de ces rôles est peut-être inutile. Néanmoins, certains navigateurs n’implémentent pas correctement certaines balises HTML5 (par exemple, la balise main dans Internet Explorer 11 et versions inférieures). De plus, ajouter les rôles ARIA aux balises HTML5 correspondantes permet de distinguer les éléments du même type qui pourraient être utilisés. En effet, en HTML5, il est possible d’utiliser plusieurs balises structurantes comme header ou footer au sein de la même page web. Ces balises peuvent par exemple se trouver à l’intérieur de balises article ou section pour créer des en-têtes et des pieds d’article. Ajouter des landmarks permet donc de différencier ces différentes balises entre elles : d’une part, les balises structurantes relatives à la page HTML elle-même, qui nécessitent un rôle ARIA, et les balises structurant les éventuels contenus indépendants à l’intérieur de la page. Enfin, si votre thème est un peu ancien et qu’il n’utilise pas HTML5, les rôles ARIA permettront d’ajouter la sémantique manquante utilisée par les lecteurs d’écran en l’absence des balises HTML5 de structuration. Pour toutes ces raisons, même si c’est redondant pour les navigateurs plus évolués, le RGAA 3 demande que soient implémentés balises HTML5 et rôles ARIA, pour être sûr que les personnes aveugles puissent bien bénéficier de cette fonctionnalité offerte par leur lecteur d’écran.

Références RGAA 3

• Critère 9.2 [A] Dans chaque page web, la structure du document est-elle cohérente ?
• Gabarit général – Guide de l’intégrateur RGAA 3. Voir en particulier « Pourquoi doubler les balises HTML5 avec les landmarks ARIA ? ».
• Document conformance requirements for use of ARIA attributes in HTML – ARIA in HTML.

Titre de la page (<title>)

Un autre point important pour l’accessibilité, c’est le titre de chaque page.

En effet, le titre d’une page web est la première information proposée aux utilisateurs. Les navigateurs s’en servent pour générer l’historique de navigation et la liste des onglets ouverts.

En l’absence de titre, ou si le titre d’une page manque de pertinence, les personnes aveugles, les grands malvoyants et les personnes handicapées mentales ou cognitives peuvent rencontrer de grandes difficultés à retrouver une page dans leur historique de navigation ou dans la liste des onglets ouverts.

D’autant que les personnes aveugles peuvent revocaliser à loisir le titre de la page avec un raccourci du lecteur d’écran.

C’est pourquoi le titre d’une page web doit permettre de retrouver la page dans un historique de navigation.

Dans WordPress, les pages d’archives et les résultats de recherche sont des contenus généralement paginés, c’est-à-dire qu’il existe plusieurs pages de résultats.

Pour permettre à l’utilisateur de retrouver ce type de page facilement dans son historique de navigation, veillez à inclure la pagination dans le titre de ces pages.

Par exemple : « Résultats de recherche pour « [requête] » – Page 2 sur 103 – [Titre du site] ». Si vous utilisez l’extension Yoast SEO, il y a des variables que vous pouvez utiliser pour réaliser ce genre de titre automatiquement.

Cela se règle dans : SEO > Archives > Pages spéciales : Pages de recherche

Par exemple :

%%searchphrase%% : résultats %%pagenumber%% sur %%pagetotal%% %%sep%% %%sitename%%

Vous pouvez retrouver ces réglages dans notre Gist sur Github.

Références RGAA 3

• Critère 8.5 [A] Chaque page web a-t-elle un titre de page ?
• Critère 8.6 [A] Pour chaque page web ayant un titre de page, ce titre est-il pertinent ?

Titres et hiérarchie de titres

Un autre élément tout aussi important pour l’accessibilité de votre thème, c’est la hiérarchie des titres HTML (h1, h2, etc.). En anglais, ces titres HTML sont désignés par le mot « headings ».

Bien utilisés, ces différents niveaux de titres fournissent aux personnes aveugles un plan du document, et leur permettent de naviguer de titre en titre pour se déplacer plus rapidement dans le contenu de la page.

Pour les utilisateurs ayant un handicap moteur et qui naviguent exclusivement au clavier, les titres sont autant de jalons qu’ils peuvent utiliser pour naviguer plus rapidement dans une page, par exemple avec une extension type HeadingsMap ou certains navigateurs.

Enfin, l’utilisation pertinente de titres crée des blocs d’information qui sont plus faciles à utiliser par d’autres personnes en situation de handicap, par exemple certaines personnes ayant un handicap cognitif et utilisant une technologie d’assistance, ou bien des personnes ayant des difficultés de lecture, qui ont recours à un lecteur d’écran pour les aider à lire (source).

Techniquement, ce qu’on veut éviter, c’est une hiérarchie de titres incomplète ou brisée.

Par exemple, un titre h3 ne peut pas suivre un titre h1 : il faut forcément qu’il suive un titre h2, et ainsi de suite pour chaque niveau de titre.

À noter :

• la hiérarchie des titres est un point qu’il est possible de maîtriser sur la plupart des templates de votre thème, par exemple la page d’accueil, les résultats de recherche, etc. ;
• il faut au moins un titre de niveau 1 (h1) par page ;
• on peut avoir plusieurs h1 dans une page, cela ne pose pas de problème pour l’accessibilité si ces titres sont utilisés de manière pertinente ;
• il n’est pas obligatoire que la hiérarchie de titres d’une page commence par un h1. Elle pourrait tout à fait commencer par un h2 par exemple. A priori, il vaut mieux garder la balise h1 pour identifier le titre de l’article (post) ou de la page.

Comment vérifier simplement la hiérarchie des titres d’une page ?

La structure de la page et la hiérarchie des titres relèvent en général de l’intégration front-end.

Les personnes qui ont les mains dans le code sont en effet en mesure de vérifier, modèle de page par modèle de page, que la hiérarchie des titres est cohérente, et d’apporter les modifications requises si cela n’est pas le cas.

Aussi, pendant le développement de votre thème WordPress, pensez à vérifier que vos différents modèles de page ont bien une hiérarchie de titres cohérente.

Voici deux extensions de navigateur très utiles pour cela :

• HeadingsMap pour Firefox et pour Chrome ;
• Web Developer pour Firefox et Chrome (option Information > View Document Outline).

Cependant, vous aurez beau prendre toutes vos précautions pour que votre thème contienne une hiérarchie de titres pertinente et cohérente, vous ne pouvez pas savoir d’avance si les contributeurs et contributrices qui vont utiliser votre thème vont choisir les bons niveaux de titres en rédigeant leurs articles et leurs pages.

Mais vous pouvez au moins prévoir plusieurs choses dans votre thème pour faciliter la contribution et éviter les erreurs.

Styler les 6 niveaux de titres

D’une part, en phase de design, prévoyez bien les 6 niveaux de titres dans votre style guide et vos maquettes.

Ne vous contentez pas de maquetter uniquement le h1, le h2 et le h3 par exemple.

Par défaut, les 6 niveaux de titres sont disponibles dans l’éditeur WYSIWYG de WordPress, donc il faut prévoir leurs différents styles pour qu’ils s’affichent bien côté front-end.

Faites également attention aux noms que vous donnez aux styles typographiques de votre projet. Par exemple, il vaut mieux éviter de nommer le style des titres de niveau 2 « h2 » par exemple.

En effet, ce nom de style, similaire au nom d’une balise, pourrait induire en erreur l’équipe chargée de l’intégration des maquettes, en leur faisant penser qu’elle doit absolument utiliser une balise <h2> à l’endroit indiqué dans la maquette… ce qui n’est pas forcément le cas !

Il vaut mieux choisir des noms de styles plus génériques, et laisser les intégratrices et intégrateurs choisir les balises pertinentes en fonction du contexte.

Côté CSS, pensez également à bien définir ces différents styles pour qu’ils s’affichent bien à l’intérieur des articles rédigés avec WordPress (.entry-content h2, .entry-content h3, etc.).

Si les styles ont bien été prévus en amont, et s’ils sont cohérents, il y a moins de risques que les contributeurs choisissent d’insérer un niveau de titre erroné juste parce qu’ils le trouvent plus joli qu’un autre – ce qui est pourtant une erreur fréquente qui nuit à la cohérence du plan du document.

À noter : il est possible d’empêcher les contributeurs et contributrices d’insérer des titres de niveau 1 (<h1>) dans les articles et les pages grâce à une fonction de quelques lignes.

En effet, en général dans le modèle de page single.php de WordPress, le titre h1 de l’article est déjà géré via une variable à part :

<?php the_title( '<h1 class="entry-title">', '</h1>' ); ?>

Et le contenu de l’article en lui-même est affiché grâce à une variable spécifique, à part :

<?php the_content(); ?>

Puisque notre modèle de page contient déjà un titre de niveau 1, on peut préférer éviter que les contributrices et contributeurs qui ne sont pas formés à l’accessibilité insèrent une ou plusieurs autres balises <h1> dans leurs articles, ce qui nuirait au plan de la page.

Référence RGAA 3

Critère 9.1 [A] Dans chaque page web, l’information est-elle structurée par l’utilisation appropriée de titres ?

Listes

Pour terminer, un dernier point important pour structurer correctement vos contenus et vos éléments d’interface, ce sont les listes HTML.

Les listes, comme les titres et les landmarks, offrent une expérience de navigation enrichie pour les utilisateurs de lecteur d’écran, notamment les personnes aveugles et les grands malvoyants : elles peuvent naviguer de liste en liste, sauter une liste, et connaître à l’avance le nombre d’items que contient chaque liste.

Aussi, pensez à prévoir et à intégrer les styles des listes dans le thème (ou le site) que vous êtes en train de concevoir : non seulement les listes ordonnées (ol) et non ordonnées (ul) de premier niveau, mais aussi les listes imbriquées (ul ul, ol ol, ul ol, ol ul).

Le cas spécifique des successions de liens

En outre, il est important de structurer toute succession de liens sous forme de liste HTML.

En effet, si votre code HTML contient plusieurs balises <a> à la suite, sans éléments de liste, cela peut poser un souci de restitution avec un lecteur d’écran.

En effet, les lecteurs d’écran parlent très vite quand les personnes aveugles les utilisent au quotidien : or, quand des liens se succèdent sans listes, l’utilisateur peut penser qu’il n’y a qu’un seul lien au lieu de deux par exemple, en particulier quand l’intitulé de ces liens sont très longs.

Le tampon de vocalisation (c’est-à-dire la mémoire vive) d’un lecteur d’écran étant relativement court, celui-ci ne vocalise pas forcément tout à temps ou d’une traite. Il peut donc y avoir une latence pendant la restitution de chaque lien, poussant le lecteur d’écran à « hacher » la restitution d’un seul et même lien, comme s’il s’agissait de plusieurs liens séparés.

L’utilisation de listes peut alors permettre à l’utilisateur de faire une distinction claire entre chaque lien de la liste.

Un exemple classique de ce problème concerne les listes d’icônes sociales, que l’on trouve souvent en pied de page ou dans la colonne latérale des thèmes WordPress.

Or, ce genre de liste visuelle est rarement structurée sous forme de liste HTML. Ce n’est d’ailleurs pas le cas dans le thème Neve à l’heure où je rédige ces lignes – un des thèmes WordPress les plus populaires, qui pose pourtant plusieurs problèmes d’accessibilité.

Le code actuel présent dans ce thème pose un gros problème aux utilisateurs de lecteurs d’écran : en effet, les liens n’ont aucun intitulé car leur contenu est géré avec un pseudo-élément CSS, et il n’y a pas non plus de liste :

<h6 lang="en"><a href="#">Keep in touch</a></h6>
<div class="elementor-widget-container">
 <div class="neve-first-social">
   <a href="https://www.facebook.com/ "></a>
 </div>
 <div class="neve-second-social">
   <a href="https://twitter.com/">#</a>
 </div>
 <div class="neve-third-social">
   <a href="https://www.instagram.com/"></a>
 </div>
 <div class="neve-fourth-social">
   <a href="https://plus.google.com/"></a>
 </div>
</div>

Ci-dessous, une restitution audio de ce qu’entend une personne utilisant NVDA quand elle tombe sur le code ci-dessus :

Voici le code corrigé, dans lequel on ajoute une liste non ordonnée ul/li et un intitulé dans chaque lien (note : j’ai aussi utilisé la classe .sr-only, qui permet de masquer cet intitulé visuellement hors écran, tout en le laissant accessible aux lecteurs d’écran, pour qu’il soit bien restitué aux utilisateurs aveugles) :

<h6 lang="en"><a href="#">Keep in touch</a></h6>
<ul class="elementor-widget-container" lang="en">
 <li class="neve-first-social">
   <a href="https://www.facebook.com/ "><span class="sr-only">Facebook</span></a>
 </li>
 <li class="neve-second-social">
   <a href="https://twitter.com/"><span class="sr-only">Twitter</span></a>
 </li>
 <li class="neve-third-social">
   <a href="https://www.instagram.com/"><span class="sr-only">Instagram</span></a>
 </li>
 <li class="neve-fourth-social">
   <a href="https://plus.google.com/"><span class="sr-only">Google+</span></a>
 </li>
</ul>

Deux autres corrections sont possibles :

• lien + image HTML ;
• lien + image SVG.

Référence RGAA 3

Critère 9.3 [A] Dans chaque page web, chaque liste est-elle correctement structurée ?

Conclusion

Dans ce premier article consacré à l’accessibilité des thèmes WordPress, nous avons passé en revue quelques points stratégiques :

• la structuration des pages (balises HTML5 et rôles ARIA) ;
• la pertinence du titre du document HTML (en particulier dans le cas de pages faisant partie d’un ensemble paginé) ;
• les titres HTML et la hiérarchie de ces titres, qui doit être cohérente ;
• les listes.

Si vous codez vous-même vos propres thèmes, dans ce cas vous avez la liberté d’implémenter ces différentes bonnes pratiques de design web dès maintenant.

Si vous ne codez pas et que vous utilisez des thèmes WordPress tout faits, alors vérifier l’implémentation de ces quatre éléments est un premier niveau de tri qui vous permettra d’effectuer un premier écrémage parmi les différents thèmes que vous aurez présélectionnés.

Dans mon prochain billet WordPress et accessibilité, qui devrait être publié le mois prochain, nous verrons ensemble comme rendre la navigation de votre thème plus accessible aux personnes en situation de handicap, en particulier aux personnes qui naviguent exclusivement au clavier. Pour ne pas manquer la publication de cet article, suivez-nous sur Twitter ou LinkedIn.

En attendant, vous pouvez retrouver le support de présentation de ma conférence « 8 conseils pour améliorer l’accessibilité de votre thème WordPress ».