Einführung in die Entwicklung barrierefreier Software, Teil 2

Inhaltsverzeichnis

Software barrierefrei zu implementieren bedeutet nicht nur, sie für körperlich behinderte Nutzer bedienbar zu machen. Von ihnen genutzte Hilfsmittel wie Braillezeilen zur Steuerung des Computers beziehungsweise zur alternativen Ausgabe von Inhalten sind lediglich ein Aspekt, der bei der Planung und der Implementierung der Software zu beachten ist. Die Erörterung in einem früheren Artikel hat aufgezeigt, dass auch weitere Nutzergruppen wie Senioren oder Personen mit einer anderen Muttersprache von barrierefreier Software profitieren. Im Alltag ist eigentlich jeder schon einmal an eine Barriere bei der Programmnutzung gestoßen.

Die Sache mit den Standards

Dabei ist es oft weniger schwer, eine Anwendung barrierefrei zu gestalten, als oft angesichts der vielen verschiedenen Bedürfnisse angenommen. Eine gute Voraussetzung ist es, wenn sich Entwickler bei der technischen Realisierung an gängige Standards halten. Den Unterschied soll ein kleines Beispiel veranschaulichen.

Optisch wird mit beiden Implementierungen das gleiche Ergebnis erreicht, allerdings ist die erste Variante nicht barrierefrei, da sie HTML-Elemente nicht entsprechend dem Standard verwendet. Statt strukturierender Tags für Überschriften, Kopf- und Fußzeile kommen hier einfache div-Container zum Einsatz.

Ausschnitt der Definition der unstrukturierten Variante:

<div id="header">
    <div id="header-title">Werbekrake GmbH</div>
</div>

<div id="main">
    <div id="tabs">
        <div id="nav">
            <ul>
                <li class="ui-tabs-active">
                    <a href="#tab-info">Information</a></li>
                <li><a href="#tab-register">Registration</a></li>
        </ul>
        </div>
        <div id="tab-info">
            <div id="tab-title">Ihre Vorteile im Überblick</div>
            <p>Mit einer Registrierung bei uns profitieren Sie von allen
                Vorteilen.</p>
            <div id="article-list>
<div id="article">
                <p>Sie erhalten täglich bis zu 10 kostenfreie Mails mit
                    Informationen zu unseren Produkten.</p>
                <a href="#">Mehr erfahren</a>
            </div>
            <div id="article">
                <p>Unsere Mitarbeiter in der Firmenzentrale pflegen den
                persönlichen Kontakt durch regelmäßige Anrufe.</p>
                <a href="#">Mehr erfahren</a>
            </div>
            <div id="article">
                <p>Durch die Weitergabe Ihrer Daten zu unseren Partnern wird
                    Ihnen ein noch breiteres Produktangebot ermöglicht.</p>
                <a href="#">Mehr erfahren</a>
            </div>
        </div>

    </div>    
</div>

Ausschnitt der Definition der strukturierten Variante:

<header>
    <h1>Werbekrake GmbH</h1>
</header>

<main>
<div id="tabs">
    <nav>
        <ul>
            <li><a href="#tab-info">Information</a></li>
            <li><a href="#tab-register">Registration</a></li>
        </ul>
    </nav>

    <div id="tab-info">
        <h2>Ihre Vorteile im Überblick</h2>
        <p>Mit einer Registrierung bei uns profitieren Sie von allen
            Vorteilen.</p>
        <section id="info-list">
            <article>
                <p>Sie erhalten täglich bis zu 10 kostenfreie Mails mit
                    Informationen zu unseren Produkten.</p>
                <a href="#">Mehr erfahren</a>
            </article>
            <article>
                <p>Unsere Mitarbeiter in der Firmenzentrale pflegen den
                    persönlichen Kontakt durch regelmäßige Anrufe.</p>
                <a href="#">Mehr erfahren</a>
            </article>
            <article>
                <p>Durch die Weitergabe Ihrer Daten zu unseren Partnern wird
                    Ihnen ein noch breiteres Produktangebot ermöglicht.</p>
                <a href="#">Mehr erfahren</a>
            </article>
        </section>

    </div>
    </div>    
</main>

Das hat zur Folge, dass insbesondere für Screenreader und Bots wichtige Strukturinformationen verloren gehen, die für die Navigation und Orientierung beziehungsweise die Bewertung der Inhalte einer Suchmaschine wichtig sind. Vergleicht man die Aufbereitung, wie sie JAWS, ein verbreiteten Screenreader, umsetzt, wird der Unterschied schnell deutlich.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes Video (Kaltura Inc.) geladen.

Videos immer laden Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Kaltura Inc.) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes Video (Kaltura Inc.) geladen.

Videos immer laden Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Kaltura Inc.) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Auffällig ist, dass die strukturierte Version die einzelnen Bereiche des Dokuments ebenfalls wiedergibt – für die Orientierung auf einer Seite eine wichtige Unterstützung.

Besser getrennt als vereint

Wer meint, dass eine derartige Strukturierung eine Selbstverständlichkeit ist, irrt leider. Vor allem wenn Template- oder GUI-Designer zum Einsatz kommen, lassen die Ergebnisse diesbezüglich oft zu wünschen übrig und man kommt um eine händische Nachbearbeitung nicht herum. In diesem Fall kann der ARIA-Standard (Accessible Rich Internet Applications) helfen, die verloren gegangene Struktur wiederherzustellen. ARIA ist Teil des HTML5-Standards und definiert Rollen, Eigenschaften und Zustände der Elemente im DOM.

Schwierig wird es auch, wenn sich zusätzlich fest definierte Formatierungsanweisungen zwischen die Strukturierungselemente mischen. Eine Anpassung an individuelle Bedürfnisse ist dann nur noch schwer möglich. Glücklicherweise gilt die Trennung von Struktur und Layout unabhängig von der
Barrierefreiheit schon lange als Qualitätsmerkmal für Softwarearchitekturen. Nur auf diese Weise lassen sich einfach responsive Dialoge für unterschiedliche Endgeräte umsetzen oder die systemweiten Einstellungen eines Betriebssystems integrieren. Ändert sich hier beispielsweise die Schriftart, sollen sie auch alle Anwendungen nutzen.

Rot-Grün-Schwäche und CAPTCHAS

Rot ist nicht immer rot

Doch obwohl man die eigene Anwendung an das jeweilige Endgerät oder Betriebssystem anpassen kann, nehmen nicht immer alle Benutzer deren Oberflächen so wahr, wie sie entworfen wurden. Allein rund 9 Prozent aller Männer in Europa und Nordamerika sind von einer Form der Rot-Grün-Sehschwäche betroffen, die umgangssprachlich auch als Farbenblindheit bekannt ist. Welche Auswirkungen in der Wahrnehmung das bei einer Rot- beziehungsweise Grün-Sehschwäche haben kann, zeigt das nächste Beispiel.

Die individuellen Ausprägungen der Farbfehlsichtigkeit lassen sich nur schwer beim Dialogentwurf in den Griff bekommen. Oft ist man auch an ein gesetztes Corporate Design gebunden, dessen Farben in das problematische Spektrum fallen. Einfache Textblöcke mit Fehlermeldungen können darin schnell nicht mehr ausreichend auffallen oder sogar unkenntlich werden. Prinzipiell ist die Information so zu transportieren, dass Farben und Formen nicht die alleinigen Informationsträger sind. Eine Fehlermeldung lässt sich beispielsweise in einem modalen Dialog anzeigen, oder eine Verdunkelung des übrigen Arbeitsbereichs konzentriert die Aufmerksamkeit auf die Meldung.

Ein großes S oder doch eine 5 – das Leid mit den CAPTCHAs

Jeder, der im Internet eingekauft, sich irgendwo registriert oder etwas kommentiert hat, kennt diesen Sicherheitsmechanismus. Durch die Entzifferung verzerrter Buchstaben und Zahlen soll die Spreu vom Weizen getrennt, das heißt menschliche Benutzer von Bots unterschieden werden.

Abgesehen von der Kuriosität, dass Google als Anbieter des ReCaptcha-Systems auch einen Algorithmus entwickelt hat, der die CAPTCHAs zuverlässiger lösen kann als ein Mensch, sind die Bilderrätsel nicht nur ein Beispiel für fehlende Barrierefreiheit, sondern auch für schlechte Bedienbarkeit. So benötigen durchschnittliche Benutzer rund zehn Sekunden für die Lösung eines CAPTCHA-Bilds. Eine unglaubliche Bremse, wenn man den Aufwand bedenkt, der oft betrieben wird, um ein oder zwei Klicks im Arbeitsfluss einzusparen. Liegt beim Benutzer noch eine kognitive oder motorische Schwäche vor, kann die Verzögerung entsprechend größer werden. Blinde Benutzer sind dabei überhaupt nicht in der Lage, selbst die Bilder zu entziffern.

Mit Text- und Audio-CAPTCHAs wird zwar versucht, barrierefreie Varianten anzubieten, diese haben allerdings andere Nachteile:

• Text-CAPTCHAs basieren auf einfachen, textuellen Fragen, zum Beispiel "Was ergibt drei plus sieben?". Diese sind jedoch für jede Sprache, in der die Anwendung oder Webseite angeboten wird, zu pflegen.
• Audio-CAPTCHAs geben die dargestellte Zeichenfolge akustisch wieder, wegen der fortschrittlichen Spracherkennung erfolgt das jedoch mit entsprechenden Störgeräuschen, was mitunter zu unverständlichen Ergebnissen führt. Hinzu kommt wieder eine Sprachabhängigkeit (beispielsweise hört sich ein Englisches "e" wie ein Deutsches "i" an).
  

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes Video (Kaltura Inc.) geladen.

Videos immer laden Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Kaltura Inc.) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Dabei gibt es subtilere Mechanismen, die ebenso effizient Bots erkennen können wie CAPTCHA-Bildrätsel. Sie sind dabei aber barrierefrei, da sie keinerlei Benutzerinteraktion erfordern. Bekannte Beispiele hierfür sind Honeypot-Felder in Formularen, die für richtige Benutzer unsichtbar sind, die Messung der Interaktionsdauer oder auch die klassischen Inhaltsfilter. Optimal wirkt eine Kombination der Maßnahmen.

Kosten

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.

Styleguide

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.

Beispiel

Beispielimplementierung einer Bibliothek

Im folgenden Beispiel wird der prinzipielle Mechanismus der Bibliothek anhand einer Implementierung mit GWT (Google Web Toolkit) gezeigt. Sie besteht aus einer Anzahl Klassen zur Instanziierung verschiedener Grafiken und Dialoge, die je nach Verwendung unterschiedlich konfiguriert werden. Bei den mit der Bibliothek eingebundenen Bildern liegt eine Besonderheit bei den Alternativtexten, die für Screenreader eine hohe Bedeutung haben. Wenn das entsprechende Attribut fehlt, wird in der Regel der Pfad beziehungsweise die URL des Bildes vorgelesen. Insbesondere für Bilder, die keinen inhaltlichen Mehrwert besitzen, lässt sich hier aber auch meistens kein sinnvoller Text finden. Deswegen besteht die Konvention, ein leeres Attribut für das Bild zu setzen. Damit ignoriert der Screenreader das Bild einfach. Das ist im Beispiel für eine Platzhaltergrafik umgesetzt.

Ausschnitt der Klasse für ein Warnsymbol:

public class WarnImage extends AbstractImage {

    /** Übersetzungsdefinitionen. */
    private static final AccessibleLibraryConstants CONSTANTS =
            GWT.create(AccessibleLibraryConstants.class);

    /** Standardklasse zur css Formatierung. */
    private static final String DEFAULT_STYLE = "image-warn";

    /**
     * Constructor
     */
    public WarnImage() {
        super(LibraryImages.WARNING, CONSTANTS.imageWarn(), DEFAULT_STYLE);
    }

}

Analog zeigt sich das Vorgehen beispielhaft hier für einen modalen Fehlerdialog und einen Dialog mit Einstellungsoptionen. GWT erzeugt bei seinen Widgets in erster Linie div-Container, weshalb es notwendig ist, mithilfe von ARIA den Dialogen ihre Strukturinformation zurückzugeben. Das wird im jeweiligen Constructor realisiert. Zusätzlich steuert man mit einer ARIA-Eigenschaft die Sichtbarkeit. Weitere Informationen zu ARIA finden sich auf der Seite des W3C.

Basisklasse für Warnmeldung der Bibliothek:

public abstract class AbstractWarningDialog extends AbstractDialog {

    protected AbstractWarningDialog(String text) {
        super(true, false, CONSTANTS.dialogTitle(), DEFAULT_STYLE);

        // Konfiguration der ARIA-Rolle als "alertdialog", initial bleibt der 
        // Dialog für Screenreader versteckt
        Roles.getAlertdialogRole().set(getElement());
        Roles.getAlertdialogRole().setAriaLabelProperty(getElement(), 
                   CONSTANTS.dialogTitle());
        Roles.getAlertdialogRole().setAriaDescribedbyProperty(getElement(), 
                   getDescriptionReference());
        Roles.getAlertdialogRole().setAriaHiddenState(getElement(), true);

        this.text = text;

    }

    @Override
    protected void createContent(Panel content, Panel wrapper) {

        // Konfiguration der Schaltfläche zur Bestätigung, beim Klicken wird 
        // der Dialog auch für Screenreader ausgeblendet
        closeButton.setText(CONSTANTS.dialogSubmit());
        registerInput(closeButton, true);
        closeButton.addClickHandler(new ClickHandler() {

            @Override
            public void onClick(ClickEvent event) {
                hide();
                Roles.getAlertdialogRole().setAriaHiddenState(getElement(),
                     true);
            }
        });

        // Hinzufügen der Elemente im Hauptbereich des Dialogs
        Panel wrapperwrapper = new FlowPanel();
        
        wrapperwrapper.add(new WarnImage());
        wrapperwrapper.add(wrapper);
        content.add(wrapperwrapper);
        content.add(closeButton);

    }

    @Override
    protected void createWrapper(Panel wrapper) {

        // Der Wrapper besteht bei diesem Dialogtyp lediglich aus der 
        // Warnmeldung
        demoMessage.setText(text);
        wrapper.add(demoMessage);

    }

    @Override
    public void show() {

        // Der Dialog wird für Screenreader sichtbar gemacht und der Fokus auf 
        // das zuvor definierte Element gesetzt
        super.show();
        center();
        Roles.getAlertdialogRole().setAriaHiddenState(getElement(), false);
        setInitialFocus();

    }

}

Ausschnitt der Implementierung einer Warnmeldung innerhalb einer Anwendung:

public class DemoApplication implements EntryPoint {

    /** Schaltfläche für das Anzeigen des Warndialogs. */
    private final Button modalButton = new Button();

    /** Warndialog. */
    private final DemoWarning warningDialog = new DemoWarning();

    @Override
    public void onModuleLoad() {

        ...

        // Konfiguration der Schaltfläche für die Anzeige des Warndialogs
        modalButton.setText(CONSTANTS.mainButtonModal());
        modalButton.addClickHandler(new ClickHandler() {

            @Override
            public void onClick(ClickEvent event) {
                warningDialog.show();
            }
        });

        ...

    }

}

Fazit

Die zu Beginn gezeigten Beispiele beleuchten nur Teilaspekte der Barrierefreiheit. Dennoch lässt sich erahnen, dass die Komplexität dieser Anforderung in einer realen Anwendung ungleich größer werden kann. Vermutlich ist das auch der Grund dafür, dass Barrierefreiheit oft noch stiefmütterlich während des Entwicklungsprozesses gesehen wird: Neben der angesprochenen Komplexität kommt die Unwissenheit über den konkreten Mehrwert für unterschiedliche Benutzergruppen und die Unklarheit hinzu, was genau und wie das zu implementieren ist. In Summe bleibt so ein eher unattraktives Anforderungspaket, das durch die falsche Herangehensweise unnötig viel Aufwand verursachen kann.

Im Kern ist die Barrierefreiheit früh im Entwicklungsprozess zu berücksichtigen. Drei Dinge lassen sich festhalten, die in besonderer Weise dabei zu beachten sind:

• Es ist bereits früh ein fachlicher Analysebeitrag notwendig, der wesentliche Punkte wie mögliche rechtliche Pflichten, Zielgruppen und Grad der umzusetzenden Barrierefreiheit im Kontext der übrigen Rahmenbedingungen klärt und definiert. Anschließend lassen sich hierauf die grundlegende Dialogstruktur und darauf aufbauende Entwürfe entwickeln. Als Gesamtes stellen die fachlichen Analyseergebnisse die Basis für die Anwendungsarchitektur dar.
• Barrierefreiheit ist als nichtfunktionale Anforderung zu behandeln. Die Konsequenz hieraus ist eine entsprechend frühe Berücksichtigung innerhalb der Anwendungsarchitektur insbesondere im Bereich der Dialoge, um beispielsweise Tastaturbedienbarkeit oder die Anreicherung der Dialogobjekte um Zusatzinformationen möglichst generisch realisieren zu können. Im vorhergehenden Abschnitt wurde exemplarisch gezeigt, wie das in Form einer Bibliothek unterstützt werden kann. Das Einhalten dieser Architektur und Nutzung der vorgesehenen Hilfsbibliotheken ist entsprechend zu dokumentieren und muss in die Programmiervorgaben für Entwickler einfließen.
• Sofern die Frage der zu nutzenden Techniken nicht ohnehin aufgrund anderer Rahmenbedingungen geklärt ist, ist deren Wahl auch aus Perspektive der Barrierefreiheit zu treffen. Ziel sollte es sein, die Techniken zu wählen, die die technischen Anforderungen der Barrierefreiheit unterstützen. Ist das nicht möglich, lässt sich der entstehende Mehraufwand zumindest frühzeitig in Kosten- und Zeitplanung berücksichtigen.
  

Diese Vorgehensweise stellt sicher, dass sich der Aufwand für die Aspekte der Barrierefreiheit in einem kalkulierbaren Rahmen bewegt. Bei näherer Betrachtung stellt das allerdings keine große Überraschung dar, handelt es sich doch in wesentlichen Teilen um ein bekanntes Vorgehen. Die entscheidende Erkenntnis ist hingegen, dass Barrierefreiheit wie jede andere Anforderung im Entwicklungsprozess zu behandeln ist.

Pierre Heim
arbeitet bei der T-Systems International GmbH als System Engineer. Neben seiner Tätigkeit in der Softwareentwicklung und Systemadministration berät er intern Softwareprojekte bei der technischen Realisierung von Barrierefreiheit.

• Vollständiges Beispiel der Demonstration von HTML-Strukturierung
• Vollständiges Beispiel der GWT-Demonstration einer Bibliothek mit Anwendung

(ane)