Knowledge Management Blog

Das von SPWorks entwickelte Open Source Projekt “Alternative Rendering Framework for SharePoint” hat sich das Ziel der Erstellung AA-konformer Publishing Sites mit MOSS und WSS 3.0 gesetzt. Einmal installiert, kann das Feature auf Site-Collection Ebene aktiviert werden und erzeugt einige neue Listen sowie Website-Spalten.

Features

• Die ARF-Controls erzeugen ausschließlich XML, welches mit XSLT in den gewünschten HTML-Code umgewandelt werden kann. Dadurch können Inhalt und Layout weitestgehend voneinander getrennt werden. Einige XSLT-Stylesheets werden bereits mitgeliefert, diese können problemlos durch eigene Stylesheets erweitert oder ersetzt werden.
• Jegliches HTML wird über XSLT oder standardmäßige ASP.Net Template Controls erzeugt.
• Über sogenannte “CompatibilityPanel-Container” kann das von Standardcontrols erzeugte HTML nachträglich von invaliden Tags und Attributen gesäubert und insgesamt W3C-konform validiert werden.
• Prüft, ob von Autoren erzeugtes HTML valides XHTML ist.
• Es werden über 30 (!) eigene Controls mitgeliefert, u.a. für Navigation, Suche, Abfragen, RSS-Feeds und Kalender.

Das ARF hebt sich durch seinen Ansatz der vollständigen Trennung von Inhalt und Layout über XML und XSLT deutlich von anderen Lösungen ab. Durch die Vielzahl der mitgelieferten Controls kann ein großer Teil der Standardfunktionalität nachgebildet werden, ohne dabei invaliden Code zu erhalten. Eine Masterpage ist allerdings (noch?) nicht enthalten. Hierfür muss man also entweder auf die “Minimal Master Page” von Microsoft zurückgreifen oder die alternative Masterpage von Heather Solomon verwenden.

Auch beim ARF ist das standardmäßige HTML-Content Control ein kritischer Punkt. Zwar korrigiert das ARF auf Wunsch invalides, von MOSS-Controls produziertes HTML. Trotzdem ist die korrekte Auszeichnung eines Tabellenkopfes, eines Zitates oder eines Sprachwechsels weiterhin nicht möglich. Auch bei Verwendung des ARF sollte also ein alternativer HTML-Editor in Betracht  gezogen werden. Dokumentationstechnisch exisitert für das ARF ein Support-Forum, ein Blog des verantwortlichen Entwicklers Vincent Rothwell sowie eine (im Aufbau befindliche und mit MOSS und dem ARF umgesetzte) Test- und Dokumentationsseite.

Zusammengefasst verfolgt das ARF für mich den saubersten und geradlinigsten Ansatz aller Barrierefrei-Lösungen für SharePoint. Zwar ist auch hier eine ganze Menge Eigenarbeit für die Installation und Konfiguration der Controls sowie für die Anpassung der Masterpage und die eigentliche Erstellung der Inhalte vonnöten. Wenn aber der eingeschlagene Weg konsequent verfolgt und auf zugängliche Auszeichnung der Inhalte geachtet wird, können unter Zuhilfenahme des ARF und eines alternativen HTML-Editors barrierefreie Webseiten mit MOSS erstellt werden.

Mögliche Alternativen:

BKS - Barrierefrei-Kit for SharePoint

AKS - Accessibility Kit for SharePoint

Das “Barrierefrei-Kit for Sharepoint” ist ein quelloffenes Codeplex-Projekt und wurde von 1eEurope in Zusammenarbeit mit Microsoft entwickelt. Es beinhaltet eine Sharepoint Solution, die bei der Erstellung  AA-konformer WCM-Seiten unterstützen kann.

Features

• Die standardmäßigen WebPart-Zonen werden durch UserControl-Zonen ersetzt. Diese beinhalten keine verschachtelten Tabellen und keine statischen <header> Elemente mehr.
• Bilder können mit einem LONGDESC-Attribut versehen werden.
• Es werden eine Masterpage und verschiedene PageLayouts mitgeliefert. Die Layouts beinhalten u.a. Controls mit einer angepasste Suche, Breadcrumbs, Buttons für das Ändern der Textgröße (JavaScript) sowie Links für den Wechsel der Sprache (Variations).
• Ein zusätzliches Navigation-Control stellt einen anpassbaren Hierarchiebaum zur Verfügung, dem eine Datenquelle sowie ein XSLT zugewiesen werden kann. Zusammen mit den Breadcrumbs wird dadurch eine saubere Navigation ermöglicht.

Die mitgelieferten Controls sind sinnvoll, aber leider sind zu wenige davon vorhanden. Auch die Dokumentation von 1eEurope lässt eher zu wünschen übrig. Dafür wurden die Webseiten mit MOSS und dem BKS entwickelt und können als Testobjekt unter die Lupe genommen werden.

Positiv ist weiterhin anzumerken, dass die mitgelieferten Controls mit XSLT arbeiten und dass mit dem BKS zumindest ein barriere”armes” Grundgerüst für Publishing Sites erstellt werden kann. Auf barriere”frei” im Sinne von “AA-konform” würde ich mich an dieser Stelle eher nicht festlegen, da keine Lösung für den barrierebehafteten HTML-Code des standardmäßigen HTML-Content Controls angeboten wird. Wenn man aber das BKS verwendet und zusätzlich das HTML-Content Control durch den TinyMCE oder den FCKEditor ersetzt, ist man dem Ziel einer AA-konformen Seite schon ein ganzes Stück näher gekommen. Insgesamt ist das BKS meiner Meinung nach also eine sinnvolle Lösung.

Mögliche Alternativen:

ARF - Alternative Rendering Framework for SharePoint

AKS - Accessibility Kit for SharePoint

Installation

Der Office-Connector ist kostenlos verfügbar und ab Confluence Version 2.10 standardmäßig bereits vorinstalliert. In älteren Versionen kann der Connector über das Plugin Repository nachträglich installiert werden. Auf dem Confluence Server muss JDK 1.5 oder höher installiert sein und im System muss das WebDAV  Plugin installiert und aktiviert sein. In der allgemeinen Konfiguration muss die Basis-URL von Confluence korrekt eingestellt sein.

Features

Bearbeiten von Wikiseiten in Microsoft Word und Open Office: über einen Link im Werzeug-Menü wird die aktuelle Wikiseite in Word geöffnet und kann dort bearbeitet werden. Die Änderungen werden in Confluence übertragen und dort als neue Version der Wikiseite gespeichert. Das gleiche funktioniert übrigens im Firefox auch mit Open Office: mit Hilfe des Firefox-Plugins “WebDAV Launcher” (siehe “Achtung”) kann man sich aussuchen, mit welchem Programm man welchen Dokumenttyp öffnen möchte.

Achtung:

• Der Link zum Bearbeiten mit Office ist standardmäßig deaktiviert. Das entsprechende Plugin-Modul muss erst von einem Systemadministrator aktiviert werden.
• In Firefox muss zunächst der WebDAV Launcher installiert werden. Wenn man in Confluence den Office-Bearbeiten Link das erste mal aufruft, erscheint eine entsprechende Hinweismeldung der man folgen muss.
• Im Internet Explorer wird immer Microsoft Office geöffnet.
• Auf dem Rechner, auf dem man die Wikiseite bearbeiten möchte, muss natürlich - je nach verwendetem Browser und Betriebssystem - Microsoft Office, Open Office oder NeoOffice installiert sein.

Einbetten von Office-Inhalten in Confluence: Word-, Excel- , PDF- oder PowerPoint-Dokumente (.doc, .xls, .pdf, .ppt) können in Wikiseiten eingebunden werden. Dafür muss das entsprechende Dokument als Anhang an die Wikiseite angefügt und dann über {viewfile:myDocument.ext} bzw. {Attachments} eingebettet werden. Derartig eingebundene Dokumente können durch einen Klick in die Titelleiste (dort steht der Dateiname des Dokumentes) direkt in Office geöffnet, bearbeitet und zurückgespeichert werden.

Achtung:

• Die Anzeige von eingebetteten Office-Dokumenten funktioniert mit jedem Browser, der den Flash Player ab Version 9 installiert hat.
• Ein Officeprogramm muss auf dem anzeigenden Rechner nicht installiert sein.

Importieren eines Office-Dokumentes in Confluence: im Werkzeugmenü findet sich ebenfalls ein Link für das Importieren von Word-Dokumenten (.doc) in Wikiseiten. Im einfachsten Fall sucht man sich ein Dokument aus und ersetzt den Inhalt der aktuell geöffneten Wikiseite komplett mit dem Inhalt dieses Dokumentes.

Ein paar wichtige Funktionen für den Import sind im Tab “Advanced” zu finden. Hier kann man u.a. wählen:

• ob bei einem Namenskonflikt das importierte Dokument die gleichnamige Wikiseite als neue Version ersetzen soll, die neue Seite einen anderen Namen erhalten soll oder die bestehende Seite unter Verlust der Historie komplett gelöscht werden soll, sowie
• ob das importierte Dokument anhand seiner Überschriftenstruktur auf mehrere Wikiseiten aufgeteilt werden soll.

Einschränkungen

Wenn man in Confluence mit Office-Dokumenten arbeiten möchte, sollte man sich gewisser Einschränkungen bewusst sein. Unter anderem kann Confluence nicht mit verschachtelten Tabellen umgehen, der Texteinzug von Word-Dokumenten geht verloren und in Word werden die Makros einer Wikiseite als Wikiquelltext dargestellt. Ein Liste aller weiteren Einschränkungen und offenen Probleme findet sich auf den Hilfeseiten von Atlassian.

Ein leider wenig bekanntes Feature von MOSS 2007  ist der “More Accessible Mode”. Wird diese Option aktiviert, werden einige Oberflächenelemente durch zugänglichere Alternativen ersetzt. Das Menü für Websiteaktionen, das persönliche Menü sowie das Hyperlinkmenü werden dann nicht mehr als Drop-Down Menü angezeigt. Stattdessen öffnet sich bei Mausklick ein neues Fenster mit einer Listenansicht der zur Verfügung stehenden Optionen. Löblicherweise wird der Benutzer im Linktext sogar darüber informiert, dass statt dem Menü ein neues Browserfenster geöffnet wird.
Zudem werden einige Listenfelder durch einfachere Alternativen ersetzt. Folgende Tabelle zeigt die Standardfelder und ihre Entsprechung im More Accessible Mode.

Der Modus wird aktiviert, indem man auf einer beliebigen MOSS-Seite den Tastaturfokus mit der Tabulator-Taste (oder Shift + Tabulator-Taste) solange springen lässt, bis man ganz am Anfang der Seite angelangt ist. Das erste auf jeder Seite anzuwählende Element ist ein Link zum More Accessible Mode, der nur dann sichtbar wird, wenn der Tastaturfokus auf ihm liegt.

Die c’t beschreibt in ihrem aktuellen Artikel “Verschleierungstaktik - Die Argumente für Kinderporno-Sperren laufen ins Leere”, wie abwegig die Argumente unserer Bundesfamilienministerin Ursula von der Leyen für eine Internetzensur sind.

Der derzeitige Gesetzesentwurf sieht vor, kinderpornografische Seiten mittels einer DNS-Sperre zu blockieren. Die Inhalte werden also nicht etwa gelöscht, nein, es wird schlicht die Auflösung der URL zu einer IP-Adresse unterbunden. Alle Seiten, die auf diese Weise indiziert werden, sind dann also nicht mehr unter ihrer normalen URL erreichbar. Das Widersinnige dabei: die Seiten können trotzdem über ihre IP aufgerufen werden. Wer also nur ein Minimum an Recherche tätigt und sich z.B. in einschlägigen Foren schlau macht, wird nach wie vor problemlos an derartige Inhalte gelangen können. Selbst wenn man mal davon absieht, dass (laut “Lawblog“-Rechtsanwalt Udo Vetter) die eigentlich Kinderporno-Szene gar nicht im freien Web, sondern in Tauschbörsen, im Usenet und durch Postversand stattfindet, bleibt der echte Nutzen dieser Zensurliste für die Bekämpfung von Kinderporografie also mehr als fraglich.

Gleichzeitig wird dem BKA - dieses soll für die Sperrliste verantwortlich sein - eine Blankovollmacht für das Sperren “beliebiger” Internetseiten ausgestellt. Wenn nun also irgendwann auch politische Seiten oder der Schutz geistigen Eigentums in den Blickpunkt “gesellschaftlich gewünschter Regulierung” (Dieter Gorny) geraten, könnten diese ohne weiteres Federlesen für den Normalsurfer aus dem Netz entfernt werden. “Praktisch” scheint dabei auch zu sein, dass die Liste geheim bleiben muss, da sie ja kinderpornografische Links enthält. Es werden also weder Journalisten noch Verbraucherschützer oder Anwälte eine Möglichkeit haben, einzusehen, welche Seiten denn nun eigentlich auf dem Index stehen.

Auch wenn auf deutsche Staatsorgane (hoffentlich) zumeist Verlass ist, hat sich gerade das BKA anscheinend nicht immer als “Freund und Helfer” für den deutschen Bürger dargestellt. Auf diesen Gedanken kann man zumindest kommen, wenn man den Artikeln Glauben schenkt, in denen behauptet wird, dass das BKA in den 70er Jahren Anschläge geplant und in einem aktuellen Verfahren Beweise gefälscht haben soll.

Wenn sich das ehrbare Ziel der Bekämpfung von Kinderpornografie also tatsächlich nur als Deckmäntelchen für eine politische Zensur des Internets herausstellen sollte… dann haben wir in Deutschland wenigstens mal irgendetwas, in dem wir sogar den Chinesen voraus sind.