Aktuelles

Universelles Design und Software

veröffentlicht am 26. Januar 2018

Dieser Beitrag ist Teil einer Blogpostreihe mit den folgenden Blogposts:

Im Rahmen dieser Blogpostreihe wurde bisher die Zusammenarbeit mit dem Behindertenverband Leipzig e.V. thematisiert. Die Schwerpunkte lagen dabei auf dem Datenmanagement seiner Gebäude-Datenbank, ihrer Publikation in maschinenlesbare Formate sowie die Vorstellung einer Web-Applikation (Gebäude-Navigator), welche die Datenbank zur Bereitstellung einer nutzerfreundlichen Gebäude-Suche und -Filterung nutzt.

Bereits während der Entwicklung des Gebäude-Navigators fragten wir uns, ob man das Konzept der Barrierefreiheit bzw. Universal Design auf die Teile zur Entwicklung einer Software anwenden kann. Dabei interessierten uns vordergründig die Entwickler und Volontäre, welche aktiv zur Weiterentwicklung beitragen oder sich dafür interessieren. Im Folgenden werden Entwickler und Volontäre der Einfachheit halber unter dem Begriff Entwickler zusammengefasst.

Folgende Fragen stellen sich uns:

Welche Dinge unterstützen bzw. behindern Entwickler, …

… sich in die Grundlagen einer Software einzuarbeiten? (Einstiegshürden)
… eine Software für eigene Zwecke einzusetzen? (Anwendung)
… eine Software in die eigene Software zu integrieren? (Integration)
… zur Weiterentwicklung einer Software beizutragen? (Weiterentwicklung)

Bevor es um diese Fragen geht, werden jedoch einige Begriffe definiert. Danach erfolgt eine differenzierte Behandlung dieser Fragen.

Der Fokus in den folgenden Betrachtungen liegt auf Open Source Software. Der Einsatz in Unternehmen wird dabei ebenso wenig ausgeschlossen, wie der Vertrieb von Open Source Software, z.B. im Rahmen von Support-Verträgen.

Wichtige Begriffe

Die Begriffe Barrierefreiheit und universelles Design liegen, auch wenn der alltägliche Sprachgebrauch dies nicht vermuten ließe, nah beieinander. Barrierefreiheit wird im Alltag eher im Zusammenhang mit Gebäuden gebraucht. Jedoch erstreckt er sich grundsätzlich nicht nur auf Strukturen der Umwelt, wie Gebäude, sondern auch auf deren Nutzung. Das Bundeskompetenzzentrum Barrierefreiheit definiert den Begriff im weiteren Sinne wie folgt: “[…] Die Umwelt soll so gestaltet sein, dass sie die Bedürfnisse aller Menschen berücksichtigt. Keine Personengruppe soll aufgrund einer bestimmten Gestaltung von der Nutzung ausgeschlossen werden. Dieses Verständnis der Barrierefreiheit wird auch “Design für alle” oder universelles Design genannt.” Statt sich nur auf Menschen mit Behinderung zu beziehen, wird sich stattdessen auf alle Menschen bezogen. Denn nicht nur Menschen mit Behinderung profitieren von barrierefreien Zugängen. Eine Rampe z.B. hilft nicht nur Rollstuhlfahrern, sondern auch Eltern mit einem Kinderwagen. Man kann also sagen, dass etwas, das barrierefrei ist, den 7 Prinzipien des universellen Designs entspricht.

Im Folgenden werden die Begriffe behindern und hindern verwendet, weshalb das Konzept der Behinderung hier kurz definiert werden soll. Im Folgenden wird aus unterschiedlichen Definitionen der Begriffe jene der UN-Behindertenrechtskonvention (deutsche Übersetzung im Bundesanzeiger) ausgewählt. Darin heißt es in der Präambel, Buchstabe e: “Recognizing that disability is an evolving concept and that disability results from the interaction between persons with impairments and attitudinal and environmental barriers that hinders their full and effective participation in society on an equal basis with others”. Zusammenfassend übersetzt: Eine Behinderung entsteht genau dann, wenn ein Mensch an der Teilhabe am (gesellschaftlichen) Zusammenleben gehindert wird, z.B. aufgrund von wie auch immer gearteten Barrieren.

Barrierefreiheit und Universelles Design bei Software

In Beiträgen über Barrierefreiheit und Software scheint es vordergründig um die barrierefreie Gestaltung der Nutzeroberfläche einer Software zu gehen. Die Bundesfachstelle Barrierefreiheit hat eine Übersicht publiziert, welche neben Hilfsmitteln zur Nutzung von Software auch allgemeine Regeln/Hinweise zur Gestaltung von Software enthalten. In dem Zusammenhang wird auch auf die Web Content Accessibility Guidelines(deutsche Übersetzung) und DIN EN ISO 9241 verwiesen. Weitere Suchergebnisse bei Google in diesem Zusammenhang haben eine ähnliche Ausrichtung.

In diesem Blogpost soll es jedoch um Open Source Software und deren Entwickler gehen, welche ebenfalls Nutzer sein können. Bei Open Source Software handelt es sich (verkürzt dargestellt) um Software, deren Quellcode allgemein verfügbar und zugänglich ist und i.d.R. unter einer freien Lizenz steht. Neben Open Source Software wird in diesem Zusammenhang auch von quelloffener Software gesprochen.

Über Open Source Software

Open Source Software prägt derzeit große Teile der Softwarelandschaft, sowohl in Unternehmen, in der öffentlichen Verwaltung als auch im Privaten. Der überwiegende Teil des Internets läuft auf Linux-basierten Systemen, welche i.d.R. unter einer freien Lizenz, wie der GPL stehen. Auf modernen Smartphones ist zumeist ein Linux-basiertes Betriebssystem namens Android installiert, welches als quelloffene Software entwickelt wird (einer Analyse von Gartner zufolge, wurden im 2. Quartal 2016 86,2% aller Smartphones mit einem Android-Betriebssystem verkauft).

Open Source Software wird in der Regel kollaborativ und transparent entwickelt. Dafür nutzen Beteiligte Web-Plattformen, wie Bitbucket oder Github, um sich untereinander abzustimmen, Probleme zu diskutieren und Quellcode-Beiträge (z.B. Pull Requests bei Github) entgegenzunehmen. Diese Plattformen haben das Ziel, die auf ihnen gehostete Software adäquat zu präsentieren und die zugehörigen Entwickler zu unterstützen.

Relevante Bereiche für Entwickler

Es gibt eine Reihe von Bereichen einer Software, die für Entwickler relevant sind. Dabei wird jedoch im Vorfeld unterschieden zwischen:

die Software an sich (Software-Quellcode)
Rahmenwerk zur Software: Dokumentation, Hilfsdienste, Lizenz usw.

Jeder Bereich kann für interessierte Entwickler unterschiedlich von Interesse sein. Manche möchten erst wissen, ob ein konkretes Problem gelöst wird, andere wiederum prüfen zuerst, ob die Lizenz passt. Aus diesem Grund werden die Bereiche im Folgenden gleichberechtigt behandelt und in der folgenden Abbildung dargestellt.

Software-Quellcode

Die folgenden Unterbereiche betreffen den Software-Quellcode und werden als relevant für Entwickler angesehen. Dabei werden für jeden Bereich Unterscheidungen hinsichtlich relevanter Zugänglichkeiten getroffen.

Coding-Style: Mit Coding-Style bezeichnet man die Art und Weise, wie Quellcode strukturiert und formatiert wird. Quellcode, welcher gut lesbar ist, unterstützt den Leser bei der Einarbeitung und bei dem allgemeinen Umgang mit der Software.

Beispiele:

PSR-2 Coding-Style für PHP
Coding Styles für JavaScript bereitgestellt von Google und einmal von Airbnb

Design Pattern: Sie beschreiben die Organisation und den Datenfluss bestimmter Software- Teile. Der Einsatz von Design Pattern kann zwar helfen, die Arbeitsweise einer Software besser zu verstehen, jedoch muss der Entwickler dazu auch das nötige Hintergrundwissen besitzen. Es gibt keine Liste offizieller Design Pattern, daher liegt es am Entwickler sich diese bei Bedarf zu erarbeiten.

Kommentare im Quellcode: Die sogenannte Inline-Dokumentation wird verwendet, um das Verhalten des Programms zu beschreiben und den Leser mit zusätzlichen Hintergrundinformationen zu versorgen. Kommentare können daneben auch zur Strukturierung und Orientierung des Quellcodes eingesetzt werden.

Rahmenwerk zur Software

Allgemeine Dokumentation

Eine Dokumentation kann Webseiten, Handbücher, Illustrationen o.ä. umfassen. Sie beschreibt, was die Software leistet und was man von ihr erwarten kann. Weiterhin soll diese Dokumentation Fragen rund um den Einsatz der Software beantworten.

Kommentare im Quellcode: Zu den oben bereits genannten Aufgaben der Kommentare kommen weitere hinzu: Diese können im Quellcode Referenzen auf externe Quellen enthalten und verknüpfen den Quellcode mit der (externen) Dokumentation.

Zusatzdienste bzw. -tools

Mithilfe von Zusatzdiensten können sich Entwickler die Arbeit mit der Software erleichtern bzw. den Aufwand bei der Weiterentwicklung reduzieren. Als Beispiel seien hier PHPUnit, für die Ausführung lokaler Tests, und Travis für Continuous Integration genannt.

Zusatzdienste bzw. -tools können unterschiedlich eingeteilt werden:

Nach Einatzort:

lokal (auf einem eigenen Computer oder Endgerät) und
als Webservice (meist betreut von einer dritten Partei)

Nach Einsatz im Lebenszyklus einer Software:

Während Softwareentwicklung (z.B. Debugging, Testing, Deployment) und
bei der Nutzung der Software:
- Analyse der Software bzw. deren Verhalten (z.B. mithilfe von Profiling, Traffic-Analyse bei Webanwendungen) und
- bei Problemen/Fragen über die Software bzw. benötigte Dritt-Systeme (z.B. über Bug-Tracker für das Melden von Fehlern).

Lizenz

Eine Lizenz regelt die Nutzungsbedingungen einer Software, d.h. sie beschreibt, wie die Software unter welchen Bedingungen eingesetzt werden kann/darf.

Für Unternehmen ist die Lizenz ein kritischer Punkt und kann zu einem Ausschluss der Nutzung von Software führen, unabhängig von deren Funktionen. So erzwingt z.B. die GPL-Lizenz die Offenlegung des Quellcodes und erfordert die Erhaltung der Lizenz und Bedingungen, wenn eine Software verändert wird und man sie Fremden zur Verfügung stellt. Dies steht jedoch Vorhaben von Firmen, z.B. mit Software-Lizenzen Geld zu verdienen, diametral gegenüber.

Beeinträchtigungen der Zugänglichkeit

In jedem der genannten Bereiche gibt es Dinge, die sich negativ auf die Zugänglichkeit auswirken können. Die folgende Auflistung benennt mögliche Beeinträchtigungen, die Entwickler erfahren können, wenn sie sich mit einer Open Source Software näher beschäftigen.

Die Tabelle erhebt jedoch keinen Anspruch auf Vollständigkeit, kann allerdings einen Ausgangspunkt darstellen. Diese Beeinträchtigungen können in verschiedenen Ausbaustufen auftreten und Menschen auf unterschiedliche Weise behindern.

Software-Quellcode

Bereich	Negative Auswirkungen auf Zugänglichkeit
Coding-Style	(CS-1) Schwer lesbarer, nicht konsistent formatierter Quellcode
	(CS-2) Verwendung von unklaren Variablen- oder Funktionsnamen
Design Pattern	(DP-1) Komplexe Design Pattern
	(DP-2) Schlecht bzw. unzureichend dokumentierte Design Pattern
Quellcode-Kommentare	(QCK-1) Kommentare sind nicht in Englisch geschrieben
	(QCK-2) Unpräzise, mehrdeutige Kommentare
	(QCK-3) Unklare Kommentare, Verwendung komplexer, ggf. nicht erklärter Begriffe
	(QCK-4) Nicht benötigter Quellcode wird so auskommentiert, dass er den Lesefluss bzw. das Verständnis negativ beeinflusst.

Rahmenwerk zur Software

Bereich	Negative Auswirkungen auf Zugänglichkeit
Allgemeine Dokumentation	(D-1) Dokumentation faktisch nicht vorhanden, unvollständig bzw. fehlerhaft
	(D-2) Dokumentation nicht für entsprechende Nutzergruppen geschrieben (z.B. Verständnisprobleme, wenn spezielles Hintergrundwissen nicht bekannt)
Kommentare im Quellcode	(QCK-5) Extern genutzte Dokumentation ist nicht verlinkt bzw. referenziert
Zusatzdienste bzw. -tools	(ZDT-1) Installation der Software wird durch Zusatztool verhindert (z.B. als nicht auflösbare Abhängigkeit)
	(ZDT-2) Verwendung von Zusatzdiensten, welche selbst nicht zugänglich/benutzerfreudlich sind
	(ZDT-3) Tools werden auf nicht-dokumentierte Weise eingesetzt
Lizenz	(L-1) Verwendung unklarer, mehrdeutiger bzw. widersprüchlicher Nutzungsbedingungen/Lizenzen
	(L-2) Lizenzbedingungen zu restriktiv für die eigene Anwendung (z.B. Beeinträchtigung Verkauf von Software-Lizenzen)

Potenzielle Maßnahmen zur Verbesserung der Zugänglichkeit

Die folgende Auflistung enthält Maßnahmen, welche die Zugänglichkeit potenziell verbessern.

Software-Quellcode

ID	Maßnahme
CS-1 + CS-2	Konsistente Verwendung etablierter Coding-Styles, Vermeidung eigener Formatierungen.
DP-1 + DP-2	Verwendung von gut dokumentierten Design Pattern. Informationen über Pattern sollten ebenso gut sichtbar in Dokumentation zu finden sein.
QCK-1	Kommentare sollten mindestens in Englisch vorliegen, insofern man auch Nicht-Muttersprachler in die Entwicklung einbeziehen möchte.
QCK-2 + QCK-3	Mithilfe von Kommentaren sollte man sowohl eingangs einen Überblick schaffen, als auch später ggf. Detailwissen vermitteln. Fachwörter sollten erklärt bzw. verlinkt sein.
QCK-4	Mithilfe eines Versionskontrollsystems (z.B. Git) kann nicht benötigter Quellcode gelöscht und ggf. wiederhergestellt werden. Auskommentierter Quellcode stört den Lesefluss und sollte vermieden werden.

Rahmenwerk zur Software

Allgemeine Dokumentation

ID	Maßnahme
D-1	Der Fokus sollte anfangs darauf liegen einen Überblick über die eigene Software zu geben sowie die Installation und ersten Schritte im Umgang zu erläutern. Ergänzt werden sollte dies durch eine API-Dokumentation. Dazu findet man z.B. hier eine kleine Übersicht mit weiterführendes Informationen.
D-2	Dokumentation verwendet passende Begriffe und Beschreibungen für jeweilige Nutzergruppe (z.B. Endanwender, Entwickler). Weiterhin ist Dokumentation für Lesegeräte/Text-to-Speech-Software geeignet.
QCK-5	Externe Dokumentation sollte so verlinkt sein, dass entsprechende Textstellen per Link erreichbar sind. Referenziert man ein Buch o.ä., sollte die Quelle optimalerweise online lesbar sein.
ZDT-1	Insbesondere beim Einsatz von lokalen Zusatztools sollte auf zusätzliche Anforderungen an das Zielsystem geachtet werden. Tools mit extra Anforderungen sollten optional sein.
ZDT-2	Alternative Verwendung von Zusatzdiensten, welche z.B. in Fach-Quellen etabliert sind.
ZDT-3	Tools sollten entweder entsprechend der Dokumentation eingesetzt werden oder eine Abweichung für Fremde dokumentiert sein.
L-1	Es sollte für Open Source Software eine etablierte, gut dokumentierte Lizenz verwendet werden. Eine gute Übersicht findet man hier.

Ergänzende Hinweise zur Verbesserung der Zugänglichkeit

Interessieren sich Entwickler für eine neue Software, so kommen sie mit dieser i.d.R. nicht gleich in Kontakt. Stattdessen werden sie über Hilfe-Seiten und andere Dokumentationen mit den ersten Informationenen darüber versorgt. Bereits an dieser Stelle kann das Interesse durch gute Texte und aussagekräftige Illustrationen gestärkt werden. Unklare, missverständliche Texte schrecken Interessenten dagegen eher ab.

Ein gutes Beispiel für eine Dokumentation ist Twig, eine Template-Engine für PHP. Die Dokumentation stellt eine Übersicht bereit, aber auch detailliertes Fachwissen für Template-Designer und PHP-Entwickler.

Nach anfänglicher Einführung sollte der Entwickler zu einem Portal kommen, um die Software und deren Quellcode betrachten können. Hierzu bieten sich Plattformen wie Github, Bitbucket und Konsorten an. Sie bieten den interessierten Entwicklern die Möglichkeit neben einem Code-Browser, auch ein Wiki, eine Übersicht gemeldeter Probleme, aktuelle Entwicklungsfortschritte sowie Installations- und Konfigurationsanleitungen bereitzustellen. Die Bereitstellung einer integrierten Plattform sollte dem Betrieb unterschiedlicher System vorgezogen werden. Eine einheitliche Oberfläche und die Vermeidung mehrerer Benutzeraccounts können bei der Zugänglichkeit helfen.

Bei bestimmten Arten von Software (z.B. (evtl. auch in unterschiedliche Zielsysteme integrierte) Betriebssysteme) kann es sinnvoll sein, den Bereich zur Beantwortung von Fragen auszulagern. Anstatt Fragen von Endnutzern über Github zu beantworten (was grundsätzlich möglich wäre), bieten Plattformen, wie zum Beispiel Stack Overflow, neben einem sehr großen Nutzerkreis, auch Vorkehrungen, um qualitativ gute Antworten quasi nach oben zu spülen. Hier kann eigene Aufwand bei der Beantwortung von Fragen durch Volontäre verringert werden. Es gibt jedoch noch etwas Nachholbedarf beim Thema Barrierefreiheit.

Die folgende Abbildung soll mögliche Maßnahmen und System illustrieren, welche bei der Zugänglichkeit dienlich sein können.

Fazit

In diesem Beitrag ging es um die Frage, welche Hürden den Zugang zu einer Software erschweren können. Der Fokus lag dabei auf Entwicklern und Volontären, nicht den Endanwendern. Das Konzept der Barrierefreiheit wurde auf die Softwareentwicklung und Softwaremanagement übertragen. Es zeigt sich dabei, dass es bereits aufgrund z.B. schlechter Dokumentation oder zu restriktiver Lizenzwahl zur Abkehrung von potenziellen Entwicklern kommen kann. Daneben wurde auch beleuchtet, welche Aspekte die Beteiligung (z.B. Code-Beiträge, Korrektur von Fehlern in der Dokumentation) von Interessierten behindern oder gar verhindern kann.

Im Sinne der Barrierefreiheit geht es darum, jedem den Zugang zu ermöglichen. Dies lässt sich in der Praxis nicht immer realisieren, weil sich die Interessen von Entwicklern von Open Source Software und deren Nutzern (Fokus Entwickler) nicht immer decken müssen. Geht es jedoch um eine möglichst gute Zugänglichkeit, wird vorgeschlagen, bei der eigenen Softwareentwicklung alle oben genannten Aspekte zu bedenken. Fremd-Entwickler werden es einem danken.

Ansprechpartner

Konrad Abicht (Universität Leipzig)

barrierefreiheit, menschen mit behinderung, software, universal design