Definition & Prüfbarkeit von Barrierefreiheit

Barrierefreiheit für das Internet zu definieren, war vergleichsweise leicht. Es gibt Quelltexte, die für alle einsehbar und damit beurteilbar sind. Wird der Quelltext dynamisch generiert, was heutzutage die Regel ist, kann anhand des DOM (Document Object Model), der vom Browser erzeugt wird, eine weitere Quelle zur Beurteilung der Barrierefreiheit hinzugezogen werden. Auf dieser Basis wurden und werden eine Vielzahl von Prüfwerkzeugen entwickelt, die das Testen erleichtern sollen. So lässt sich leicht herausfinden, ob ein Bedienelement mit der korrekten Rolle, dem korrekten Namen und bei Bedarf Wert und Status versehen sind und ob das Aussehen von Bestandteilen wie Bildern, Texten, Überschriften, Listen etc. sich auf der semantischen Ebene widerspiegelt, damit bei Screenreader-Nutzung sich eine vollkomme Entsprechung des Sichtbaren erschließen lässt. Mit Hilfe von Berater*innen können Korrekturvorschläge erarbeitet und Alternativen skizziert werden. 

Auf Anwendungssoftware kann diese Vorgehensweise nicht übertragen werden. Semantische Entsprechungen für Überschriften, Listen oder Texte lassen sich bei der Nutzung von Programmierumgebungen, wie z. B. Visual Studio oder Eclipse, nur selten finden. Dafür gibt es aber durchaus Control-Typen (Controls) mit einer Vielzahl von möglichen Property-Werten, die Rückschlüsse auf die korrekte Verwendung von Name, Rolle, Wert und Status für ein Benutzungsschnittstellenelement ziehen lassen. Doch je nach verwendeter Programmiersprache ändern sich die Controls und die damit verbundenen Definitionsmöglichkeiten. Hinzu kommt, dass Betriebssysteme unterschiedliche Accessibility-Schnittstellen - oder besser Accessibility API (Application Programming Interface) - verwenden. In der Windows-Welt sind aktuell UI-Automation und das bereits betagte MSAA (Microsoft Active Accessibility) üblich. Doch auch APIs wie iAccessible2 finden in der Windows-Welt Anwendung. Vor allem dann, wenn es darum geht, in Java geschriebene Programme für Screenreader zugänglich zu machen.

Zusätzliche Komplikationen ergeben sich, wenn man Drittanbieter-Anwendungen innerhalb einer Anwendung zur Verfügung stellt. Im Fall von DMS ist das oft ein Multi-Format-Betrachter und -Editor für Text-Dokumente wie PDF- oder Word-Dateien. Da in solchen Programmen für die barrierefreie Nutzung die korrekte semantische Wiedergabe von Überschriften, Listen, Bildern oder Formatierungen wie fett, kursiv, unterstrichen, Textgröße, Textart etc. maßgeblich ist, müssen diese Informationen ebenfalls ihren Weg durch das Accessibility-API finden. Im Gegensatz zu Browsern lässt sich hier aber nicht einfach ein Blick in den Quelltext werfen, sondern man ist auf Prüfprogramme, wie z. B. inspect.exe angewiesen, die Control-Typen und dazu gehörende Property-Werte anzeigen. Allerdings ist das nur für das UIAutomation und das MSAA API möglich. IAccessible2 ist so nicht prüfbar.

Diese Ausführungen sollen einen beispielhaften Einblick zu geben, mit welchen Problemen man konfrontiert ist, wenn man Anwendungssoftware auf Barrierefreiheit untersuchen will. Glücklicherweise gibt es bereits Prüfverfahren, wie z. B. den BIT inklusiv-Anwendungssoftware-Test, der eine klare Aussage zur Barrierefreiheit von Anwendungssoftware zulässt, die das UIAutomation- oder MSAA-API verwendet.

Im Rahmen von IDESkmu bietet sich die Möglichkeit, diese Verfahren nicht nur weiterzuentwickeln, sondern genau auf DMS und ECMS abzustimmen und so eine konkrete Definition für deren Prüfbarkeit zu finden. Dabei wird die Weiterentwicklung des Standards EN 301 549 berücksichtigt, der Einzug in die Anforderungen der BITV (Barrierefreie Informationstechnik Verordnung des Bundes) erhalten hat. Auch die Prüfmöglichkeiten haben sich in den letzten Jahren geändert. Neben inspect.exe gab es zwar bereits immer schon andere Prüfprogramme, wie z. B. AccCheckUI oder AccScope (unter Windows 10 leider nicht mehr lauffähig), doch Neuerungen, wie z. B. AccessibilityInsights wurden bisher in das Test-Prozedere noch nicht mit einbezogen, obwohl sie vielversprechend wirken.

IDESkmu wird am Beispiel von DMS neue Prüfmethoden testen und in bestehende Verfahren integrieren. Ziel ist es, die Spannweite der Möglichkeiten zum Testen von Software zu erweitern und gleichzeitig die praktische Prüfung zu vereinfachen. Prüfprogramme sollen an jeder Stelle transparent machen, was genau geprüft wird. Dazu müssen Prüfanleitungen an den Status Quo angepasst und überarbeitet werden.