Tuiles

Le composant tuiles est une collection de blocs de contenus unis par le sens. Les blocs (tuiles) d’une même collection présentent généralement une structure similaire. Même s’il est courant de délimiter visuellement les tuiles au moyen de bordures, certaines peuvent avoir un contour implicite, sans bordure apparente.

Il existe deux principaux types de tuiles :

• Les tuiles simples : elles contiennent un seul lien ou un seul bouton par tuile.
• Les tuiles complexes : elles contiennent plusieurs liens menant vers des destinations distinctes et/ou plusieurs boutons déclenchant des comportements distincts.

Dans une tuile complexe, chaque lien ou bouton doit être mis en focus et activé séparément, car leurs destinations ou leurs comportements ne sont pas les mêmes.

En revanche, pour une tuile simple, il est possible de rendre cliquable l’entièreté de celle-ci à la souris, car il n’y a qu’un seul lien ou un seul comportement à déclencher. Dans ce cas de figure, il est essentiel de respecter certains requis fonctionnels pour que cette approche demeure compatible avec les outils d’adaptation et la navigation au clavier.

Les exemples accessibles que nous documentons sont des tuiles simples.

Voici les principaux comportements attendus avec les outils d’adaptation (lecteurs d’écran, commandes vocales, etc.) ainsi que la navigation au clavier :

• Chaque tuile comporte un titre (en-tête) de niveau approprié pour l’architecture de la page.
• Même si toute la surface d’une tuile est cliquable, un seul élément de contenu est identifié comme lien et reconnu comme tel par les lecteurs d’écran. L’élément choisi est concis et évocateur de la destination du lien :
  • Préférablement, il s’agit du titre de la tuile (pour des raisons précisées dans la section Préoccupations complémentaires d’utilisabilité).
  • Si la tuile contient une mention de type « En savoir plus » : seul cet élément est identifié comme lien. Cependant, le libellé doit également reprendre le titre de la tuile, de manière perceptible pour les lecteurs d’écran, afin de rendre explicite la destination du lien.
• Le véritable lien de la tuile répond également aux critères suivants :
  • Il peut être activé avec un outil de commandes vocales, en dictant les mots de son libellé visible;
  • Il est le seul élément qui reçoit vraiment le focus clavier avec la touche Tabulation. Cela n’empêche pas la possibilité que l’indicateur visuel de focus englobe toute la tuile contenant ce lien.
• (Recommandé) La collection de tuiles est présentée sous forme de liste. Voir la section Avantages d’une structure de liste pour le balisage des tuiles.
• Lors de la navigation dans la collection de tuiles, les informations de contextualisation suivantes sont communiquées aux lecteurs d’écran. (La structure de liste permet de transmettre avec une plus grande robustesse ces informations) :
  • L’appartenance des tuiles à une même collection d’éléments;
  • (Recommandé) La présence de tuiles dans cette collection, par l’entremise d’un nom accessible donné à celle-ci, tel que « Groupe de tuiles »;
  • Le début et la fin de la collection de tuiles;
  • Le nombre de tuiles présentes;
  • Le début et la fin de chaque tuile.

Il n’existe pas d’attributs ARIA spécifiques pour la création de tuiles accessibles. La transposition technique des préoccupations fonctionnelles repose en majeure partie sur le choix d’une structure HTML appropriée, combinée à une mise en forme CSS et à un codage JavaScript. Voici les principaux aspects à surveiller :

Titre et image des tuiles

• Chaque tuile contient un titre, balisé avec un niveau d’en-tête approprié à la structure de la page.
• Ce titre est le premier élément de contenu de la tuile, dans l’ordre d’apparition du code source.
• Lorsqu’une image est intégrée à la tuile, son placement respecte un ordre séquentiel logique. Plus précisément :
  • Si l’image contient un équivalent textuel, elle figure après le titre dans l’ordre d’apparition du code source. Au besoin, des effets de styles CSS permettent de positionner visuellement l’image sans altérer cet ordre séquentiel.
  • Si l’image reçoit un traitement décoratif (ex. : alt="" ou aria-hidden="true"), cette technique suffit à préserver l’ordre séquentiel logique. En effet, l’image sera ignorée par les lecteurs d’écran.

Lien de chaque tuile

• Un seul élément de contenu de la tuile est balisé comme lien, à l’aide de la balise <a> . Préférablement, il s’agit du titre de la tuile.
• Si la tuile utilise un lien de type « En savoir plus », plutôt qu’un titre-lien :
  • Seul le lien « En savoir plus » est encadré par la balise de lien <a>.
  • La destination du lien doit être précisée. Cela peut se faire au moyen d’un texte hors écran, en ajoutant le titre complet de la tuile à la fin du libellé du lien, pour qu’il figure dans son nom accessible. Il est aussi possible de redéfinir le nom accessible du lien avec un attribut aria-label, dont la valeur reprend tel quel le libellé générique visible, tout en ajoutant le titre concerné de la tuile.

Balisage structurel de la collection de tuiles

(Cette partie s’aligne à la recommandation d’emploi d’une structure de liste, conformément à la section Avantages d’une structure de liste pour le balisage des tuiles.)

• La collection de tuiles est codée sous forme de liste (<ul>), dont chaque élément de ligne (<li>) contient une tuile.
• Un nom accessible est donné à la collection de tuiles (<ul>), depuis l’attribut aria-label.Ex. : aria-label="Groupe de tuiles".
  • Remarque : Le lecteur d’écran JAWS présente un bogue mineur, qui consiste à omettre une espace entre l’annonce de la liste et son nom accessible. Cet irritant peut être contourné en ajoutant une espace au début du nom accessible. Ex. : aria‑label=" Groupe de tuiles".
• (Optionnel) Les contenus de chaque tuile sont inclus dans la balise <article>, lorsque le type de contenus s’y prête.

Autres considérations techniques

• Dans les exemples fournis, JavaScript gère deux principaux comportements :
  • Créer une surface cliquable recouvrant toute la tuile, qui conduit à l’adresse spécifiée dans le véritable lien (<a>).
  • Permettre la sélection du texte de la tuile (copier-coller, etc.) sans que cette action provoque l’activation du lien.
• Le segment de texte balisé avec <a> est le seul élément qui reçoit véritablement le focus clavier. Cependant, pour renforcer la cohérence des interactions auprès des différentes clientèles, il est suggéré de concevoir un indicateur de focus qui englobe toute la tuile, et pas seulement le lien balisé. Les exemples de tuiles fournis illustrent cette approche, avec un indicateur de focus doté d’une épaisseur et d’un contraste suffisants.
• Les personnes utilisant des outils de commandes vocales ont besoin d’une identification claire du véritable lien reconnu par leur outil, pour savoir quel libellé dicter. Cette distinction ne doit pas reposer uniquement sur la couleur.
  • Lorsque possible, privilégier le soulignement pour le lien au repos. L’utilisation d’autres types de mises en forme (texte plus grand, caractères gras, etc.) n’est pas forcément gage de la présence de liens et peut être confondue avec du texte non interactif.
  • Si le soulignement du lien au repos n’est pas envisageable : respecter un ratio de contraste d’au moins 3:1 entre la couleur du lien et celle des autres contenus de la tuile. Les règles d’accessibilité demandent également un changement visuel au survol dans ce cas de figure. Nénamoins, il convient de se rappeler que cet indice n’est pas perceptible avec des commandes vocales. C’est pourquoi nous recommandons de viser le meilleur contraste possible.
• Dans les exemples de tuiles, les puces de liste sont masquées au moyen de styles CSS, à l’aide d’une technique qui préserve leur rendu par les lecteurs d’écran. En effet, la puce peut constituer un indice supplémentaire pour marquer le début d’une nouvelle tuile. Pour parvenir à ce résultat :
  • Désactiver l’affichage des puces de l’élément ul  (list-style-type: none);
  • Cibler le pseudo-élément ::before de l’élément li. Puis, ajouter une puce avec la propriété content, en lui donnant une couleur transparente. Notons que la mise en transparence de la puce via le pseudo-élélément ::marker n’est pas suffisante pour obtenir l’effet souhaité avec certains lecteurs d’écran.

À la suite de tests fonctionnels et de tests utilisateurs, nous constatons qu’une structure de liste est plus robuste que d’autres approches souvent proposées pour répondre à certains requis d’accessibilité de tuiles simples.

Nous présentons plus bas nos observations, obtenues avec différentes combinaisons de lecteurs d’écran et de navigateurs. Les versions employées pour ces tests sont les plus à jour en date du 21 mars 2025 :

• NVDA avec Chrome
• VoiceOver iOS et VoiceOver Mac avec Safari
• TalkBack avec Chrome
• JAWS avec Chrome

Principaux constats :

• Pour délimiter une collection de tuiles : La liste est un élément natif reconnu de longue date par l’ensemble des lecteurs d’écran. Elle permet un lien programmatique clair et robuste pour établir la relation entre les différentes tuiles d’une même collection. En comparaison, la balise <section> connait un support plus limité (non annoncée par JAWS ni par TalkBack). De plus, elle ne traduit pas sémantiquement la notion de collection ou de groupe d’éléments. Quant au rôle ARIA group, il est relativement peu supporté par les lecteurs d’écran et ne se prête pas à ce contexte d’emploi.
• Pour identifier une collection de tuiles à l’aide d’un nom accessible, via aria-label : La liste est également plus robuste que la balise <section> :
  • Sur un <ul>, le nom accessible est annoncé en entrée de liste par JAWS, NVDA, ainsi que VoiceOver sur Mac et iOS. Seul TalkBack ignore le nom accessible.
  • En revanche, sur <section>, on perd cette information avec JAWS. Par ailleurs, VoiceOver iOS annonce le nom accessible d’une section à sa sortie seulement. Cela empêche de percevoir le nom dès l’entrée dans la collection de tuiles.
• Pour identifier de manière non visuelle le début et la fin de chaque tuile : La structure de liste est également plus robuste, comparativement à d’autres approches :
  • La balise <article> , employée de manière optionnelle pour encadrer chaque tuile, est ignorée par plusieurs lecteurs d’écran. De plus, elle ne se prête pas à tous les contextes d’emploi.
  • La présence systématique de titres (en-têtes) au début de chaque tuile peut contribuer à distinguer le début d’une tuile, mais n’est pas toujours aussi explicite que la liste, dépendamment de la structure et de la longueur des contenus. La combinaison des deux approches est donc souhaitable.
• Pour annoncer le nombre d’éléments d’une collection de tuiles : La liste offre un moyen natif de communiquer cette information de contextualisation, avec tous les lecteurs d’écran testés.
• Pour la navigation : Étant donné la possibilité de naviguer par titres (en-têtes), la structure de liste n’offre pas d’avantage additionnel pour se déplacer d’une tuile à l’autre. Cependant, pour atteindre une collection de tuiles, la navigation par liste peut constituer un atout intéressant.

Retrait de la balise <section>

Considérant ce qui précède, nous estimons que l’inclusion d’une collection de tuiles dans la balise <section> présente peu d’intérêt. Nous l’avons par conséquent retirée de nos exemples :

• Cette balise communique une sémantique générique.
• Elle n’apporte pas de réel avantage pour la navigation par région. En effet, il est recommandé de s’en tenir aux régions déjà bien connues, ayant une sémantique forte. De plus, la navigation par liste offre quand même un mécanisme pour atteindre rapidement une collection de tuiles.
• Pour les quelques rares lecteurs d’écran qui reconnaissent la balise <section>, cette dernière introduit une redondance vis-à-vis de l’emploi de la liste, pour délimiter le début et la fin d’une collection de tuiles.

Privilégier des modèles de tuiles basés sur des titres-liens, plutôt que sur des liens « En savoir plus »

Le modèle « En savoir plus » présente des inconvénients pour l’utilisabilité, même s’il peut être codé de manière conforme aux normes d’accessibilité.

Le principal enjeu réside dans l’utilisation de liens commençant par le même libellé générique. La mention qui précise l’article ou le sujet concerné est reportée à la toute fin du lien, dans un texte hors écran. Cette approche réduit la convivialité pour certaines clientèles :

• Avec un lecteur d’écran, cela nuit au repérage d’un lien spécifique, lorsqu’on consulte la liste de l’ensemble des liens d’une page. On ne peut pas se fier aux premières lettres du lien pour le trouver rapidement.
• Avec un logiciel de commandes vocales, cela augmente les étapes nécessaires pour sélectionner une tuile. Comme le segment visible du lien est le même dans toutes les tuiles, il n’est pas possible d’activer le lien du premier coup en le dictant. L’outil de commandes vocales fera apparaître une numérotation devant tous les liens de même libellé, ce qui nécessite de dicter le numéro correspondant.

Ces inconvénients ont des impacts plus prononcés sur des sites utilisant une abondance de tuiles (ex. : sites de nouvelles). Pour cette raison, l’approche des titres-liens demeure à privilégier, particulièrement dans ces contextes. Si l’on souhaite recourir au modèle « En savoir plus », il convient de se limiter à un petit nombre de tuiles. De plus, le lien doit être codé selon les requis d’accessibilité mentionnés à la section Explications techniques.

Les exemples fournis se basent sur un prototype de tuiles de Joel Strohmeier, auquel nous avons apporté divers correctifs d’accessibilité. Voici les principaux changements, qui tiennent compte des aspects fonctionnels et techniques abordés dans cette fiche :

• Ciblage des liens : La partie du script responsable de générer la zone cliquable demeure fonctionnelle même si les liens sont ciblés en _blank (pour l’ouverture d’une nouvelle fenêtre).
• Sélection des contenus : Les internautes peuvent maintenant sélectionner ou copier-coller le texte des tuiles avec la souris ou un autre pointeur, sans que cela n’active la tuile par inadvertance.
• Structure HTML : La structure de liste existante est bonifiée par l’ajout d’un nom accessible à la balise <ul>, pour évoquer la fonction de cette liste (aria-label="Groupe de tuiles"). La balise <section> a par ailleurs été retirée, pour des motifs évoqués plus tôt.
• Mise en forme CSS : Divers ajustements de styles ont été effectués pour :
  • rendre les véritables liens plus distinguables du reste des contenus de la tuile (principe d’affordance);
  • offrir un indicateur de focus conforme au critère 2.4.13  – Apparence du focus (AAA), des WCAG 2.2;
  • s’assurer que les puces de la liste demeurent reconnues par VoiceOver iOS, même si elles sont visuellement cachées.
• Liens « En savoir plus » : Le prototype de Strohmeier contient un segment souligné « En savoir plus », qui donne l’impression d’être un lien sans en être un. Ce faux lien est masqué aux outils d’adaptation avec l’attribut aria-hidden. Il s’agit d’une approche à proscrire, qui est non conforme aux WCAG, à partir de la version 2.1. Cela crée des enjeux d’accessibilité pour les personnes utilisatrices de commandes vocales, qui pourraient tenter sans succès d’activer le faux lien en dictant son libellé. Désormais, la variante de tuiles qui utilise la mention « En savoir plus » respecte les requis d’accessibilité pour ce cas de figure, tels que couverts dans la présente fiche.