Kommunikation mit Kunden & Nutzern

Eine große Anzahl an Vergabeverfahren, in welchen zwar die Barrierefreiheit der ausgeschriebenen Software gefordert, die dafür notwendigen Kriterien aber nicht konkretisiert wurden, haben zu einem größeren Bewusstsein für die Notwendigkeit barrierefreier Softwarelösungen geführt. Dahinter stehen auf rechtlicher Ebene die europäische Richtlinie 2102 von 2016 mit ihren klaren Barrierefreiheits-Anforderungen für den öffentlichen Bereich und die daraus folgende Novelle der BITV von 2019. Softwarehersteller waren so entweder dazu gezwungen, ihre Software von externen Expertinnen und Experten überprüfen zu lassen und in der Folge zu überarbeiten, oder darauf zu vertrauen, dass ihre Software ausreichend zugänglich ist und einer eventuellen Prüfung standhalten würde.

War die ausschreibende Stelle die öffentliche Hand, so kam es nicht selten zu einer Prüfung nach erfolgter Vergabe. Das brachte die öffentliche Stelle in eine unangenehme Lage: Die Haupt-Schwerbehindertenvertretung (SV) forderte ein Gutachten über den Stand der Barrierefreiheit der betreffenden Software an. Das darauf in Auftrag gegebene Gutachten dokumentierte, dass die Software nicht barrierefrei ist. Nun musste sich die öffentliche Stelle gegenüber ihrer SV rechtfertigen, Termine nennen und die Überarbeitung der Software neu beauftragen. Das ist meist nicht nur mit zusätzlichen Kosten verbunden, sondern auch mit einem nicht unerheblichen Verwaltungsaufwand, der wertvolle Zeit und Ressourcen kostet. Potenziell entstehen dabei Differenzen, die einen Vertrauensverlust zur Folge haben. Für Softwareanbieter, meist im Mittelstand angesiedelt, eine möglicherweise existenzielle Situation.

Doch auch dann, wenn die ausschreibende Stelle nicht öffentlich ist, also selbst auch dem Mittelstand angehört, entsteht oft Unklarheit über die hinsichtlich der Barrierefreiheit einzuhaltenden Kriterien.

Daher hat es sich IDESkmu zur Aufgabe gemacht, die Softwareentwicklung und -überarbeitung so zu unterstützen, dass die oben beschriebene Situation erst gar nicht entsteht.

• Wir entwickeln Prüfverfahren und Fragenkataloge für Laien und Expert*innen, die die Softwareentwicklung optimal unterstützen.
• Wir optimieren Beratungs- und Prüfprozesse, damit der Mehraufwand in der Entwicklung den bisherigen Workflow nicht stört, sondern sensibilisierend bereichert.
• Wir bieten Unterstützung bei Ausschreibungen, die auf allen Seiten Klarheit schafft und den potenziellen Bieterkreis nicht unverhältnismäßig einschränkt.
• Wir bieten Vernetzungsmöglichkeiten, damit einmal gefundene Lösungen über das Projekt hinaus für die Öffentlichkeit nutzbar sind.
• Wir realisieren einen DMS-Musterarbeitsplatz, der als Inspirationsquelle für Alle dienen kann.

Die Lösungen, die wir beispielhaft für die Entwicklung oder Überarbeitung von Dokumentenmanagementsystemen (DMS) und Enterprise Content Managementsystemen (ECMS) finden, können auf andere Softwareprodukte bzw. Entwicklungsprozesse übertragen werden.

Dass dies nicht allein in Entwicklungsabteilungen umsetzbar ist, sondern ein unternehmensweites Bewusstsein für die Belange von Menschen mit Behinderungen voraussetzt, ist offensichtlich. iDESkmu wird deshalb neben Fragenkatalogen und Expert*innen-Tests auch Kommunikationskonzepte für alle Unternehmensebenen entwickeln.

Die notwendige Expertise, um Barrieren zu erkennen, kann durchaus abgestuft betrachtet werden:

• Betroffene liefern über die Kooperation ihrer Hilfsmittel mit der Software wertvolle Infos
• Expert*innen liefern in Kenntnis der notwendigen Standards und Richtlinien über die kombinierte Anwendung von Prüftools und Hilfsmitteln (sofern möglich, mit Blick auf den Quelltext) eindeutige Informationen über mögliche Barrieren
• Das Windows-Betriebssystem besitzt eine Reihe von Einstellmöglichkeiten, die es auch Nicht-Expert*innen (in Grenzen) erlauben, Barrieren zu identifizieren
• Eine der wichtigsten Quellen wird im Bereich der Barrierefreiheit oft vergessen: die Nutzerzufriedenheit

Die Nutzerzufriedenheit kann nicht nur im Bereich der Usability zum Haupt-Hinweisgeber für die notwendige Überarbeitung von Software genutzt werden, sondern auch zur Ermittlung von Barrieren. Denn wenn bei der Nutzung eines Programms Schwierigkeiten auftreten, dann werden diese in der Regel hingenommen. Wenn es eine größere Anzahl solcher Schwierigkeiten gibt, dann wird das Programm von den Nutzer*innen oft bereits als unbrauchbar bezeichnet. Manchmal ist es aber auch so, dass man sich beim Gebrauch, unabhängig von der Tagesverfassung, unsicher fühlt. Diese diffuse Unsicherheit stellt, richtig genutzt, einen wertvollen Hinweis potenzieller Barrieren für Entwicklerinnen und Entwickler dar.