Eine kurze, meinungsstarke Checkliste für barrierefreie Web-Buttons

Das Problem mit Ratschlägen zur Barrierefreiheit von Buttons

Die meisten Empfehlungen zur Barrierefreiheit von Buttons fallen in zwei Kategorien: Entweder handelt es sich um eine 40-seitige WCAG-Auslegung, die niemand liest, oder um den vagen Hinweis, Buttons „barrierefrei zu machen“, ohne konkrete Schritte. Beides hilft nicht, wenn am Donnerstag ein Feature ausgeliefert werden soll.

Diese Checkliste behandelt die fünf häufigsten Barrierefreiheitsfehler bei Buttons, die wir in Produktion sehen. Sie macht Sie nicht zur WCAG-Expertin oder zum WCAG-Experten, aber sie fängt die Probleme ab, die Nutzerinnen und Nutzer tatsächlich betreffen.

1. Verwenden Sie das button-Element für Buttons

Wenn sich etwas wie ein Button verhält, sollte es ein <button>-Element sein. Kein <div> mit onclick, kein <span> mit role="button", kein <a> mit href="#" und preventDefault.

Das <button>-Element bringt Tastaturnavigation, Fokusverwaltung und Screenreader-Ankündigungen kostenlos mit. Wenn Sie ein <div> verwenden, bauen Sie all das von Grund auf neu — und Sie werden dabei Fehler machen.

Die einzige Ausnahme: Wenn die Aktion zu einer neuen Seite navigiert oder die URL ändert, verwenden Sie ein <a>-Element. Links und Buttons unterscheiden sich semantisch. Screenreader-Nutzerinnen und -Nutzer navigieren nach Elementtyp und erwarten, dass Buttons Aktionen ausführen und Links navigieren.

2. Sorgen Sie für eine Trefferfläche von mindestens 44×44 Pixeln

WCAG 2.5.5 (Level AAA) verlangt, dass interaktive Elemente eine Mindestzielgröße von 44×44 CSS-Pixeln haben. Dabei geht es nicht um die sichtbare Größe — sondern um den klickbaren Bereich.

Sie können einen optisch kleinen Button mit ausreichendem Padding haben, oder Sie können die Trefferfläche mit einem Pseudo-Element erweitern. Entscheidend ist, dass Nutzerinnen und Nutzer nicht exakt zielen müssen.

Mobile Nutzerinnen und Nutzer, Menschen mit motorischen Einschränkungen und alle, die ein Gerät in Bewegung verwenden, verfehlen kleine Ziele. Ein 24×24-Pixel-Icon-Button mag aufgeräumt aussehen, ist aber ein Usability-Problem.

3. Stellen Sie sichtbare Fokuszustände bereit, die nicht nur Browser-Defaults sind

Der Standard-Fokusring des Browsers ist besser als nichts, aber er ist je nach Browser unterschiedlich und vor bestimmten Hintergründen oft unsichtbar. Sie brauchen einen eigenen Fokuszustand, der in Ihrem Designsystem funktioniert.

Ein guter Fokusindikator hat drei Eigenschaften:

• Hoher Kontrast: mindestens 3:1 gegenüber angrenzenden Farben
• Sichtbarer Abstand: nicht durch den Rahmen oder Hintergrund des Buttons verdeckt
• Konsistente Form: Nutzerinnen und Nutzer sollten ihn in der gesamten Oberfläche als Fokusindikator erkennen

Entfernen Sie outline: none nicht, ohne es durch etwas Besseres zu ersetzen. Und machen Sie Fokuszustände nicht so subtil, dass nur Sie sie bei perfekten Lichtverhältnissen sehen können.

4. Schreiben Sie Button-Beschriftungen, die auch ohne Kontext verständlich sind

Screenreader-Nutzerinnen und -Nutzer navigieren häufig, indem sie zwischen Buttons springen. Dabei hören sie eine Liste von Button-Beschriftungen ohne umgebenden Kontext.

Ein Button mit der Beschriftung „Mehr erfahren“ ist in dieser Liste nutzlos. Dasselbe gilt für „Hier klicken“ oder „Absenden“. Die Beschriftung sollte die Aktion beschreiben: „Barrierefreiheits-Checkliste herunterladen“, „Updates abonnieren“, „Diesen Kommentar löschen“.

Wenn Ihr Design eine kurze sichtbare Beschriftung erfordert, verwenden Sie aria-label, um eine beschreibende Alternative bereitzustellen. Die bessere Lösung ist jedoch, Beschriftungen zu schreiben, die für alle funktionieren.

Für reine Icon-Buttons ist aria-label zwingend erforderlich. Ein Button mit nur einem Lupen-Icon benötigt aria-label="Search" oder einen gleichwertigen Text. Das Icon ist für Screenreader nicht zugänglich.

5. Stellen Sie ausreichenden Farbkontrast sicher

WCAG 2.1 verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (18pt oder 14pt fett). Button-Beschriftungen sind in der Regel normaler Text.

Hellgrauer Text auf einem weißen Button fällt durch. Blasses Blau auf hellblauem Hintergrund fällt durch. Diese Kombinationen mögen anspruchsvoll aussehen, schließen aber Nutzerinnen und Nutzer mit eingeschränktem Sehvermögen, Farbenblindheit oder alle aus, die den Bildschirm in hellem Sonnenlicht betrachten.

Verwenden Sie bereits im Design einen Kontrastprüfer, nicht erst nach dem Launch. Kontrastprobleme in Produktion zu beheben, ist teuer, weil dafür oft Änderungen am Designsystem nötig sind.

Wenn Sie mit Bildverarbeitungswerkzeugen arbeiten, kann client-side processing can help preserve privacy while generating accessible visual assets — insbesondere beim Testen von Farbkombinationen oder beim Erzeugen von Vorschauzuständen.

Was diese Checkliste nicht abdeckt

Diese Liste ist bewusst unvollständig. Sie behandelt keine Semantik für deaktivierte Zustände, Ladezustände, Fehlerbehandlung oder komplexe Button-Muster wie Split-Buttons oder Dropdown-Auslöser. Diese Muster benötigen eigene Leitlinien.

Sie behandelt auch nicht die allgemeinere Frage, wann ein Button statt anderer interaktiver Elemente verwendet werden sollte. Dafür müssen Sie semantisches HTML und den Accessibility Tree verstehen — Themen, die eigene Artikel verdienen.

Was sie abdeckt, sind die naheliegenden Punkte: die Fehler, die in fast jedem Code-Review auftauchen, die die meisten Nutzerinnen und Nutzer betreffen und die sich während der Entwicklung am einfachsten beheben lassen.

So integrieren Sie diese Checkliste in Ihren Workflow

Barrierefreiheits-Checklisten funktionieren nur, wenn sie Teil des Entwicklungsprozesses sind und nicht nachträglich angehängt werden. So gelingt das:

Im Design: Fügen Sie Ihren Designdateien Fokuszustände und Anmerkungen zur Trefferfläche hinzu. Überlassen Sie diese Punkte nicht den Entwicklerinnen und Entwicklern zum Raten.

Im Code-Review: Prüfen Sie auf <button>-Elemente, aria-label bei Icon-Buttons und CSS für Fokuszustände. Diese Dinge sind schnell zu erkennen.

Beim Testen: Navigieren Sie mit der Tastatur per Tab durch Ihre Oberfläche. Wenn Sie einen Button nicht erreichen oder nicht sehen können, wo der Fokus ist, können Ihre Nutzerinnen und Nutzer das ebenfalls nicht.

In der Dokumentation: Nehmen Sie Anforderungen an die Barrierefreiheit von Buttons in Ihre Komponentenbibliothek auf. Machen Sie es einfacher, das Richtige zu tun, als das Falsche.

Wenn Sie Probleme in Produktion debuggen, können tools for inspecting HTTP headers and redirects Ihnen helfen zu verstehen, wie assistive Technologien Ihr Markup interpretieren — insbesondere bei der Fehlersuche in der Fokusverwaltung nach Navigation.

Die Kosten, wenn diese Arbeit übersprungen wird

Nicht barrierefreie Buttons verfehlen nicht nur die WCAG-Konformität — sie unterbrechen Arbeitsabläufe. Eine Nutzerin oder ein Nutzer, der einen Absende-Button nicht anklicken kann, kann ein Formular nicht abschließen. Wer Fokuszustände nicht sehen kann, kann nicht mit der Tastatur navigieren. Wer den Button-Text nicht vom Hintergrund unterscheiden kann, kann die Beschriftung nicht lesen.

Das sind keine Randfälle. Rund 15 % der Weltbevölkerung haben irgendeine Form von Behinderung, und vorübergehende Einschränkungen (kaputte Maus, helles Sonnenlicht, ein Baby auf dem Arm) betreffen irgendwann alle.

Die gute Nachricht ist: Die Barrierefreiheit von Buttons besteht größtenteils aus gelösten Problemen. Sie müssen keine neuen Muster erfinden oder auf Browser-Support warten. Sie müssen nur die Plattform korrekt nutzen und Ihre Arbeit testen.

Wichtige Erkenntnisse

• Verwenden Sie <button>-Elemente für Buttons und <a>-Elemente für Navigation — der semantische Unterschied ist für assistive Technologien wichtig
• Stellen Sie sicher, dass Trefferflächen mindestens 44×44 CSS-Pixel groß sind, um motorische Einschränkungen und mobile Nutzerinnen und Nutzer zu berücksichtigen
• Stellen Sie sichtbare, kontrastreiche Fokuszustände bereit, die in Ihrem gesamten Designsystem funktionieren
• Schreiben Sie Button-Beschriftungen, die isoliert gelesen verständlich sind, und verwenden Sie aria-label für reine Icon-Buttons
• Prüfen Sie den Farbkontrast bereits im Design, nicht erst nach dem Launch, um teure Nachbesserungen zu vermeiden

FAQ

Q: Kann ich role="button" auf einem <div> verwenden, wenn ich Tastatur-Handler hinzufüge?

A: Sie können, aber Sie sollten nicht. Sie müssen Enter, Space, Fokusverwaltung und deaktivierte Zustände manuell behandeln — und Sie werden unweigerlich etwas übersehen. Das <button>-Element erledigt all das standardmäßig korrekt. Verwenden Sie es.

Q: Was ist mit Buttons, die ihren Zustand umschalten, etwa einem Wiedergabe/Pause-Button?

A: Verwenden Sie aria-pressed="true" oder aria-pressed="false", um den aktuellen Zustand anzugeben. Die Button-Beschriftung sollte außerdem die Aktion widerspiegeln, die beim Klicken ausgeführt wird („Pause“ während der Wiedergabe, „Wiedergabe“ während der Pause), nicht den aktuellen Zustand. Screenreader-Nutzerinnen und -Nutzer müssen wissen, was der Button tun wird, nicht in welchem Zustand sich das System befindet.

Q: Müssen deaktivierte Buttons die Kontrastanforderungen erfüllen?

A: WCAG 2.1 nimmt deaktivierte Steuerelemente von den Kontrastanforderungen aus (1.4.3), aber das ist umstritten. Deaktivierte Buttons mit schlechtem Kontrast sind für alle schwer wahrzunehmen. Wenn Sie einen deaktivierten Button anzeigen, machen Sie ihn lesbar. Noch besser: Verbergen Sie ihn oder erklären Sie, warum er deaktiviert ist.

Q: Wie teste ich die Barrierefreiheit von Buttons ohne Screenreader?

A: Verwenden Sie Ihre Tastatur. Navigieren Sie per Tab durch die Oberfläche und prüfen Sie, ob Sie jeden Button erreichen, sehen, wo der Fokus ist, und Buttons mit Enter oder Space aktivieren können. Das deckt die meisten Probleme auf. Für tiefergehende Tests verwenden Sie den Accessibility Inspector in Chrome oder Firefox DevTools, um die berechnete Rolle und Beschriftung zu prüfen.

Q: Was ist der Unterschied zwischen aria-label und aria-labelledby?

A: aria-label stellt direkt eine Textzeichenfolge bereit. aria-labelledby verweist auf die ID eines anderen Elements, dessen Textinhalt zur Beschriftung wird. Verwenden Sie aria-labelledby, wenn der Beschriftungstext bereits an anderer Stelle im DOM vorhanden ist. Verwenden Sie aria-label, wenn Sie eine Beschriftung bereitstellen müssen, die auf dem Bildschirm nicht sichtbar ist.

Quellen

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM