Tout thème WordPress qui veut atteindre un bon niveau d’accessibilité doit intégrer sur toutes les pages du site, des éléments de code obligatoires.
Les thèmes du répertoire de WordPress ayant le tag « Accessibility ready » prennent en compte une partie de ces éléments. Encore faut-il qu’ils répondent aux exigences du Référentiel Général d’Accessibilité pour les Administrations (RGAA), notre référentiel d’accessibilité français.
Mais quels sont ces morceaux de code très simples que vous devez toujours prévoir dans vos thèmes WordPress et qui sont très souvent absents ou mal intégrés ?
A qui s’adresse l’accessibilité
Développer un thème WordPress avec un bon niveau d’accessibilité, c’est permettre aux personnes en situation de handicap d’accéder à votre site. Ces internautes utilisent des matériels et logiciels spécifiques tels qu’un lecteur d’écran qui vocalise le contenu et le transmet à un afficheur braille, une loupe d’écran, mais aussi les fonctionnalités d’agrandissement du navigateur et des extensions tel que Confort Plus d’Orange permettant d’adapter la lecture du site au besoin de chacun.
Le tag « Accessibility Ready »
Pour qu’un thème puisse avoir le tag « Accessibility ready » dans le répertoire des thèmes WordPress, il doit respecter une liste d’exigences en accessibilité et faire l’objet d’un audit effectué par l’équipe qui examine les thèmes.
L’adaptation au RGAA
Le RGAA est un ensemble de tests unitaires qui permettent d’appliquer les Web Content Accessibility Guidelines (WCAG) du W3C, recommandations internationales en matière d’accessibilité des contenus web. Le RGAA est la déclinaison française des WCAG.
Pour que les thèmes WordPress puissent à la fois respecter les exigences publiées par WordPress et les critères du RGAA, chaque point a été repris, détaillé et illustré par du code directement intégrable à vos thèmes WordPress.
Les fichiers du thème hors plugins
Nous ne parlons pas du code généré par les plugins rajoutés au site WordPress, ni des contenus web rédigés par les rédacteurs et contributeurs. Nous ne parlons que du code présent dans les fichiers d’un thème WordPress, provenant de la hiérarchie des templates.
Certains points sont parfois des évidences mais ne vous y trompez pas, s’ils sont mentionnés, c’est que leur prise en compte est très souvent oubliée par les développeurs.
Partons à la découverte de ces morceaux de code qui vont améliorer vos thèmes !
Le code à intégrer
Valider votre code
Le code html produit par votre thème doit être valide au regard du validateur du W3C et la première ligne de vos pages générées doit contenir une déclaration DOCTYPE qui précise la grammaire HTML utilisée.
Dans le fichier header.php, pour une page écrite en HTML5 :
|
1 |
< ! DOCTYPE html> |
Utilisez régulièrement le validateur HTML du W3C mais aussi le validateur CSS du W3C.
Un code valide permet d’être correctement interprété par les technologies d’assistance utilisées par les personnes en situation de handicap et par tous les navigateurs de manière identique.
Indiquer la langue principale du document
Dans la balise <html>, l’attribut lang doit être présent et reprendre le code de la langue du site, choisie dans l’administration de WordPress, dans la page « Réglages généraux ».
Dans le fichier header.php, ajouter la ligne suivante :
|
1 |
<html <?php language_attributes(); ?>> |
Si la langue principale du site est le français, le code généré est le suivant :
|
1 |
<html lang="fr-FR"> |
Il n’est pas rare de rencontrer des sites en français et qui ont un attribut lang= »en ».
Un lecteur d’écran dont la voix synthétique est capable de changer d’accent va vocaliser les pages écrites en français avec un accent anglais, le résultat pouvant être difficilement compréhensible. Il est donc important de bien vérifier la langue principale dans l’administration de votre site WordPress.
Proposer un titre de page pertinent
Le titre d’une page est vocalisé en premier par les lecteurs d’écran. Grâce à lui, l’utilisateur doit comprendre le contenu de la page consultée.
Le titre d’une page d’accueil doit contenir au minimum et dans cet ordre, le nom du site et éventuellement la signification d’une abréviation ou un slogan :
|
1 2 3 |
<title>Nom du site – signification</title> <title>Nom du site – slogan</title> |
Le titre d’une page de contenu doit indiquer au minimum le titre éditorial de la page, suivi du nom du site :
|
1 |
<title>Titre du contenu éditorial – nom du site</title> |
WordPress génère automatiquement cette balise en ajoutant le code suivant dans le fichier functions.php :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
< ?php if ( ! function_exists( montheme_setup' ) ) : function montheme_setup() { add_theme_support( 'title-tag' ); } endif ; add_action( 'after_setup_theme', montheme_setup' ); ?> |
Le contenu de la balise <title> peut être modifié à l’aide d’un plugin de référencement.
Rendre possible le zoom sur toutes les plateformes
Ce n’est pas parce qu’un site est responsive qu’il faut absolument interdire le zoom sur tablette et smartphone. Laisser l’utilisateur zoomer s’il en a besoin.
Prévoir dans la balise <head> le code suivant :
|
1 |
<meta name="viewport" content="width=device-width, initial-scale=1.0"> |
Permettre la navigation par régions
Un utilisateur de lecteur d’écran a la possibilité de naviguer par région. Pour qu’un lecteur d’écran puisse identifier toutes ces zones, il faut que chacune d’elle soit contenue dans une balise spécifique HTML5 avec un attribut ARIA associé.
Pour l’en-tête de la page :
|
1 |
<header role="banner">…</header> |
Pour le menu de navigation principale :
|
1 |
<nav role="navigation">…</nav> |
Pour le moteur de recherche :
|
1 |
<form role="search">…< /form> |
Pour le contenu principal de la page :
|
1 |
<main role="main" id="content">…</main> |
Pour le pied de page :
|
1 |
<footer role="contentinfo">…< /footer> |
La balise <main> est présente une seule fois dans un même page.
Seul l’attribut role= »navigation » peut être utilisé plusieurs fois dans une même page.
Pour différencier un menu de navigation principal, d’un menu de navigation secondaire, l’attribut aria-label est ajouté à la balise <nav> :
|
1 2 3 |
<nav role="navigation" aria-label="Menu principal">…</nav> <nav role="navigation" aria-label="Menu secondaire">…</nav> |
Permettre la navigation au clavier
Pour les internautes qui ne peuvent pas utiliser une souris, la navigation par les touches tab, shift tab et les flèches est un moyen de se déplacer dans une page Web.
Encore faut-il pouvoir se repérer visuellement lors de ce déplacement. Pour cela, la propriété outline est définie par défaut sur tous les navigateurs.
Pour harmoniser ce repère visuel, prévoir de le redéfinir dans la feuille de style du thème, avec la couleur de votre choix, comme par exemple :
|
1 2 3 4 5 |
:focus{ outline : 3px solid #4d90fe; } |
Faciliter la navigation au clavier avec des liens d’évitement
Pour les utilisateurs qui naviguent uniquement au clavier, les premiers liens de chaque page doivent être des liens internes vers le contenu principal, vers le menu principal, vers le moteur de recherche si ces deux derniers sont loin du début de la page.
Ces liens sont soit toujours visibles, soit cachés de manière accessible, apparaissant uniquement lorsqu’ils reçoivent le focus.
Exemple de liens d’évitement : « Aller au contenu », « Aller au menu », « Aller à la recherche »
Texte caché mais accessible
Pour qu’un texte caché puisse être vocalisé par les lecteurs d’écran, WordPress utilise la classe CSS screen-reader-text, qui doit être définie dans la feuille de style CSS de votre thème.
Vous trouverez le code de cette classe sur le site make WordPress Core.
Permettre la navigation par titres
La présence de titres sur une page est très importante pour les utilisateurs de lecteurs d’écran car ils naviguent de titre en titre avec des raccourcis clavier.
La hiérarchie des titres doit être pertinente et sans rupture. Le niveau d’un titre n’est pas choisi pour son visuel mais pour sa logique de structuration. Un titre <h1> ne peut pas être suivi d’un titre <h3> mais il peut être suivi d’un titre <h2>.
Ces utilisateurs préfèrent également ne trouver qu’un seul titre de niveau 1 (nom du site pour la page d’accueil, titre du contenu éditorial pour un page interne). Il n’est pas nécessaire de mettre des titres partout dans la page, comme par exemple dans les menus.
Permettre la navigation par lien
Les utilisateurs de lecteurs d’écran ont la possibilité d’extraire la liste des liens d’une page. Hors contexte, l’intitulé de chaque lien doit être pertinent et faire comprendre la cible du lien. Il faut donc éviter les liens « Lire la suite », « En savoir plus », présents plusieurs fois sur une même page mais qui n’ont pas la même cible.
Et si vous souhaitez vraiment garder des liens « Lire la suite » dans un template archive par exemple, complétez cet intitulé en ajoutant un texte caché avec la classe screen-reader-text :
|
1 2 3 4 5 |
<a href="<?php the_permalink(); ?>" > <span class="screen-reader-text"><?php the_title(); ?> - </span>Lire la suite </a> |
Mais il arrive qu’un lien n’ait pas d’intitulé et l‘utilisateur est alors face à un lien vide. Dès qu’un lien est associé à un icone ou une image, l’intégrateur ne prévoit pas de texte pour rendre explicite ce lien.
Pour résoudre ces problèmes, ajouter un texte caché avec la classe screen-reader-text.
Pour les liens vers les réseaux sociaux :
|
1 2 3 4 5 6 7 |
<a href="https://www.facebook.com/..." > <span class="fa fa-facebook" aria-hidden="true"></span> <span class="screen-reader-text">Nous suivre sur Facebook</span> </a> |
Pour le lien interne permettant de revenir au début de la page :
|
1 2 3 4 5 6 7 |
<a href="#top"> <span class="fa fa-angle-up" aria-hidden="true"></span> <span class="screen-reader-text">Haut de page</span> </a> |
Le logo cliquable est généré par WordPress en appelant la fonction suivante dans votre thème :
|
1 |
< ?php the_custom_logo() ; ?> |
Il est conseillé de renseigner systématiquement le texte alternatif de l’image logo, avec le nom du site.
Si vous utilisez la fonction « the_custom_logo() ; » dans votre thème, et si le texte alternatif est vide, cette fonction génère un attribut alt avec le nom du site.
Dans tous les cas, vérifiez que vous obtenez au minimum le code suivant :
|
1 2 3 4 5 |
<a href="https://www.mon-site.fr" > <img src="…" alt="Mon site" … /> </a> |
Proposer un moteur de recherche utilisable
Le formulaire de base est généré par WordPress en appelant la fonction suivante dans votre thème :
|
1 |
<?php get_search_form(); ?> |
Pour améliorer son accessibilité, il est nécessaire d’adapter son code. Pour cela, le fichier « searchform.php » est rajouté à votre thème WordPress.
L’étiquette doit être liée au champ avec par exemple l’attribut « for » sur la balise <label> et l’attribut « id » sur la balise <input>. Le placeholder doit fournir un exemple de saisie et ne doit pas remplacer l’étiquette. Ici l’étiquette n’est pas visualisée mais cachée de manière accessible avec la classe screen-reader-text.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<form role="search" method="get" id="searchform" class="searchform" action="<?php echo esc_url( home_url( '/' ) ); ?>"> <label for="s" > <span class="screen-reader-text" >Votre recherche :</span> <input id="s" type="search" class="search-field" placeholder="ex : WordPress" value="" name="s" /> </label> <input class="searchsubmit" value="Rechercher" type="submit" /> </form> |
Signaler l’ouverture d’une nouvelle fenêtre
Il n’est pas interdit d’ouvrir une nouvelle fenêtre à l’activation d’un lien ou d’un bouton mais il faut le signaler aux utilisateurs.
C’est souvent le cas pour les liens vers les réseaux sociaux, ou plus généralement pour les liens externes au site. Une solution consiste à rajouter un texte caché avec la classe screen-reader-text qui va compléter l’intitulé du lien :
|
1 2 3 4 5 |
<a href="https://www.facebook.com/..." target="_blank"> Nous suivre sur Facebook <span class="screen-reader-text"> – nouvelle fenêtre</span> </a> |
Utiliser un attribut title sur un lien n’est pas obligatoire
Un attribut title sur un lien doit servir à compléter l’intitulé du lien. Si sa valeur est identique à l’intitulé du lien, cette infobulle ne fait que visualiser l’intitulé déjà visible. Un lecteur d’écran va très souvent vocaliser l’intitulé et l’infobulle, répétant deux fois la même information.
Vérifier le code de vos éléments interactifs
Tous les éléments cliquables présents dans vos pages doivent être atteignables au clavier. Pour cela, ils doivent être codés de préférence avec des éléments recevant nativement le focus clavier.
Par exemple, le code suivant permet de revenir en haut de la page. Il est utilisable avec la souris car un script js capture l’événement onclick sur la balise <div>. Mais il n’est pas atteignable au clavier :
|
1 2 3 4 5 |
<div class="td-scroll-up td-scroll-up-visible"> <i class="td-icon-menu-up"></i> </div> |
La fonctionnalité de ce morceau de code est de pouvoir revenir en haut de la page. C’est donc un lien interne à la page. Pour coder ce lien, c’est la balise <a> qui est sémantiquement la plus appropriée, associée à la définition d’une ancre.
Remplacer la balise <div> par une balise<a>, en profiter pour ajouter un intitulé de lien :
|
1 2 3 4 5 6 7 |
<a href="#top" class="td-scroll-up td-scroll-up-visible"> <span class="td-icon-menu-up" aria-hidden="true"></span> <span class="screen-reader-text">Haut de page</span> </a> |
Et le CSS !
Pour permettre à tous les utilisateurs d’augmenter la taille des caractères via la fonctionnalité de son navigateur, la propriété font-size doit être exprimée en unité variable. L’unité pixel est à proscrire au profit des unités rem, em…
|
1 |
font-size :1.6rem ; |
La hauteur de ligne doit être exprimée avec un facteur et la hauteur éventuelle d’un bloc doit être exprimée avec une unité relative. Si l’internaute augmente la taille des caractères, le texte doit rester lisible à l’intérieur des blocs et ne doit pas se chevaucher :
|
1 2 3 4 5 6 7 8 9 10 11 |
body{ line-height :1.5 ; } .bloc{ height :14rem ; } |
Le texte ne doit pas être justifié à gauche et à droite, car les espacements entre les mots risquent de ne pas être réguliers, entrainant des problèmes de lecture pour les personnes dyslexiques par exemple.
|
1 2 3 4 5 |
body{ text-align :left ; } |
Mise en oeuvre au WordCamp Paris 2018
Cet article vous a donné une première liste de codes à ajouter à vos thèmes WordPress pour améliorer l’accessibilité de vos sites.
Le 9 mars prochain, j’ai la chance d’animer un atelier intitulé : « Améliorer l’accessibilité d’un thème WordPress à partir d’une checklist ».
Au cours de cet atelier, les participants pourront ensemble modifier un thème existant, au niveau design et au niveau codage, pour à la fin de la séance obtenir un thème plus accessible. Une checklist de recommandations sera à suivre pour atteindre cet objectif.
Pour aller plus loin
- Ressources du Référentiel Général d’Accessibilité pour les Administrations (RGAA)
- Ressources et articles sur WebAim
- Lecteurs d’écran : préférences et principaux problèmes des utilisateurs
- Make WordPress Accessible : handbook
Bonjour Claire,
merci pour ce super article. Que penses-tu des templates Premium ? En existe-t-il selon toi quelques uns qui soient Accessibility-Ready et sympas ?
Bonne journée,
Rashel