Accessibilité – 3 : le contenu

Troisième article de la série sur le thème de l'accessibilité.

---

Sommaire

---

Retrouvez l'ensemble de notre contenu sur l'accessibilité dans un livret PDF dédié. Il est à la destination de tous les professionnels du Web afin de rendre le web plus inclusif.

---

La même expérience, pour tous

Comme évoqué dans le premier article de notre série, l’accessibilité numérique permet un même niveau d’accès aux informations et aux services pour toutes les personnes. 

D’une manière  générale, il ne doit y avoir aucune perte d’information selon :

• le rendu avec ou sans style
• la taille et le zoom de l'écran
• la navigation à la souris ou la navigation au clavier
• les contenus visibles ou invisibles
• l’ordre logique de lecture du contenu, et donc du focus

L’expérience utilisateur doit pouvoir être la même dans tous les cas.

Rendu avec ou sans style

Pour pourvoir comparer, on peut utiliser l'extension Web Developer (disponible sur Chrome (nouvelle fenêtre)↗ et Firefox (nouvelle fenêtre)↗). Dans l'onglet "CSS" de l'extension, il faut sélectionner "Disable all styles".

On peut ensuite repérer les différences :

• les informations sont-elles présentées dans le même ordre, avec la même pertinence ?
• les menus sont-ils utilisables et compréhensibles ?
• les titres ont-ils le même niveau hiérarchique visuellement et sémantiquement ?
• les informations comme par exemple les erreurs de formulaires sont-elles restituées autrement que par la couleur ?
• etc...

Prenons l'exemple d'un bouton avec une icône. Une fois le style désactivé, on doit toujours avoir une indication sur ce bouton. Pour ce faire, si vous ne souhaitez pas mettre de texte dans le bouton, vous pouvez le cacher visuellement, mais il sera bel et bien présent :

See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.

À noter dans cet exemple :

• l'attribut title sur le bouton ne sert que pour l'indication au survol. Le nom accessible du bouton est bien le contenu textuel de celui-ci.
• l'attribut aria-hidden="true" sur l'icône, afin qu'elle ne soit pas vocalisée par les technologies d'assistance

Taille et zoom

Premièrement, il ne faut pas fixer la taille de l'écran ou le zoom, évidemment. Pour cela, il faut veiller à mettre dans l'en-tête du HTML :

<meta name="viewport" content="width=device-width, initial-scale=1">

Ensuite, il faut prévoir aussi bien pour les écrans en 320 pixels de large, que pour les grands écrans, que pour les écrans avec un zoom à 200%. Aucune information ne doit être tronquée, ce qui veut dire que les tailles fixes sont à bannir pour les conteneurs, il faut préférer les tailles relatives.

Souris et clavier

Toutes les actions possibles à la souris doivent avoir un équivalent au clavier. Par exemple : 

• à la souris : au clic sur un bouton, une liste s’ouvre ou se ferme
• au clavier : quand le focus est sur le bouton, on doit pouvoir ouvrir ou fermer la liste en appuyant sur “Entrée” ou “Espace”

On peut donc en déduire que tous les éléments cliquables doivent donc pouvoir recevoir le focus. Concernant les interactions avec l'utilisateur, si un clic doit déclencher :

• une action dans la page, on utilise la balise button
• un lien vers une partie de page ou une nouvelle page, on utilise la balise a

Les deux peuvent bien sûr se ressembler visuellement, mais le comportement attendu n'est pas le même. Et avant de rajouter un attribut tabindex="0" sur un élément ne recevant pas le focus par défaut (par exemple span ou div), on se demande avant si on ne peut pas plutôt le transformer en button.

Contenus visibles et invisibles

Pour les contenus à cacher pour tous les utilisateurs, on peut utiliser :

• la propriété display: none
• la propriété visibility: hidden
• la propriété font-size: 0
• l'attribut hidden

Pour les contenus à cacher pour les technologies d’assistance :

• la liste précédente
• l'attribut aria-hidden="true"

Pour les contenus à cacher pour les autres utilisateurs : 

• la liste précédente
• ajouter une classe .sr-only ou .visually-hidden, comme dans l'exemple du bouton précédent

HTML

Penser à la sémantique

Si ça ressemble à une liste, ça doit être baliser comme une liste, et si ça ressemble à un titre, ça doit être baliser comme un titre...

Ça peut sembler évident et redondant de le rappeler, mais les span et les div sont à utiliser en dernier recours car elles n'ont aucune valeur sémantique. Ces balises ne sont pas interdites, loin de là, mais avant de les utiliser à tout va, on peut parfois prendre un instant de réflexion.

Penser aux balises peu utilisées

C’est l’occasion de réviser un peu les balises…

• Pour les citations : blockquote, cite, q
• Pour les informations de contact : address
• Pour les passages importants : strong, mark
• Pour les abréviations : abbr
• Pour les listes de définitions : dl, dt, dd
• etc...

Prenons l'exemple des FAQ. Ça existe, déjà tout prêt, accessible au clavier et indépendant de tout style ou script, avec les balises details et summary :

See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.

On peut bien sûr reproduire le comportement avec des boutons et des régions, mais cela demande plus de travail :

See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.

Penser aux noms accessibles

Il y a plusieurs façons d'ajouter un nom accessible à un élément, et il y a aussi un ordre de priorité :

1. contenu textuel (pour les boutons, liens, ...)
2. attribut title="" non vide (qui a l'avantage de s'afficher également au survol)
3. ensuite, selon les éléments :
   • img : attribut alt="" non vide
   • fieldset : présence d'un élément legend
   • champs de formulaires : présence d'un élément label avec l'attribut for="" non vide et contenant l'identifiant du champ en question (l'attribut placeholder="" n'est pas considéré comme accessible car il disparaît lorsque le champ n'est plus vide)
   • figure : présence d'un élément figcaption
   • table : présence d'un élément caption
   • input (type : submit, reset, button) : avec l'attribut value="" non vide
4. attribut aria-label="" non vide
5. attribut aria-labelledby="" non vide et contenant l'identifiant de l'élément contenant le nom accessible

Comme vu dans le premier article de cette série sur l'accessibilité, il convient de faire attention à ce que les éléments suivants aient chacun un nom accessible unique car ils peuvent servir de navigation pour certaines technologies d'assistance :

• liens
• menus
• images
• formulaires
• tableaux
• . . .

On peut ensuite inspecter l'arbre d’accessibilité dans son navigateur pour effectuer les vérifications (comme vu dans le deuxième article de cette série).

Attributs interdits

Pas d’attributs contrôlant l’affichage. Pour tester, copier dans la console du navigateur : 

document.querySelectorAll('basefont, blink, center, font, marquee, s, strike, tt, big, [align], [alink], [background], [bgcolor], [border], [cellpadding], [cellspacing], [char], [charoff], [clear], [compact], [color], [frameborder], [hspace], [link], [marginheight], [marginwidth], [text], [valign], [vlink], [vspace], [size]');

Il ne faut trouver aucune occurrence.

Aussi, vérifier dans la console que le résultat de la commande suivante ne contient que des résultats img, object, embed, canvas et svg : 

document.querySelectorAll('[width], [height]');

CSS

Textes

Concernant les textes, il faut garder en tête que sur les navigateurs les plus courants, l'utilisateur peut paramétrer ses préférences : police, taille de police, zoom, ... on ne peut pas partir du principe qu'un site sera utilisé d'une seule et même manière.

Sachant cela, il faut utiliser des tailles relatives, et non des tailles fixes, c'est-à-dire utiliser plutôt des rem que des px. On peut ensuite faire un système de conversion dans sa feuille de style, pour pouvoir faire le lien entre les tailles en px des maquettes, et les tailles en rem du thème (voir l'exemple de conversion de tailles (nouvelle fenêtre)↗, en anglais).

Concernant les blocs de textes :

• l'interlignage doit être au moins égal à 1,5 fois la taille du texte
• la largeur doit être inférieure ou égale à 80 caractères
• la justification est tout simplement à proscrire...

Focus

Supprimer l'indication visuelle de focus dans le CSS, sans proposer d'alternative, est à proscrire absolument. Cela reviendrai au même que supprimer le curseur de la souris :

body {
    cursor: none; /* suppression du curseur de la souris */
}
:focus {
    outline: none; /* suppression de l'indicateur de focus */
}

Si le style du focus n'est pas modifié, le critère est respecté, mais ce n'est pas toujours très visible, comme dans Firefox par l'exemple. Mieux vaut donc définir dès le départ le CSS du focus pour :

• qu’il soit visible
• qu’il soit en accord avec la charte graphique du projet
• qu’il soit identique sur tous les navigateurs

Couleurs

Plusieurs outils peuvent aider à construire ou tester une palette de couleur accessibles :

• Accessible palette (nouvelle fenêtre)↗
• Accessible color matrix (nouvelle fenêtre)↗
• Contrast grid (nouvelle fenêtre)↗
• Color contrast analyzer (nouvelle fenêtre)↗ de Adobe

Certains outils sont spécialement conçus pour les palettes dédiées à la data visualisation :

• Viz palette (nouvelle fenêtre)↗
• Color palette helper (nouvelle fenêtre)↗

Et d'autres permettent de trouver la couleur accessible la plus proche : 

• Contrast checker (nouvelle fenêtre)↗
• Color review (nouvelle fenêtre)↗

Images

En général, quand on utilise la propriété background-image, c'est que l'image est purement décorative. Cependant, si l'image n'est pas décorative, par exemple l'image d'un article dans une liste d'articles, on perd la possibilité d'ajouter une alternative textuelle. Il faut donc pouvoir trouver un compromis, comme l'exemple suivant :

See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.

Comme pour les arrière-plans d'une seule couleur, ou les background-image contenant un dégradé, il faut veiller à ce que le texte à l'intérieur soit assez contrasté, quitte à mettre un filtre sur l'image pour accentuer le contraste, et/ou une ombre portée pour le texte :

See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.

En général, dans le cas des background-image contenant un dégradé ou une image, les tests automatisés ne pourront pas faire les calculs de contrastes, et lanceront des alertes pour que l'on puisse juger nous-mêmes de la conformité ou non par rapport au critère.

Personnalisation

Nul besoin d'utiliser des plugins ou autres qui vous promettent une solution "tout-en-un" (expression malheureusement courante dans les cahiers des charges ou les réunions...) qui rendrait, en un clic, votre site accessible, cela n'existe pas...

Par contre, il existe un système plutôt simple à mettre en oeuvre au début de la phase d'intégration, et qui peut aider à améliorer l'accessibilité sur certains points. On peut déjà se baser sur les préférences que l'utilisateur a défini dans son navigateur, et adapter les media queries dans le CSS., comme on le fait déjà pour l'orientation et la taille de l'écran. Par exemple :

• prefers-contrast: more (pour afficher plus de contrastes)
• prefers-reduced-motion: reduce (pour ne pas avoir d'animations)
• prefers-color-scheme: dark (pour afficher un thème clair ou foncé)

Sur Chrome, on peut simuler ces préférences dans l'inspecteur : Customize > More tools > Rendering

• contrastes : Emulate CSS media feature prefers-contrast > More
• animations : Emulate CSS media feature prefers-reduced-motion > Reduce
• theme : Emulate CSS media feature prefers-color-scheme > Light/Dark

On peut ensuite proposer aux utilisateurs, via un bouton qui affiche un formulaire, de pouvoir choisir ou modifier certains paramètres. Mais attention toutefois : ces éléments doivent quant à eux déjà être 100% accessibles sans appliquer aucun changement de paramètres.

Dans l'idéal, au chargement de la page :

1. on vérifie en javascript les préférences utilisateurs (cette étape doit être faite avant de charger les styles, pour ne pas avoir l'impression que la page saute)
2. on stocke ces préférences en localStorage et dans un attribut data- sur la balise html
3. ensuite on charge le CSS
4. on stocke les variables de chaque choix possibles dans le sélecteur :root {} du CSS
5. on récupère ensuite les variables pour les appliquer à nos éléments
6. et enfin on propose une manière à l'utilisateur de modifier ces paramètres, qui mettra à jour le localStorage et la valeur de l'attribut data- de la balise html

Dans les prochains exemples, les deux solutions sont montrées. Une se basant uniquement sur les préférences utilisateur (solution A), l'autre permettant de mettre à jour ses préférences (solution B).

Contrastes

See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.

Animations

See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.

Thème

Ce point ne fait pas partie des critères, mais aujourd'hui beaucoup de sites proposent à la fois un thème clair et un thème sombre. Google par exemple.

See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.

Polices

Dans le même ordre d'idée, on pourrait aussi laisser à l'utilisateur le choix de la police, pour le cas de la dyslexie. D'après l'étude "Good fonts for dyslexia (nouvelle fenêtre)↗" (en anglais), on peut proposer en alternative une des polices suivantes : Helvetica, Courier, Arial.

Conclusion

Cet article a pour thème le contenu, mais vous avez certainement noté que le contenu textuel n'a pas été abordé. C'est le contenu rédigé par les auteurs et contributeurs d'un site, le service marketing, ou le prestataire SEO. Le contenu sur lequel chez Globalis, en tant que développeurs, nous n'intervenons pas. Il doit pourtant lui aussi refléter une volonté d'accessibilité, et ne pas aller à contre-courant du travail mis en place en amont : il doit être structuré, compréhensible, facile à lire, et donner une information à la fois. Attention aux mots étrangers, complexes, et aux abréviations, qui ne sont pas toujours correctement restitués par les technologies d'assistance.

Retrouvez notre série sur l'accessibilité :

• Article 1 - introduction
• Article 2 - la base
• Article 4 - les composants simples