Doppelte Barrierefreiheit mit axesWord 23.1 - mit Detlef Girke

Seit etwas mehr als 20 Jahren. Ich bin studierter Elektroingenieur und auf der Suche nach einem Job, der Technik und Soziales verbindet, bin ich auf den Hamburger Blinden- und Sehbehindertenverein zugegangen. Zufälligerweise wurde dort zu dieser Zeit das Projekt BIK (Barrierefrei Informieren und Kommunizieren) ins Leben gerufen, in welchem ich dann als Berater angefangen habe. So nahm das seinen Lauf.

Seit 2008 bin ich selbstständig in der Branche tätig, habe aber ein Team von Leuten um mich, mit denen ich gerne regelmäßig zusammenarbeite. Dazu gehören z.B. Prüfaufträge, bei denen wir uns das Testen, die Qualitätssicherung und den Prüfbericht aufteilen. Wir testen sowohl Software, Webseiten als auch PDF-Dokumente – eigentlich alles! Anteilig hat sich das in den letzten Jahren stark verändert. Früher waren es deutlich mehr Websites, mittlerweile würde ich sagen, dass der Anteil der Software-Prüfungen überwiegt.

Ursprünglich ist der Software-Test im Rahmen des Projektes BIT Inklusiv entstanden, da es damals noch kein Prüfverfahren für Anwendungssoftware gab. Allerdings gab es schon den europäischen Standard zur Vergabe barrierefreier IT, auf Grundlage dessen wir das Prüfverfahren entwickelt haben. Dieses hat Software in einem relativ kompakten Verfahren auf Praxistauglichkeit, Konformität mit der Norm und Usability getestet.

Ja, die letzte große Novelle hat er im vergangenen Jahr erfahren und wurde damit stärker an die aktuelle EN Norm angepasst. Es freut mich sehr, dass das BIT inklusiv-Projekt – obwohl ehrenamtlich – noch aktiv ist und fortlaufend an der Weiterentwicklung des Prüfverfahrens gearbeitet wird. Mittlerweile hat das Verfahren 75 Prüfschritte und bezieht damit alle relevanten Kriterien der EN Norm 301 549 mit ein. (Unter bit-inklusiv.de können diese eingesehen werden.) Da die EN Norm der Maßstab für die BITV-Konformität ist, ist dieser Standard mit dem BITi-Test ebenfalls abgedeckt.

Die Zeiten sind durch die vielen Prüfschritte definitiv länger geworden. Vier Tage, sprich 32 Stunden, sitzt man da schon locker dran.

Es wird beispielsweise die richtige Rollenbezeichnung geprüft, also dass die einzelnen Elemente mit der richtigen Rolle ausgegeben werden. Dafür arbeite ich mich mit dem Screenreader durch die Anwendung. Wenn z.B. eine Ausklappliste als Eingabefeld ausgegeben wird, kann ein vollständig blinder Nutzer dies nicht erkennen und muss über Umwege herausfinden, wie er weiter navigieren muss. Ein anderes Beispiel sind Beschriftungen von Formularfeldern. Es kommt immer wieder vor, dass man durch das Dokument navigiert und nur hört „Eingabefeld“ – Aber für was? Ein sehender Mensch kann hier den Kontext in wenigen Sekunden erfassen, während eine sehbeeinträchtigte Person diesen nur auf Umwegen in Erfahrung bringen kann, was durchaus mehrere Minuten in Anspruch nehmen kann.

Ja, Barrierefreiheit schon. Wir erleben aber leider häufig, dass die Usability darunter leidet. Es ist durchaus möglich eine Anwendung komplett barrierefrei zu programmieren, die jedoch in der alltäglichen Verwendung eigentlich nicht zu gebrauchen ist. In meinen Anmerkungen im Prüfbericht schreibe ich sowas natürlich dazu, um auch für Usability zu sensibilisieren.

Man merkt, dass hier Leute am Werk waren, die sich mit Barrierefreiheit beschäftigt haben. Bereits in der alten Version war die Software gut nutzbar, dementsprechend lag die Messlatte nun besonders hoch. Im Vorher/Nachher-Vergleich könnte man es durchaus als Wechsel von gut zu perfekt bezeichnen. Die Anmerkungen, die ich im alten Prüfbericht gemacht hatte, wurden angegangen und sehr gut umgesetzt. Damit ist axesWord wirklich eine sehr gute, barrierefreie Anwendung geworden!

Meine Erfahrung ist ehrlich gesagt, dass viele Entwickler keine Erfahrung mit dem Thema haben und ich eine gewisse innere Abwehr spüre. Wozu brauchen wir das überhaupt? Wir beschäftigen doch aktuell überhaupt keine beeinträchtige Person? Denen erkläre ich dann, dass Barrierefreiheit einen Nutzen für alle hat, z.B. für Brillenträger, die mit geringen Kontrasten zu kämpfen haben. Ich habe schon erlebt, dass Leute durch einen plötzlichen Unfall erblindet sind und nicht mehr mit der Anwendung arbeiten konnten. Dem könnte man mit barrierefreien Anwendungen von Vornherein vorbeugen.

Wenn es darum geht wirklich PDF/UA-konform zu sein, ist axesWord das Tool der Wahl. Ich kenne kein anderes Tool, das auf Knopfdruck die PDF/UA-Konformität einbaut. Ich kenne auch kein Tool, das so schön mit Fußnoten umgeht – dass man wirklich von der Zahl zur Fußnote und wieder zurück zum Inhalt springen kann. An nächster Stelle steht, was die Einfachheit betrifft, der PDF-Export in Microsoft Word. Das ist sofort getaggt und kann von blinden Menschen gelesen werden ohne dass Acrobat Pro dafür gebraucht wird.

Ich war tatsächlich bei einem solchen Ausschreibungsverfahren einmal von Anfang an dabei, dabei ging es um eine eAkte in einem Bundesland. Was wir dann gemacht haben, ist, dass wir geschaut haben, welche Kriterien wir unbedingt in der Ausschreibung brauchen, jedoch ohne dass es gleich abschreckend wirkt. Das hat dazu geführt, dass viele Angebote vorlagen, die ich getestet habe. Am Ende wurde zwar nicht mein Favorit in Sachen Barrierefreiheit genommen, aber zumindest eine Anwendung, die nicht am schlechtesten abgeschnitten hat.

Das Problem ist, wie willst du Effizienz messen und welches Kriterium der EN 301 549 wird dazu herangezogen? Ich mache das über die Tastaturbedienbarkeit, und kritisiere z.B. wenn Elemente zwar bedienbar sind, aber nur über Umwege. Darüber hinaus bleiben in Sachen Barrierefreiheit nach Standard nicht so viele Wege um zu sagen, ob etwas effizient ist oder nicht. Da müsste man dann über die Usability-Kriterien gehen.

Also ich wünsche mir, dass das Thema zur Selbstverständlichkeit in der Dokumenten-, Web- und Softwareentwicklung wird; dass zum Beispiel bei jeder Anwendung im Rahmen der Qualitätssicherung sofort die Frage gestellt wird: Ist das auch tastaturbedienbar? Wie springe ich von Bereich zu Bereich? Dass solche Fragen ganz selbstverständlich gestellt werden.