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 !

Free-Photos / Pixabay

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 :

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 :

Si la langue principale du site est le français, le code généré est le suivant :

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 :

Le titre d’une page de contenu doit indiquer au minimum le titre éditorial de la page, suivi du nom du site :

WordPress génère automatiquement cette balise en ajoutant le code suivant dans le fichier functions.php :

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 :

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 :

Pour le menu de navigation principale :

Pour le moteur de recherche :

Pour le contenu principal de la page :

Pour le pied de page :

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> :

Permettre la navigation au clavier

geralt / Pixabay

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 :

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 :

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 :

Pour le lien interne permettant de revenir au début de la page :

Le logo cliquable est généré par WordPress en appelant la fonction suivante dans votre thème :

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 :

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 :

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.

 

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 :

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

MorganK / Pixabay

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 :

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 :

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…

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 :

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.

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

 

 

 

Accessibilité d’un thème WordPress : les éléments de code obligatoires
Moyenne des notes : 5 (100%) 5 votes
PARTAGER
Article Précédent[Meetup] WordPress 5.0 & Gutenberg : Les conséquences, de l’agence aux l’utilisateurs (Caen)
Article SuivantLa parodie a encore de beaux jours devant elle !
Consultante, formatrice spécialisée en accessibilité numérique et WordPress, certifiée Opquast Qualité Web niveau expert. J’ai adopté WordPress en 2006 pour toutes réalisations de site web. Mon activité principale est le conseil et la formation autour des technologies web et plus particulièrement en accessibilité numérique. Je développe également des sites WordPress pour des petites structures. Je réalise des audits basés sur le Référentiel Général d’Accessibilité pour les Administrations (RGAA). J’accompagne les maîtrises d’ouvrage et les maîtrises d’œuvre pour la prise en compte de l’accessibilité dans les projets web. J’aide également les rédacteurs dans l’écriture de contenus accessibles. Certification Opquast : https://certificates.opquast.com/certificate/4FJC03/

1 COMMENTAIRE