Les composants de type carte sont largement utilisés dans les listes d'articles et ailleurs. Bien que simples en apparence, leur conception soulève des enjeux surprenamment complexes lorsqu'on considère l'accessibilité.
Considérons un modèle de carte classique avec, de haut en bas :
- Image
- Titre de l'article
- Résumé de l'article
- Lien vers plus de détails
et explorions les modèles d'implémentation dans une disposition verticale.
Principaux points de conception à considérer
1. Ordre visuel et structure HTML
Les lecteurs d'écran lisent généralement le contenu dans l'ordre du code HTML. WCAG 2.0 établit que le critère de succès 1.3.2 (ordre logique, niveau A) pose comme principe fondamental l'alignement de l'ordre visuel avec l'ordre HTML.
Cependant, modifier l'ordre via CSS ne constitue pas en soi une violation de WCAG. Si l'ordre visuel diffère de l'ordre HTML mais que le contenu reste compréhensible, ce n'est pas problématique. L'important est d'évaluer chaque situation avec flexibilité.
2. Traitement des images
Les images des cartes d'articles sont généralement décoratives. Puisque le titre de l'article suffit à communiquer le contenu, la nécessité de faire lire la description de l'image est faible.
Traiter l'image comme décoration nécessite simplement alt="".
<img src="thumbnail.jpg" alt="">
3. Libellés des liens détaillés
Les textes génériques comme « En savoir plus » doivent être évités pour les raisons suivantes:
Problèmes visuels
Sans contexte environnant, il est impossible de déterminer la destination du lien
Problèmes pour les lecteurs d'écran
Lorsque vous affichchez une liste avec la fonction de liste de liens, tous les éléments indiquent « Afficher les détails » et il n'est pas possible de les distinguer
Problèmes de reconnaissance vocale
Lorsqu'il y a plusieurs textes identiques, la sélection par numéro devient nécessaire et l'opération devient fastidieuse
Idéalement, le texte du lien devrait indiquer le but de manière autonome, par exemple « Afficher les détails de ○○ ». Cependant, cette section traite de la méthode de mise en œuvre en reproduisant le design « Afficher les détails » tel quel.
4. Zone cliquable de la carte
Pour améliorer l'expérience utilisateur, on souhaite souvent rendre la carte entière cliquable. Il existe plusieurs méthodes de mise en œuvre, mais chacune a des impacts différents sur l'accessibilité.
5. La carte doit-elle être un article ou une div ?
Le choix dépend de la nature du contenu.
est approprié lorsque :
- Le contenu de la carte constitue un contenu indépendant et autonome
ne pose pas de problème :
- Fonctionne simplement comme un groupe de liens
- La carte elle-même n'a pas d'indépendance sémantique
Pour les listes de blog ou de produits courants, est approprié. Cependant, lors de l'utilisation de plusieurs , il est recommandé de permettre aux lecteurs d'écran de naviguer entre les points de repère et d'identifier chaque article avec aria-labelledby ou aria-label (WCAG 2.4.6, niveau AA).
Lors de l'utilisation de aria-labelledby, assurez-vous que l'ID soit une valeur unique.
Ordre visuel et structure HTML
Modèle 1 : Aligner l'ordre visuel avec l'ordre HTML
<article class="article-card" aria-labelledby="article-title">
<img src="thumbnail.jpg" alt="">
<h3 id="article-title"><a href="#" class="card-link">記事タイトル</a></h3>
<p>記事の概要...</p>
<a href="#" class="card-detail-link">
<span class="visually-hidden">記事タイトル:</span>詳細を見る
</a>
</article>
L'ordre d'écriture HTML correspond complètement à l'ordre visuel, ce qui rend le code simple et intuitif.
Remarque : Le premier élément de est idéalement un titre, mais ce n'est pas une exigence absolue. Si vous privilégiez la correspondance avec l'ordre visuel, ce modèle convient.
Complément :
Les logiciels de reconnaissance vocale (Dragon, Voice Control, etc.) fonctionnent en se basant sur le texte affiché à l'écran. En utilisant visually-hidden (sr-only), le texte visuel est conservé et la manipulation par reconnaissance vocale devient possible. Voici des exemples d'implémentation avec des modèles appropriés et inappropriés pour les libellés de lien.
<!-- 以下は可視テキストがアクセシブルな名前に含まれているのでOK -->
<a href="#" id="link-text" class="card-detail-link" aria-labelledby="link-text article-title">
詳細を見る
</a>
<a href="#" aria-label="詳細を見る:記事タイトル">
詳細を見る
</a>
<!-- 以下は可視テキストがアクセシブルな名前に含まれていないのでNG -->
<a href="#" class="card-detail-link" aria-labelledby="article-title">
詳細を見る
</a>
<a href="#" class="card-detail-link" aria-label="記事タイトル">
詳細を見る
</a>
Modèle 2 : Ajustement de l'ordre visuel avec CSS order
<article class="article-card" aria-labelledby="article-title">
<h3 id="article-title"><a href="#">記事タイトル</a></h3>
<p>記事の概要...</p>
<a href="#" class="card-detail-link">
<span class="visually-hidden">記事タイトル:</span>詳細を見る
</a>
<img src="thumbnail.jpg" alt="">
</article>
.article-card {
display: flex;
flex-direction: column;
}
.article-card img {
order: -1;
}
Puisque le premier élément de est un titre, cette structure est sémantiquement plus préférable.
Pour les images décoratives (avec alt=""), il n'y a pas d'impact sur l'ordre de lecture (l'image est ignorée).
Attention :
- Si l'image a une signification et que l'attribut alt est spécifié, cette structure n'est pas appropriée car l'ordre visuel et l'ordre de lecture diffèrent.
- L'ordre de tabulation du clavier suit l'ordre du HTML. Si la carte contient plusieurs éléments pouvant recevoir le focus, vérifiez que l'ordre de focus ne rompt pas le flux logique.
Lorsque vous souhaitez rendre toute la zone de la carte cliquable
Modèle 3 : Rendre toute la carte cliquable avec un pseudo-élément
Avec cette méthode, un pseudo-élément du lien de titre couvre toute la carte, et « Voir plus » devient une ornementation visuelle avec un .
Garder « Voir plus de détails » en tant que avec tabindex="-1" ou aria-hidden="true" crée du bruit dans la liste des liens des lecteurs d'écran et en mode navigation par éléments. Il est donc préférable de l'utiliser comme .
<article class="article-card" aria-labelledby="article-title">
<img src="thumbnail.jpg" alt="">
<h3 id="article-title"><a href="#" class="card-link">記事タイトル</a></h3>
<p>記事の概要...</p>
<span class="card-detail-link">詳細を見る</span>
</article>
.article-card {
position: relative;
}
.card-link::after {
content: '';
position: absolute;
inset: 0;
z-index: 1;
}
.card-link:focus-visible {
outline: none;
}
.card-link:focus-visible::after {
outline: 2px solid currentColor;
outline-offset: 2px;
}
/* カード内に複数のリンクがある場合の例 */
.article-card a:not(.card-link) {
position: relative;
z-index: 2;
}
Avantages :
- Conservation d'une structure sémantique
- Lecture naturelle par les lecteurs d'écran
- Possibilité de placer plusieurs liens dans la carte (catégories, étiquettes, liens auteur, etc.)
Inconvénients :
- Gestion de
z-indexrequise (bien que cela ne pose pas de problème une fois configuré)
Modèle 4 : Envelopper la carte entière dans un
Avec cette approche, la carte entière devient un lien unique, donc « Voir plus de détails » devient naturellement un .
<article class="article-card" aria-labelledby="article-title">
<a href="#" class="card-link">
<img src="thumbnail.jpg" alt="">
<h3 id="article-title">記事タイトル</h3>
<p>記事の概要...</p>
<span class="card-detail-link">詳細を見る</span>
</a>
</article>
Avantages :
- Implémentation simple
- Ajustement facile du CSS
Inconvénients :
- Certains lecteurs d'écran peuvent lire tous les textes de manière concaténée (notamment VoiceOver qui les lit comme « titre de l'article résumé de l'article... voir les détails, lien »)
- Impossible de placer plusieurs liens dans une carte
Exemples pour chaque modèle
Conclusion
Il existe plusieurs approches pour implémenter un composant de type carte accessible. L'important à comprendre est qu'il n'existe pas « une seule bonne solution », et que la meilleure implémentation varie selon le contexte.
Lors de l'implémentation, il est important de tenir compte des points suivants.
- Choisir une implémentation qui ne crée pas de difficultés pour les utilisateurs réels
- Considérer la signification de l'image, l'objectif de la carte et la structure globale du site
- Privilégier une implémentation pratique et facile à maintenir
Passé du DTP au monde du web, il s'est avéré être un « sage des techniques » maîtrisant le markup, le frontend, la direction et l'accessibilité. Actif depuis la fondation de Liberogic, il est devenu une référence incontournable en interne. Récemment, il explore l'optimisation via des prompts IA, se demandant « Pourrions-nous déléguer davantage la conformité en accessibilité à l'IA ? ». Sa technologie et sa réflexion continuent d'évoluer.
Futa
Spécialiste en accessibilité web certifié par l'IAAP (WAS) / Ingénieur markup / Ingénieur frontend / Directeur web