Bedienbarkeit muss in den Funktionen stecken
Ein Kunde hat ein Produkt gefunden und seine Daten eingetragen. Beim letzten Schritt kommt er nicht weiter: Die Schaltfläche lässt sich mit der Tastatur nicht erreichen. Ein anderer Nutzer hört über seinen Screenreader nur „Schaltfläche“, aber nicht, wofür sie gedacht ist.
Die Anwendung mag auf dem Bildschirm der Entwickler einwandfrei aussehen. Für diese beiden Menschen ist sie trotzdem nicht vollständig benutzbar.
Das Beispiel zeigt, weshalb Barrierefreiheit keine zusätzliche Dekoration ist. Sie betrifft die Frage, ob Menschen eine Aufgabe selbstständig erledigen können.
Eine größere Schrift oder ein nachträglich eingebauter Vorleseschalter kann an einzelnen Stellen helfen. Ein unzugänglicher Bestellablauf wird dadurch aber nicht automatisch brauchbar.
Gute Bedienbarkeit muss in den Funktionen stecken, nicht nur in ihrer Darstellung.
Warum das Thema inzwischen auch rechtlich wichtig ist
Seit dem 28. Juni 2025 gelten wesentliche Anforderungen des Barrierefreiheitsstärkungsgesetzes, kurz BFSG, für bestimmte Produkte und Dienstleistungen. Dazu gehören unter anderem erfasste Dienstleistungen im elektronischen Geschäftsverkehr, Bankdienstleistungen für Verbraucher und E-Books einschließlich bestimmter Software. Der genaue Anwendungsbereich ergibt sich aus § 1 BFSG. [1]
Das bedeutet nicht, dass jede Internetseite und jede betriebsinterne Anwendung automatisch denselben Vorgaben unterliegt.
Bei Dienstleistungen im elektronischen Geschäftsverkehr kommt es insbesondere darauf an, ob sie elektronisch auf individuelle Anfrage eines Verbrauchers im Hinblick auf einen Verbrauchervertrag erbracht werden. Die Bundesfachstelle Barrierefreiheit erläutert dazu typische Anwendungsfälle in ihren FAQ, Stand Mai 2025. [1][2]
Eine wichtige Ausnahme betrifft Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen. Nach der gesetzlichen Definition beschäftigen sie weniger als zehn Personen und erzielen entweder höchstens zwei Millionen Euro Jahresumsatz oder haben eine Jahresbilanzsumme von höchstens zwei Millionen Euro. Diese Ausnahme ist keine pauschale Befreiung kleiner Unternehmen für sämtliche Produkte und Tätigkeiten. [1]
Auch Übergangsregelungen müssen genau gelesen werden. § 38 BFSG enthält bestimmte Erleichterungen für bereits eingesetzte Produkte und bestehende Dienstleistungsverträge. Daraus folgt kein allgemeiner Aufschub bis 2030 für jede ältere Website. [1]
Für ein konkretes Angebot würde ich daher zuerst den Anwendungsbereich prüfen. Unabhängig davon bleibt zugängliche Bedienung eine Qualitätsfrage.
Barrierefreiheit umfasst mehr als die Sehfähigkeit
Das BFSG beschreibt Barrierefreiheit als grundsätzlich selbstständige Auffindbarkeit, Zugänglichkeit und Nutzbarkeit ohne besondere Erschwernis. Die zugehörige Verordnung verlangt für erfasste Webseiten und Apps eine wahrnehmbare, bedienbare, verständliche und robuste Gestaltung. [1][3]
In der Entwicklung lassen sich daraus konkrete Fragen ableiten:
Wahrnehmung: Sind Informationen auch ohne alleinige Unterscheidung von Farben verständlich?
Bedienung: Lassen sich die benötigten Funktionen mit der Tastatur erreichen und ausführen?
Verständnis: Erklären Beschriftungen und Fehlermeldungen, was zu tun ist?
Technische Verlässlichkeit: Können unterstützende Programme erkennen, welche Bedeutung ein Bedienelement hat?
Ein Screenreader gibt Inhalte beispielsweise über Sprache oder eine Braillezeile aus. Damit die Bedienung funktioniert, muss die Anwendung die Bedeutung ihrer Elemente technisch erkennbar machen. Ein optisch auffälliger Knopf ohne verständliche Bezeichnung genügt dafür nicht. Die W3C-Leitlinien behandeln entsprechende Anforderungen an Namen, Rollen und Zustände von Bedienelementen. [4]
Für mich folgt daraus: Es reicht nicht, eine Seite nur unter den Bedingungen zu prüfen, unter denen sie gestaltet wurde.
Technische Leitlinien helfen – sie sind nicht das gesamte Gesetz
Eine wichtige Orientierung bieten die Web Content Accessibility Guidelines, WCAG. Die hier herangezogene W3C-Empfehlung WCAG 2.2 trägt den Stand 12. Dezember 2024. Sie enthält überprüfbare Anforderungen, etwa zu Tastaturbedienung, Kontrasten, sichtbarem Fokus und verständlicher Eingabeunterstützung. [4]
Diese technischen Kriterien sind für Entwicklung und Prüfung hilfreich. Eine bestandene WCAG-Prüfung ist aber nicht automatisch mit der Erfüllung sämtlicher Pflichten aus BFSG und BFSGV gleichzusetzen. Die gesetzlichen Regelungen betreffen beispielsweise auch Informationen über die Dienstleistung und bestimmte Unterstützungsangebote. [3]
Ich würde deshalb zwei Fragen getrennt dokumentieren: Welche rechtlichen Anforderungen gelten für unser Angebot? Und anhand welcher technischen Kriterien prüfen wir die Umsetzung?
So lässt sich vermeiden, dass ein allgemeiner Prüfbericht mehr verspricht, als tatsächlich untersucht wurde.
Für Entwickler: Gemeinsame Bausteine statt einzelner Nachbesserungen
Wenn jede Eingabemaske ihre eigenen Schaltflächen, Dialoge und Fehlermeldungen bekommt, muss auch deren Bedienbarkeit immer wieder neu geprüft werden.
Für eine neue Anwendung würde ich deshalb eine kleine Sammlung gemeinsam verwendeter Oberflächenelemente aufbauen. Dazu gehören verständlich beschriftete Eingabefelder, erreichbare Schaltflächen und Dialoge mit festgelegtem Tastaturverhalten.
Dabei sollte vorhandene Browserfunktionalität genutzt werden, wo sie passt. Das W3C weist in seinem am 10. Oktober 2026 geprüften ARIA-Leitfaden ausdrücklich darauf hin, dass eine zusätzliche Rollenbeschreibung allein noch kein Tastaturverhalten erzeugt. Wer ein gewöhnliches Element lediglich als „Schaltfläche“ kennzeichnet, muss die zugehörige Bedienung trotzdem richtig umsetzen. [6]
Für die Praxis heißt das: Nicht jedes Gestaltungselement muss technisch neu erfunden werden.
Gemeinsame Bausteine ersetzen allerdings nicht die Prüfung des vollständigen Ablaufs. Ein einzeln gut bedienbarer Dialog kann innerhalb einer Anwendung trotzdem an der falschen Stelle erscheinen oder den weiteren Zugang blockieren.
Formulare entscheiden darüber, ob Menschen weiterkommen
Gerade bei Formularen wird sichtbar, ob eine Anwendung verständlich entwickelt wurde.
Die W3C-Handreichung zu zugänglichen Formularen, aktualisiert am 27. März 2026, behandelt unter anderem eindeutige Beschriftungen, sinnvoll gruppierte Eingaben, verständliche Anweisungen und hilfreiche Rückmeldungen bei Fehlern. [5]
Ein Beispiel: Nach dem Absenden erscheint lediglich „Eingabe ungültig“. Die betroffene Person weiß weder, welches Feld gemeint ist, noch wie sie den Fehler beheben kann.
Besser wäre eine konkrete Rückmeldung, etwa: „Bitte ergänzen Sie bei der Telefonnummer die Ortsvorwahl.“ Die Meldung sollte dem betreffenden Feld zugeordnet sein und auch mit unterstützender Technik wahrgenommen werden können.
Bereits korrekt eingegebene Angaben würde ich bei einer Korrektur erhalten. Niemand sollte ein langes Formular vollständig neu ausfüllen müssen, weil an einer Stelle etwas fehlt.
Auch zeitliche Begrenzungen verdienen Aufmerksamkeit. Die W3C empfiehlt, vermeidbare Zeitlimits wegzulassen und notwendige Grenzen unter den beschriebenen Voraussetzungen abschaltbar oder verlängerbar zu gestalten. Sicherheitsanforderungen müssen dabei weiterhin berücksichtigt werden. [5]
Für die Architektur bedeutet das, Fehlerbehandlung und Sitzungsabläufe früh mitzudenken. Sie sind nicht nur eine Frage der späteren Textgestaltung.
Anmeldung und Bezahlung gehören zur Prüfung dazu
Eine zugängliche Startseite ist wenig wert, wenn anschließend die Anmeldung oder die Zahlungsbestätigung nicht bedienbar ist.
§ 19 BFSGV nennt für erfasste Dienstleistungen im elektronischen Geschäftsverkehr ausdrücklich Identifizierungs-, Authentifizierungs-, Sicherheits- und Zahlungsfunktionen. Auch diese müssen entsprechend zugänglich gestaltet werden. [3]
Deshalb würde ich bei der Auswahl externer Komponenten nicht nur fragen, ob sie technisch eingebunden werden können. Ich möchte wissen, ob sie unter den vorgesehenen Nutzungsbedingungen funktionieren.
Das betrifft beispielsweise Terminbuchungen, Zahlungsfenster oder die Auswahl eines Liefertermins. Die technische Herkunft eines Bausteins ändert für den Nutzer nichts daran, dass er Teil seines Bestellvorgangs ist.
Vor einer Freigabe würde ich deshalb den vollständigen Weg testen: vom ersten Aufruf über die Eingabe und eine mögliche Korrektur bis zur Bestätigung.
Automatische Prüfungen sind hilfreich, aber nicht ausreichend
Automatische Werkzeuge können auf bestimmte Probleme hinweisen. Sie können jedoch nicht allein feststellen, ob eine Website die Anforderungen an Barrierefreiheit erfüllt. Das W3C betont in seiner am 10. Oktober 2026 geprüften Übersicht, dass dafür auch fachkundige menschliche Bewertung erforderlich ist. [7]
Ein sauberer Prüfbericht wäre für mich deshalb kein Endpunkt, sondern ein Bestandteil der Qualitätssicherung.
Zusätzlich würde ich typische Aufgaben mit der Tastatur durchführen, Vergrößerungen ausprobieren und die Ausgabe mit geeigneter assistiver Technik untersuchen. Entscheidend ist dabei nicht, ob sich irgendwo ein Menü öffnen lässt, sondern ob die Aufgabe vollständig erledigt werden kann.
Das W3C empfiehlt außerdem, Menschen mit Behinderungen in die Bewertung einzubeziehen. Ihre praktische Nutzung ergänzt die technische Prüfung um Erfahrungen, die ein automatischer Test nicht vollständig abbilden kann. [7]
Auch solche Tests sind kein Ersatz für sämtliche Anforderungen. Eine einzelne Person kann nicht stellvertretend alle unterschiedlichen Nutzungsbedingungen prüfen.
Nachrüsten: Mit den entscheidenden Abläufen anfangen
Bei einer bestehenden Anwendung würde ich zuerst erfassen, welche Hindernisse die Nutzung unmittelbar verhindern.
Kann jemand sich nicht anmelden? Lassen sich Pflichtangaben nicht ausfüllen? Ist der Abschluss einer Bestellung unmöglich? Solche Probleme hätten für mich Vorrang vor einer rein optischen Überarbeitung.
Anschließend würde ich gemeinsame Ursachen suchen. Wenn dieselbe unzugängliche Auswahlbox an vielen Stellen verwendet wird, ist eine Korrektur dieses Bausteins sinnvoller als zahlreiche voneinander abweichende Einzeländerungen.
Dabei braucht jede Änderung eine erneute Prüfung im Zusammenhang. Eine neue Darstellung kann an einer Stelle helfen und an anderer Stelle den Tastaturfokus verdecken.
Ein nachträglich eingeblendetes Bedienmenü würde ich jedenfalls nicht allein als Nachweis ausreichender Barrierefreiheit akzeptieren. Maßgeblich wäre, ob die Anwendung selbst die benötigten Aufgaben zugänglich unterstützt.
Verständliche Inhalte bleiben eine redaktionelle Aufgabe
Technik kann keine verständliche Anleitung garantieren.
Wenn eine Schaltfläche „Weiter“ heißt, sollte erkennbar sein, wohin sie führt. Vor einer verbindlichen Handlung sollten deren Folgen deutlich werden. Hilfetexte gehören in die Nähe der Stelle, an der sie benötigt werden.
Auch wichtige Informationen würde ich nicht ausschließlich in eine Grafik schreiben. Die WCAG behandeln Textalternativen und den zurückhaltenden Einsatz von Schrift als Bild ausdrücklich. [4]
Für einen Blog bedeutet das beispielsweise: Das Titelbild darf den Beitrag ergänzen. Die Überschrift und die wesentlichen Informationen sollten aber ebenso als normaler Text vorhanden sein.
Barrierefreiheit verlangt damit Zusammenarbeit zwischen Entwicklung, Gestaltung und Redaktion. Eine technisch korrekte Oberfläche kann durch unverständliche Inhalte unnötig schwer benutzbar werden.
Was Nutzer bei einem Problem melden können
Wer an einer Anwendung scheitert, muss keine vollständige technische Diagnose liefern.
Hilfreich wäre eine kurze Beschreibung: Welche Aufgabe sollte erledigt werden? An welcher Stelle ging es nicht weiter? Welche Eingabemethode oder unterstützende Technik wurde verwendet?
Bei einem Screenshot sollten persönliche Angaben möglichst ausgeblendet werden. Eine verständliche Problembeschreibung ist wichtiger als die Weitergabe eines vollständigen Kundenkontos.
Für Anbieter gehört ein erreichbarer Rückmeldeweg deshalb zur laufenden Betreuung. Solche Hinweise würde ich nicht als Sonderwunsch behandeln, sondern als konkrete Information über eine Funktion, die unter bestimmten Bedingungen nicht nutzbar ist.
Mein Fazit: Zugänglichkeit ist ein Teil von Softwarequalität
Barrierefreiheit beginnt für mich nicht mit einem Siegel und endet nicht mit einem einmaligen Test.
Sie beginnt bei der Entscheidung, welche Menschen eine Anwendung selbstständig nutzen können sollen. Daraus folgen Anforderungen an Aufbau, Bedienung, Sprache und Qualitätssicherung.
Nicht jedes Problem lässt sich sofort lösen. Aber es sollte erkennbar sein, welche Hindernisse bestehen, wer sie bearbeitet und wie neue Funktionen geprüft werden.
Eine Anwendung ist nicht schon dann gut, wenn ihre Entwickler sie bedienen können. Sie muss auch für die Menschen funktionieren, für die sie gedacht ist.
Einordnung und Recherche
Recherchestand: 10. Oktober 2026. Allgemeine Information, keine rechtliche Prüfung eines konkreten Angebots und keine vollständige technische Barrierefreiheitsprüfung. BFSG-Ausnahmen und Übergänge sind einzelfallbezogen zu prüfen; WCAG-Kriterien allein decken nicht sämtliche gesetzlichen Pflichten ab.
Quellen und weiterführende Informationen
Originalquellen geprüft am 10.10.2026. Veröffentlichungs- und Abrufdaten sind zu unterscheiden.
[1] Barrierefreiheitsstärkungsgesetz – BFSG
Quelle lesen ↗
[1] Barrierefreiheitsstärkungsgesetz – BFSG
Quelle lesen ↗
[1] Barrierefreiheitsstärkungsgesetz – BFSG
Quelle lesen ↗
[1] Barrierefreiheitsstärkungsgesetz – BFSG
Quelle lesen ↗
[2] Bundesfachstelle Barrierefreiheit: FAQ zu Dienstleistungen im elektronischen Geschäftsverkehr
Quelle lesen ↗
[3] Verordnung zum Barrierefreiheitsstärkungsgesetz – BFSGV
Quelle lesen ↗
[3] Verordnung zum Barrierefreiheitsstärkungsgesetz – BFSGV
Quelle lesen ↗
[4] W3C: „Web Content Accessibility Guidelines 2.2“
Quelle lesen ↗
[5] W3C Web Accessibility Initiative: „Forms Tutorial“
Quelle lesen ↗
[6] W3C: „ARIA Authoring Practices Guide – Read Me First“
Quelle lesen ↗
[7] W3C Web Accessibility Initiative: „Evaluating Web Accessibility Overview“
Quelle lesen ↗