Seite 3: Kosten

Inhaltsverzeichnis

Alles für jeden oder doch nur ein bisschen für einzelne?

Die aufgeführten Beispiele bieten zwar nur einen Einblick in einzelne Teilaspekte, trotzdem lässt sich bereits der Aufwand erahnen, den Barrierefreiheit als Anforderung in Softwareprojekten mit sich bringen kann. Daraus ergibt sich wiederum die Herausforderung, den Spagat zwischen der Umsetzung dieser Anforderung und einer kosteneffizienten Entwicklung zu schaffen. Mit anderen Worten: Was kostet Barrierefreiheit?

Die Berücksichtigung aller Aspekte der Barrierefreiheit als Anforderung ist zwar begrüßenswert, der frühere Artikel beschrieb jedoch, dass das nicht unbedingt immer ein sinnvoller Weg sein muss, und zeigte Alternativen auf. Beispielsweise ist in einem klar abgrenzbaren Einsatzgebiet Plattformunabhängigkeit nicht als Anforderung zu berücksichtigen. Eine zweite Möglichkeit zur Reduzierung der konkreten Anforderungen bieten die WCAG (Web Content Accessibility Guidelines) mit den sogenannten "Levels", einem Umsetzungsgrad in drei Stufen. Welche Variante zur Konkretisierung der Anforderungen zum Einsatz kommt, ist jedoch immer im Einzelfall zu entscheiden.

Kostenfresser lauern bei der Umsetzung

Es ist jedoch nicht damit getan, die Aspekte der Barrierefreiheit beispielsweise auf WCAG-Level A abgespeckt als Anforderungen zu definieren, damit der Gesamtaufwand minimiert wird. Vielmehr lauern gerade in der Detailplanung und Realisierung Probleme, die sich langfristig als Kostenfresser entpuppen können – vorausgesetzt, man strebt ein für den Benutzer qualitativ gutes Ergebnis an. Die Ursache der erhöhten Kosten kann dabei unterschiedlich sein:

• Liegt ein falsches Verständnis der Arbeitsweisen oder konkreten Bedürfnisse einzelner Benutzergruppen vor, führt das in der Regel zu einem für den einzelnen Benutzer zumindest teilweise unbrauchbaren Ergebnis, sofern sie überhaupt berücksichtigt wurden. Beispielsweise reicht es nicht aus, dass sich Dialogelemente mit der Tastatur erreichen lassen, wenn die Tab-Reihenfolge auch unsichtbare Elemente umfasst und es so zu einem unnötigen Tab-Marathon kommt.
• Barrrierefreiheit lässt sich zwar mit vielen Verfahren erreichen, allerdings haben sie unterschiedliche Stärken und Schwächen. Je nach Programmiersprache und gewähltem Framework sind für die Barrierefreiheit selbst grundsätzliche Funktionen nachzubauen, wenn es hierfür keine Unterstützung direkt oder durch Erweiterungen gibt. So ist es aktuell schwierig, für JSF (JavaServer Faces) eine Komponentenbibliothek zu finden, die ARIA als Teil des HTML5-Standards unterstützt. ARIA ist jedoch für blinde Benutzer eine Notwendigkeit, wenn es gilt, eine AJAX-basierte Anwendung zu nutzen.
• Für viele Benutzer stellt die Barrierefreiheit eine der wichtigsten Eigenschaften einer Anwendung dar. Hebt man sich diese Anforderung jedoch bei der Implementierung bis zum Ende auf, kann das tiefgreifende Änderungen der Architektur vor allem im Dialogbereich mit sich bringen. Das zu Beginn gezeigte Beispiel demonstriert, zu welchen Unterschieden bereits die Wahl unterschiedlicher HTML-Tags führt. Grundsätzliche Lösungen, die bis in die Persistenzschicht durchschlagen können, werden auch von alternativen Medienarten wie Infotext, Gebärdenübersetzung et cetera benötigt.
• Ein eher allgemeines Problem ist das Fehlen konkreter Lösungsvorgaben. Unterschiedliche Programmierer implementieren dieselbe Anforderung unterschiedlich, was sich im Ergebnis und in der Qualität niederschlägt. Bei nachträglichen Änderungen, zum Beispiel bei der Verbesserung des Layouts, ist an vielen Stellen mehr nachzuarbeiten als bei einer zentralen Umsetzung zu kontrollieren. Für die Barrierefreiheit hat das jedoch noch einmal einen anderen Stellenwert, da oft mit den entstehenden Kosten gegen diese Anforderung argumentiert wird.

Berücksichtigung als nichtfunktionale Anforderung

Die beschriebenen Schwierigkeiten gilt es, unter dem Aspekt der allgemeinen Softwarequalität zu vermeiden. Das wird aber nur dann möglich sein, wenn die Barrierefreiheit als gleichwertig zu anderen nichtfunktionalen Anforderungen wahrgenommen wird. Diesen Anspruch unterstreicht auch die Tatsache, dass Barrierefreiheit beziehungsweise die Vermeidung der aufgeführten Schwierigkeiten unmittelbar auf klassische nichtfunktionale Anforderungen wie Wartbarkeit, Bedienbarkeit oder Erlernbarkeit einzahlt.

Dies bedeutet in der Konsequenz die Notwendigkeit einer frühzeitigen Berücksichtigung in der Softwarearchitektur und damit auch im Entwicklungsprozess.