Comment faire une tuile accessible pour votre design system ?
Qu’est-ce qu’une tuile ?
Dans cet article, une « tuile » désigne un modèle de conception qui regroupe un contenu et une action qui s’y rapporte. On peut également appeler ce modèle de conception une « card » ou même « carte »1. Elle dispose souvent d’un visuel, et l’utilisateur pourra cliquer sur la tuile pour accéder à la version complète du contenu ou cliquer sur un bouton visible sur la tuile pour y accéder.

Quels sont les enjeux d’accessibilité liées aux tuiles ?
En tant que tel les tuiles ne posent pas de problème spécifique d’accessibilité : si le RGAA est respecté, toutes les informations sont correctement transmises à tous les utilisateurs quel que soient leurs manières de naviguer (Lecteur d’écran, contrôle de l’interface au clavier…). L’enjeu spécifique apparaît lorsque les concepteurs souhaitent que la zone de clic couvre toute la tuile.
La mise en place de ce choix d’interface utilisateur (UI) est particulièrement utile sur mobile ou il peut être difficile d’appuyer sur un simple lien texte avec son doigt. Non évoqué dans le RGAA 4.2.1, cet aspect devrait devenir obligatoire dans la version 5 du référentiel qui reprendra le critère 2.5.8 des WCAG 2.2 qui demande une taille de zone minimale pour les zones de clic (24*24 pixels css).
Une idée qui vient naturellement pour mettre en place cette fonctionnalité serait simplement d’intégrer la totalité de la tuile au sein d’une balise de lien <a>.
Cette technique peut poser de nombreux problèmes d’accessibilité, en fonction des configurations d’utilisateurs :
- Répétition de liens pour chaque élément contenu
- Textes répétés plusieurs fois
- Disparition des titres du plan
Les grands principes d’accessibilités des tuiles
Avant de concevoir ou de choisir une tuile accessible, on devra bien garder à l’esprit les grands principes suivants :
- Lien explicite (RGAA4 6.1)
- L’intitulé de lien (ou « nom accessible », par défaut, cela correspond au contenu de la balise <a>) doit permettre d’en comprendre la fonction et la destination
- Le nom accessible d’un lien ayant un intitulé visible doit contenir à minima l’intitulé visible
- Détournement de balise (RGAA4 8.9)
- L’élément qui porte le lien de la tuile doit être une balise de lien <a>, ou porter un role= »link »
- Gestion des titres (RGAA4 9.1)
- Chaque passage de texte constituant un titre (présentant donc un contenu) doit être structuré comme tel
- Information compréhensible lors de la désactivation du css (RGAA4 10.3)
- L’ordre visuel de la tuile ne doit pas poser de problème par rapport à l’ordre logique : les éléments les plus importants sémantiquement (comme les titres) doivent être situés en premier dans le flux html (mais il est possible de changer l’ordre visuel à l’aide des feuilles de styles pour faire apparaître d’autres éléments avant dans la présentation graphique – illustration, dates, mots clés))
- Visibilité des liens (RGAA4 10.7)
- Le style de focus ne doit pas être supprimé où dégradé
- Ordre de tabulation (RGAA4 12.8)
- L’ordre de tabulation à l’intérieur de la tuile doit être cohérent
Comment coder une tuile accessible ?
Quel doit-être l’intitulé de la tuile ?
Avant de passer au code, le concepteur devra se poser la question du contenu qui doit porter l’intitulé de la tuile. L’intitulé est défini dans le glossaire du RGAA comme le nom accessible qui sera restitué par les technologies d’assistance (TA). En effet si un utilisateur voyant peut appréhender d’un coup d’œil l’ensemble du contenu d’une tuile, un utilisateur non-voyant l’approchera d’une manière séquentielle, un élément après l’autre. Ainsi il est primordial de lui fournir les informations les plus importantes en premier afin qu’il puisse continuer à naviguer avec la plus grande connaissance de son environnement possible.
Concrètement il s’agit de comprendre que lorsqu’on met en place une tuile, il faut se pose la question du contenu « le plus important » :
- S’agit-il du Call-To-Action2 (CTA) de la tuile ?
- Du titre de la tuile ?
- De son contenu textuel ?
Une fois le contenu identifié il s’agit de faire porter à ce contenu le lien de la tuile, afin que ce contenu soit considéré comme intitulé de la tuile.
Par exemple on pourra traiter le CTA de la tuile comme un lien si c’est approprié, ou bien insérer une balise de lien à l’intérieur de la balise de titre de la tuile. Le plus important est de ne pas encapsuler toute la tuile dans une balise de lien, sinon tous les contenus textuels de la tuile deviendront son intitulé : ce qui est désastreux pour la compréhension. Plus la tuile possède de contenu (date, auteur, résumé, …) plus il est important de bien sélectionner l’élément qui va porter le lien et constituer l’intitulé de la tuile.
La méthode css : l’astuce pseudo-content
Spécialiste du développement front-end et du css accessible Heydon Pickering propose sur son excellent blog une méthode pour réaliser une tuile accessible uniquement en html et css. Iel3 propose les étapes suivantes :
- Donner à l’élément du container de la tuile position: relative
- Donner au pseudo-élément ::after du lien position: absolute et content :’’
- Donner à chaque propriétés left, top, right et bottom du pseudo-élément ::after du lien une valeur nulle
Cela va étendre la mise en page du lien sur la tuile entière : la rendant cliquable comme un bouton.
<li class="card">
<img src="/path/to/image.png" alt="">
<h2>
<a href="/card-design-woes">Card design woes</a>
</h2>
<p>Ten common pitfalls to avoid when designing card components.</p>
<small>By Heydon Pickering</small>
</li>
Css :
.card {
display: flex;
flex-direction: column;
position: relative;
}
.card a::after {
content: '';
position: absolute;
left: 0;
top: 0;
right: 0;
bottom: 0;
}
Vous pouvez découvrir (et étudier) le modèle de Heydon via son github.
Comment fonctionne cette méthode ?
Reprenons les étapes proposées par Heydon :
1. Donner à l’élément container de la tuile position: relative
En CSS, la propriété position définit comment un élément est positionné dans la page. Par défaut, tous les éléments sont en position: static, ce qui signifie qu’ils suivent le flux normal de la page. En revanche, un élément avec position: relative reste dans le flux normal, mais on peut le déplacer par rapport à sa position initiale avec top, bottom, left, right. De plus, il devient un repère de positionnement pour ses enfants en position: absolute.
Ainsi dans notre cas le container de la tuile ( <li class= »card »>) est en position: relative.
Cela signifie que tout élément enfant positionné en absolute sera positionné par rapport à ce container, et non par rapport à la fenêtre du navigateur.
2. Donner au pseudo-élément ::after du lien position: absolute et content: »
Un pseudo-élément comme ::after permet d’ajouter du contenu généré uniquement par CSS (sans modifier le HTML). Ici, on va l’utiliser pour créer une couche invisible qui recouvrira toute la tuile.
On donne à ce pseudo-élément les propriétés suivantes :
- content: » : La valeur par défaut de la propriété « content » dans le cadre d’un pseudo-éléments est « normal », ce qui correspond à « none » pour ::before ou ::after. Notre objectif ici est de créer un contenu vide, pas de ne pas créer de contenu du tout !
- position: absolute : Le pseudo-élément sera positionné par rapport à son parent le plus proche qui a une position autre que static (ici, le container de la tuile, qui dispose de la propriété position en relative).
Dans notre cas : on cible le lien (<a>) à l’intérieur de la tuile, et on lui ajoute un ::after.
3. Donner à left, top, right et bottom du pseudo-élément ::after une valeur nulle
En donnant 0 à left, top, right et bottom, on dit au pseudo-élément de s’étirer pour toucher tous les bords de son parent positionné en relative.
En effet :
- left: 0; : Le bord gauche du pseudo-élément touche le bord gauche du parent.
- top: 0; : Le bord haut touche le bord haut du parent.
- right: 0; : Le bord droit touche le bord droit du parent.
- bottom: 0; : Le bord bas touche le bord bas du parent.
Ainsi le pseudo-élément ::after s’étire sur toute la surface du container de la tuile, comme une couche transparente.
L’article de Heydon va plus loin avec différentes techniques pour modifier légèrement les propriétés de la tuile
Quelles sont les limites et les avantages de la méthode css
Malheureusement la méthode css n’est pas sans inconvénients : notamment il n’est pas possible de sélectionner le texte contenu dans la tuile à cause de la superposition de la zone de clic css. On pourrait être tenté de modifier le z-index pour forcer le texte au-dessus, rendant la zone de texte sélectionnable ; mais dans ce cas ce même texte n’est plus cliquable !
On se retrouve alors avec un « trou » dans la zone de sélection de la tuile.
Le principal bénéfice de cette méthode est sa rapidité de mise en place et sa simplicité : pas de JavaScript nécessaire ! Cette version du modèle de conception de la tuile est par ailleurs très répandue dans les designs systèmes (celui de l’état par exemple).
La méthode JavaScript
Un article de Vikas Parashar résume bien les différentes étapes pour arriver à une tuile pleinement accessible (avec la possibilité de sélectionner le texte et d’avoir de multiples éléments cliquables dans la tuile). Le design système du W3C utilise d’ailleurs à la fois du pseudo-contenu et du JavaScript dans sa proposition.
Pour conclure
La méthode css et la méthode JavaScript disposent d’avantages et d’inconvénients :
| Avantages | Inconvénients | |
|---|---|---|
| CSS | Simple à mettre en œuvre | Texte non sélectionnable |
| JavaScript | Texte sélectionnable, sur-mesure | Mise en œuvre plus complexe |
En prenant en compte les contraintes liées à vos projets nos auditeurs en accessibilité sauront vous conseiller au mieux pour la mise en conformité de votre design system.
- On a choisi dans le présent article d’éviter le mot « carte » pour son autre signification de « carte interactive » pour les outils type Google Maps, Mappy, etc… ↩︎
- Appel à l’action : le plus souvent dans le cas qui nous concerne un composant ressemblant à un bouton qui a pour objectif de déclencher une action de l’utilisateur (ici cliquer sur la tuile) ↩︎
- Heydon se définie comme non-binaire : nous choisissons ici de respecter ce choix et utilisons « iel » qui remplace (et mélange) « il » ou « elle ». ↩︎
Rédigé par
Yves-Pol Cabon
Consultant en accessibilité numérique