Den folgenden Beitrag von Tobias Roppelt auf Gehirngerecht Digital fand ich super – gut geschrieben, hilfreich und hochrelevant. Sehr praxisnah geht es in "Barrierefreie Cards erstellen – Schritt-für-Schritt-Anleitung" darum, wie Du Teaser (für Beiträge oder Produkte) barrierefrei implementierst.
Denn obwohl Teaser – oder wie Tobias sie nennt: Cards – ziemlich verbreitet sind im Web, sind sie aus Screenreader-Sicht eher selten so schön umgesetzt. Drei verbreitete Probleme hat Tobias anschaulich visualisiert:
Wir schauen uns einmal die verschiedenen Probleme genauer an. Am Ende gibt es dann einen Vorschlag für die barrierefreie Gestaltung von Teasern.
Mehrere Links von A nach B
Wenn verschiedene Elemente des Teasers einzeln verlinkt sind – das Bild, die Überschrift, der Text, ein "Weiterlesen"-Button – und die Linkliste zur Navigation gewählt wird (was durchaus eine genutzte Option ist) dann taucht jeder Link einzeln in dieser Liste auf, die der Screenreader vorliest. Ziemlich anstrengend, wenn dann pro Teaser ein und derselbe Link 4x vorgelesen wird. Gerade bei einer Übersichtsseite mit vielen Teasern der Horror und UX-technisch furchtbar.
Aus SEO-Sicht ist vor allem dieser Punkt auch immer wieder ein Thema. Welchen Link bewertet Google, wenn wir mehrfach von Seite A auf Seite B linken? Dazu hat Jolle in Ausgabe 152 ein Experiment von Cyrus Shepard aufgegriffen.
Alles in einem a-Tag verpackt
Eine beliebte Möglichkeit, um dem "Mehrere Links von A nach B" Problem zu begegnen: Anstatt die Teaser-Elemente einzeln zu verlinken, einen a-Tag außenrum legen. Denn so macht es auch keinen Unterschied, wohin Nutzer\*innen klicken oder tappen – sie erwischen den Link immer. Google und andere Suchmaschinen haben innerhalb des Links dann auch genug und relevantes Futter, um zu verstehen, worum es auf der Zielseite geht.
Denn sowohl leere als auch generische Linktexte sind aus verschiedenen Gründen nicht zu empfehlen:
-
In Ausgabe 188 erklärt Sandra unter anderem, warum leere Linktexte nicht barrierefrei sind.
-
In Ausgabe 145 befasst Sandra sich mit generischen Linktexten und wie wir sie via ScreamingFrog finden können.
Allerdings ist das einmal komplett um den Teaser gewickelte a-Tag auch nicht die allerbeste Lösung: Wenn man den Teaser mit dem Screenreader ansteuert, bekommt man den kompletten Inhalt des Teasers vorgelesen, jeden alt-Text, jede Headline, jede Beschreibung, etc. – einfach alles. Nutzer\*innen sind dem ausgeliefert und haben nicht die Freiheit, innerhalb des Teasers zu navigieren und sich nur einzelne Inhalte gezielt vorlesen zu lassen.
Chaos in der Reihenfolge
Priorisierung ist wichtig – und für Menschen, die einen Screenreader nutzen, anders. Für sie ist es beispielsweise enorm hilfreich, wenn erst der Titel und dann die Beschreibung vorgelesen wird, auch wenn das erste Element des Teasers häufig ein Bild ist.
Vor allem bei mehreren Teasern verschwimmen bei einer unlogischen Reihenfolge beim Vorlesen oft die Grenzen – wo fing der eine Teaser nun nochmal an und hörte der andere auf?
Blaupause für barrierefreie und SEO-friendly Teaser
Tobias zeigt in seinem Beitrag sehr anschaulich, wie der ideale Teaser aussehen sollte und erklärt direkt, warum.
Am besten schaust Du Dir das inklusive Code-Beispielen direkt in seinem Artikel an.
Aus SEO-Sicht stolpert man dann am Ende nur noch über die Auszeichnung der Teaser-Überschrift mit einem h-Element, am Beispiel einer h3. Ganz nüchtern betrachtet ist "a um h" kein regelkonformes HTML. Auch wenn Screenreader damit kein Problem haben. Zudem betonen wir es, beispielsweise in Redaktions-Workshops, immer und immer wieder: Überschriften sind dazu da, um den Hauptinhalt einer Seite zu gliedern. Teaser verlinken auf eine andere Seite und gehören daher in dem Sinne nicht zum Hauptinhalt der Seite, auf der sie zu finden sind. Deswegen sollen hier keine h-Elemente zum Einsatz kommen.
Zudem haben sich Sandra und ich im Austausch dazu die Frage gestellt: *Ist es wirklich im Sinne der Nutzer\innen, hier h-Elemente zu nutzen? Stellen wir uns eine Übersichtsseite mit 50 Teasern vor, die man alle durchtabben und vorlesen lassen kann oder wohl eher muss, wenn man über die Headlines navigiert. Dabei spielt der Kontext auch eine Rolle. Bei einer Zeitung ist es vielleicht sinnvoller als bei einem Online-Shop? Aus der realen Welt kennen wir Beispiele, in denen die neuesten Teaser h-Elemente haben, die älteren jedoch nicht mehr – womöglich ein gangbarer Kompromiss?
Aus SEO-Sicht (und auch soweit ich es bewerten kann, UX-Sicht) plädiere ich also dafür, hier kein h-Element zu nutzen. Ich möchte aber nicht ausschließen, dass es noch andere gute Gründe gibt, die für den Einsatz von h-Elementen an der Stelle sprechen, die ich (noch) nicht kenne.
Noch ein bisschen Lesefutter zu Links & Barrieren
Schon eine Weile her, trotzdem noch spannend: In Ausgabe 84 habe ich über "Links & Linktexte aus Design-Sicht" geschrieben.
Noch ziemlich frisch: Philipp hat Anfang des Jahres auf Gehirngrececht einen Gastbeitrag zu barrierefreien Ankertexten beigesteuert: "So schreibst du barrierefreie Ankertexte, die alle lieben"