« Weg mit der PDF-Prüfung im BITV-Test!
Standardkonform? - Kann ich nicht mehr hören! »

worldusabilityday.de - Bericht aus der Online-Redaktion

Am 8. November 2007 findet zum dritten Mal der World Usability Day statt, der weltweite Aktionstag für benutzerfreundliche Technik, ausgerichtet von der UPA, internationaler Berufsverband der Usability Professionals. In Deutschland machen 15 Städte mit, von Dresden bis Aachen, von Hamburg bis München. Es wird ein spannender Tag mit tollen Programmen, in jeder Stadt anders und einmalig. Unbedingt hingehen, der Eintritt ist frei!

Eine gemeinsame Website rückt die Programme aller deutschen Städte ins rechte Licht: www.worldusabilityday.de. Es ist eine spannende, inhaltsreiche Website, und auch noch barrierefrei nach 95plus-Standard. Wie machen die das? - Es folgt ein Blick hinter die Kulissen der barrierefreien Webredaktion.

Eine barrierefreie Website aufzusetzen ist nicht ganz trivial, aber doch schon oft und gut gemacht worden. Schwierig wird es, wenn die barrierefreie Gestaltung sich im Redaktionsalltag bewähren muss. Die Autoren kommen mit ihren Beiträgen und wollen sie sofort und möglichst selber einpflegen, natürlich ohne sich lange einarbeiten zu müssen. Sie bringen Material an, mit dem vorher niemand gerechnet hat. “Flöhe hüten” heißt die Aufgabe für den verantwortlichen Redakteur, auf neudeutsch “Qualitätssicherung”. Die Lösung sucht man heute gemeinhin in Content-Management-Systemen. Ich bin aber froh, dass wir bei worldusabilityday.de immer noch mit statischen HTML-Seiten arbeiten.

2005, als wir mit 7 Städten anfingen, war eine statische Website für den World Usability Day - kurz WUD - noch ohne Alternative. Barrierefreiheit war ein Muss, das war die gc-upa sich schuldig, und barrierefreie CMS-Systeme hatten damals noch Seltenheitswert. Rückendeckung fand ich bei Wolfgang Wiese, der im Rechenzentrum der Uni Erlangen einen barrierefreien Vorlagenkatalog mit statischen HTML-Seiten aufgebaut hat und auf dieser Basis Massen von Websites organisiert.

Statische Websites gelten an sich als One-Man-Show mit begrenztem Umfang und geringer Flexibilität. Das sind aber Weisheiten aus der alten Zeit, als man Homepages mit Tabellen und Spacer-Images gebaut hat, am besten gleich aus GoLive exportiert. Einem Laien durfte man das nicht in die Hand geben - der wollte nur eine kleine Textänderung machen und brachte dabei garantiert das ganze Layout durcheinander. Mit standardkonform programmierten HTML-Seiten ist das anders. Da ist das Layout ausgelagert in separate CSS-Dateien, mit denen man bei der Pflege gar nicht in Berührung kommt. In der Seite selbst steht der blanke Inhalt, Navigation und Content, in sauberem, wohl strukturiertem HTML, das sogar ein Laie versteht. Und wenn der Auftraggeber jede Woche einen neuen Menüpunkt eingebaut haben will, ist das auch kein Problem. Stimmt, beim WUD mit seiner flachen Gliederung fange ich jetzt doch langsam zu stöhnen an, wenn sich wieder eine neue Stadt anmeldet und ich sie auf 24 Seiten eintragen darf. Also, für 2008 planen wir nun doch ein CMS.

Für die Autoren jedenfalls sind standardkonforme HTML-Seiten einfach zu handhaben. Beim WUD haben wir eine Musterseite mit Beispielen für die verfügbaren Inhaltsformate: Fließtext, Auszeichnungen, Tabellen, Bilder. Hier kann man sich Anregungen für die Gestaltung der eigenen Inhalte holen und die benötigten Formate herauskopieren. Wer seine Seite selber pflegen will, bekommt sie als ZIP-Datei mit allen Styles und einer Bedienungsanleitung zugeschickt. Die Autoren bearbeiten ihre Seite lokal mit einem HTML-Editor ihrer Wahl (Dreamweaver, phase5, BBedit, Frontpage …) und schicken sie zur Veröffentlichung an den Redakteur. Der Redakteur kontrolliert die Seite auf Einhaltung der Konventionen, formale und inhaltliche, bevor er sie auf den Server hochlädt.

Der Workflow funktioniert in der Praxis überraschend gut. Von den 30 Autoren, die seit 2005 an der WUD Website beteiligt waren, haben 15 die HTML-Vorlagen genutzt und ihre Inhalte selber eingepflegt. Die andere Hälfte hat auf die Editierdienste des Redaktionsteams zurückgegriffen. Ob mit CMS mehr Autoren selber pflegen würden, möchte ich in Frage stellen. Dennoch freuen sich alle auf das CMS - das fühlt sich mehr nach direktem Zugriff an. Die Armen wissen ja noch gar nicht, was auf sie zu kommt …

Die Qualitätskontrolle durch den Redakteur muss natürlich auch in einem CMS geregelt werden. Bei einer repräsentativen Website wie dem WUD ist es unerlässlich, dass die Konventionen eines gemeinsamen Auftritts eingehalten werden. Und Qualitätsmaßstäbe wie Barrierefreiheit erfordern nun mal ein besonderes Know How. Das verlangen wir nicht von jedem Autor, es genügt, wenn die Redakteure Bescheid wissen. In diesem Jahr haben wir den Ansturm mit zwei qualifizierten Redakteuren bewältigt, einer mehr wäre gut gewesen.

Der Kenntnisstand der selbst pflegenden Autoren ist ganz verschieden. Einige (5 Personen, ein Drittel) kommen mit den standardkonformen Vorlagen gut zurecht und liefern fehlerfreien, wohl strukturierten Content. Das sind die Logiker, die sich nur für die Inhalte interessieren. Die größte Mühe macht uns die Gruppe der Webdesigner, die mit ihren WYSIWYG-Techniken erfinderisch umgehen und dabei nicht nur die Konventionen der Website aufbohren, sondern auch Validität, logische Struktur und Skalierbarkeit verletzen. Da müssen wir regelmäßig nachformatieren und nachentwickeln. Einzelne (2 Personen) können es aber richtig gut und liefern das CSS gleich mit, so dass wir ein neues Format für die Musterseite haben. Dazwischen liegen die “normalen” Autoren, die sich in die Webtechniken irgendwie eingearbeitet haben und eigentlich “nur” unter unzulänglichen Editoren leiden. Da haben wir formale Mängel wie <br> statt <br />, unpassende Codierung von Sonderzeichen, gebrochene HTML-Strukturen … . Genug zu tun jedenfalls für den Redakteur, bevor er eine Seite online stellen kann.

Beeindruckend ist die Vielfalt der Inhaltsformate, die die Autoren bei freier Entfaltung hervorbringen, wie es im Moment nur mit statischen HTML-Seiten möglich ist. Zur Veranschaulichung bitte mal die Musterseite ansehen: die Zahl der Tabellenformate, der Bildvorlagen. Dabei ist es gar nicht immer so einfach, die angemessene HTML-Struktur für einen Inhalt zu finden. 2005 habe ich die 95plus-Anerkennung vermasselt, weil eine Programmtabelle mit Zwischenüberschriften dabei war, für die die Prüfer das Markup einer komplexen Tabelle einforderten. Welchen Editor hätte ich den Autoren dafür empfehlen sollen? Heute haben wir für diesen Zweck eine Definition List. Aber auch der BITV-Test ist maßvoller geworden, bei einfachen Zweispaltern darf man sogar auf die Header-Zellen verzichten ;-). Und 2006 haben wir dann 95plus geschafft, bei aller Komplexität der Inhalte.

Wenn wir jetzt also ein CMS einrichten, wird die größte Herausforderung darin bestehen, die Vielfalt der Inhaltsformate zu übernehmen, bzw. sie den Autoren in einer handhabbaren Form zugänglich zu machen. Welcher Online-Editor hat schon eine Eingabehilfe für individuelle Style-Klassen? Der BIK-Test für Editoren fragt gar nicht erst danach. Ich kenne nur Kupu für Plone, der in begrenztem Umfang die Auswahl von Styles unterstützt. Ja, Plone wird es wahrscheinlich werden, auch wegen der Vorzüge im Workflow.

Für die Autoren ist mit CMS jedenfalls die Zeit der freien Entfaltung vorbei. Klar, die Korrektur von Tippfehlern ist online einfacher. Bis wir aber ein neues Inhaltsformat ins CMS eingebaut haben, hat der Initiator schon die Lust daran verloren und sich irgendwie beholfen. Schade eigentlich. Darum genieße ich die statischen HTML-Seiten, solange wir sie haben.

Referenzen

Der Beitrag wurde am Samstag, den 3. November 2007 um 11:44 Uhr veröffentlicht und wurde unter Qualitätssicherung, CMS, Online-Redaktion, E-Publishing abgelegt. du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Einen Kommentar schreiben