Wir wollen uns möglichst viel Arbeit durch die hervorragende WPF-Datenbindung abnehmen lassen. Dazu verwenden wir das MVVM-Pattern und beginnen mit dem ViewModel, an das wir die UI binden können. Da wir später möglichst wenig Code zur Bindung der UI an unseren Bindungshelfer schreiben möchten, liegt es nahe, diesen in ein Basis ViewModel so zu integrieren, dass wir leichten Zugriff darauf erhalten.

Die ViewModel-Basisklasse

Wir definieren also zunächst unser Grundgerüst für die Basisklasse aller späteren ViewModels: ViewModelBase.

public abstract class ViewModelBase : ObservableObject {

    // CTORS
    protected ViewModelBase() {}

    // PROPERTIES
    private static Translator _translator;
    public static Translator Translator
    {
        get { return _translator; }
        set {
            if (_translator == null)
                _translator = value;
            else
                throw new InvalidOperationException("Translator already initialized;");
        }
    }
    public Translator T9
    {
        get { return Translator; }
    }

}

Mehrere Stellen bedürfen einer Erläuterung:

Da es sich um eine Basisklasse handelt, von der konkrete ViewModels abgeleitet werden sollen, ist die ViewModelBase als abstract definiert und kann über einen geschützten Konstruktor instantiiert werden. Die ViewModelBase stellt den Bindungshelfer als statische Eigenschaft Translator bereit (diese Klasse implementieren wir später). Statisch ist diese Eigenschaft, da anwendungs-weit nur eine Instanz benötigt wird und möglichst zentral darauf zugegriffen werden soll. Der Setter dieser Eigenschaft erlaubt die einmalige Instanziierung der Translator-Klasse gemäß dem Singleton-Pattern.

Um die Bindung an das konkrete ViewModel zu erleichtern, kommt außerdem ein pseudo-instanzspezifischer Alias T9 zum Einsatz, der auf die klassen-spezifische Eigenschaft Translator verweist. Über diesen steuern wir die Bindung der Übersetzungen und Artefakte an unsere Steuerelemente.

Weiterhin erbt die ViewModelBase von ObservableObject, welches den Kontrakt von INotifyPropertyChanged mit Hilfe einer zentralen Funktion SetPropertyValue() kapselt. Diese erleichtert die Zuweisung von Werten an die VM, welche bei etwaigen Änderungen gleichzeitig die UI via Publish-Subscribe-Pattern benachrichtigt.

public abstract class ObservableObject : INotifyPropertyChanged
{
	// CTORS
	protected ObservableObject() {}

	// EVENTS
	public event PropertyChangedEventHandler PropertyChanged;

	// PRIVATE FIELDS
	protected virtual void OnPropertyChanged(string propertyName) {
		// wird Event überwacht?
		var handler = PropertyChanged;
		if (handler != null)
			handler(this, new PropertyChangedEventArgs(propertyName));
	}
	internal protected void SetPropertyValue(string propertyName, ref T propertyReference, T value) {
		// Wert verändert?
		if (Equals(propertyReference, value))
		return;

		// setzen und benachrichtigen
		propertyReference = value;
		OnPropertyChanged(propertyName);
	}
}

Das ViewModel-Grundgerüst ist damit fertig und wir kommen zum zentralen Teil: Dem Bindungshelfer, genannt: Translator.

Die Translator-Klasse: Rüstzeug

Unser Bindungshelfer gewinnt gewiss keinen Preis in der Kategorie “innovative Produktnamen”. Das heißt jedoch nicht, dass es sich um eine triviale Klasse handelt. Im Gegenteil: Wir beginnen mit den zentralen Merkmalen und Anforderungen, die wir sodann in Code umsetzen.

Unsere Translator-Klasse ist der zentrale ad-hoc Übersetzer und hat als solcher folgende Aufgaben zu erfüllen:

1. Erlaube die Angabe einer (aktuellen) Zielkultur, welche vorgibt, in welche Sprache und kulturellen Parameter die UI übersetzt werden soll.
2. Erlaube das Anlegen und Registrieren von mehreren verfügbaren Zielkulturen, zwischen denen gewechselt werden kann.
3. Erlaube das Anlegen und Registrieren von kulturspezifischen Artefakten (Text, Grafik, URIs) in Form von Schlüssel-Wert-Paaren.
4. Erlaube das direkte Umschalten zwischen den verfügbaren Zielkulturen (auch via Datenbindung); so dass die UI in Echtzeit (d.h. ohne Neustart der Anwendung) übersetzt wird.
5. Erlaube die Verwendung eines Debug-Modus, welcher fehlerhafte Bindungen noch zur Entwurfszeit sichtbar macht.
6. Erlaube es dem Programm, auf die nächstmögliche Kultur und Sprache zurückzuspringen, falls eine gewünschte Zielkultur nicht existiert (Defaulting).
7. Erlaube das Einlesen von Artefakten über externe (XML-) Dateien.
8. Erlaube möglichst einfaches Binden der Steuerlemente bereits zur Entwurfszeit an die Artefakte.

Ich werde die Translator-Klasse im kommenden dritten Teil dieses Artikels mit Hilfe dieser Vorgaben mit Leben füllen.

Viele Großprojekte für Wirtschaft und Industrie werden von Beginn an mit dem Anspruch entwickelt, sie eines Tages exportieren zu können. Für die Entwicklung stellen sich hierdurch nicht unerhebliche Herausforderungen, da die Prozesse der Globalisierung und Lokalisierung, oft in enger Zusammenarbeit mit Designern und Fachübersetzern, geplant und koordiniert werden müssen.

Dabei sind die Anforderungen desto komplexer, je Kultur-unabhängiger eine Anwendung geplant werden soll. Bevor wir uns ans Werk machen, gilt es die Grundbegriffe näher zu bestimmen:

• Unter Globalisierung versteht man allgemein, eine Anwendung so zu entwickeln vorzubereiten, dass sie möglichst über keinerlei Sprach- und Kulturabhängigkeiten verfügt. Die Globalisierung einer Anwendung befähigt diese, in andere Sprachen und Kulturen übersetzt zu werden. Sie ist, so gesehen, der notwendige Schritt hin zum Übersetzen einer Anwendung. Startpunkt für eine Globalisierung ist die Ausgangskultur. Ihr Ziel ist ein kulturagnostisches Anwendungsgerüst.
• Die Lokalisierung knüpft nahtlos an die Globalisierung an und meint das Übersetzen einer (globalisierten, kulturagnostischen) Anwendung in eine spezifische Sprache und Kultur (Zielkultur).

Globalisierung und Lokalisierung

In einem gewissen Sinn stehen sich Globalisierung und Lokalisierung gegenüber und sind doch integrative Bestandteile eines Ganzen. Beide Prozesse sind komplementär, d.h. sie erfolgen stets gemeinsam und sind aneinander gebunden. Dies lässt sich leicht erkennen, da es einerseits keine kulturagnostische (d.h. globalisierte, aber nicht lokalisierte) Anwendung geben kann, andererseits eine lokalisierte Anwendung immer die Überführung dieser aus einer Ausgangskultur bedingt.

Globalisierung und Lokalisierung schließen Tätigkeiten wie das Entwickeln kultur-unabhängiger Datentypen und kultur-spezifischer Datenhaltung wie auch das Übersetzen von Artefakten (Text, Grafik, Multimedia) ein. Zwar handelt sich es nach wie vor um kostenintensive Arbeiten, jedoch erleichtert das .NET Framework diese enorm — insbesondere WPF mit seiner hervorragenden Fähigkeit zur Datenbindung (Dependency Properties).

Ich möchte im Folgenden eine Möglichkeit aufzeigen, einen effizienten “Übersetzer” in Form eines Bindungshelfers zu schreiben, der die Eigenschaften der WPF-Datenbindungsmittel geschickt auszunutzen weiß. Es handelt sich hierbei um einen frühen Prototypen, der gewiss nur den Anfang eines solchen Unternehmens markiert und in keiner Weise den Anspruch der Vollständigkeit erhebt.

Anforderungen an den Bindungshelfer

Stellen wir uns vor, eine mittelgroße deutsche Anwendung soll möglichst effizient für die Globalisierung und Lokalisierung vorbereitet werden:

1. Der Einfachheit halber wollen wir uns auf europäische Zielkulturen beschränken (z.B. germanische und romanische Sprachen).
2. Wir möchten die Artefakte (Texte, Grafiken und URIs) innerhalb von Visual Studio an die Ziel-Steuerelemente binden können, und das möglichst ohne umständlichen Schreibaufwand. Auch sollen die Entwickler bei Ihrer Arbeit nicht gestört werden, so dass sich die Artefakt-Anbindung nahtlos in den Code integrieren lassen muss.
3. Dabei sollen die Artefakte unabhängig durch Dritte (Übersetzer) bearbeitet und in die Anwendung injiziert werden können, wobei bereits beim Debuggen des Quelltexts Bindungsfehler erkannt werden sollen.
4. Zu guter Letzt soll es dem Anwender möglich sein, die Benutzeroberfläche per einfachem Klick und ohne Neustart der Anwendung zu “übersetzen”.

Vorüberlegungen zu einer möglichen Implementierung

Da wir uns auf i.w.S. europäische Kulturen, insbesondere romanische und germanische Sprachen, beschränken wollen (Anforderung 1), können wir das zwar spannende aber anspruchsvolle Problem der Linksläufigkeit von Sprachen (z.B. im Arabischen) außer Acht lassen. (Kurz notiert: Mit dieser Aussage stecken wir bereits in unserer eingeschränkten, westlichen Sichtweise fest [für eben jene Araber sind linksläufige Sprachen mitnichten ein Problem, wohl aber Textverarbeitungsprogramme westlicher Entwickler]. Wir geben also den Anspruch an eine echte Globalisierung zum Wohle der didaktischen Simplifizierung auf.)

Das Bindungsverhalten wird durch WPF vorgegeben und eignet sich mit seinen Observer und Publish–Subscribe Patterns  hervorragend für die Implementierung eines Übersetzungshelfers, der ad hoc zwischen den Zielsprachen wechseln kann (Anforderungen 2 und 4). Die zentrale Steuerung erfolgt hier über die INotifyPropertyChanged Implementierung des ViewModels, das im Falle eines Umschaltens zwischen den Sprachen die Neubindung der Artefakte an die UI veranlässt.

Wir binden unsere Zielsteuerelemente (Dependency Objects) wie gewohnt per Data Binding an die Artefakte an, um den Entwicklern eine nahtlose Integration der Übersetzung(en) in ihren Code zu ermöglichen. Um den zu schreibenden Code gering zu halten, erlauben wir den Zugriff auf die Artefakte über indizierte Eigenschaften (Indexed Properties) einer zentralen Übersetzungsinstanz (Singleton Pattern), die über das ViewModel direkt zur Verfügung gestellt wird.

Die gewünschten Artefakttypen (Text, Grafik und URI) lassen sich leicht auf die CLR-Typen string, image source und uri mappen. Durch Ausgliederung der Übersetzungen in externe XML- und Grafik-Ressourcen erreichen wir ferner eine strikte Trennung zwischen der Zurverfügungstellung und dem Konsumieren der Artefakte (Anforderung 3). Diese können z.B. über eine externe XML-Datei zu Programmstart in die Anwendung injiziert werden und eigenen sich ebenfalls als Ziel für die redaktionelle Bearbeitung durch Drittanwendungen (z.B. Excel).

Mit diesen Vorüberlegungen im Gepäck sind wir für die weiteren Arbeitsschritte bestens vorbereitet und können uns nun an die eigentliche Code-Implementierung machen.

In einem zweiten Teil werde ich die Implementierung in Kürze konkretisieren…

Als Innendienstler möchte ich Aufträgen Termine zuweisen können, um den Personaleinsatz (Techniker) vor Ort optimieren zu können. Zu jedem Auftrag sollen die Termine in Echtzeit ersichtlich sein. Jeder Auftrag soll den frühesten Termin explizit anzeigen.

Zum Hintergrund: Die mittels WPF in .NET 4 umgesetzte Anwendung ist mehrbenutzerfähig und verwendet einen SQL Server 2012 zur Datenhaltung. Zum Einsatz kommt außerdem das aktuelle Entity Framework 5.0.

Gesucht: Datencontainer für Termine

Um die oben genannte Anforderung zu erfüllen, benötigten wir einen Container, der…

• generische Items aufnehmen kann (wir arbeiten mit einer Klasse Termin),
• sich nahtlos an die UI binden lässt, sowie
• Änderungen im Items-Bestand automatisch mitteilt (INotifyCollectionChanged, INotifyPropertyChanged).

Die Klasse Termin definiert die Eigenschaften Start und Ende (beide DateTime) und sieht im Kern wie folgt aus (Auszug):

public class Termin : ObservableObject
{
    // PRIVATE BACKING VARS
    private DateTime _start;
    private DateTime _ende;

    // CTORS
    public Termin(DateTime start, TimeSpan dauer)
    {
        // validiere
        if(start == null)
            throw new ArgumentNullException("start");

        if(dauer == null)
            throw new ArgumentNullException("dauer");

        // zuweisen
        Start = start;
        Ende = start.Add(dauer);
    }

    // PROPERTIES
    public DateTime Start
    {
        get { return _start; }
        set { SetPropertyValue("Start", ref _start, value); }
    }
    public DateTime Ende
    {
        get { return _ende; }
        set { SetPropertyValue("Ende", ref _ende, value); }
    }
}

Der gesuchte Container soll es der Klasse Auftrag ermöglichen, seine Termine über die gleichnamige Eigenschaft Clients zur Verfügung zu stellen, so dass dem Auftrag beliebig Termine hinzugefügt und entfernt werden können:

public class Auftrag : ObservableObject
{
    // PRIVATE BACKING VARS
    private ObservableCollection<Termin> _termine;
    private Termin _fruehesterTermin;

    // CTORS
    public Auftrag()
    {
        // instantiiere
        Termine = new ObservableCollection<Termin>();
    }

    // PROPERTIES
    public Termin FruehesterTermin
    {
        get { return _fruehesterTermin; }
        private set { SetPropertyValue("FruehesterTermin", ref _fruehesterTermin, value); }
    }
    public ObservableCollection<Termin> Termine
    {
        get { return _termine; }
        private set { SetPropertyValue("Termine", ref _termine, value); }
    }
}

Berechnung des Wertes Auftrag.FruehesterTermin

Änderungen im Termin-Bestand müssen deshalb abgefangen werden, damit der Wert FruehesterTermin eines Auftrags neu berechnet werden kann. Diese Neuberechnung wird erforderlich, wann immer

• sich der früheste Termin durch das Hinzufügen oder Entfernen von Terminen aus der Collection ändert, oder auch
• das Ändern von Eigenschaften bestehender Termine (insbes. der Start-Eigenschaft) eine Neuberechnung von Auftrag.FruehesterTermin erforderlich macht.

Unter den potentiellen Kandidaten stand natürlich die generische ObservableCollection<T> an erster Stelle, die uns WPF-Entwicklern sehr gute Dienste erweist. Die Sache hat jedoch einen Haken: Zwar meldet die ObservableCollection<T> Änderungen im Items-Bestand über das Ereignis CollectionChanged (INotifyCollectionChanged), so z.B. beim Hinzufügen und Entfernen von Terminen. Jedoch werden Änderungen innerhalb von Terminen (z.B. das Ändern eines Start-Datums) nicht über die Collection selbst an Dritte weitergegeben. Dies ist jedoch erforderlich, um sicherzustellen, dass ein Auftrag seinen Wert FruehesterTermin neu berechnen kann, wenn sich die Start-Werte seiner Termine ändern.

ObservableCollection<T> erweitert: DeeplyObservableCollection<T>

Wir beauftragen also die ObservableCollection mit der Beobachtung seiner Items. Da dies nicht von Haus aus implementiert ist, erweitern wir die Klasse durch den abgeleiteten Typen DeeplyObservableCollection<T>. Dieser beobachtet Änderungen in seinem Items-Bestand bis hinunter zu den Properties der Items. Dazu ist es erforderlich, dass nur Items aufgenommen werden können, die INotifyPropertyChanged implementieren:

public class DeeplyObservableCollection : ObservableCollection where T : INotifyPropertyChanged
{
    // CTORS
    public DeeplyObservableCollection() : base() {
        // auf Bestandsänderungen reagieren
        CollectionChanged += DeeplyObservableCollection_CollectionChanged;
    }
}

Änderungen am Items-Bestand werden durch das Ereignis CollectionChanged abgefangen. Neue Items werden ebenfalls über PropertyChanged auf Änderungen beobachtet:

private void DeeplyObservableCollection_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
    // reagiere auf Änderungen innerhalb von items
    if(e.NewItems != null) {
        foreach(var item in e.NewItems)
            (item as INotifyPropertyChanged).PropertyChanged += DeeplyObservableCollection_Item_PropertyChanged;
    }

    // löse Ereignis-Handler von alten Elementen
    if(e.OldItems != null) {
        foreach (var item in e.OldItems)
            (item as INotifyPropertyChanged).PropertyChanged -= DeeplyObservableCollection_Item_PropertyChanged;
    }
}

Schließlich sollen Änderungen innerhalb von Items durch das Ereignis CollectionChanged der zugrundeliegenden ObservableCollection an Clients weitergegeben werden. Dazu zweckentfremden wir die NotifyCollectionChangedAction:

private void DeeplyObservableCollection_Item_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
    // Event feuern
    var e2 = new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Replace);
    OnCollectionChanged(e2);
}

Das Resultat

Jetzt können wir Änderungen an unseren Terminen sowohl auf Collection- als auch Item-Ebene bequem über das CollectionChanged-Ereignis unserer DeeplyObservableCollection abfangen, um dann den Wert FruehesterTermin neu berechnen lassen. Zuerst aber müssen wir die ObservableCollection-Instanzen durch unsere neue DeeplyObservableCollection austauschen:

public class Auftrag : ObservableObject
{
    // PRIVATE BACKING VARS
    private DeeplyObservableCollection _termine;

    // ...

    // CTOR
    public Auftrag()
    {
        // instantiiere
        Termine = new DeeplyObservableCollection();

        // Änderungen abfangen
        Termine.CollectionChanged += Termine_CollectionChanged;
    }

    // EVENT HANDLERS
    private void Termine_CollectionChanged(object sender, System.Collections.Specialized.NotifyCollectionChangedEventArgs e)
    {
        // fruehesten Termin neu berechnen
        FruehesterTermin = Termine.OrderBy(t => t.Start).FirstOrDefault();
    }
}

Das von Taylor Otwell entwickelte Web Application Framework kommt frisch und frech daher. Es verzichtet auf die PHP-Altlasten, die viele andere PHP Frameworks mit sich herum schleppen. Grund dafür dürfte sein, dass Otwell langjähriger .NET Entwickler ist und erst spät in PHP geschrieben hat, als eine ausreichende objektorientierte Unterstützung gegeben war.

Sein Anspruch: ein intuitives, expressives Web Framework, das die modernen Features der aktuellen PHP-Version 5.3 unterstützt, einfach zugänglich und gut dokumentiert ist. Nebenbei preist er es als ein Werkzeug an, das die Entwicklung zur Freude macht. Recht hat er: Laravel macht viel Freude.

Objektorientierung bis zur Perfektion

Laravel glänzt durch seinen konsequenten objektorientierten Ansatz. Alles, aber auch wirklich alles wird über Klassen bereitgestellt, die sich nahezu beliebig erweitern lassen. Mehr noch: Wo Objektmethoden keinen Sinn haben, übernehmen statische Funktionen die Aufgaben, die unabhängig von einzelnen Instanzen ausgeführt werden, z.B. das Auslesen von Input über via GET:

$your_name = Input::get('your_name', 'John Doe');

Artisan und Projektstruktur

Artisan (zu Deutsch: Handwerker) heißt der Projektassistent, der für das Generieren der Basis-Implementierung zuständig ist (sog. Scaffolding). Insofern ist der Name gut gewählt, da dieser tatsächlich die wichtige Handarbeit erledigt.

So wird u.a. die Projektstruktur über die Kommandozeile von Artisan bereitgestellt. Sie entspricht dem üblichen Convention over Configuration Credo.

Die Abbildung links lässt die konsequente Sauberkeit schon erahnen, die sich durch das gesamte Framework bis hin zur Perfektion zieht. Gerade das aber macht die Freude an Laravel aus, denn die Arbeit damit gestaltet sich äußerst effizient und produktiv.

Auch beim Migrieren der Daten und dem Erstellen neuer Controller hilft Artisan ungemein.

MVC und Routing

Es folgt ein einfaches Beispiel für Laravels MVC-Unterstützung.

    class Home_Controller extends Base_Controller {
        public function action_index() {
            return View::make('index.index');
        }
        public function action_about() {
            return View::make('home.about');
        }
    }

MVC-Kennern zeigt der Code-Ausschnitt nichts Neues: Alle Controller erben von Base_Controller und stellen die nächst kleineren logischen Einheiten (Actions) bereit. Die About Action des Home Controller ließe sich bsplws. über die URL /home/about aufrufen.

Weitere Goodies und Fazit

Die vorgestellten Features sind nur die Spitze des Eisberges: Laravel hat noch mehr Leckerbissen an Bord:

• Routes und Closures,
• Form-Generierung und -Validierung,
• Query Builder (Fluent) sowie OR-Mapper (Eloquent),
• Templates (Blade),
• Authentication und Event Handling

Insgesamt präsentiert sich Laravel als kompaktes, modernes und hoch effizientes Framework. Die Arbeit damit macht nicht nur Spaß, man ist auch sehr schnell mit hoher Produktivität dabei. Die offizielle Homepage bietet eine ausführliche Dokumentation, Benutzerforen sowie kostenlose Erweiterungen (sogen. Bundles).

Ich bin sicher, wir werden in Zukunft noch viel von Otwell und seinem vielversprechenden Framework hören.

Staatliche Stellen sind verpflichtet, ihre Webauftritte möglichst barrierearm zu gestalten (bzw. gestalten zu lassen) und budgetieren entsprechend. Private Auftraggeber und solche aus der freien Wirtschaft hingegen halten einen barrierearmen Webauftritt zwar für erstrebenswert. Von ihrem hehren Anspruch bleibt jedoch nicht viel, sobald es um die Bereitstellung finanzieller Mittel geht.

Die Kosten von Barrierefreiheit

Zwar ist der Aufwand, barrierearme Seiten und Webanwendungen zu schreiben, dank moderner Webtechniken (XHTML, HTML5, CSS) enorm gesunken. Gleichzeitig jedoch wird die positive Entwicklung durch anspruchsvollere inhaltliche Gestaltung und gestiegene Ansprüche der Besucher konterkariert.

Machen wir uns nichts vor: Barrierearmut im Web ist teuer. Sie verursacht Fixkosten und laufende Kosten, die in jedem Projekt eingeplant werden müssen. Das fängt beim Entwickler an, denn der möchte für den Zusatzaufwand bezahlt werden (Fixkosten: Entwicklung). Allein mit validem XHTML/HTML5 konformem Code und ein Paar alt-Attributen für Image-Tags ist es nämlich lange nicht getan.

Schließlich hat der Kunde von dem Aufwand nichts, wenn er den durch ihn generierten Inhalt nicht streng nach barrierearmen Prinzipien gestaltet (laufende Kosten: Content-Pflege): Bilder müssen mit Alternativtexten versehen werden und Videos gänzlich alternativen Content bereitstellen. Die Nachrichten vieler audiovisueller Gimmicks (man denke gerade an die zahlreichen Neuerungen im Bereich CSS3) werden dem Besucher mit Behinderung entweder gänzlich verwehrt, oder aber nur sehr eingeschränkt zugänglich gemacht.

Die multimediale Collage aus Texten, Grafiken, Videos und Audiodaten muss als Ganzes strengen Tests und Simulationen unterzogen werden — und das immer und immer wieder. Nur so kann sichergestellt werden, dass ihre Barrierefreiheit kein bloß theoretischer Anspruch ist. Es ist klar zu sehen, welche Kostenfaktoren hier eine Rolle spielen. Letzten Endes ist es im Bauwesen und in der Architektur, wo der Begriff Barrierefreiheit schon viele Jahrzehnte eine zentrale Rolle spielt, nicht anders.

Das Problem: Barrieren und ihre Opfer sieht der Betreiber einer Site nicht

Zynisch gesagt müsste es eigentlich lauten: Der Aufwand für Barrierefreiheit rechnet sich nicht (sprich: Rendite gleich null). Nun möchte ich aber meinen Kunden solch zynische Ansichten nicht unterstellen. Ich glaube daher, dass ein Hauptproblem darin besteht, dass Barrieren schlichtweg nicht erkannt werden.

Damit meine ich zum einen, dass strukturelle Hindernisse (z.B. die Zugänglichkeit von visuellen Medien für Sehbehinderte) nicht immer offensichtlich sind, und sich somit der Gedanke um die Notwendigkeit ihrer Vermeidung nicht gerade aufdrängt. Umso schlimmer ist es, wenn der Betreiber selbst weder Mitarbeiter mit solchen Beeinträchtigungen eingestellt hat noch selbst solchen Beeinträchtigungen unterworfen ist.

Zum anderen, und das halte ich für weitaus wichtiger, ist nicht ersichtlich, wie Besucher an solchen Barrieren gehindert werden oder ganz verzweifeln. Jede Treppe stellt für einen Rollstuhlfahrer ein nahezu unüberbrückbares Hindernis dar. Das ist für jeden sofort ersichtlich. Nicht sehen hingegen können wir, wie der Sehbehinderte den Inhalt kontrastarmer visueller Medien nicht wahrnehmen kann, oder an der Nutzung einer Site mangels alternativer Auszeichnungen gänzlich verzagt.

Wo die Opfer dieser unzulänglichen Aufbereitung von Medien nicht gesehen werden, kann folglich auch keine Abhilfe geschaffen, geschweige denn ein Bewusstsein um deren Nöte etabliert werden.

Die Lösung?

Zunächst einmal sei angemerkt, dass natürlich nicht jedes Projekt das Budget für eine nahezu barrierefreie Aufbereitung mitbringt (oder mitbringen müsste). Hier verhält es sich wie im realen Leben, wo auch nicht jeder Betrieb einen barrierefreien Zugang zu allen Räumlichkeiten anbieten kann. Letzten Endes sind also die Kostengründe immer entscheidend.

Die Betreiber aber, die auf einen barrierefreien Zugang nicht verzichten können, wollen oder müssten, täten gut daran, sich das Web einmal aus der Perspektive jener anzusehen, die es tatsächlich mit Beeinträchtigungen erleben. Dazu gibt es web- und anwendungsbasierte Simulatoren sowie Hilfsmittel für zahlreiche Beeinträchtigungen.

Wer das Web einmal aus der Perspektive von z.B. Blinden (Screenreader hier und hier)  erlebt hat, geht die Aufbereitung der eigenen Inhalte kritischer an und neigt eher dazu, ein Verständnis für die Notwendigkeit und Richtigkeit von barrierearmer Webentwicklung aufzubringen.