Buttons und Links auf Barrierefreiheit korrekt zu testen bedeutet, sie auf Tastaturzug\u00e4nglichkeit, erkennbare Fokuszust\u00e4nde, eindeutige Beschriftungen, ausreichende Farbkontraste und korrekte semantische Auszeichnung zu pr\u00fcfen. Diese Kriterien sind in den WCAG-Richtlinien verankert und bilden die Grundlage f\u00fcr eine BITV-Pr\u00fcfung sowie die Anforderungen des Barrierefreiheitsst\u00e4rkungsgesetzes (BFSG). Der folgende Artikel beantwortet die wichtigsten Fragen rund um den Barrierefreiheitstest f\u00fcr interaktive Elemente.<\/p>\n
Ein Button oder Link gilt als barrierefrei, wenn er f\u00fcr alle Nutzerinnen und Nutzer unabh\u00e4ngig von ihrer Eingabemethode oder Hilfstechnologie erkennbar, erreichbar und bedienbar ist. Die WCAG definieren daf\u00fcr konkrete Erfolgskriterien, die sich auf Beschriftung, Kontrast, Fokus und Semantik beziehen.<\/p>\n
Im Detail sind folgende Eigenschaften entscheidend:<\/p>\n
<button><\/code>-Element oder mit der ARIA-Rolle role=\"button\"<\/code> ausgezeichnet sein. Links geh\u00f6ren in ein <a href=\"...\"><\/code>-Element. Falsch ausgezeichnete Elemente werden von Screenreadern nicht korrekt interpretiert.<\/li>\n- Klickziel gro\u00df genug:<\/strong> WCAG 2.5.5 empfiehlt eine Mindestgr\u00f6\u00dfe von 44 x 44 CSS-Pixeln f\u00fcr interaktive Elemente, damit sie auch per Touchscreen sicher bedient werden k\u00f6nnen.<\/li>\n<\/ul>\n
Diese Kriterien gelten sowohl f\u00fcr den Barrierefreiheitstest einer Website<\/a> als auch f\u00fcr interne Audits. Wer Websites auf Barrierefreiheit pr\u00fcfen m\u00f6chte, sollte diese Punkte systematisch f\u00fcr jeden Button und jeden Link \u00fcberpr\u00fcfen.<\/p>\nWie testet man Tastaturzug\u00e4nglichkeit bei Buttons und Links?<\/h2>\n
Die Tastaturzug\u00e4nglichkeit pr\u00fcfen Sie, indem Sie die Maus weglegen und ausschlie\u00dflich mit der Tastatur durch die Website navigieren. Dr\u00fccken Sie die Tabulatortaste, um von Element zu Element zu springen, und die Eingabetaste oder Leertaste, um Buttons und Links zu aktivieren.<\/p>\n
Gehen Sie dabei folgende Pr\u00fcfschritte durch:<\/p>\n
\n- Tab-Reihenfolge pr\u00fcfen:<\/strong> Ist die Reihenfolge, in der Elemente fokussiert werden, logisch und entspricht sie dem visuellen Layout? Spr\u00fcnge oder fehlende Elemente in der Tab-Reihenfolge deuten auf ein Problem hin.<\/li>\n
- Fokusindikator sichtbar?<\/strong> Ist bei jedem fokussierten Button und Link ein deutlicher visueller Rahmen oder eine andere Markierung erkennbar? Fehlt dieser, ist die Seite f\u00fcr Tastaturnutzer kaum nutzbar.<\/li>\n
- Aktivierung funktioniert:<\/strong> L\u00e4sst sich jeder Button mit der Eingabetaste und jeder Link mit der Eingabetaste aufrufen? Buttons sollten zus\u00e4tzlich auf die Leertaste reagieren.<\/li>\n
- Keine Tastaturfallen:<\/strong> Gibt es Bereiche, aus denen man mit der Tastatur nicht mehr herauskommt, etwa Modaldialoge oder Dropdown-Men\u00fcs? Das ist ein kritischer Fehler gem\u00e4\u00df WCAG 2.1.2.<\/li>\n
- Skiplinks vorhanden:<\/strong> Bietet die Seite einen Link, der direkt zum Hauptinhalt springt, damit Tastaturnutzer nicht bei jedem Seitenaufruf die gesamte Navigation durchlaufen m\u00fcssen?<\/li>\n<\/ol>\n
Dieser manuelle Test l\u00e4sst sich nicht vollst\u00e4ndig automatisieren, da er das tats\u00e4chliche Nutzungsverhalten simuliert. Er ist jedoch unverzichtbar f\u00fcr jeden seri\u00f6sen Web-Accessibility-Check.<\/p>\n
Wie pr\u00fcft ein Screenreader Buttons und Links korrekt?<\/h2>\n
Ein Screenreader liest die semantische Struktur einer Seite vor, nicht ihr visuelles Erscheinungsbild. F\u00fcr Buttons und Links bedeutet das: Der Screenreader gibt die Rolle des Elements an, seinen zug\u00e4nglichen Namen und seinen aktuellen Zustand, etwa \u201edeaktiviert“ oder \u201eerweitert“.<\/p>\n
Um zu testen, wie ein Screenreader Buttons und Links verarbeitet, gehen Sie wie folgt vor:<\/p>\n
\n- Verwenden Sie einen g\u00e4ngigen Screenreader wie NVDA (Windows, kostenlos), JAWS (Windows, kostenpflichtig) oder VoiceOver (macOS und iOS, integriert).<\/li>\n
- Navigieren Sie ausschlie\u00dflich per Tastatur und h\u00f6ren Sie, was der Screenreader f\u00fcr jeden Button und Link ank\u00fcndigt.<\/li>\n
- 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.<\/li>\n<\/ul>\n
Was der Screenreader bei Buttons pr\u00fcft<\/h3>\n
Bei einem korrekt ausgezeichneten Button liest der Screenreader typischerweise: \u201eAbsenden, Schaltfl\u00e4che“. Fehlt das <button><\/code>-Tag oder ist ein <div><\/code> als Button gestaltet, ohne role=\"button\"<\/code>, h\u00f6rt die Nutzerin oder der Nutzer nur den Text, aber keine Rollenangabe. Das Element ist damit nicht als interaktiv erkennbar.<\/p>\nWas der Screenreader bei Links pr\u00fcft<\/h3>\n
Links werden als \u201eLink“ angek\u00fcndigt. Problematisch sind Links ohne sichtbaren oder programmatischen Text, etwa reine Icon-Links ohne aria-label<\/code>. Ebenfalls kritisch sind Links, deren Text identisch ist, die aber zu unterschiedlichen Zielen f\u00fchren, weil der Screenreader sie nicht unterscheiden kann. Ein aria-label<\/code> oder title<\/code>-Attribut kann hier Abhilfe schaffen, sollte aber sparsam eingesetzt werden.<\/p>\nWas ist der Unterschied zwischen automatisiertem und manuellem Barrierefreiheitstest?<\/h2>\n
Automatisierte Barrierefreiheitstests pr\u00fcfen den Quellcode einer Website auf bekannte Muster, die gegen WCAG-Kriterien versto\u00dfen, zum Beispiel fehlende Alt-Texte, unzureichende Kontraste oder fehlende ARIA-Attribute. Manuelle Tests simulieren dagegen die tats\u00e4chliche Nutzung durch Menschen mit unterschiedlichen Beeintr\u00e4chtigungen und Hilfstechnologien.<\/p>\n
Beide Ans\u00e4tze erg\u00e4nzen sich, k\u00f6nnen sich aber nicht gegenseitig ersetzen:<\/p>\n
\n- Automatisierte Tests<\/strong> sind schnell, reproduzierbar und skalierbar. Sie eignen sich hervorragend, um eine gro\u00dfe Anzahl von Seiten regelm\u00e4\u00dfig zu \u00fcberwachen und offensichtliche Fehler fr\u00fchzeitig zu erkennen. Typischerweise decken sie einen erheblichen Teil der technisch pr\u00fcfbaren WCAG-Kriterien ab.<\/li>\n
- Manuelle Tests<\/strong> sind notwendig f\u00fcr Aspekte, die Kontext und Urteilsverm\u00f6gen erfordern: Ist der Linktext im Zusammenhang verst\u00e4ndlich? Ergibt die Tab-Reihenfolge inhaltlich Sinn? Ist ein Formular mit dem Screenreader tats\u00e4chlich nutzbar?<\/li>\n<\/ul>\n
F\u00fcr eine BITV-Pr\u00fcfung oder eine Konformit\u00e4tserkl\u00e4rung nach BFSG reicht ein rein automatisierter Scan nicht aus. Er liefert jedoch eine wertvolle Grundlage und zeigt, wo manueller Pr\u00fcfaufwand besonders n\u00f6tig ist. Beachten Sie: Auch umfangreiche automatisierte Tests k\u00f6nnen nicht alle m\u00f6glichen Barrieren erfassen. Das Ergebnis eines Scans zeigt den Stand zum Zeitpunkt der Pr\u00fcfung und ersetzt keine vollst\u00e4ndige manuelle Bewertung durch Fachleute.<\/p>\n
Welche h\u00e4ufigen Fehler bei Buttons und Links fallen bei BFSG-Pr\u00fcfungen auf?<\/h2>\n
Bei BFSG-Pr\u00fcfungen treten bei Buttons und Links immer wieder dieselben Schwachstellen auf. Viele davon lassen sich mit einem strukturierten Barrierefreiheitstest fr\u00fchzeitig identifizieren, bevor sie zum rechtlichen Risiko werden.<\/p>\n
Die h\u00e4ufigsten Fehler sind:<\/p>\n
\n- Nichtssagende Linktexte:<\/strong> \u201eHier“, \u201eMehr erfahren“ oder \u201eWeiter“ ohne Kontext sind f\u00fcr Screenreader-Nutzer unverst\u00e4ndlich. Jeder Link sollte aus sich heraus beschreiben, wohin er f\u00fchrt.<\/li>\n
- Fehlender oder unsichtbarer Fokusindikator:<\/strong> Wird der Standard-Fokusrahmen per CSS entfernt, ohne einen gleichwertigen Ersatz zu bieten, ist die Seite f\u00fcr Tastaturnutzer kaum bedienbar.<\/li>\n
- Unzureichender Farbkontrast auf Buttons:<\/strong> Insbesondere bei Ghost-Buttons oder Buttons mit Verlaufshintergrund unterschreitet das Kontrastverh\u00e4ltnis h\u00e4ufig den WCAG-Mindestwert von 4,5:1.<\/li>\n
- Div- oder Span-Elemente als Buttons:<\/strong> Werden interaktive Elemente mit
<div><\/code> oder <span><\/code> umgesetzt, fehlen Rolle, Tastatursteuerung und Zustandsinformationen, sofern diese nicht explizit per ARIA erg\u00e4nzt werden.<\/li>\n- Fehlende Zust\u00e4nde bei Buttons:<\/strong> Buttons, die ein- und ausgeschaltet werden k\u00f6nnen, m\u00fcssen ihren Zustand programmatisch kommunizieren, etwa \u00fcber
aria-pressed<\/code> oder aria-expanded<\/code>.<\/li>\n- Icon-Links ohne zug\u00e4nglichen Namen:<\/strong> Ein Link, der nur aus einem Symbol besteht und kein
aria-label<\/code> tr\u00e4gt, ist f\u00fcr Screenreader-Nutzer nicht identifizierbar.<\/li>\n<\/ul>\nDiese Fehler fallen nicht nur bei formalen BFSG-Pr\u00fcfungen auf, sondern auch bei einer regul\u00e4ren WCAG-Pr\u00fcfung. Sie sind oft leicht zu beheben, sobald sie identifiziert sind.<\/p>\n
Wann sollte eine Website regelm\u00e4\u00dfig auf Barrierefreiheit gepr\u00fcft werden?<\/h2>\n
Eine Website sollte immer dann auf Barrierefreiheit gepr\u00fcft werden, wenn Inhalte oder Code ge\u00e4ndert 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\u00fcllen.<\/p>\n
Konkrete Anl\u00e4sse f\u00fcr einen Barrierefreiheitstest sind:<\/p>\n
\n- Relaunch oder umfangreiche \u00dcberarbeitung der Website<\/li>\n
- Einf\u00fchrung neuer Funktionen, Formulare oder interaktiver Komponenten<\/li>\n
- Wechsel des CMS, Frameworks oder Templates<\/li>\n
- Integration von Drittanbieter-Widgets oder externen Skripten<\/li>\n
- Regelm\u00e4\u00dfige Routinepr\u00fcfungen zur Dokumentation des Compliance-Stands<\/li>\n<\/ul>\n
Kontinuierliches Monitoring ist dabei sinnvoller als einmalige Audits, weil Websites sich laufend ver\u00e4ndern. Neue Inhalte, Plugin-Updates oder Designanpassungen k\u00f6nnen Barrieren einf\u00fchren, die bei der letzten Pr\u00fcfung noch nicht vorhanden waren. Wer Websites dauerhaft im Blick behalten m\u00f6chte, profitiert von automatischen Benachrichtigungen, sobald sich der Barrierefreiheitsstatus einer Seite \u00e4ndert.<\/p>\n
So unterst\u00fctzt decareto beim Barrierefreiheitstest f\u00fcr Buttons und Links<\/h2>\n
Wir bei decareto haben unsere Barrierefreiheitssoftware<\/a> genau f\u00fcr die Herausforderungen entwickelt, die in diesem Artikel beschrieben werden. Statt stundenlanger manueller Pr\u00fcfung f\u00fchrt unsere Plattform automatisierte Scans durch, die typische Fehler bei Buttons und Links zuverl\u00e4ssig erkennen und strukturiert aufbereiten:<\/p>\n\n- Automatische Erkennung von WCAG-Verst\u00f6\u00dfen<\/strong> bei Buttons und Links, darunter fehlende zug\u00e4ngliche Namen, unzureichende Kontraste und falsche ARIA-Attribute, orientiert an WCAG 2.1 und vorbereitet auf WCAG 2.2<\/li>\n
- Priorisierung nach Schweregrad<\/strong>, von kritisch bis geringf\u00fcgig, damit Sie wissen, wo Handlungsbedarf am dringendsten ist<\/li>\n
- Konkrete Handlungsempfehlungen<\/strong> f\u00fcr jedes gefundene Problem, verst\u00e4ndlich formuliert f\u00fcr Entwicklerinnen und Entwickler sowie f\u00fcr Beraterinnen und Berater ohne tiefes technisches Vorwissen<\/li>\n
- Dauerhaftes Monitoring<\/strong> mit automatischen Benachrichtigungen bei \u00c4nderungen, damit neu eingef\u00fchrte Barrieren sofort auffallen<\/li>\n
- Teilbare Reports<\/strong> im PDF-Format oder per Link, die direkt mit Kundinnen und Kunden oder Entwicklungsteams geteilt werden k\u00f6nnen, inklusive Whitelabel-Option f\u00fcr Agenturen<\/li>\n
- Dokumentation manueller Tests<\/strong>, weil wir wissen, dass nicht alle Barrieren automatisiert pr\u00fcfbar sind<\/li>\n<\/ul>\n
Unsere Plattform richtet sich an Datenschutzbeauftragte, Agenturen, Anwaltskanzleien und Compliance-Teams, die den Aufwand f\u00fcr Web-Audits deutlich reduzieren m\u00f6chten, ohne auf Pr\u00fcftiefe zu verzichten. Bitte beachten Sie: Automatisierte Scans unterst\u00fctzen Ihre Compliance-Arbeit, ersetzen jedoch keine vollst\u00e4ndige manuelle Pr\u00fcfung oder rechtliche Beratung durch qualifizierte Fachleute.<\/p>\n
Testen Sie jetzt Ihre Website mit unserem Barrierefreiheitstest-Tool<\/a> oder erfahren Sie mehr \u00fcber unsere Preismodelle<\/a>. Bei Fragen stehen wir Ihnen gerne zur Verf\u00fcgung.<\/p>\nDieser Text wurde mit Hilfe von KI erstellt und k\u00f6nnte Fehler beinhalten.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"Buttons barrierefrei testen: WCAG-Kriterien, Fokus, Kontrast und Semantik \u2013 so gelingt der BFSG-konforme Check.<\/p>\n","protected":false},"author":6,"featured_media":9536,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[44],"tags":[],"class_list":["post-9288","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/posts\/9288","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/comments?post=9288"}],"version-history":[{"count":1,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/posts\/9288\/revisions"}],"predecessor-version":[{"id":9386,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/posts\/9288\/revisions\/9386"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/media\/9536"}],"wp:attachment":[{"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/media?parent=9288"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/categories?post=9288"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/decareto.com\/de\/wp-json\/wp\/v2\/tags?post=9288"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}