Topics

Barrierefreie Implementierungsmuster für kartenbasierte Komponenten

  • column

Kartenbasierte Komponenten werden häufig in Artikelübersichten eingesetzt. Ihr Aufbau wirkt schlicht, doch unter Berücksichtigung der Barrierefreiheit ergeben sich überraschend anspruchsvolle Gestaltungsfragen.

Betrachten wir eine typische Karte von oben nach unten:

  • Bild
  • Artikeltitel
  • Artikelzusammenfassung
  • Details-Link

und sehen uns anschließend Implementierungsmuster für ein vertikales Layout an.

Wichtige Überlegungen beim Design

1. Visuelle Reihenfolge und HTML-Struktur

Screenreader lesen Inhalte grundsätzlich in der Reihenfolge des HTML-Codes vor. Im Erfolgskriterium 1.3.2 (Bedeutungstragende Reihenfolge, Stufe A) von WCAG 2.0 gilt als Grundprinzip, dass die visuelle Reihenfolge mit der HTML-Reihenfolge übereinstimmen sollte.

Die Reihenfolge mit CSS zu verändern, stellt jedoch nicht automatisch einen WCAG-Verstoß dar. Weichen visuelle und HTML-Reihenfolge voneinander ab, ist dies unproblematisch, solange der Inhalt verständlich bleibt. Entscheidend ist, dass die Situation im Einzelfall flexibel beurteilt wird.

2. Umgang mit Bildern

Bilder in Artikelkarten sind häufig dekorativ. Ist ein Artikeltitel vorhanden, wird der Inhalt ausreichend vermittelt, sodass eine Vorlesung der Bildbeschreibung meist nicht erforderlich ist.

Bei dekorativen Bildern genügt alt="".

<img src="thumbnail.jpg" alt="">

3. Beschriftung von Detaillinks

Allgemeine Formulierungen wie „Details ansehen“ sollten aus folgenden Gründen vermieden werden:

Visuelle Probleme

Ohne umgebenden Kontext ist nicht erkennbar, wohin der Link führt.

Probleme mit Screenreadern

Wird die Linkliste eines Screenreaders aufgerufen, lauten alle Links „Details ansehen“ und sind nicht voneinander zu unterscheiden.

Probleme mit Spracheingabe

Gibt es mehrere identische Texte, muss der Nutzer per Nummer auswählen, was die Bedienung umständlich macht.

Idealerweise sollte der Linktext für sich allein den Zweck erkennen lassen, etwa „Details zu [Name] ansehen“. Dieser Artikel behandelt jedoch die Umsetzung für den Fall, dass das Design „Details ansehen“ unverändert beibehalten werden soll.

4. Klickbare Bereiche von Karten

Zur Verbesserung der Nutzerfreundlichkeit soll häufig die gesamte Karte anklickbar sein. Es gibt mehrere Umsetzungsmöglichkeiten, die sich jedoch unterschiedlich auf die Barrierefreiheit auswirken.

5. Karte als article oder div umsetzen

Welche Variante passt, hängt von der Art des Inhalts ab.

<article>Geeignet, wenn:

  • Der Inhalt der Karte als eigenständiger Inhalt funktioniert

<div>Unbedenklich, wenn:

  • Sie lediglich als Gruppe von Links fungiert
  • Die Karte selbst keine eigenständige inhaltliche Bedeutung hat

Bei gewöhnlichen Blogbeitragsübersichten oder Produktlisten mit Karten ist <article>die Verwendung eines einfachen Links angemessen. Werden jedoch mehrere <article>Karten verwendet, empfiehlt es sich, die Navigation über Landmarken für Screenreader zu berücksichtigen und jeden Beitrag mithilfe von aria-labelledby oder aria-label eindeutig zu kennzeichnen (WCAG 2.4.6, Stufe AA).

Bei Verwendung von aria-labelledby ist darauf zu achten, dass die IDs eindeutig sind.

Visuelle Reihenfolge und HTML-Struktur

Muster 1: Visuelle Reihenfolge und HTML-Reihenfolge abgleichen

<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>

Da die Reihenfolge im HTML vollständig der visuellen Reihenfolge entspricht, ist dieses Muster einfach und intuitiv.

Hinweis: <article>Das erste Element sollte idealerweise eine Überschrift sein, ist aber keine zwingende Anforderung. Wenn die Übereinstimmung mit der visuellen Reihenfolge Priorität hat, ist dieses Muster unbedenklich.

Ergänzung:

Spracherkennungssoftware (z. B. Dragon, Voice Control) arbeitet auf Basis des auf dem Bildschirm angezeigten Textes. Durch die Verwendung von visually-hidden (sr-only) bleibt der sichtbare Text erhalten, sodass die Bedienung per Sprachsteuerung weiterhin möglich ist. Außerdem folgen Implementierungsbeispiele für zulässige und unzulässige Muster bei Linkbeschriftungen.

<!-- 以下は可視テキストがアクセシブルな名前に含まれているので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>

Muster 2: Visuelle Reihenfolge mit CSS order anpassen

<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;
}

Da <article>das erste Element eine Überschrift ist, entspricht diese Struktur semantisch besser.

Bei dekorativen Bildern (alt="") hat dies keinen Einfluss auf die Reihenfolge beim Vorlesen, da Bilder übersprungen werden.

Achtung:

  • Wenn ein Bild eine inhaltliche Bedeutung hat und ein alt-Attribut angegeben ist, eignet sich diese Struktur nicht, da sich die visuelle und die vorgelesene Reihenfolge dadurch unterscheiden.
  • Die Tab-Reihenfolge der Tastatur folgt der HTML-Reihenfolge. Wenn sich innerhalb einer Karte mehrere fokussierbare Elemente befinden, prüfen Sie daher, ob die Fokusreihenfolge den logischen Ablauf nicht unterbricht.

Wenn der klickbare Bereich der Karte vollständig sein soll

Muster 3: Gesamte Karte per Pseudoelement klickbar machen

Bei diesem Ansatz deckt das Pseudoelement des Titel-Links die gesamte Karte ab, während "Details ansehen" <span>nur noch als rein visuelles Gestaltungselement dient.

Selbst wenn "Details ansehen" <a>als Link belassen wird und tabindex="-1" bzw. aria-hidden="true" erhält, würde es in Linklisten von Screenreadern und im Element-Navigationsmodus nur störend wirken. Daher halte ich es für besser, es <span>als reines Dekorationselement umzusetzen.

<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;
}

Vorteile:

  • Die semantische Struktur bleibt erhalten
  • Wird von Screenreadern natürlich vorgelesen
  • Innerhalb der Karte können mehrere Links platziert werden (z. B. Kategorie, Tags, Autorenlinks)

Nachteile:

  • Die Verwaltung von z-index ist erforderlich (einmal richtig gesetzt, treten jedoch keine Probleme auf)

Muster 4: Gesamte Karte mit <a>umschließen

Bei diesem Ansatz wird die gesamte Karte zu einem einzigen Link, daher wird "Details ansehen" ganz natürlich <span>als Linktext verwendet.

<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>

Vorteile:

  • Einfache Implementierung
  • Einfache Anpassung des CSS

Nachteile:

  • Je nach Screenreader können alle Texte zusammenhängend vorgelesen werden (insbesondere bei VoiceOver etwa so: "Artikeltitel Artikelzusammenfassung ... Details ansehen, Link").
  • Innerhalb der Karte lassen sich keine mehreren Links platzieren.

Beispiele für die einzelnen Muster

Fazit

Für die Umsetzung barrierefreier kartenbasierter Komponenten gibt es mehrere Ansätze. Entscheidend ist, dass es nicht "das eine richtige" Implementierungsmuster gibt; die optimale Lösung hängt von der jeweiligen Situation ab.

Bei der Umsetzung ist Folgendes wichtig zu beachten.

  1. Eine Lösung wählen, die für die tatsächlichen Nutzer gut funktioniert
  2. Bildbedeutung, Zweck der Karte und Gesamtstruktur der Website berücksichtigen
  3. Praktische, leicht wartbare Implementierungen haben Vorrang

Über den Autor

Vom DTP in die Webwelt: Heute beherrscht er Markup, Frontend, Projektleitung und Barrierefreiheit gleichermaßen – ein wahrer "Techniker-Guru". Seit den Anfängen von Liberogic vielseitig im Einsatz und heute eine lebende Enzyklopädie im Team. Derzeit tüftelt er mit großer Begeisterung an effizienteren Abläufen durch gezielte Prompts – etwa mit der Frage: "Können wir bei der Barrierefreiheit nicht mehr auf KI setzen?" Technik und Denkweise entwickeln sich weiter.

Ayumu Futamata

IAAP-zertifizierter Web Accessibility Specialist (WAS) / Markup-Entwickler / Frontend-Entwickler / Webdirektor

Artikel dieses Teammitglieds ansehen

Fallstudien