Einführung in barrierefreie Software

Realität

Konkrete Abhilfe schaffen

Eine Darstellung der einzelnen Aspekte, die die WCAG von einer barrierefreien Anwendung fordert, würde den Rahmen dieses Artikels sprengen. Daher sollen nur einige daraus abgeleitete Kernaussagen exemplarisch mit ihrer Wirkung vorgestellt werden:

Eine Anforderung, die eigentlich eine Selbstverständlichkeit sein sollte, ist die Einhaltung von Standards. Ungültiges und nicht valides HTML sind hier die eine Seite des Problems, die zweite ergibt sich durch den falschen semantischen Einsatz der Strukturierungselemente wie der Definition von Überschriften durch einfache Formatierung von Text oder Textfragmente mit Klick-Handler, die als Link-Ersatz fungieren. Das führt nicht nur dazu, dass Screenreader falsche Information zur Aufbereitung einer Webseite erhalten oder ein Suchmaschinen-Crawler eine schlechtere Gewichtung der Inhalte vornimmt. Standards sind auch der erste Schritt für Plattformunabhängigkeit, da sie einen gemeinsamen Nenner von Geräten oder Softwarekomponenten definieren.

Sind des Weiteren Layout und Inhalt vermischt, verhindern sie oft eine individuelle Anpassung des Layouts durch geänderte Schriftgrößen, Kontraste oder in einigen Fällen sogar durch unterschiedliche Fenstergrößen. Die Folge sind abgeschnittene Texte oder zerrissene Dialoge, deren Inhalte so nur noch bedingt nutzbar sind. Auf diese Anpassungen sind jedoch besonders Personen mit einer Sehschwäche jeglicher Form angewiesen.

Blinde Nutzer haben ferner das Problem, dass Grafiken oder Farben für sie keine Informationen transportieren können, wie es oft zur Markierung von Fehleingaben gemacht wird. Links mit Grafiken auf Webseiten sind unter Umständen für sie gar nicht existent, da sich unbeschriftete Bilder durch den Screenreader filtern lassen. Zusätzliche Möglichkeiten wie Alternativtexte oder textuelle Beschreibungen schaffen hier Abhilfe. Ein Problem, dem sich auch ein Crawler stellen muss. Bereiche einer Webseite, die nur über einen Grafik-Link ohne Alternativtext erreichbar sind, werden so bei der Indizierung schlechter gewichtet, was wiederum einen Einfluss auf die Suchergebnisse bei entsprechenden Suchbegriffen hat.

Es ist außerdem wichtig, an jeder Stelle der Anwendung sofort zu erkennen, wo man sich als Nutzer befindet, wie man zu einer anderen Stelle kommt und wie das geschehen kann (z. B. durch bestimmte Tasten oder Navigationssymbole). Ebenso müssen die Dialoge so strukturiert und gestaltet sein, dass sie konsistent sind und das Wesentliche in den Mittelpunkt stellen und nicht mit nebensächlichen Informationen ablenken. Ein Vorteil, der allen Nutzergruppen nützt.

Schließlich macht ein Verzicht auf unnötig lange Satzkonstrukte oder Fachbegriffe Anwendungen im Allgemeinen verständlicher. Davon profitieren besonders ältere Nutzer und Personen, für die die genutzte Anwendungssprache eine Fremdsprache ist.

Alter Wein in neuen Schläuchen

Es fällt auf, dass viele der gezeigten Aspekte nicht nur eine Erleichterung für eine einzelne Nutzergruppe bringen – in weiteres Indiz dafür, dass barrierefreie Software nicht nur für behinderte Personen wichtig ist.

Auf den zweiten Blick wird aber noch ein weiterer Punkt deutlich. Viele der aufgezeigten Aspekte sind bekannte Anforderungen aus der Softwareentwicklung. Entweder gelten sie, wie die Trennung von Layout und Inhalt, als Merkmal für eine saubere Anwendungsarchitektur oder sie sind Anforderungen, die bei der Berücksichtigung allgemeiner Usability-Grundsätze ohnehin gestellt werden. Zu diesen gehören unter anderem ein logischer Seitenaufbau mit einer intuitiven Navigation. Etablierte Techniken wie das responsive Design oder Frameworks beziehungsweise CMS liefern Ansätze für die gängigsten Problemstellungen plattformübergreifend genutzter Angebote.

Barrierefreiheit zwischen Kosten und Sinnhaftigkeit

Eine Optimierung der Software auf die Aspekte der Barrierefreiheit ist in jedem Fall wünschenswert. Es gibt aber auch Argumente, die gegen eine umfängliche Umsetzung der Barrierefreiheit sprechen. Dies sind vor allem:

  • Weiterentwicklung von Altsystemen: Hier kann es vorkommen, dass die bestehende Anwendungsarchitektur es nur eingeschränkt zulässt, die verschiedenen Aspekte der Barrierefreiheit umzusetzen. Die Anpassung unflexibler Masken eines CMS oder das Nachprogrammieren fehlender Funktionen für die eingesetzte Technik ist zwar prinzipiell möglich, kann aber schnell das Budget sprengen. Sofern hier nicht gesetzliche Regelungen eine umfassende Umsetzung fordern, kann hier aber auf einen niedrigeren Umsetzungsgrad der WCAG zurückgegriffen werden, beispielsweise Level A.
  • Klar abgegrenzte Zielgruppe: Hier stellt sich die Frage, ob Aspekte umgesetzt werden sollen, wenn bereits klar ist, dass die jeweilige Software nur von einem bekannten Kreis von Nutzern eingesetzt wird. Ein typisches Beispiel sind hier in Unternehmen intern genutzte Webanwendungen. In der Regel gibt es in größeren Unternehmen und Konzernen einen Standard-Browser mit einem Standard-Betriebssystem, hier ergibt es keinen Sinn, eine plattformunabhängige Software zu implementieren. Das liegt auf der Hand. Vor der Einsparung anderer Aspekte ist der Nutzerkreis jedoch genau zu analysieren.

Die Konzentration auf bestimmte Aspekte der Barrierefreiheit beziehungsweise deren Erfüllungsgrad im Rahmen der WCAG ermöglicht eine Reduzierung der oft kritisierten Implementierungskosten. Diese Kritik ist zunächst legitim, zumal ein allgemeiner Kostendruck die Anbieter zu Einsparungen zwingt und einige Aspekte der Barrierefreiheit wie gezeigt als Investition nicht immer rentabel und sinnvoll erscheinen.

Dabei darf allerdings nicht der Fehler begangen werden, die barrierefreie Realisierung einer Anwendung oder Webseite als binäre Entscheidung zu betrachten und diese grundsätzlich in Frage zu stellen. Vielmehr kann die Umsetzung wie aufgezeigt in unterschiedlichen Abstufungen und Ausprägungen geschehen. Man spricht in diesem Zusammenhang auch von einer "barrierearmen" Anwendung. Wie die Abstufungen konkret aussehen, lässt sich aber nur schwer verallgemeinern, da sich das Umfeld der Software jeweils sehr individuell gestaltet. Grundsätzlich gilt zwar das Motto "alles ist besser als nichts", in Hinblick auf die Nutzer sollte aber immer das maximal Mögliche angestrebt werden. Hier kann auch eine schrittweise Verbesserung der Barrierefreiheit über mehrere Releases ein gangbarer Weg sein.