Seite 4: Styleguide

Inhaltsverzeichnis

Hausaufgaben für alle Beteiligten

Wer sich anschaut, welche Disziplinen typischerweise hier beteiligt sind, dem wird deutlich, dass Barrierefreiheit nicht ausschließlich ein technisches Thema ist. Einen wesentlichen Beitrag zu einer guten Realisierung ist bereits bei der fachlichen Analyse und Konzeption zu leisten. Hier sind vor allem die wichtigen Fragen nach Zielgruppe beziehungsweise Benutzerkreis, rechtlichen Aspekten und dem daraus resultierenden Grad der umzusetzenden Barrierefreiheit zu beantworten. Das schlägt sich unmittelbar in den entstehenden Spezifikationen als konkrete Anforderung nieder, beispielsweise in einem generellen Styleguide und darauf aufbauenden, spezifischen Dialogentwürfen. Dialogaufbau und Benutzerführung, Farbwahl und Symbolik oder auch Mehrsprachigkeit sind Beispiele für Aspekte, die in dieser Phase der Entwicklung bereits Konturen angenommen haben und damit mit den fachlichen Anforderungen die Basis für den Architekturentwurf bilden.

Bei ihm gilt es allerdings nicht nur, die zuvor spezifizierten Anforderungen in eine sinnvolle Architektur zu überführen, sondern weitere elementare Aspekte der Barrierefreiheit zu manifestieren. Diese sind jedoch weniger offensichtlich, da sie in erster Linie die technische Voraussetzung für beispielsweise Bots, Sprachausgaben und andere Bedienungs- beziehungsweise Darstellungshilfen bilden. Insbesondere das Trennen von Layout und Inhalt, saubere Dokumentenstrukturen und das Einhalten der genutzten Standards bilden eine wichtige Grundlage für die Barrierefreiheit. Des Weiteren ist zu klären, mit welchen Technologien oder Bibliotheken die Anwendung realisiert werden soll. Da die Unterstützung benötigter Funktionen wie ARIA oder das Erstellen eigener Erweiterungen für diese Funktionen nicht immer gleich gut vorhanden ist, bedeutet die Wahl für eine bestimmte Lösung eventuell einen Mehraufwand, der entsprechend einzukalkulieren ist.

Dokumentation und Richtlinien für die einheitliche Umsetzung

Sind die wichtigen Architekturentscheidungen einmal getroffen, müssen sie Teil der Dokumentation und der Implementierungsrichtlinien werden. Das stellt sicher, dass in der Anwendung die Aspekte der Barrierefreiheit in der notwendigen Vollständigkeit umgesetzt werden. Im Kern ist das nichts Neues, wendet man hier ja lediglich etablierte Techniken der Architekturdokumentation an. Entscheidend ist hier jedoch, dass die umzusetzenden Aspekte der Barrierefreiheit bereits als nichtfunktionale Anforderung ihre Spuren hinterlassen.

Prototypen können darüber hinaus helfen, eine konkrete Implementierung für beispielsweise eine generische Abfolge oder weitere Dialogverhalten zu veranschaulichen und weiterzuentwickeln.

Abkürzungen für Entwickler

Die Praxis hat gezeigt, dass es sinnvoll ist, hier sogar einen Schritt weiter zu gehen. In größeren Projekten oder Anwendungsverbünden ist meistens ohnehin eine Art Bibliothek mit nützlichen Hilfsfunktionen oder eigenen Komponenten vorhanden. Diese gilt es so zu erweitern, dass sich alle unmittelbar für die Dialoge relevanten Aspekte darüber generisch nutzen lassen. Das ist deutlich weniger Aufwand und Wildwuchs als durch die Entwicklung durch Einzelkämpfer.

Implementierungsdetails, beispielsweise zu zusätzlich bereitgestellten Informationen der Steuerelemente, müssen nur denjenigen bekannt sein, die die Bibliothek pflegen. Lediglich wie eine Bibliothek angewendet wird, ist bekannt zu machen.

Gleichartige Probleme werden gleichermaßen gelöst, dadurch lassen sich grundlegende Änderungen zentral vornehmen – und die Architektur zeigt ein einheitliches Bild. Über Analysewerkzeuge lässt sich außerdem sicherstellen, dass die Bibliothekskomponenten tatsächlich genutzt werden beziehungsweise die Nutzung nativer Aufrufe untersagt bleibt. Für Benutzer bietet das gleichzeitig den Effekt, dass sich die Anwendung bezüglich Aufbau und Verhalten überall konsistent verhält.