Barrierefreiheit beim Softwareeinkauf: Worauf du vor dem Kauf achten solltest

Ein neues Buchungs-Plugin, ein Chat-Tool oder ein Newsletter-Anbieter ist schnell eingebunden — und wird oft erst zum Problem, wenn ein Scan nach dem Einbau plötzlich neue Mängel zeigt, die aus dem eigenen Code gar nicht stammen. Zugekaufte Software ist eine der häufigsten Quellen für Barrieren, die niemand im eigenen Team verursacht hat.

Dieser Beitrag zeigt, wie du Barrierefreiheit schon bei der Auswahl von Software berücksichtigst, welche Fragen du Anbietern stellen solltest und wie du damit umgehst, wenn eine bereits genutzte Lösung durchfällt.

Warum Zukäufe ein blinder Fleck sind

Eigene Entwicklung lässt sich prüfen, bevor sie live geht. Zugekaufte Software dagegen wird häufig ohne eigene Prüfung eingebunden, weil sie als fertiges Produkt eines externen Anbieters wahrgenommen wird — nach dem Motto, das werde der Hersteller schon bedacht haben.

Diese Annahme trifft oft nicht zu. Viele Plugins, Widgets und SaaS-Tools sind nicht barrierefrei entwickelt, weil Barrierefreiheit für den Hersteller selbst kein geprüftes Kriterium war. Rechtlich bleibt die Verantwortung trotzdem bei dir als Betreiber der Webseite, nicht beim Softwarehersteller.

Je zentraler die Funktion — etwa ein Checkout-Baustein oder ein Buchungssystem —, desto größer der Schaden, wenn erst nach der Einführung auffällt, dass sie sich nicht barrierefrei nutzen lässt.

Erschwerend kommt hinzu, dass ein einzelnes Tool oft von mehreren Mitarbeitenden gleichzeitig eingeführt wird, ohne dass jemand die Gesamtübersicht behält — ein Marketing-Tool hier, ein Buchungssystem dort. Ohne zentrale Prüfung sammeln sich so über die Zeit mehrere unabhängige Fehlerquellen an, die einzeln jeweils klein wirken, in Summe aber erheblich sein können.

Fragen an den Anbieter vor dem Kauf

Frage konkret, ob das Produkt gegen einen anerkannten Standard wie WCAG 2.1 AA getestet wurde, von wem und wann zuletzt. Eine vage Antwort wie „wir legen Wert auf gute Usability“ ist kein Nachweis für tatsächliche Barrierefreiheit.

Frage nach einer Testmöglichkeit vor dem Kauf — eine Demo-Umgebung oder ein Testzugang, den du selbst mit einem Scan und einer kurzen Tastaturprüfung gegenchecken kannst, sagt oft mehr als jede Selbstauskunft.

Frage außerdem, wie mit gemeldeten Barrierefreiheits-Mängeln umgegangen wird: Gibt es einen definierten Prozess für Fehlermeldungen, oder bleibt das dem Zufall überlassen? Die Antwort zeigt, wie ernst der Anbieter das Thema langfristig nimmt, nicht nur zum Verkaufszeitpunkt.

Frage bei individualisierbaren Tools zusätzlich, ob die von dir vorgesehene Konfiguration ebenfalls geprüft wurde. Ein Basisprodukt kann barrierefrei sein, während dieselbe Software nach individueller Anpassung, etwa durch ein eigenes Theme oder Zusatzmodule, wieder neue Barrieren mitbringt.

Eigene Prüfung vor der Kaufentscheidung

Verlasse dich nicht ausschließlich auf Anbieterangaben. Teste, wenn möglich, die zentralen Funktionen selbst: Lässt sich das Tool vollständig mit der Tastatur bedienen? Sind interaktive Elemente für einen Screenreader verständlich benannt? Funktioniert es bei vergrößerter Textdarstellung noch sinnvoll?

Bei SaaS-Produkten, die in bestehende Systeme wie einen Online-Shop eingebunden werden, lohnt sich zusätzlich ein Blick darauf, ob die Einbindung selbst neue Probleme schafft — etwa durch iFrames ohne aussagekräftigen Titel oder Fokusfallen in eingebetteten Widgets.

Ein kurzer Test vor dem Kauf ist deutlich günstiger als eine nachträgliche Korrektur oder gar ein späterer Anbieterwechsel, nachdem interne Prozesse bereits auf das Tool aufgebaut wurden.

Barrierefreiheit als Kriterium im Beschaffungsprozess

Nimm Barrierefreiheit als festen Punkt in einen bestehenden Beschaffungsprozess auf, statt sie als informelle Nachfrage zu behandeln, die leicht untergeht. Eine kurze Checkliste, die vor jeder Anschaffung durchlaufen wird, reicht oft schon aus.

Bei größeren Anschaffungen, etwa einem neuen CMS oder einer Buchungsplattform, gehört Barrierefreiheit als eigener, klar formulierter Punkt in die Anforderungen, statt sie nur als allgemeine Erwartung mitlaufen zu lassen.

Wichtig ist, diese Prüfung nicht nur bei großen, sichtbaren Projekten anzuwenden, sondern auch bei kleineren Anschaffungen wie einzelnen Plugins, die in Summe genauso viele Barrieren erzeugen können.

Benenne innerhalb des Beschaffungsprozesses außerdem, wer die Entscheidung am Ende freigibt, wenn ein Tool die Prüfung nicht besteht. Ohne eine solche Eskalationsstelle setzt sich in der Praxis oft der günstigste oder funktional passendste Anbieter durch, unabhängig vom Ergebnis der Barrierefreiheitsprüfung.

Wenn eine bereits genutzte Lösung durchfällt

Zeigt ein Scan oder eine manuelle Prüfung, dass ein bereits im Einsatz befindliches Tool erhebliche Mängel hat, lohnt sich zunächst der direkte Kontakt zum Hersteller mit einer konkreten Fehlerbeschreibung — viele Anbieter reagieren auf präzise, nachvollziehbare Meldungen eher als auf allgemeine Kritik.

Parallel solltest du realistisch einschätzen, wie kritisch die betroffene Funktion für deine zentralen Nutzerprozesse ist. Bei einem Randfeature reicht oft eine Frist zur Nachbesserung, bei einer zentralen Funktion wie dem Checkout kann ein Anbieterwechsel die konsequentere Lösung sein.

Dokumentiere die gefundenen Mängel und die Kommunikation mit dem Hersteller — diese Dokumentation ist Teil des Nachweises, dass du dich aktiv um Barrierefreiheit bemühst, auch wenn eine sofortige technische Lösung noch aussteht.

Prüfe bei größeren, geschäftskritischen Tools auch, ob ein Wechsel zeitlich überhaupt kurzfristig realistisch ist. Ist er das nicht, dokumentiere zusätzlich, welche Zwischenschritte du bis zu einem möglichen Wechsel unternimmst, statt das Thema bis zur nächsten Vertragsverlängerung ruhen zu lassen.

Open-Source-Komponenten und Baukästen

Auch kostenlose oder Open-Source-Komponenten sind keine Ausnahme von dieser Prüfung, nur weil kein klassischer Kaufprozess dahintersteht. Community-Plugins unterscheiden sich stark in ihrer Qualität, und Barrierefreiheit ist selten ein zentrales Entwicklungsziel kleinerer Projekte.

Website-Baukästen bringen eigene Einschränkungen mit, die sich oft nicht durch eigene Entwicklung umgehen lassen — konkrete Hinweise dazu liefert der Beitrag zu Barrierefreiheit bei Website-Baukästen.

Prüfe bei Open-Source-Komponenten zusätzlich, wie aktiv das Projekt gepflegt wird — eine Komponente ohne aktive Weiterentwicklung wird gefundene Mängel wahrscheinlich nicht mehr beheben.

Gerade weil solche Komponenten meist ohne formalen Einkaufsprozess eingebunden werden, lohnt sich hier eine klare interne Regel: Wer ein neues Plugin oder eine neue Bibliothek einbindet, prüft vorab kurz, ob es aktiv gepflegt wird und ob bekannte Probleme mit Barrierefreiheit gemeldet wurden.

Hinweis: Dieser Beitrag bietet eine allgemeine Orientierung und ersetzt keine individuelle Prüfung der von dir genutzten Software.

Häufig gestellte Fragen