Barrieren gibt es nur in den Köpfen von WebDesignern

»Ich schau mal schnell im Internet nach«. Längst gehört das Internet zu den täglichen Werkzeugen in Haushalt, Schule und Beruf. Ein Werkzeug, das sich zudem auch noch eine grunddemokratische Struktur auszeichnet. Jeder kann hier seine Botschaften einstellen, jeder kann diese Informationen nutzen. Wirklich jeder?

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«

!DOCTYPE-HTML-PUBLIC“-// W3C//DTD XHTML 1.0 ohne Einschränkungen

Zum ersten Mal ein Artikel, der nicht aus unserer Feder stammt sondern dem Weblog »The Man in Blue« entnommen wurde. Cameron Adams – der »Mann in Blau« – spricht uns in seinem englischsprachigen Artikel dermaßen aus der Seele, das wir uns eine Übersetzung nicht verkneifen konnten:

Beim Gestalten tabellenfreier Websites sind viele Dinge zu beachten: Das Box-Modell, mysteriöse 3-Pixel große Abstände, relative Schriftgrößen, kaskadierende Stilregeln, Textumfluß … aber nichts davon ist wirklich wichtig. Beim Entwurf einer Website sollte man an all das nicht denken.

Wenn es an die Gestaltung von Websites geht, sind reine Grafikdesigner mit Unwissenheit gesegnet. Sie müssen nicht vorausdenken, wie ihr Design umzusetzen ist. Sie müssen sich keine Gedanken machen, wie ein Fußbereich auf einer Seite konstant unten fixiert wird. Und genau so
sollten es WebDesigner machen.

Standard-basiertes WebDesign steckt noch in den Kinderschuhen. Überall findet man Tutorials über die Erstellung von Webseiten in XHMTL/CSS und jeden Tag entsteht eine neue Technik in diesem Bereich. Ohne fortschrittliches Design, ohne die Freiheit mal nicht über die Umsetzung nachzudenken, würde niemand die Grenzen der Webstandards verschieben. Möglicherweise wären sie in dem Moment
verschwunden, wenn jemand die Frage stellte »Wie schaffe ich es, daß zwei Spalten immer gleich lang sind?«.

Beim Design geht es nicht um die Werkzeuge, es soll dem Anwender das bestmögliche Erlebnis vermitteln. Ein Design sollte auf Benutzbarkeit (usability), Zugänglichkeit (accesibility) und Ästhetik beruhen, aber niemals auf Umflüssen, Listen oder Hintergrundbildern.

Wenn ich)* beginne, eine Website zu entwerfen, ist es ein rein graphischer Ansatz. Photoshop und Illustrator allein bestimmen die Grenzen. Innerhalb dieser Grenzen kann ich ein fünfspaltiges Layout mit fixiertem Fußbereich, Drop-Down-Menüs und freischwebender Farbauswahl für die Schrift erschaffen. Egal ob ich das umsetzen kann – das ist, was ich gerne sehen würde.

Dann, … danach geht es an die Lösung der Probleme. Es ist die analytische Seite des WebDesign, bei der uns WebDesignern das Wasser im Mund zusammenläuft, die uns teilweise zu Turing, teilweise zu Picasso (zumindest ein bischen) macht. Natürlich dürfte es ruhig machmal etwas einfacher sein, die Lösung für das Layout zu finden, Aber ich genieße die Herausforderung und stelle mich allem, was da kommt.

Das Ziel der Web-Standards ist es, unsichtbar zu sein. Sie dürfen nichts anderes hervorbringen als Tabellenlayouts oder jeder andere Tag-Sumpf. Es ist also unsere Pflicht, gut zu designen und uns erst
später um die Standards zu kümmern.

* ich = „The Man in Blue“, AKA Cameron Adams. Aber wir arbeiten da genauso…

(Übersetzt von The Man in Blue
Dort an ein Gespräch mit der Web Standards Group angelehnt.)

Elastisches Design

Bei der Überarbeitung der red@ktiv-Webseite wurde nicht nur Wert auf eine inhaltliche Neuausrichtung gelegt. Ziel des Redesigns war u.a. auch die universelle Zugänglichkeit (Accessibilty) für alle Browser und alternative Ausgabegeräte. Die technische Umsetzung mit Cascading Style Sheets (CSS) ist dabei die erste Wahl. Und wenn schon CSS dann gleich richtig.

Was kann an Webdesign elastisch sein?

Gemeint ist, das eine Seite unabhängig von der Fenstergröße oder der Bildschirmauflösung für den Betrachter benutzbar bleibt. Inspiriert durch die Artikel Sliding Doors of CSS und Elastic Design entstand für die red@ktiv-Seite ein entsprechendes Layout.

Zunächst gilt es das Font-Size Problem zu lösen. Während Mac und Linux Browser i.d.R. eine Auflösung von 72 dpi (dot per inch = Pixel pro Zoll) nutzen, sind Windows Browser i.d.R. auf 96 dpi eingestellt. Wie immer, so auch hier: keine Regel ohne Ausnahme. Aber egal wie ihr Browser eingestellt ist: Bei Schriftgrößen, die über die Einheit »Punkt« definiert werden, kommt es zum Problem, das eine mittlere Schriftgröße auf 72 dpi für den 96 dpi-Browser zu groß erscheint und umgekehrt eine mittlere Schriftgröße für 96 dpi bei 72 dpi-Browsern zu Augenpulver wird. Ein erster Ansatz »Pixel« (px) als Einheit zu wählen (10 px sind und bleiben 10 px, egal wieviele davon auf einem Zoll untergebracht werden, die Schriften erscheinen also überall gleich groß) stellt sich schnell als unbrauchbar heraus, weil damit die Skalierung der Schrift durch den Benutzer unterbunden wird. Genau diese Bevormundung steht dem Anspruch einer »universellen Zugänglichkeit« aber im Weg. Man denke nur an Menschen mit eingeschränkter Sehfähigkeit, die auf die Vergrößerung der Schrift angewiesen sind. Abhilfe schafft die Verwendung der Einheit »em«. »em« steht dabei für »Elementeinheit«. 1 em entspricht dabei 100 % der im Browser voreingestellten Standardschriftgröße. Diese kann der Benutzer global in den Voreinstellungen seines Browsers anpassen; oder auch je Fenster individuell über entsprechende Vergrößerungs-/Verkleinerungs-Tasten oder -Menüeinträge in seinem Browser. Damit ist ein erster Schritt zum »elastischem Design« getan.

Der zweite wesentliche und konsequente Schritt besteht nun darin, die Einheit »em« auf weitere Seitenelemente zu übertragen. Arbeitet man CSS nach dem Box-Modell ab, besteht eine Seite letztlich immer aus neben-, über- und ineinander gestapelten Rechtecken (Boxes). Diese Boxes wiederum sind durch einige Attribute beschrieben – z.B. die Beschaffenheit des Hintergrunds (Farbe, eingebundenes Bild, das ggf. wiederholt wird), Beschaffenheit des Rahmens (Dicke, Farbe, Strichelung), der Abstand des enthaltenen Textes zum äußeren Rahmen (padding) und der Randabstand der Box zu benachbarten Elementen (margin). Wendet man nun auf alle Größenangaben die eine solche Box beschreiben wiederum die Einheit »em« an, so werden auch diese Elemente anhand der Browservorgaben skaliert.

Als dritter – schon etwas anspruchsvollerer – Schritt kommt noch die Anwendung der Einheit »em« auf Bilder dazu. Anstatt der üblichen Höhen- und Breitenangaben in Pixeln (px) erfolgt auch hier die Angabe in »em«. Dabei ist darauf zu achten, das durch die Verwendung das Seitenverhältnis des Bildes gewahrt bleibt. Letztlich eine einfache Dreisatzrechnung um die vorhandene Pixelgröße in em zu übertragen. Idealerweise sollten daher Bilder verarbeitet werden, die über ein fixes Seitenverhältnis verfügen (4:3 oder 16:9 oder quadratisch). Damit können CSS-Klassen auf das jeweilige Verhältnis in Hoch- und Querformat beschränkt werden. Desweiteren müssen die Bilder in einer etwas höheren Qualitätsstufe als ansonsten üblich vorliegen, da diese ja vergrößert werden können und dann immer noch scharf sein sollten. Wahlweise kann dies über eine niedrigere Kompressionsrate bei .jpgs oder über ein größeres Format (mehr Pixel) erfolgen. Die Möglichkeiten muß man abhängig vom Motiv durchprobieren, ein Patentrezept für einen Kompromiß aus bestmöglicher Darstellungsqualität und kleiner Dateigröße (für schnelle Ladezeiten) gibt es leider nicht.

Im Ergebnis ergibt sich dann eine Webseite, die komplett »mitwächst« wenn die Darstellung vergrößert oder verkleinert wird. Die Proportionen innerhalb der Seite von Textgrößen zueinander, Bild zu Text und Gestaltungsmerkmale des Layouts bleiben – unabhängig von der eingestellten Darstellungsgröße – weitestgehend erhalten. Weitestgehend deshalb, weil »ems« mit »nur« einer Stelle hinter dem Komma zuverlässig anzugeben sind. Durch Rundungsfehler beim Skalieren können dann einzelne geringere Abweichungen entstehen.

Wird das CSS komplett abgeschaltet (z.B. durch alternative Darstellungsgeräte, wie Screenreader, Brailledisplays oder auch durch reine Textbrowser) bleibt der Inhalt komplett zugänglich. Durch eine durchdachte Struktur z.B. bei der Anordnung von Links zur Navigation innerhalb der Seite wird zudem auch bei nicht vorhandenem CSS eine gute Nutzbarkeit (Usability) sichergestellt.

Optimiert für …

Weil ich es gerade mal wieder – bei einem hochdekorierten Preisträger! – gefunden habe: es gibt nach wie vor WebDesigner die glauben, die Webwelt bestehe aus ihrer (beschränkten) Produktionsumgebung. Oder dem was Aldi verkauft. In der Konsequenz verlangt das nichts anderes als daß der Anbieter des Produkts als erstes nicht sein Produkt kommunizieren kann, sondern seiner Kundschaft Rahmenbedinungen diktieren muß. Oder gleich auf deren Besuch verzichtet. Beide Alternativen sind unter Marketinggesichtspunkten eine schlichte Katastrophe. Kunden wünschen bedient zu werden, nicht belehrt oder gar abgewiesen. Wie würden Sie empfinden, wenn Ihnen vor dem Supermarkt ein Türsteher erklärt das Sie nur unter diesen oder jenen Bedingungen hier einkaufen könnten?

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.