Alle Interaktiven Elemente lassen sich mit Buttons oder Links auszeichnen. Obwohl die eigentliche Implementierung von Buttons und Links einfach ist, gibt es hinsichtlich der Barrierefreiheit viel zu beachten.
Screenreader geben interaktive Elemente so aus, dass Nutzerinnen und Nutzer sofort verstehen, was das Element ist, wie es heißt und wie sie damit interagieren können. Sobald ein Element fokussiert wird, liest der Screenreader typischerweise drei Informationen vor:
der zugängliche Name
die Rolle
der Zustand bzw. die Eigenschaften
Folgendes Video der Harvard Universität verdeutlicht die Ausgabe.
Deutsches Gesetz: Anforderungen der Konformitätsstufe A und AA müssen umgesetzt werden.
Eine saubere und semantische Auszeichnung von Buttons und Links im HTML ist eine wichtige Basis.
Zwischen Links und Buttons gibt es klare Unterschiede, auch wenn sie visuell identisch aussehen können. Links sollten immer mit einem <a>-Tag ausgezeichnet werden und haben immer ein href-Attribut für das Linkziel. Ein Button hingegen wird semantisch korrekt <button> ausgezeichnet und wird meistens dafür verwendet, JavaScript-Aktionen auszuführen oder Formulare abzuschicken.
Mithilfe des HTML-Validators, der von den W3C zur Verfügung gestellt wird, kann der Quellcode auf semantisches und valides HTML überprüft werden.
Zugängliche Labels von interaktiven Elementen sind wichtig, damit alle Nutzer:innen den Kontext verstehen.
Ein Link oder Button muss klar machen, wohin er führt oder was er auslöst.
Das kann auf zwei Arten passieren:
Der Text selbst ist eindeutig (z. B. „Dokument herunterladen“).
Der umgebende Kontext erklärt es – z. B. wenn ein Link „Mehr erfahren“ heißt, aber direkt unter einer Überschrift steht, die den Inhalt beschreibt. Diese zweite Variante ist im AAA-Standard nicht erlaubt, dort muss der Linktext selbst eindeutig sein.
Mit ARIA-Attributen wie aria-label oder aria-labelledby kann man Elemente zugänglich beschriften. Man sollte ARIA aber sparsam einsetzen, weil die erste ARIA-Regel lautet: „Nutze ARIA nur, wenn es keine native HTML-Lösung gibt.“ Außerdem können ARIA-Attribute Probleme bei automatischen Übersetzungen verursachen. Darum ist Variante 1 meist die sauberere und zuverlässigere Lösung.
Sobald ARIA-Attribute genutzt werden, muss der neu gesetzte Text im ARIA-Attribut den originalen Link-Text beinhalten. Dies wird in WCAG-Richtlinie 2.5.3 Label in Name definiert.
Alle Buttons, die Aktionen ausführen bzw. andere Elemente beeinflussen, müssen mit entsprechenden ARIA-Attributen ausgezeichnet werden.
Für Links gibt es nicht viele häufig eingesetzte ARIA-Attribute, da sie Verlinkungen darstellen. Es gibt jedoch ein ARIA-Attribut, welches in Navigationen eingesetzt werden sollte.
aria-current gibt an, ob ein Link derzeit aktiv ist (z. B. in einer Breadcrumb)
Meistens führen Buttons Aktionen aus, die andere HTML-Elemente beeinflussen. Dementsprechend sollten sie mit ARIA-Attributen ausgezeichnet werden, die auch den aktuellen Zustand vermitteln.
aria-expanded gibt an, ob ein verknüpftes Element (z. B. Akkordeon, ausklappbares Menü) aktuell geöffnet oder geschlossen ist.
aria-pressed zeigt den aktuellen gedrückten/aktivierten Zustand eines Umschaltknopfs an (z. B. Play/Pause, Dark-Mode).
aria-haspopup gibt Typ und Verfügbarkeit eines interaktiven Pop-up-Elements an (z. B. Dialog, Menü, Tooltip).
aria-controls verweist auf die Elemente, die vom Button gesteuert werden (z. B. Panel eines Akkordeons, Tab-Inhalt).
aria-checked kennzeichnet den Status von Auswahl- oder Kontrolloptionen, wie Checkboxen oder Toggle-Buttons (ein/aus).
aria-selected zeigt an, ob ein Element innerhalb einer Gruppe (z. B. Tab, Listenpunkt) ausgewählt ist.
aria-disabled kennzeichnet, dass ein Element vorübergehend deaktiviert ist, auch wenn es visuell aktiv erscheint.
aria-hidden gibt an, ob ein Element für assistive Technologien unsichtbar ist (z. B. temporär ausgeblendete Inhalte).
Alle interaktiven Elemente sind per Tastatur ansprechbar und die Aktionen können per Tastatur ausgeführt werden
Alle interaktiven Elemente müssen per Tastatur erreichbar und eine Fokus erhalten können, sobald diese auch visuell sichtbar sind. Dementsprechend ist es nicht erlaubt, interaktive Elemente per ARIA-Attribut aria-hidden oder per role="presentation" für assistive Technologien auszublenden.
Alle Elemente mit denen die Nutzer:innen interagieren können, müssen eine bestimmte Größe aufweisen.
Bei dieser Konformitätsstufe müssen alle Objekte, mit denen interagiert werden kann, eine Größe von mindestens 24px x 24px aufweisen.
Kleinere Elemente sind erlaubt, wenn sie entweder isoliert, durch Alternativen abgedeckt, durch Text eingeschränkt, vom Browser gesteuert oder essenziell sind.
Bei dieser Konformitätsstufe müssen alle Objekte, mit denen interagiert werden kann, eine Größe von mindestens 44px x 44px aufweisen.
Kleinere Elemente sind nur erlaubt, wenn sie äquivalent erreichbar, inline im Text, vom Browser gesteuert oder essenziell sind.
Links, die sich beispielsweise in einem neuen Fenster öffnen, müssen dies zugänglich der Nutzer:in vermitteln.
Links dürfen keine Kontextänderungen herbei führen, außer die Nutzenden wurden darüber informiert. Sobald sich ein Link in einem neuen Fenster öffnet, also Links mit target="_blank" ausgezeichnet sind, muss dies dem User mitgeteilt werden.
Zuletzt aktualisiert am 14.12.25