Topics

Modèles d'implémentation accessibles pour les composants de type carte

  • column

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-index requise (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.

  1. Choisir une implémentation qui ne crée pas de difficultés pour les utilisateurs réels
  2. Considérer la signification de l'image, l'objectif de la carte et la structure globale du site
  3. Privilégier une implémentation pratique et facile à maintenir

Auteur de cet article

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

Voir les articles de ce membre

Notre équipe fiable et nos capacités de réactivité font notre fierté

Chez Liberogic, nos équipes expérimentées sont reconnues pour diriger activement les projets et sont hautement appréciées par nos clients.
Nous assignons correctement un chef de projet et un directeur, et veillons à assurer le déroulement fluide de l'ensemble du projet. Nous évitons une augmentation inutile des coûts en engagements complets, en allouant les ressources de manière optimale. Notre approche est réputée pour sa rapidité dans la compréhension des besoins, la création et la soumission des devis.

* Veuillez noter que nous n'engageons pas activement de missions d'intégration type SES.

Slack, Teams, Redmine, Backlog, Asana, Jira, Notion, Google Workspace, Zoom, Webex, et pratiquement tous les principaux outils de gestion de projet et de communication que vous utilisez.

Avez-vous besoin d'aide pour la conformité en matière d'accessibilité web ?

Études de cas