Bei red@ktiv sind wir zwischenzeitlich dazu übergegangen, an uns herangetragene Projekte gegen folgende OpenSource-Lösungen zu prüfen:

• Typo3: ein sehr mächtiges Content-Management-System, das mit TypoScript fast eine eigene Programmiersprache mitbringt. Ist die Einrichtung einer Präsenz mit der Festlegung von Templates, Funktionen und Gestaltung erst einmal erfolgt, wird man jedoch mit einem leistungsfähigen Tool belohnt, mit dem man dennoch Kunden nach kurzer Einarbeitung guten Gewissens bei der Pflege ihrer Seiten weitgehend alleine lassen kann. Insbesondere die Möglichkeit mehrere Sprachvarianten einer Seite zu haben ist ein schlagendes Argument pro Typo3. Vorgehende Versuche ähnliches mit Mambo zu realisieren endeten in einem ziemlichen Desaster, so daß wir davon komplett abgekommen sind. Auch wenn die Einrichtung und Verwaltung unter Mambo sehr viel einfacher und oft genug auch ausreichend wäre, greifen wir auch für kleinere Projekte bevorzugt auf Typo3 zurück.
• WordPress: Blog-Systeme sind nach wie vor en vogue und für kleine, private Webseiten ein gutes Mittel der Wahl um aktuelle Begebenheiten zu erfassen und zu publizieren. Darüberhinaus können Blogs eine wichtige Begleitmusik in Sachen Suchmaschinenoptimierung spielen. Aktualität ein wichtiges Kriterium für das Ranking bei Suchmaschinen. Und einfacher als mit einem Blog lassen sich aktuelle Dinge kaum erfassen. Über ein gut ausgebautes System von PlugIns lassen sich leicht zusätzliche Funktionen in WordPress implementieren.
• xt:Commerce: auch wenn das Vertriebskonzept mit kostenpflichtiger Zwangsmitgliedschaft im Supportforum der Hauptentwickler mit dem Opensoure-Gedanken in krassem Widerspruch steht und etliches am HTML- und CSS-Code von xtCommerce ziemlich krank ist – es ist das Mittel der Wahl, wenn es um einen guten Webshop geht! Sowohl funktional als auch gestalterisch (wenn man denn die elementarsten Fehler mal gerade gerückt hat) bietet xt-Commerce eine exzellente Basis für eCommerce Anwendungen. Wie auch bei Typo3 ist die Möglichkeit mehrere Sprachvarianten zu verwalten sehr ausgeprägt und für ein Online-Business geradezu elementar. Über das smarty-System das für die Generierung der Templates verantwortlich ist, kann man zu dem die Gestaltung der Seiten sehr gut anpassen und in valides XHTML überführen, so daß ein gute Grundlage für die Gestaltung mit CSS besteht. Die in der Szene gehandelten oder bereitgestellten total veralteten Tabellenlayout-Konstrukte, die mit i
• phpiCalender/phpMyCal: wenn es um die Erfassung und Verwaltung von Terminen geht kann es nur eine Wahl gegen – ein System das den iCal-Standard unterstützt. phpiCalendar tut dies vorbildlich. In Zusammenarbeit mit phpMyCal entsteht noch ein Webfrontend über das Termine zu erfassen und zu pflegen sind. Leider ist phpMyCal derzeit vom Netz verschwunden, so daß wir hier eine von Relate Me >bereitgestellte Version, die wir auf Standalone-Betrieb rückentwickelt haben, nach den Regeln der GPL zum Download einstellen.

Modifizierte Version von phpiCalendar mit phpMyCal-Extension

Wie man an den aufgeführten Beispielen unschwer erkennen kann: es bleibt in allen Fällen genügend Arbeit übrig um die “fertigen” System passend für die Kundenanforderunge zu modifizieren. Durch die Offenheit des Quelltextes ist es uns jedoch leicht möglich zusätzliche Funktionaliäten oder kundenspezifische Änderungen zu erstellen. Der Fall, das eine OpenSource-Software out-of-the-box die Anforderungen des Kunden erfüllt ist höchst selten. Mindestens die Identifikation und Installation von PlugIns gehört zum Standardrepertoire. Im nächsten Schritt steht dann die Entwicklung eigner Erweiterungen. Erst wenn die Anforderungen soweit vom Grundsystem abweichen, das schon die Umprogrammierung und -konfigurierung des Grundsystems einer kompletten Neuentwicklung gleich kommt, greift noch “Plan B” und wir entwickeln Dinge von Grund auf neu und kundenspezifisch.

Bekanntermassen ist nicht jeder Mensch mit allen Sinnen gleich gut ausgestattet. Unsere Wahrnehmung der Welt ist unterschiedlich – auch die der Netzwelt. Umso mehr gilt das Gebot, das diesen unterschiedlichen Wahrnehmungen Rechnung getragen werden muss. Ein Gebot, das durch WAI erstmals konkretisiert wurde. Später mündete es für deutsche Bundesbehörden sogar in die Verordnung zur Barrierefreiheit in der Informationstechnik (BITV) ein. In zunehmendem Masse wird diese Verordnung auch durch die Gleichstellungsgesetze der Bundesländer in die Länder- und Kommunalverwaltungen einziehen. Bei Unternehmen wird der Markt für den notwendigen Druck sorgen. Welcher klug rechnende Kaufmann wird es sich auf Dauer leisten können auch nur einen Teil seiner potentiellen Kundschaft von seinem Warenangebot aussperren zu können?

Die Umsetzung in der Praxis ist derzeit jedoch noch nicht sehr weit fortgeschritten. Unverständlicherweise, ist doch der Anspruch an einen barrierefreien Internetauftritt mit einem sehr geringen Aufwand zu realisieren. Alle notwendigen Techniken um einen barrierefreien Internetauftritt zu erstellen sind etabliert und verfügbar. Mehr noch: es sind die Techniken, die man braucht um den gängigen Anforderungen an einen Internetauftritt gerecht zu werden:

• Schnelle Ladezeiten durch »schmalen« Code
• Leichte Pflegbarkeit der Präsenz durch stringente Trennung von Gestaltung und Inhalt
• Suchmaschinenoptimierung durch textbasierten Inhalt in semantisch korrektem Kontext
• Universelle Zugänglichkeit durch validen Code, der von allen Ausgabegeräten verarbeitet werden kann

Von diesen Zielvorgaben ausgehend ist es nur noch ein kleiner Schritt hin zur Barrierefreiheit. Für die Aufteilung von Gestaltung und Inhalt stehen HTML und CSS zur Verfügung. Beschränkt sich der WebDesigner bei der Seitenerstellung auf die Hinzufügung von einigen wenigen HTML-Tags zum eigentlichen Inhalt ist damit die Zugänglichkeit für alle, ein schneller Seitenaufbau und eine optimale Suchmaschinenwahrnehmung sichergestellt.

Dieses »HTML-Gerippe« ist optisch alles andere als ansprechend. Wer durch eine Sehbehinderung jedoch von dieser Optik sowieso nichts erfährt, wird jedoch für eine klare Struktur die ein Screenreader optimal verarbeiten kann dankbar sein. Für die Sehenden kommt dann im zweiten Schritt via CSS ein ansprechende Gestaltung dazu. Funktion und Ästhetik müssen dabei keine Gegensätze sein. Die Möglichkeiten die CSS für moderne und reiche Gestaltungen liefern reichen von der Vielfalt an die von Printlayout heran. Halbtransparenzen, mehrspaltiger Satz mit überlappenden Bildern, Schriftvariationen, mitwachsende Layouts, … alles ist (mit etwas Hirnschmalz) machbar.

Barrieren können aber nicht nur in der Visualisierung bestehen. Auch motorische Beeinträchtigungen, Schwierigkeiten im Textverständnis (Pisa lässt grüßen!) oder auch Hörschäden können zur Barriere hin zu einen erfolgreichen Webauftritt werden. Auch diese Lösungen sind nicht schwer umzusetzen. Ein kurzer Text, der ein Bild beschreibt, ein Untertitel in einem Tonfilm oder die Möglichkeit Links einfach nur per Tastatur statt mit einer Maus zu erreichen. Alles einfaches Handwerkszeug, das ein WebDesigner in seiner Werkzeugkiste finden sollte.

Fazit: schaut man sich im Netz um, finden sich immer wieder sehr gute Umsetzungen von Barrierefreien Internetseiten, die auch für uns »Normale« ansprechend und leicht zu bedienen sind. Leider überwiegen immer noch handwerklich schlechte Lösungen, die mit Frames, Javascripten oder Flash vielen ihrer Nutzer das Leben schwer machen. Bei einigen Internetauftritten muss man nicht mal behindert sein um daran zu verzweifeln. Die größte Barriere im Netz besteht leider immer noch in den Köpfen von WebDesignern.

Dieser Artikel erschien Anfang Januar auch in der Zeitschrift »Sprachrohr«

Wir diskutieren mit einigen Kollegen. Und immer wieder mit welchen, die glauben an dieser Stelle die Statistiken auf ihrer Seite zu haben. Über den Verbreitungsgrad dieses oder jenes Betriebssystems, des Browsers XYZ, die Bildschirmauflösung 08/15 und des Sowieso-PlugIns.

Ok, reden wir über Statistik:

Blenden wir die auch in diesem Fall völlig richtige Weisheit Winston Churchills Man kann nur einer Statistik trauen, die man selbst gefälscht hat einmal komplett aus. Versuchen wir einfach den höchstmöglichen Verbreitungsgrad für die häufigst unterstellte Umgebung zu errechnen:

• aktueller Internet Explorer (ab Version 5 und neuer)
• unter Windows (wir nehmen alles mit: 3.x, 95, 98, ME, 2000, NT, XP)
• bei einer Bildschirmauflösung von mindestens 1024 x 768 Pixeln
• mit installiertem Macromedia Flash-PlugIn, wahlweise aktiviertem JavaScript

Unterstellen wir Windows einen Marktanteil von 90% (genaue Zahlen für Desktop Betriebssysteme sind leider nirgends zu bekommen – wahrscheinlich aus gutem Grund nicht mal von Microsoft selbst). Auch für die Browserverteilung gehen wir von 90% aus . Ebenso nehmen wir für Bildschirmauflösungen von 1024 x 768 und höher einen Verbreitungsgrad von 90% an. Bei der Auswahl zwischen Pest und Cholera Flash und JavaScript entscheiden wir uns für Flash und übernehmen die 97% Verbreitungsgrad die Macromedia von sich selbst behauptet.

Jetzt wird’s spannend

Nach einfachen Rechenregeln und der Annahme einer statistischen Normalverteilung macht das: 0,9 * 0,9 * 0,9 * 0,97 = 0,70713 oder großzügig gerundet: 71%! Nochmal: sämtliche Basiszahlen sind mit hoher Unsicherheit behaftet. Aber selbst wenn man einen »Sicherheitsaufschlag« dazu nähme und mit 0,95 * 0,95 * 0,95 * 0,99 rechnete, würden »nur« knappe 85% herauskommen. Das Szenario das eintritt, wenn die Zahlen schlechter sein sollten, mag sich jeder selbst ausmalen.

Sind 85% viel?

Nein, es sind glatte 15%, die an vollständiger Zugänglichkeit fehlen. Mal ehrlich: welcher klug rechnende Geschäftsmann kann es sich heutzutage leisten auf 15 oder gar 30% seiner potentiellen Kundschaft, seiner Umsätze, seiner Gewinne zu verzichten? Die Antwort ist ebenso einfach wie die Lösung für das oben beschriebene Dilemma: Verlangen Sie als Kunde von ihrem WebDesigner Seiten die auf allen Browsern, auf allen Betriebssystemen, bei allen Bildschirmauflösungen – richtiger sogar auf allen Ausgabegeräten, es gibt mehr als nur optische Ausgabegeräte! – mit allen Systemumgebungen funktionieren. Nicht auf einigen. Nicht auf den meisten. Auf allen! Der Aufwand für solche Seiten ist nicht größer als für das was die »optimiert für«-Fraktion abliefert.