1246301858|%d.%m.%Y
Andere Blickwinkel sind ja zuweilen wichtig, um etwas besser zu verstehen. Und an jedem Blickwinkel ist immer auch was Wahres dran. Wohlan denn: Unter dem Titel Strukturbereinigung im Web 2.0 lässt der Gedankenblitzer aus der Schweiz ein paar Streiflichter wandern. Dabei hebt er mit einem Gedanken an, der erst mal im Kopf kleben bleibt:
Das Web 2.0 ist der Nachfolger des barrierenfreien Internets. Das barrierefreie Internet wurde nach dem Platzen der Dotcomblase erfunden. Webworker sprachen vom barrierefreien Internet, wenn sie Ihnen ein Redesign schmackhaft machen wollten.
Da sind natürlich eine Menge grober Verallgemeinerungen drin. Aber eben auch das Körnchen Wahrheit. Tatsächlich herrschte im Netz in den Jahren nach der Dotcom-Blase eine gewisse Orientierungslosigkeit. Neue Ideen wie Wikis, Blogs und diverse Social Services waren zwar schon geboren, wurden aber von der großen Masse der Netz-User noch nicht wahrgenommen, nicht mal von den Webworkern. Die stürzten sich zu jener Zeit tatsächlich vor allem auf das Thema Webstandards und zugleich auch auf das Thema Accessibility (Barrierefreiheit).
Das Körnchen Wahrheit
Es war die Zeit, als Webdesigner in Sachen mehrspaltiger Layouts vom Tabellendenken auf Floating-Bereiche umgepolt wurden. Seiten mussten ohne Wenn und Aber vor dem Validator bestehen, XHTML wurde als das bessere HTML gepriesen, und alles, was dem HTML-4.01-Standard zufolge als deprecated eingestuft war, wurde zuerst kritisiert, später regelrecht dämonisiert. Valide und strikt standardkonforme Seiten wurden dabei allerdings gerne mit barrierefreien Seiten verwechselt. Außerdem waren die glühendsten Verfechter der reinen Webstandards-Lehre nicht unbedingt die begnadetsten Kreativ-Designer. Deshalb sahen Seiten, die sich stolz mit ihrer Standard-Konformität brüsteten, häufig sehr eintönig und langweilig aus.
Der Barrierefreiheit wurde damit kein guter Dienst erwiesen. Obwohl sich Einrichtungen wie der BIENE-Award redlich bemühen, das Thema Barrierefreiheit in seiner ganzen Komplexität zu vermitteln, haftet dem Ausdruck selber ein seltsam aschfahler Oberlehrer-Geschmack an. Er riecht wie eine Mischung aus sonderpädagogischem Lehrplan und Straßenverkehrsordnung. Jedenfalls nichts, woran man mit Freude denkt.
Und genau in diese Lücke stößt wie der Gedankenblitzer richtig bemerkt das Web 2.0. Plötzlich machte das Web wieder Spaß. Man konnte allerortens problemlos publizieren, beitragen und kommunizieren. Dabei hatte man allerdings kaum mehr Zeit und Gelegenheit, sich mit Details des zugrundeliegenden Markups auseinanderzusetzen. Man wurde auch gar nicht mehr so stark damit konfrontiert — denn mehr und mehr publizierte man nun direkt über Web-Formulare als über klassische HTML-Editoren. Heute twittert und networkt man, bloggt zwischendurch und zieht kommentierend und diskutierend durch Web. Zum Veröffentlichen befüllt man freundliche Eingabefelder in Facebook, Wordpress, Blogger.com, MediaWiki und anderen Systemen. Mal Richtext, mal Wikitext, mal BB-Code, mal HTML mit bestimmten, erlaubten Elementen. Aber „barrierefreies Markup“? Klingt das, wenn man so von Eingabefeld zu Eingabefeld unterwegs ist, nicht eher nach etwas für liebevoll entworfene, statische Websites von Pudelsalons und Weinläden?
Ein wichtiger Grund für das allmähliche Verstummen der Rufe nach Barrierefreiheit ist leider auch, dass man in den Jahren, als sehr viel vom barrierefreien Web die Rede war, nur wenig von Betroffenen hörte. Stattdessen waren es immer wieder die gleichen, bereits erwähnten Prediger, die den Webdesignern wegen jeder blinden Tabelle ein schlechtes Gewissen einredeten und ihre immer gleichen Phrasen von den angeblichen Todsünden beim Markup droschen. Eine Zeitlang fügten sich auch alle in ihr Schicksal und bastelten zähneknirschend XHTML-basierte float-Konstrukte im Namen der Barrierefreiheit. Doch genau wegen dieser eigentlich am Thema vorbeigehenden Reduktionen rückte das Thema Barrierefreiheit schnell wieder aus dem Fokus, als das Web wieder andere, spannendere Dinge zu bieten hatte.
Konsequenzen
Um so wichtiger ist es, dass Maßnahmen für mehr Barrierefreiheit auf Webseiten bereits getroffen werden, bevor normale Blogger, Wiki-Artikelschreiber, Forumsdiskutanten und Networker überhaupt drauflos schreiben. Im Klartext bedeutet das:
- Templates von Webanwendungen müssen in hohem Grad die Kriterien für Barrierefreiheit erfüllen. So gibt es unzählige frei verfügbare, optisch zunächst durchaus ansprechende Templates für Blogs. Doch so manche davon haben einen ungünstigen strukturellen Aufbau. Im Markup kommen nicht identifizierbare Überschriften vor. Navigationen sind nicht ohne JavaScript benutzbar. Kontraste sind zu schwach, die Rot-Grün-Problematik wird nicht bedacht usw.
- Richtext-Editierwerkzeuge innerhalb von Webanwendungen müssen semantisch sinnvolles Markup erzeugen. Leider erfüllen viele beliebte und verbreitete dieser Werkzeuge immer noch schlechten bis indiskutablen HTML-Code. Kaum eines der Werkzeuge ist in der Lage, seinen Code bei vielen Überarbeitungsvorgängen ordentlich aufzuräumen. Einige Richtext-Editoren erlauben das Umschalten auf Code-Editing. Doch wenn dabei erzeugter Code beim Zurückschalten in den Wysiwyg-Modus nicht erhalten bleibt, ist der ganze Umschalt-Modus sinnlos.
- Web-basiertes Editieren schmückt sich zwar mittlerweile gern mit Funktionen wie Rechtschreibprüfung. Hinsichtlich barrierefreier Aspekte wäre es jedoch ebenso wichtig, wenn etwa auch Abkürzungen, Datum- und Zeitangaben erkannt und automatisch durch intelligentes Markup ausgezeichnet würden. Oder wenn Links automatisch typisiert würden. Auch Funktionen, die mittlere Satzlängen oder die mittlere Fremdwortdichte in Texten messen und gegebenenfalls warnen, könnten dazu beitragen, dass Inhalte verständlicher und damit besser zugänglich werden.
Fazit: Barrierefreiheit muss im Web 2.0 vor allem „unter der Haube“ stattfinden. Dann muss auch niemand mehr lästern, dass das Web 2.0 der Nachfolger des barrierefreien Web sei. Und das „barrierefreie Web“ könnte mehr als nur ein kurzes Kapitel der Web-Historie bleiben.
Unter der Voraussetzung, dass das Publizieren ansich heutzutage im Vordergrund steht, kann ich deinen Konsequenzen voll und ganz zustimmen [1]. Diejenigen, die die Software und die Templates erstellen sollten sich als einzige um solche Dinge kümmern müssen. Sie sollen die Templates entsprechend vorbereiten und die Software so umsetzen, dass die Publizierenden garnicht erst damit konfrontiert wird. Sie kennen sich damit im Normalfall eh nicht aus. Warum auch, sie wollen einfach nur etwas veröffentlichen.
Das muss dann, sobald es der aktiven Umsetzung durch den Nutzer bedarf, aber auch eingänglicher — also selbsterklärender — sein, als bei einschlägigen Textprogrammen (Word und Konsorten). Dort kommt es ja auch nur allzuoft vor, dass die Gliederungsmöglichkeiten der Programme (Überschriften, Absätze, Listen etc.) nicht benutzt werden und Hervorhebungen ausschließlich über Schriftart, -größe u.s.w. realisiert werden. Wenn die Möglichkeiten in Webanwendungen einfach nur da sind, damit sie da sind, werden sie höchstwahrscheinlich ebenso ignoriert wie im heimischen Textprogramm.
[1] Als Autor von Skripten stehe ich ja auf beiden Seiten (Autor und Nutzer).
Posting-Vorschau:
Vorschau schließen