Wie testet man Buttons und Links auf Barrierefreiheit korrekt?

Buttons und Links auf Barrierefreiheit korrekt zu testen bedeutet, sie auf Tastaturzugänglichkeit, erkennbare Fokuszustände, eindeutige Beschriftungen, ausreichende Farbkontraste und korrekte semantische Auszeichnung zu prüfen. Diese Kriterien sind in den WCAG-Richtlinien verankert und bilden die Grundlage für eine BITV-Prüfung sowie die Anforderungen des Barrierefreiheitsstärkungsgesetzes (BFSG). Der folgende Artikel beantwortet die wichtigsten Fragen rund um den Barrierefreiheitstest für interaktive Elemente.

Welche Kriterien machen einen Button oder Link barrierefrei?

Ein Button oder Link gilt als barrierefrei, wenn er für alle Nutzerinnen und Nutzer unabhängig von ihrer Eingabemethode oder Hilfstechnologie erkennbar, erreichbar und bedienbar ist. Die WCAG definieren dafür konkrete Erfolgskriterien, die sich auf Beschriftung, Kontrast, Fokus und Semantik beziehen.

Im Detail sind folgende Eigenschaften entscheidend:

• Eindeutige Beschriftung: Jeder Button und jeder Link muss einen aussagekräftigen Text tragen. Formulierungen wie „Hier klicken“ oder „Mehr“ sind ohne Kontext nicht verständlich und verstoßen gegen WCAG-Erfolgskriterium 2.4.6 und 4.1.2.
• Ausreichender Farbkontrast: Das Kontrastverhältnis zwischen Text und Hintergrund muss mindestens 4,5:1 betragen (WCAG-Level AA). Ein WCAG-Kontrastcheck deckt Schwachstellen auf, die visuell oft unsichtbar bleiben.
• Sichtbarer Fokusindikator: Beim Navigieren per Tastatur muss erkennbar sein, welches Element gerade fokussiert ist. Viele Designs entfernen den Standard-Fokusrahmen aus ästhetischen Gründen, was Tastaturnutzer erheblich einschränkt.
• Korrekte semantische Auszeichnung: Ein Button sollte als <button>-Element oder mit der ARIA-Rolle role="button" ausgezeichnet sein. Links gehören in ein <a href="...">-Element. Falsch ausgezeichnete Elemente werden von Screenreadern nicht korrekt interpretiert.
• Klickziel groß genug: WCAG 2.5.5 empfiehlt eine Mindestgröße von 44 x 44 CSS-Pixeln für interaktive Elemente, damit sie auch per Touchscreen sicher bedient werden können.

Diese Kriterien gelten sowohl für den Barrierefreiheitstest einer Website als auch für interne Audits. Wer Websites auf Barrierefreiheit prüfen möchte, sollte diese Punkte systematisch für jeden Button und jeden Link überprüfen.

Wie testet man Tastaturzugänglichkeit bei Buttons und Links?

Die Tastaturzugänglichkeit prüfen Sie, indem Sie die Maus weglegen und ausschließlich mit der Tastatur durch die Website navigieren. Drücken Sie die Tabulatortaste, um von Element zu Element zu springen, und die Eingabetaste oder Leertaste, um Buttons und Links zu aktivieren.

Gehen Sie dabei folgende Prüfschritte durch:

1. Tab-Reihenfolge prüfen: Ist die Reihenfolge, in der Elemente fokussiert werden, logisch und entspricht sie dem visuellen Layout? Sprünge oder fehlende Elemente in der Tab-Reihenfolge deuten auf ein Problem hin.
2. Fokusindikator sichtbar? Ist bei jedem fokussierten Button und Link ein deutlicher visueller Rahmen oder eine andere Markierung erkennbar? Fehlt dieser, ist die Seite für Tastaturnutzer kaum nutzbar.
3. Aktivierung funktioniert: Lässt sich jeder Button mit der Eingabetaste und jeder Link mit der Eingabetaste aufrufen? Buttons sollten zusätzlich auf die Leertaste reagieren.
4. Keine Tastaturfallen: Gibt es Bereiche, aus denen man mit der Tastatur nicht mehr herauskommt, etwa Modaldialoge oder Dropdown-Menüs? Das ist ein kritischer Fehler gemäß WCAG 2.1.2.
5. Skiplinks vorhanden: Bietet die Seite einen Link, der direkt zum Hauptinhalt springt, damit Tastaturnutzer nicht bei jedem Seitenaufruf die gesamte Navigation durchlaufen müssen?

Dieser manuelle Test lässt sich nicht vollständig automatisieren, da er das tatsächliche Nutzungsverhalten simuliert. Er ist jedoch unverzichtbar für jeden seriösen Web-Accessibility-Check.

Wie prüft ein Screenreader Buttons und Links korrekt?

Ein Screenreader liest die semantische Struktur einer Seite vor, nicht ihr visuelles Erscheinungsbild. Für Buttons und Links bedeutet das: Der Screenreader gibt die Rolle des Elements an, seinen zugänglichen Namen und seinen aktuellen Zustand, etwa „deaktiviert“ oder „erweitert“.

Um zu testen, wie ein Screenreader Buttons und Links verarbeitet, gehen Sie wie folgt vor:

• Verwenden Sie einen gängigen Screenreader wie NVDA (Windows, kostenlos), JAWS (Windows, kostenpflichtig) oder VoiceOver (macOS und iOS, integriert).
• Navigieren Sie ausschließlich per Tastatur und hören Sie, was der Screenreader für jeden Button und Link ankündigt.
• Achten Sie darauf, ob der vorgelesene Name dem sichtbaren Label entspricht. Weicht er ab oder fehlt er ganz, ist das ein Hinweis auf fehlende oder fehlerhafte ARIA-Attribute.

Was der Screenreader bei Buttons prüft

Bei einem korrekt ausgezeichneten Button liest der Screenreader typischerweise: „Absenden, Schaltfläche“. Fehlt das <button>-Tag oder ist ein <div> als Button gestaltet, ohne role="button", hört die Nutzerin oder der Nutzer nur den Text, aber keine Rollenangabe. Das Element ist damit nicht als interaktiv erkennbar.

Was der Screenreader bei Links prüft

Links werden als „Link“ angekündigt. Problematisch sind Links ohne sichtbaren oder programmatischen Text, etwa reine Icon-Links ohne aria-label. Ebenfalls kritisch sind Links, deren Text identisch ist, die aber zu unterschiedlichen Zielen führen, weil der Screenreader sie nicht unterscheiden kann. Ein aria-label oder title-Attribut kann hier Abhilfe schaffen, sollte aber sparsam eingesetzt werden.

Was ist der Unterschied zwischen automatisiertem und manuellem Barrierefreiheitstest?

Automatisierte Barrierefreiheitstests prüfen den Quellcode einer Website auf bekannte Muster, die gegen WCAG-Kriterien verstoßen, zum Beispiel fehlende Alt-Texte, unzureichende Kontraste oder fehlende ARIA-Attribute. Manuelle Tests simulieren dagegen die tatsächliche Nutzung durch Menschen mit unterschiedlichen Beeinträchtigungen und Hilfstechnologien.

Beide Ansätze ergänzen sich, können sich aber nicht gegenseitig ersetzen:

• Automatisierte Tests sind schnell, reproduzierbar und skalierbar. Sie eignen sich hervorragend, um eine große Anzahl von Seiten regelmäßig zu überwachen und offensichtliche Fehler frühzeitig zu erkennen. Typischerweise decken sie einen erheblichen Teil der technisch prüfbaren WCAG-Kriterien ab.
• Manuelle Tests sind notwendig für Aspekte, die Kontext und Urteilsvermögen erfordern: Ist der Linktext im Zusammenhang verständlich? Ergibt die Tab-Reihenfolge inhaltlich Sinn? Ist ein Formular mit dem Screenreader tatsächlich nutzbar?

Für eine BITV-Prüfung oder eine Konformitätserklärung nach BFSG reicht ein rein automatisierter Scan nicht aus. Er liefert jedoch eine wertvolle Grundlage und zeigt, wo manueller Prüfaufwand besonders nötig ist. Beachten Sie: Auch umfangreiche automatisierte Tests können nicht alle möglichen Barrieren erfassen. Das Ergebnis eines Scans zeigt den Stand zum Zeitpunkt der Prüfung und ersetzt keine vollständige manuelle Bewertung durch Fachleute.

Welche häufigen Fehler bei Buttons und Links fallen bei BFSG-Prüfungen auf?

Bei BFSG-Prüfungen treten bei Buttons und Links immer wieder dieselben Schwachstellen auf. Viele davon lassen sich mit einem strukturierten Barrierefreiheitstest frühzeitig identifizieren, bevor sie zum rechtlichen Risiko werden.

Die häufigsten Fehler sind:

• Nichtssagende Linktexte: „Hier“, „Mehr erfahren“ oder „Weiter“ ohne Kontext sind für Screenreader-Nutzer unverständlich. Jeder Link sollte aus sich heraus beschreiben, wohin er führt.
• Fehlender oder unsichtbarer Fokusindikator: Wird der Standard-Fokusrahmen per CSS entfernt, ohne einen gleichwertigen Ersatz zu bieten, ist die Seite für Tastaturnutzer kaum bedienbar.
• Unzureichender Farbkontrast auf Buttons: Insbesondere bei Ghost-Buttons oder Buttons mit Verlaufshintergrund unterschreitet das Kontrastverhältnis häufig den WCAG-Mindestwert von 4,5:1.
• Div- oder Span-Elemente als Buttons: Werden interaktive Elemente mit <div> oder <span> umgesetzt, fehlen Rolle, Tastatursteuerung und Zustandsinformationen, sofern diese nicht explizit per ARIA ergänzt werden.
• Fehlende Zustände bei Buttons: Buttons, die ein- und ausgeschaltet werden können, müssen ihren Zustand programmatisch kommunizieren, etwa über aria-pressed oder aria-expanded.
• Icon-Links ohne zugänglichen Namen: Ein Link, der nur aus einem Symbol besteht und kein aria-label trägt, ist für Screenreader-Nutzer nicht identifizierbar.

Diese Fehler fallen nicht nur bei formalen BFSG-Prüfungen auf, sondern auch bei einer regulären WCAG-Prüfung. Sie sind oft leicht zu beheben, sobald sie identifiziert sind.

Wann sollte eine Website regelmäßig auf Barrierefreiheit geprüft werden?

Eine Website sollte immer dann auf Barrierefreiheit geprüft werden, wenn Inhalte oder Code geändert werden, mindestens jedoch einmal pro Jahr als Teil eines strukturierten Compliance-Prozesses. Websites, die unter das BFSG fallen, sind seit dem 28. Juni 2025 verpflichtet, die Anforderungen der WCAG 2.1 AA zu erfüllen.

Konkrete Anlässe für einen Barrierefreiheitstest sind:

• Relaunch oder umfangreiche Überarbeitung der Website
• Einführung neuer Funktionen, Formulare oder interaktiver Komponenten
• Wechsel des CMS, Frameworks oder Templates
• Integration von Drittanbieter-Widgets oder externen Skripten
• Regelmäßige Routineprüfungen zur Dokumentation des Compliance-Stands

Kontinuierliches Monitoring ist dabei sinnvoller als einmalige Audits, weil Websites sich laufend verändern. Neue Inhalte, Plugin-Updates oder Designanpassungen können Barrieren einführen, die bei der letzten Prüfung noch nicht vorhanden waren. Wer Websites dauerhaft im Blick behalten möchte, profitiert von automatischen Benachrichtigungen, sobald sich der Barrierefreiheitsstatus einer Seite ändert.

So unterstützt decareto beim Barrierefreiheitstest für Buttons und Links

Wir bei decareto haben unsere Barrierefreiheitssoftware genau für die Herausforderungen entwickelt, die in diesem Artikel beschrieben werden. Statt stundenlanger manueller Prüfung führt unsere Plattform automatisierte Scans durch, die typische Fehler bei Buttons und Links zuverlässig erkennen und strukturiert aufbereiten:

• Automatische Erkennung von WCAG-Verstößen bei Buttons und Links, darunter fehlende zugängliche Namen, unzureichende Kontraste und falsche ARIA-Attribute, orientiert an WCAG 2.1 und vorbereitet auf WCAG 2.2
• Priorisierung nach Schweregrad, von kritisch bis geringfügig, damit Sie wissen, wo Handlungsbedarf am dringendsten ist
• Konkrete Handlungsempfehlungen für jedes gefundene Problem, verständlich formuliert für Entwicklerinnen und Entwickler sowie für Beraterinnen und Berater ohne tiefes technisches Vorwissen
• Dauerhaftes Monitoring mit automatischen Benachrichtigungen bei Änderungen, damit neu eingeführte Barrieren sofort auffallen
• Teilbare Reports im PDF-Format oder per Link, die direkt mit Kundinnen und Kunden oder Entwicklungsteams geteilt werden können, inklusive Whitelabel-Option für Agenturen
• Dokumentation manueller Tests, weil wir wissen, dass nicht alle Barrieren automatisiert prüfbar sind

Unsere Plattform richtet sich an Datenschutzbeauftragte, Agenturen, Anwaltskanzleien und Compliance-Teams, die den Aufwand für Web-Audits deutlich reduzieren möchten, ohne auf Prüftiefe zu verzichten. Bitte beachten Sie: Automatisierte Scans unterstützen Ihre Compliance-Arbeit, ersetzen jedoch keine vollständige manuelle Prüfung oder rechtliche Beratung durch qualifizierte Fachleute.

Testen Sie jetzt Ihre Website mit unserem Barrierefreiheitstest-Tool oder erfahren Sie mehr über unsere Preismodelle. Bei Fragen stehen wir Ihnen gerne zur Verfügung.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.

Ähnliche Artikel

• Welche Datenschutzrisiken entstehen durch fehlende oder falsche Rechtstexte?
• Was prüft ein Barrierefreiheits-Tool bei Überschriftenstrukturen?
• Was bedeutet Barrierefreiheit für Nutzer mit Sehbehinderungen konkret?
• Was prüft ein Barrierefreiheits-Tool bei Ladeanimationen?
• Wie erkennt man Barrierefreiheitsprobleme bei Dropdown-Menüs?