Kurz und einfach erklärt
Viele Links und Knöpfe auf Websites haben keinen Namen. Ein Screenreader liest dann nur „Link“ oder „Schaltfläche“ vor. Wer nicht gut sieht, weiß so nicht, was der Knopf tut.
Jeder Link und jeder Knopf braucht einen Namen. Der Name sagt, was passiert. Zum Beispiel: „In den Warenkorb“.
Bei Knöpfen mit einem Bild fehlt der Name oft. Dann hilft ein Text, den nur der Screenreader liest. Bei einem Link mit dem Wort „mehr“ fehlt das Ziel. Dann hilft ein genauer Text.
Was man sieht, soll auch im Namen stehen. Sonst findet die Sprachsteuerung den Knopf nicht.
Wir prüfen Links und Knöpfe auf Ihrer Website. Wir zeigen Ihnen, wie Sie die Fehler beheben.
Ein Screenreader sagt bei einem Herz-Symbol ohne Namen nur „Schaltfläche“, bei einem verlinkten Produktbild ohne Alternativtext oft die Adresse und bei einer Reihe von Links mit dem Text „mehr“ ein ums andere Mal dasselbe Wort. Genau diese Befunde gehören zu den häufigsten, die eine automatisierte Prüfung meldet: Leere Links fanden sich im Februar 2026 auf 46,3 Prozent (WebAIM Million 2026) der untersuchten Startseiten, leere Buttons auf 30,6 Prozent (WebAIM Million 2026), und beide Werte sind gegenüber dem Vorjahr gestiegen. Dieser Beitrag zeigt, woher ein Bedienelement seinen zugänglichen Namen bekommt, welche WCAG-Kriterien dabei zusammenwirken und wie sich Icon-Buttons, Bild-Links und „mehr“-Links reparieren lassen. Zum Schluss beschreiben wir die Prüfung über die Linkliste des Screenreaders, mit der sich eine Vorlage ohne zusätzliches Werkzeug durchgehen lässt.
Das Wichtigste in Kürze
- Leere Links stehen auf 46,3 Prozent, leere Buttons auf 30,6 Prozent der Startseiten der eine Million meistbesuchten Websites (WebAIM Million 2026); beide Anteile sind gegenüber 2025 gestiegen.
- Jeder Link und jeder Button braucht einen Namen, der seinen Zweck nennt. WCAG 2.2 verlangt das auf Stufe A über SC 4.1.2 (Name, Rolle, Wert) und SC 2.4.4 (Linkzweck im Kontext) (W3C, WCAG 2.2).
- Icon-Buttons erhalten ihren Namen über optisch versteckten Text oder aria-label, das Symbol wird mit aria-hidden ausgeblendet. Benannt wird die Funktion, nicht die Form: „Schließen“ statt „X“ (W3C, APG).
- Bild-Link und Textlink zum selben Ziel gehören in ein gemeinsames a-Element, das Bild bekommt dann ein leeres alt (W3C, Technik H2). Ein verlinktes Bild ohne Alternativtext liefert keinen brauchbaren Linknamen.
- Wer eine sichtbare Beschriftung per aria-label überschreibt, verletzt leicht SC 2.5.3: Der Name muss den sichtbaren Text enthalten, möglichst an seinem Anfang (W3C, WCAG 2.2, SC 2.5.3).
- Geprüft wird über die Linkliste des Screenreaders, etwa NVDA+F7: Jeder Eintrag muss ohne Umgebung verständlich sein. Leere Einträge, Adressen, Dateinamen und mehrfach „mehr“ sind Befunde für die Vorlage.
Was ein zugänglicher Name ist und woher er kommt
Jedes Bedienelement einer Website hat für assistive Technik drei Eigenschaften: eine Rolle wie Link, Schaltfläche oder Kontrollkästchen, gegebenenfalls einen Zustand wie gedrückt oder ausgeklappt, und einen Namen. Den Namen liest der Screenreader vor, die Spracheingabe nutzt ihn als Befehl, und in der Linkliste erscheint er als einziger Text. Bei Links und Schaltflächen ist der zugängliche Name der einzige Inhalt, den Screenreader-Nutzende von dem Element wahrnehmen (W3C, APG). Fehlt er, bleibt nur die Rolle übrig: „Schaltfläche“ oder „Link“, ohne jeden Hinweis darauf, was passiert.
Woher der Name kommt, regelt eine feste Rangfolge. Bei einem einfachen Link oder Button ist es der enthaltene Text, bei einem verlinkten Bild dessen alt-Attribut. Die Attribute aria-labelledby und aria-label haben Vorrang vor diesen Quellen und überschreiben den sichtbaren Text, selbst wenn er korrekt mit dem Element verknüpft ist (W3C, Understanding SC 2.5.3). Ganz am Ende stehen title und placeholder: Browser greifen auf sie nur als Notlösung zurück, und das Ergebnis ist meist ein schwacher Name (W3C, APG). Die ARIA Authoring Practices fassen das in fünf Grundregeln (W3C, APG) zusammen: Warnungen beachten und gründlich testen, sichtbaren Text bevorzugen, native HTML-Technik bevorzugen, Notlösungen des Browsers vermeiden und kurze, nützliche Namen formulieren.
Für die Praxis heißt das: Ein <button> mit Text ist gut benannt, ohne dass ein einziges ARIA-Attribut nötig wäre. Probleme entstehen vor allem dort, wo Text fehlt, also bei Symbolen, Bildern und Elementen, die nur über einen CSS-Hintergrund gestaltet sind, und dort, wo nachträglich ein aria-label über einen vorhandenen Text gelegt wird. Einen allgemeinen Überblick über Rollen, Landmarken und Überschriften gibt unser Beitrag zur Screenreader-Optimierung; hier geht es ausschließlich um die Namen von Links und Buttons.
Ein Befund, mehrere Kriterien: WCAG 2.4.4, 2.5.3 und 4.1.2
In einem Prüfbericht taucht ein schlecht benannter Link selten nur unter einer Nummer auf. Mehrere Erfolgskriterien der WCAG 2.2 greifen ineinander, alle auf Stufe A und damit Teil jeder Prüfung nach Stufe AA (W3C, WCAG 2.2). Die Tabelle ordnet sie den typischen Befunden zu.
| Kriterium (W3C, WCAG 2.2) | Stufe | Was es verlangt | Typischer Befund |
|---|---|---|---|
| 4.1.2 Name, Rolle, Wert | A | Name und Rolle jedes Bedienelements sind programmatisch ermittelbar | Icon-Button ohne Text und ohne aria-label |
| 2.4.4 Linkzweck (im Kontext) | A | Zweck jedes Links aus dem Linktext oder aus Linktext plus programmatisch ermitteltem Kontext erkennbar | „mehr“ ohne Bezug, verlinktes Bild ohne alt |
| 2.5.3 Beschriftung im Namen | A | Der Name enthält den sichtbar dargestellten Text | sichtbar „Jetzt kaufen“, angesagt „Bestellung abschließen“ |
| 1.1.1 Nicht-Text-Inhalt | A | Ein Bedienelement aus Nicht-Text hat einen Namen, der seinen Zweck beschreibt | Lupen-Bild als Suchknopf mit alt „lupe.svg“ |
SC 4.1.2 nennt ausdrücklich auch Links und Komponenten, die per Skript erzeugt werden (W3C, WCAG 2.2, SC 4.1.2). SC 2.4.4 lässt Kontext zu: Der Zweck darf sich aus demselben Satz, Absatz, Listenpunkt oder derselben Tabellenzelle ergeben (W3C, Understanding SC 2.4.4). Die strengere Fassung SC 2.4.9 verlangt einen Mechanismus, mit dem sich der Zweck jedes Links allein aus dem Linktext erkennen lässt, gehört aber zur Stufe AAA (W3C, WCAG 2.2, SC 2.4.9). SC 2.5.3 greift nur, wenn eine sichtbare Textbeschriftung existiert; ein reines Symbol fällt nicht darunter. Fehlt einem Element mit sichtbarem Text der Name ganz, verletzt es 4.1.2 und 2.5.3 zugleich (W3C, Understanding SC 2.5.3).
Rechtlich ist das kein Detail. Das Barrierefreiheitsstärkungsgesetz gilt für Dienstleistungen, die für Verbraucher nach dem 28. Juni 2025 (BFSG, § 1) erbracht werden, darunter der elektronische Geschäftsverkehr. Nach § 12 Nummer 3 BFSGV müssen Webseiten auf konsistente und angemessene Weise wahrnehmbar, bedienbar, verständlich und robust gestaltet sein (BFSGV, § 12). Für Webinhalte verweist die europäische Norm EN 301 549 auf die WCAG; die Regelungskette erklärt unser Beitrag zur EN 301 549, die Pflichten im Überblick stehen unter BFSG-Anforderungen. Verstöße können je nach Tatbestand mit einer Geldbuße bis zu hunderttausend Euro (BFSG, § 37) geahndet werden.
Wie verbreitet leere Links und Buttons sind
Zahlen dazu liefert die jährliche Auswertung WebAIM Million. Für die Ausgabe 2026 hat WebAIM die Startseiten der 1.000.000 (WebAIM Million 2026) meistbesuchten Websites automatisiert mit dem Prüfwerkzeug WAVE untersucht, die Ergebnisse stammen aus dem Februar 2026 (WebAIM Million 2026). Leere Links fanden sich auf 46,3 Prozent (WebAIM Million 2026) der Startseiten, nach 45,4 Prozent (WebAIM Million 2026) im Vorjahr. Der Anteil mit leeren Buttons stieg von 29,6 Prozent auf 30,6 Prozent (WebAIM Million 2026). Beide gehören zu den Fehlerarten, die seit 7 Jahren (WebAIM Million 2026) unverändert die Liste der häufigsten Befunde bilden.
Hinzu kommen Links, die zwar Text haben, aber keinen brauchbaren: 15,2 Prozent (WebAIM Million 2026) der Startseiten verwendeten mehrdeutige Linktexte wie „hier klicken“, „mehr“ oder „weiter“, gegenüber 13,7 Prozent (WebAIM Million 2026) im Vorjahr. Auf diesen Seiten standen im Schnitt 5,3 (WebAIM Million 2026) solcher Links. Ein Teil des Problems geht auf Bilder zurück: 45 Prozent (WebAIM Million 2026) der Bilder ohne Alternativtext waren verlinkte Bilder, und jedes vierte verlinkte Bild hatte keinen Alternativtext (WebAIM Million 2026).
Der Web Almanac des HTTP Archive kommt mit anderer Methode zu einem ähnlichen Bild. Er wertet einen monatlichen Crawl über 17 Millionen Websites (Web Almanac 2025) mit Start- und Unterseiten aus. Danach haben etwa 9 Prozent der Buttons am Desktop und 11 Prozent auf Mobilgeräten keinen zugänglichen Namen (Web Almanac 2025). Bei 57 Prozent der Desktop-Buttons stammt der Name aus dem Inhalt, bei 28 Prozent aus einem aria-label (Web Almanac 2025). Die Autoren beobachten einen anhaltenden Anstieg um 4 bis 5 Prozent bei Buttons, die allein über aria-label ohne sichtbare Beschriftung benannt werden (Web Almanac 2025), also eine wachsende Lücke zwischen dem, was man sieht, und dem, was angesagt wird.
Wie stark das im Alltag stört, zeigt die Umfrage von WebAIM unter Screenreader-Nutzenden. Befragt wurde im Dezember 2023 und Januar 2024 (WebAIM Screen Reader Survey 2024), es kamen 1.539 gültige Antworten zusammen (WebAIM Screen Reader Survey 2024). In der Rangliste der problematischsten Elemente stehen „Links oder Buttons, die keinen Sinn ergeben“ auf Platz 3 (WebAIM Screen Reader Survey 2024), hinter CAPTCHA und hinter Menüs, Tabs und Dialogen, die sich nicht wie erwartet verhalten.
Leer ist nur die Untergrenze
Muster 1: Icon-Buttons mit Namen versehen
Herz für die Merkliste, Warenkorb, Lupe, Schließen-Kreuz, Pfeile im Karussell: Symbolschaltflächen sind eine typische Quelle leerer Buttons. Der Code sieht meist so aus wie im ersten Beispiel unten, ein <button> mit einer SVG-Grafik darin, aber ohne Text. Der Screenreader sagt dann nur „Schaltfläche“. Für die Reparatur gibt es zwei gleichwertige Wege. Entweder steht im Button ein Text, der nur optisch ausgeblendet ist, etwa über eine Klasse visually-hidden, die den Text aus dem Bild nimmt, ihn aber im Zugänglichkeitsbaum lässt. Oder der Button bekommt ein aria-label. Das Symbol selbst wird in beiden Fällen mit aria-hidden="true" ausgeblendet, damit kein Grafikname dazwischenfunkt.
<!-- Befund: Schaltfläche ohne Namen -->
<button class="tile__fav">
<svg viewBox="0 0 24 24"><path d="..."/></svg>
</button>
<!-- Reparatur A: optisch versteckter Text im Button -->
<button class="tile__fav" aria-pressed="false">
<svg aria-hidden="true" viewBox="0 0 24 24"><path d="..."/></svg>
<span class="visually-hidden">Merken: Wanderschuh A</span>
</button>
<!-- Reparatur B: aria-label, wenn kein Text ins Markup soll -->
<button class="dialog__close" aria-label="Schließen">
<svg aria-hidden="true" viewBox="0 0 24 24"><path d="..."/></svg>
</button>Für den Namen selbst gelten die Empfehlungen der APG. Benannt wird die Funktion, nicht die Form, also „Schließen“ statt „X“ (W3C, APG). Das unterscheidende Wort steht vorn, bei Aktionen meist das Verb, und für viele Elemente genügen ein bis drei Wörter (W3C, APG). Die Rolle gehört nicht in den Namen: Ein Button mit dem Namen „Schaltfläche Schließen“ wird doppelt angesagt, weil der Screenreader die Rolle ohnehin nennt (W3C, APG). Stehen auf einer Übersicht viele Herz-Buttons, braucht jeder einen eigenen Namen wie „Merken: Wanderschuh A“, denn Elemente mit gleicher Rolle sollen unterscheidbare Namen tragen, sofern sie nicht wirklich dasselbe tun (W3C, APG).
Ein Sonderfall sind Umschalter wie das Merken-Herz. Hier bleibt der Name gleich, und der Zustand wechselt über aria-pressed. Die APG betonen, dass sich die Beschriftung eines Umschalters beim Zustandswechsel nicht ändern darf (W3C, APG); der Screenreader sagt dann etwa „Merken: Wanderschuh A, Umschalter, gedrückt“. Alternativ wechselt der Name zwischen „Merken“ und „Von der Merkliste entfernen“, dann entfällt aria-pressed. Beides zu mischen erzeugt widersprüchliche Ansagen. Wer die Vorlage einer ganzen Produktseite prüft, findet die übrigen Bausteine in unserem Beitrag zur barrierefreien Produktseite.
Muster 2: Bild-Links und verlinkte Logos
Bei einem verlinkten Bild ist das alt-Attribut der Linkname. Fehlt es, greifen Screenreader häufig auf den Dateinamen oder die Zieladresse zurück, und die Linkliste füllt sich mit Einträgen wie „produkt-4711-thumb.jpg“. Das verletzt SC 1.1.1, denn ein Bild, das als Bedienelement dient, braucht einen Namen, der seinen Zweck beschreibt (W3C, WCAG 2.2, SC 1.1.1), und zugleich SC 2.4.4. Der Alternativtext eines verlinkten Bildes beschreibt deshalb das Ziel, nicht das Motiv: „Wanderschuh A, Details“ statt „brauner Schuh auf Holzboden“.
Beim Logo in der Kopfzeile gilt dasselbe. Führt es zur Startseite, nennt der Alternativtext den Anbieter und das Ziel, etwa „Name des Unternehmens, Startseite“. Ein Logo, das nur als CSS-Hintergrund eingebunden ist, hat gar keinen Text; dann braucht der Link ein aria-label oder einen optisch versteckten Text. Wie informative, dekorative und funktionale Bilder zu unterscheiden sind, behandelt unser Beitrag zu Alt-Texten.
Auf Produktkacheln steht oft ein verlinktes Bild direkt neben einem Textlink zum selben Ziel. Für Tastatur- und Screenreader-Nutzende sind das zwei aufeinanderfolgende, gleiche Links. Die W3C-Technik H2 setzt Bild und Text in ein gemeinsames <a>-Element und gibt dem Bild ein leeres alt=""; dann gibt es nur einen Link, und die Linkliste enthält keine Dublette (W3C, Technik H2). In einer Übersicht mit vielen Kacheln spart das ebenso viele Tabulatorschritte, wie es Kacheln gibt.
<!-- Befund: zwei Links zum selben Ziel, das Bild ohne alt -->
<a href="/wanderschuh-a/"><img src="schuh-a.jpg"></a>
<a href="/wanderschuh-a/">Wanderschuh A</a>
<!-- Reparatur: ein Link, das Bild ist Beiwerk -->
<a href="/wanderschuh-a/">
<img src="schuh-a.jpg" alt="">
Wanderschuh A
</a>Muster 3: „mehr“-Links mit Ziel im Namen
„Mehr“, „Weiterlesen“, „Details“ oder „Hier klicken“ sind nach SC 2.4.4 nicht automatisch ein Verstoß. Das Kriterium lässt zu, dass sich der Zweck aus dem programmatisch ermittelten Kontext ergibt, etwa aus demselben Satz, Absatz oder Listenpunkt (W3C, Understanding SC 2.4.4). Das W3C empfiehlt aber, den Zweck nach Möglichkeit im Linktext selbst zu nennen, weil assistive Technik eine Liste aller Links der Seite anbieten kann und dort der Kontext fehlt (W3C, Understanding SC 2.4.4). Mehrere Einträge „mehr“ sind in dieser Liste nicht zu unterscheiden. Wo kontextabhängiger Linktext unvermeidbar ist, gehört er ans Ende des Satzes, der das Ziel beschreibt, nicht an den Anfang (W3C, Understanding SC 2.4.4).
Für die Reparatur gibt es drei Wege, hier in der Reihenfolge, in der wir sie empfehlen:
- Sichtbaren Text ändern: „Details zu Wanderschuh A“ statt „mehr“. Das ist die robusteste Lösung, weil sichtbarer Text und Name übereinstimmen und die Seite für alle verständlicher wird.
- Sichtbaren Text ergänzen: „Mehr“ bleibt sichtbar, ein optisch versteckter Zusatz ergänzt „über Wanderschuh A“. Der Name beginnt mit dem sichtbaren Wort, so wie SC 2.5.3 es als bewährte Praxis empfiehlt.
- Kontext verknüpfen:
aria-labelledbyverweist auf den Link selbst und auf die Überschrift der Kachel. Die APG zeigen das am Beispiel eines „Read more“-Links, der die Artikelüberschrift in seinen Namen aufnimmt (W3C, APG). Der eigene Text des Links steht dabei an erster Stelle der Verweisliste.
Was nicht hilft, ist ein title-Attribut. Browser nutzen es nur als Notlösung, wenn kein anderer Name vorhanden ist (W3C, APG); bei einem Link mit dem sichtbaren Text „mehr“ bleibt der Name „mehr“. Ebenso wenig hilft ein aria-label, das „mehr“ durch „Produktdetails öffnen“ ersetzt: Der Name enthält das sichtbare Wort dann nicht mehr, und SC 2.5.3 ist verletzt. Für die Linkliste gilt außerdem: Links zum selben Ziel sollten gleich heißen, Links zu verschiedenen Zielen verschieden (W3C, Understanding SC 2.4.4).
Muster 4: Sichtbare Beschriftung im Namen
SC 2.5.3 verlangt, dass der zugängliche Name den sichtbar dargestellten Text enthält (W3C, WCAG 2.2, SC 2.5.3). Als bewährte Praxis nennt die Richtlinie, den sichtbaren Text an den Anfang des Namens zu setzen (W3C, WCAG 2.2, SC 2.5.3). Hintergrund ist die Spracheingabe: Wer per Stimme „Klicke In den Warenkorb“ sagt, trifft die Schaltfläche nur, wenn ihr Name diese Wörter enthält. Und für Screenreader-Nutzende, die zusätzlich sehen, ist es irritierend, wenn Gehörtes und Gesehenes auseinanderfallen (W3C, Understanding SC 2.5.3). Den Abgleich für die Sprachbedienung samt Prüfraster beschreibt unser Beitrag zur Sprachsteuerung; hier geht es darum, wie Namen für Links und Buttons gebaut werden, ohne den sichtbaren Text zu verlieren.
Der typische Fehler entsteht in guter Absicht. Ein Team möchte eine Schaltfläche genauer beschreiben und setzt ein aria-label darauf. Weil aria-label Vorrang vor dem Inhalt hat, verschwindet der sichtbare Text aus dem Namen (W3C, Understanding SC 2.5.3). Aus „Jetzt kaufen“ wird angesagt „Bestellung abschließen“, und die Spracheingabe findet „Jetzt kaufen“ nicht mehr. Groß- und Kleinschreibung sowie die meisten Satzzeichen sind für das Kriterium dagegen unerheblich, und Symbole wie ein Pfeilzeichen gelten nicht als Beschriftung (W3C, Understanding SC 2.5.3).
| Sichtbarer Text | Zugänglicher Name | Bewertung nach SC 2.5.3 (W3C, Understanding SC 2.5.3) |
|---|---|---|
| In den Warenkorb | In den Warenkorb | erfüllt |
| In den Warenkorb | In den Warenkorb: Wanderschuh A | erfüllt, sichtbarer Text steht vorn |
| mehr | Mehr über Wanderschuh A | erfüllt, Schreibweise unerheblich |
| Jetzt kaufen | Bestellung abschließen | nicht erfüllt, sichtbarer Text fehlt im Namen |
| Weiter … | Weiter | erfüllt, die Auslassungspunkte zählen nicht |
| nur Herz-Symbol | Merken: Wanderschuh A | nicht anwendbar, keine sichtbare Textbeschriftung |
Faustregel für Namen mit Zusatz
Prüfen über die Linkliste des Screenreaders
Eine schnelle Prüfung dieser Befunde braucht keinen Code-Editor, sondern die Liste, die Screenreader-Nutzende selbst verwenden. Sie zeigt alle Links einer Seite ohne Umgebung, also genau so, wie sie nach SC 2.4.4 im ungünstigsten Fall wahrgenommen werden. In NVDA öffnet NVDA+F7 die Elementliste mit Links, Überschriften, Formularfeldern und Schaltflächen; in VoiceOver auf dem Mac erfüllt der Rotor (VO+U) denselben Zweck, in JAWS listet Einfügen+F7 die Links. Unser Screenreader-Test setzt an der Auszeichnung an: Er prüft, ob Namen, Rollen, Zustände und Hinweismeldungen so im Code stehen, dass Screenreader sie ansagen können.
- Linkliste öffnen und von oben nach unten lesen. Jeder Eintrag muss ohne Seitenkontext sagen, wohin er führt.
- Leere Einträge, Adressen, Dateinamen und Platzhalter wie „icon-arrow“ notieren: Das sind fehlende oder falsche Namen nach SC 4.1.2, 1.1.1 und 2.4.4.
- Gleiche Namen mit verschiedenen Zielen markieren, etwa mehrfach „mehr“, und umgekehrt gleiche Ziele mit verschiedenen Namen.
- Schaltflächen über die Elementliste oder die Schnellnavigation durchgehen, besonders Symbolschaltflächen in Kopfzeile, Kacheln, Karussell und Dialogen.
- Bei jedem Element mit sichtbarer Beschriftung vergleichen, ob der angesagte Name den sichtbaren Text enthält und mit ihm beginnt (SC 2.5.3).
- Zustände mitprüfen: Merklisten-Umschalter melden gedrückt oder nicht gedrückt, Menüschalter ausgeklappt oder eingeklappt.
Diese Prüfung ersetzt keine Messung, sie ergänzt sie. Ein automatischer Lauf findet leere Links und Buttons über viele Seiten hinweg; die Linkliste zeigt, ob vorhandene Namen etwas taugen. Welche Werkzeuge was finden, vergleicht unser Beitrag zu Prüfmethoden. Die Entwicklerwerkzeuge des Browsers zeigen zusätzlich im Zugänglichkeitsbaum, aus welcher Quelle ein Name berechnet wurde, etwa aus dem Inhalt, dem alt-Attribut oder einem aria-label.
| Befund | Automatische Prüfung | Manuelle Prüfung über Linkliste und Ansage |
|---|---|---|
| Link oder Button ohne jeden Text | wird zuverlässig erkannt | bestätigt den Befund in der Vorlage |
| Verlinktes Bild ohne alt | wird zuverlässig erkannt | klärt, welcher Alternativtext das Ziel beschreibt |
| Linktext „mehr“ oder „hier“ | meist nur als Hinweis | klärt, ob der Kontext reicht |
| Name „Bild“, „icon-cart“ oder Dateiname | oft nicht erkannt | klärt, ob der Name den Zweck nennt |
| aria-label weicht vom sichtbaren Text ab | nur teilweise erkannt | vergleicht Gesehenes und Gehörtes |
| Gleicher Name, verschiedene Ziele | selten erkannt | Abgleich in der Linkliste |
Reparatur in Vorlage und Redaktion verankern
Leere Links und Buttons entstehen selten einzeln. Meist steckt der Fehler in einer Komponente, die auf vielen Seiten wiederkehrt: der Produktkachel, dem Karussell, dem Teilen-Menü. Deshalb wird in der Komponente repariert, nicht auf der einzelnen Seite. Bewährt hat sich, Icon-Buttons nur über eine Komponente zuzulassen, die einen Namen als Pflichtangabe verlangt, und im Redaktionssystem das alt-Feld für verlinkte Bilder nicht leer speichern zu lassen. Wie das in einem Komponentensystem aussieht, zeigt unser Beitrag zum barrierefreien Design System.
Zwei Punkte werden in mehrsprachigen Shops leicht übersehen. Erstens bleiben aria-label-Werte bei der Übersetzung gern auf der Strecke, weil sie nicht sichtbar sind; die APG weisen ausdrücklich darauf hin, sie mitzuübersetzen (W3C, APG). Zweitens ist sichtbarer Text die stabilere Quelle: Namen, die nur im Markup stehen, werden bei Änderungen an Gestaltung oder Inhalt eher vergessen (W3C, APG). Für Redaktionen hilft eine kurze Regel im Styleguide: Linktext nennt das Ziel, nicht die Geste, also „Preisliste als PDF“ statt „hier“. Solche Regeln vermitteln wir in Schulungen für Redaktion und Entwicklung.
In einem WCAG-Audit gehören diese Befunde zu den ersten, die auftauchen, weil sie sich in jeder Vorlage wiederholen. Wir prüfen dabei automatisiert, bewerten jedes Kriterium und gehen Tastaturbedienung und Ausgabe für Screenreader von Hand durch; jeder Befund kommt mit Schweregrad, WCAG-Referenz und Lösungsweg. Für die Umsetzung in Komponenten und Vorlagen steht die barrierefreie Webentwicklung bereit, und damit neue Inhalte keine leeren Links nachliefern, überwacht das BFSG-Monitoring die Website fortlaufend. Wie aus einer Befundliste ein Maßnahmenplan wird, beschreibt unser Beitrag zum Prüfbericht.
Verwandte Artikel
Leichte Sprache beauftragen: DIN SPEC 33429 in der Praxis
Leichte Sprache beauftragen: Textauswahl, Briefing, Prüfung durch mindestens 2 Menschen mit Lernschwierigkeiten und Einbau nach DIN SPEC 33429 und BITV 2.0.
Barrierefreier Kundenservice: was § 12 BFSGV verlangt
Hotline, E-Mail, Formular oder Chat: Was § 12 Nr. 4 BFSGV von Unterstützungsdiensten verlangt und wie Sie Auskunft und Kontaktwege barrierefrei aufstellen.
Countdown, Timer, Pop-up: Weihnachtsaktionen barrierefrei
Countdown-Leiste, Warenkorb-Timer und Gutschein-Pop-up: welches Element unter WCAG 2.2.1 oder 2.2.2 fällt und was Shops vor dem Aktionsstart prüfen sollten.