Cet article fait partie d’une série sur le vaste monde des alternatives textuelles :
Le texte masqué en CSS est un moyen de fournir une alternative textuelle ou d’ajouter du contexte à des éléments pour lesquels on ne peut pas le faire de façon visible, sans déstructurer la mise en page prévue par les maquettes graphiques.
Dans un monde idéal, les interfaces devraient être suffisamment bien conçues pour qu’on n’ait pas besoin d’utiliser ce genre d’artifice. Malheureusement, ce n’est pas toujours le cas.
Le texte masqué en CSS, qu’est-ce que c’est ?
Il s’agit d’un texte que l’on place dans un élément HTML avec une classe qui porte un style bien particulier.
On l’appelle .sr-only chez Bootstrap, parfois, ailleurs, .visually-hidden ou .element-invisible chez Drupal ou .screen-reader-text chez WordPress. Ce sont des classes qui permettent de masquer un contenu en le rendant malgré tout restituable par les technologies d’assistance dont les lecteurs d’écran.
Ainsi, on ne masquera pas une alternative avec les propriétés CSS display: none; ou visibility: hidden;. En effet, si on souhaite que le contenu soit restitué aux utilisateurs et utilisatrices de lecteurs d’écran, cela ne fonctionnera pas avec ces propriétés CSS qui vont désactiver complètement la visibilité de ces éléments.
Attention, ça ne veut pas dire qu’il ne faut jamais utiliser ces propriétés CSS : on ne les utilisera simplement pas dans ce contexte de texte destiné à aider les personnes notamment aveugles.
Il y a une manière bien précise de le faire et c’est tout une science car il faut que le texte soit restitué de façon convenable. En 2016, j’avais voulu relever les différentes techniques utilisées sur un CodePen pour pouvoir les tester avec différents lecteurs d’écran. Lors de ma formation AccessiWeb chez BrailleNet, le formateur avait évoqué qu’avec le lecteur d’écran ORCA sous Linux, certaines techniques n’étaient pas géniales. En effet, après quelques tests, il s’avère que la classe .sr-only de Bootstrap faisait lire le texte mot par mot à la synthèse vocale ; ce qui est assez pénible et peut devenir incompréhensible.
Quelques mois plus tard, Gaël Poupard s’est également penché sur le sujet et a corrigé le style de la classe .sr-only. Le meilleur code trouvé actuellement est donc celui qu’il a mis en ligne dans son article « Cache-cache CSS » (que je colle ici avec sa permission – lisez son article, il y en a plus) :
.sr-only {
border: 0 !important;
clip: rect(1px, 1px, 1px, 1px) !important;
-webkit-clip-path: inset(50%) !important;
clip-path: inset(50%) !important;
height: 1px !important;
overflow: hidden !important;
padding: 0 !important;
position: absolute !important;
width: 1px !important;
white-space: nowrap !important;
}Dans quel contexte utiliser un texte masqué en CSS ?
Une icône porteuse d’information
Il arrive parfois qu’on utilise des icônes pour donner des informations. Par exemple, on peut vouloir indiquer les services présents dans un lieu en particulier. Si la maquette graphique prévoit uniquement des icônes sans texte accolé, un texte masqué en CSS pourra alors servir d’alternative à l’utilisation de cette icône affichée en CSS :
<span class="icon-accessibility" aria-hidden="true"></span>
<span class="sr-only">Accessible aux personnes handicapées</span>Dans cet exemple, l’icône a un attribut aria-hidden="true" car, si on utilise une police d’icônes, celle-ci est construite via la propriété CSS content à laquelle on donne pour valeur une suite de caractères (exemple : content: "\f021"). Cette propriété CSS pouvant être restituée par les lecteurs d’écran, on évitera donc sa restitution inutile et perturbante.
Par ailleurs, on pourra éviter d’utiliser l’élément <i> qui a sa propre valeur sémantique (et ça ne veut pas dire « icon » mais, initialement, « italique » même si aujourd’hui, cet élément a un réel usage sémantique) ; on pourra lui préférer le <span> qui, lui, ne porte aucune sémantique particulière. À noter qu’il s’agit d’un point de détail de puriste car l’attribut aria-hidden="true" retire totalement la sémantique de n’importe quel élément en le masquant totalement lui et son contenu.
Un lien ou un bouton doit toujours avoir un intitulé
Lorsque vous aurez des retours sur l’accessibilité d’un site web, il est fort probable que l’on vous remonte des problèmes comme « un lien ou un bouton doit toujours avoir un intitulé ». C’est vraiment très fréquent car on ne se doute pas forcément de l’importance que ça a en tant que personne voyante : il y a une icône dedans, on le voit bien ce bouton. L’utilisation sera similaire à celle présentée précédemment.
Par exemple, pour un bouton avec seulement une icône visible, on procèdera de cette façon :
<button type="submit">
<span class="icon-search" aria-hidden="true"></span>
<span class="sr-only">Rechercher dans le site</span>
</button>Ainsi, le lecteur d’écran dira bien que le bouton permet de rechercher dans le site et ne dira pas le charabia du code de l’icône. Si on désactive les feuilles de styles CSS, le bouton restera également visible et utilisable.
À titre d’information, pour un bouton sans intitulé, le lecteur d’écran pourra dire qu’il s’agit d’un bouton ou du bouton numéro 10 dans la page ; bref, rien qui ne pourra aider.
On procèdera de la même façon pour un lien sinon, le lecteur d’écran lira l’attribut href du lien (et c’est vraiment pas sympa à entendre !) :
<a href="https://mamot.fr/@ParisWeb">
<span class="icon-mastodon" aria-hidden="true"></span>
<span class="sr-only">Suivre Paris Web sur Mastodon</span>
</a>Fournir une aide complémentaire aux utilisateurs et utilisatrices de technologies d’assistance
Il est possible que, dans certains cas de navigation complexe notamment, vous deviez ajouter du texte masqué en CSS pour donner plus de précisions sur l’action à effectuer, sur l’emplacement des éléments, etc. En général, les maquettes graphiques ne peuvent pas suivre car on trouve cela pas terrible visuellement et que ce n’est souvent pas prévu. Donc, ce ne sera pas terrible non plus de faire ça en texte masqué mais ce sera mieux que de mettre les utilisateurs et utilisatrices dans l’embarras.
Je pense notamment à un cas que j’ai rencontré sur un projet où on utilise un système d’autocomplétion dans un champ de recherche. Dans ce cas, il n’est pas possible d’écrire n’importe quoi puis de valider la recherche et d’obtenir un résultat. Un message d’erreur dira qu’il faut choisir un élément dans la liste d’autocomplétion. Par conséquent, afin d’avertir l’utilisateur ou l’utilisatrice de ce comportement, nous avons ajouté un texte masqué qui sera lu par le lecteur d’écran et qui dit de choisir un résultat dans la liste en utilisant les flèches de navigation du clavier.
Ces cas particuliers sont à valider avec un ou une experte en accessibilité web avant toute utilisation pour éviter d’ajouter inutilement des textes masqués partout qui pourraient plus gêner qu’aider.