Barrierefreie Cards mit HTML und CSS umsetzen

5.2.2025
Absurde Illustration: Ein Strichmännchen mit langem mantel und großem Hut balanciert auf Säulen, deren Oberseite aus Spielkarten besteht. An der Seite hangelt eine zweite Figur.

Cards sind ein beliebtes Inhaltselement auf Blogs und Online-Shops. So können sie einfach und schnell mit HTML und CSS barrierefrei umgesetzt werden.

Inhaltsverzeichnis

Will ich jetzt schon Karten spielen auf dem stolperfreien Blog? Nein, natürlich nicht. Sogenannte Cards, also Karten, haben sich auf Websites trotzdem zu einem beliebten Designelement gemausert. Häufig bestehen sie aus einem Bild, einer Überschrift und einem kurzen Teasertext und verlinken auf eine Unterseite. Sie werden beispielsweise auf Blog-Übersichten oder in Produkt-Kategorien eines Online-Shops eingesetzt. Doch wie setzt man diese Cards mit passendem HTML und CSS barrierefrei um? Los geht’s.

Übliche Cards und ihre Fehler

Cards sind zwar weit verbreitet, jedoch genauso oft nicht für die Nutzung mit Screenreadern und der Tastatur optimiert. Werfen wir einen Blick auf die üblichen Probleme.

Schlechte Reihenfolge

Eine typische Card beginnt mit einem Bild – sei es das wichtigste Produktbild oder ein dekoratives Teaserbild – da Bilder Aufmerksamkeit erregen und Emotionen wecken. Erst darauf folgt die Überschrift und der restliche Inhalt. Genau diese Reihenfolge wird dann auch im HTML gepflegt.

Doch inhaltlich ist diese Reihenfolge ein Problem. Zum Einen gehört auch das Bild zu dem Inhaltselement, das von der Überschrift eingeleitet wird und nicht zu dem davor. Es sollte also auch nach der Überschrift im HTML-Markup stehen. Zum Anderen können Nutzer von Screenreadern anhand der Überschriften schnell und effizient auf einer Website navigieren. Sie können sich so schnell einen Überblick über die Inhalte verschaffen und gewünschte Seitenbereiche anhand der Überschrift direkt anspringen. Steht bereits Inhalt vor dieser Überschrift, kann dieser übersehen werden.

Redundante Links

Einige Cards sind so umgesetzt, dass der Nutzer viele Möglichkeiten hat, die entsprechende Unterseite zu erreichen. Das Bild wird verlinkt, die Überschrift und oft genug gibt es einen zusätzlichen Link in Form eines Buttons unter dem Text – der typische „Mehr erfahren“- oder „Weiterlesen“-Link.

Hier ein Beispiel einer solchen Card:

<div class="card">
  <a href="LINK">
    <img src="BILD" alt="ALTERNATIVE" />
  </a>
  <h4>
    <a href="LINK">ÜBERSCHRIFT</a>
  </h4>
  <p>TEASER</p>
  <a href="LINK">LINKTEXT</a>
</div>

Für Nutzer der Maus ist das angenehm, sie finden auf beliebige Art und Weise ihr Ziel. Nutzer von Screenreadern und anderen Assistenzsystemen hingegen bekommen jeden dieser Links einzeln vorgelesen. Sie können sich eine Liste aller Links einer Seite erstellen lassen. Redundante Links blähen diese nur unnötig auf.

Auch bei der Nutzung der Tabulatortaste sind redundante Links frustrierend, denn Nutzer kommen so nur langsam voran und landen bis zu dreimal auf derselben Card.

Wieso „Weiterlesen“ und „Mehr erfahren“ keine geeigneten Linktexte sind, habe ich übrigens im Artikel Einen barrierefreien Linktext verfassen – von „Hier klicken“ zu Klartext schon einmal genauer beschrieben.

Alles umfassende Links

Um genau dieses Problem der redundanten Links zu lösen, sieht man mindestens genauso oft die Variante eines einzelnen Links, der die gesamte Card umfasst. In ihm enthalten sind Bild, Überschrift, Text und gegebenenfalls ein falscher Button. Anklickbar ist dann die gesamte Kachel.

So könnte die Card aussehen:

<a href="LINK" class="card">
  <img src="BILD" alt="ALTERNATIVE" />
  <h4>ÜBERSCHRIFT</h4>
  <p>TEASER</p>
  <span>LINKTEXT</span>
</a>

Der Vorteil ist klar: es gibt nur noch einen einzelnen Link in den Linklisten und in der Tabreihenfolge. Syntaktisch korrekt ist diese Lösung auch, keine Angst. Links dürfen nahezu alle anderen Elemente enthalten (außer solche, die selbst Interaktionen besitzen wie andere Links, Eingabefelder oder Buttons).

Der Große Nachteil liegt in seinem scheinbaren Vorteil. Denn Screenreader lesen den gesamten Linktext am Stück vor. Nutzer können also nicht entscheiden, ob sie den Alternativtext des Bildes, die Überschrift oder den Teasertext vorgelesen bekommen wollen. Außerdem gehen zusätzliche strukturelle Informationen verloren. Auch bei dieser Lösung wird Nutzern von Screenreadern also kein effizientes Arbeiten ermöglicht.

Cards barrierefrei umsetzen

Nachdem wir nun mögliche Barrieren unserer Cards kennen schauen wir uns an, wie wir diese mit einfachen Änderungen an unserem HTML und ein wenig CSS beheben können.

HTML Grundgerüst für Cards

Zunächst benötigen wir das passende Markup um alle 3 der oben genannten Probleme zu beheben. Dabei achten wir also insbesondere auf folgende Punkte:

  • Wir verwenden nur einen Link.
  • Dieser Link hat einen möglichst kurzen, aber sprechenden Linktext.
  • Die Überschrift ist das erste Element der Card.

Also starten wir mit folgendem Aufbau:

<article class="card">
  <h4>
    <a href="LINK">
      ÜBERSCHRIFT
    </a>
  </h4>
  <p>TEASER</p>
  <img src="BILD" alt="ALTERNATIVE" />
  <span aria-hidden="true">LINKTEXT</span>
</article>

Schauen wir uns nun nach und nach den Quelltext an. Den Rahmen bildet ein <article>, womit wir ein semantisches Element anstatt dem generischen <div> nutzen. Artikel werden immer dann eingesetzt, wenn der Inhalt unabhängig von den restlichen Texten auf der Seite zu sehen ist. Das trifft auf Artikel einer Zeitung zu, daher der Name. Man kann es aber genauso gut für Teaser auf andere Seiten eines Blogs oder Online-Shops einsetzen.

Anschließend folgt, wie geplant, zuerst die Überschrift in der für Ihre Struktur passenden Überschriftenebene (meist h2 bis h4). Diese verlinken wir als einziges Element und haben so einen aussagekräftigen Linktext. Erst danach folgen die weiteren Texte und das Bild. Je nach eigener Prioritäten kann man hier auch die Position des Bildes ändern.

Zum Schluss folgt, wenn im Design unbedingt gewünscht, ein falscher Button. Den braucht es zwar technisch nicht, als Call-To-Action ist er aber manchmal gewünscht um deutlich zu machen, dass man hier zu einer Unterseite wechseln kann. Dieser ist für die Verwendung vollkommen nutzlos und verwirrt die Nutzer von Screenreadern eher. Deshalb wird er dank aria-hidden="true" für Assistenzsysteme ausgeblendet.

So werden zunächst also alle genannten Probleme gelöst. Doch nun sieht unsere Card nicht mehr aus, wie zuvor. Es fehlt also noch das passende CSS.

Mit CSS die Card nach eigenen Wünschen gestalten

Durch das neue Markup haben wir uns nun leider Probleme geschaffen, die vorher keine waren. Diese lassen sich jedoch durch ein wenig CSS lösen.

Korrektur der Reihenfolge

Die meisten Designer und Nutzer sind daran gewohnt, dass das Bild das erste visuelle Element einer Card ist. Nur weil dieses Bild im Markup erst nach der Überschrift eingefügt wird, sollte das nicht auch so angezeigt werden. Hier hilft uns das Flexbox-Modell im CSS, in dem wir die Reihenfolge von Elementen selbst steuern können. Über die Eigenschaft order kann jedem Element genau mitgeteilt werden, an welcher Stelle es angezeigt werden soll. Nun schaut unser Teaser schon wieder aufgeräumt aus.

.card {
  display: flex;
  flex-direction: column;
}

.card > img {
  order: 0;
}

.card > h4 {
  order: 1;
}

.card > p {
  order: 2;
}

.card > span {
  order: 3;
}

Eine gute Anleitung zur Anwendung des Flexbox-Models (auf englisch) gibt es übrigens auf css-tricks.com.

Die ganze Card klickbar machen

Im nächsten Schritt sorgen wir dafür, dass Nutzer der Maus wieder die gesamte Card anklicken können und nicht nur die Überschrift. Hierfür zaubern wir ein Pseudoelement in den Link, welches sich über die gesammte Kachel erstreckt.

.card {
  position: relative;
}

.card > h4 > a::before {
  content: "";
  position: absolute;
  inset: 0 0 0 0;
  z-index: 1;
}

Die Kachel sieht nun wieder aus wie geplant und funktioniert auch wie erwartet. Eine Kleinigkeit bleibt jedoch noch: nutzt man, wie empfohlen, eine Fokus-Outline, so wird diese trotz des Pseudoelements nur um die Überschrift gezeichnet. Da man aber eine insgesamt fokussierte Kachel anzeigen möchte, sollte dieser Rahmen auch die gesamte Kachel einschließen. Dazu fügen wir das letzte Schnipsel CSS hinzu.

.card:has(:focus-visible) {
    outline: 2px solid orange;
    outline-offset: 2px;
}

.card > h4 > a:focus-visible {
  outline: none;
}

Navigieren Sie doch jetzt einmal mit der Tastatur durch die einzelnen Varianten unserer Card. Sie werden schnell den Unterschied bemerken.

Wie kann man den Fokus eines Elementes eigentlich deutlich hervorheben? Das beantworte ich im Artikel Fokus auf CSS – focus, focus-within und focus-visible.

Fazit – barrierefreie Cards sind keine Hexenwerk

Sie sehen: mit dem passenden HTML-Grundgerüst und ein wenig Feenstaub mit CSS sind barrierefreie Cards kein Problem. Legen Sie sich diese am Besten als Template ab, wenn Ihr CMS das erlaubt, und nutzen Sie sie wann immer Sie sie benötigen. Dabei muss, wie man sieht, an der Optik und Nutzerfreundlichkeit für sehende Nutzer nichts verändert werden und es sind keine Kompromisse notwendig. Am Ende erreicht man aber eine effiziente Bedienbarkeit sowohl mit der Maus, als auch der Tastatur, mit Monitor und Screenreader.

Mehr entdecken

Das hat Ihnen gefallen? Dann verpassen Sie den nächsten nicht!

Jetzt per Newsletter erhalten
  • Absurde Illustration: Ein Mann mit einem Blumenstrauß als Kopf steht mit de Rücken zum Betrachter. Rechts und Links von ihm stehen 2 große Spiegel, in denen er sich betrachtet. Ein Spiegelbild hat einen Fisch als Kopf, das andere einen Stromstecker.