Nachdem der MS Office SharePoint Server 2007 (oder kurz: MOSS) inzwischen auch in einigen deutschen Bundes- und Landesbehörden Einzug gehalten hat, rückt das Thema Barrierefreiheit nun stärker in den Vordergrund. Grund genug, das MOSS Inhalts-Editor-Webpart an dieser Stelle etwas näher zu untersuchen und dessen Möglichkeiten für die Erstellung BITV – gerechter Inhalte zu beurteilen.
Zunächst die Voraussetzungen:
Annahme A: Der Benutzer ist Willens, barrierefreie Inhalte zu erstellen. Anders hat es sowieso keinen Sinn – kein Editor kann seine Nutzer dazu zwingen, sinnvolle Linktexte zu vergeben oder aussagekräftige Alternativtexte für Grafiken bereitzustellen. Ein Editor kann seine Benutzer aber sehr wohl in ihrer Arbeit unterstützen und ihnen Mittel an die Hand geben, auf möglichst einfache Weise zugängliche Inhalte zu erzeugen.
Annahme B: Der Quelltexteditor ist tabu. Natürlich kann man seine HTML-Inhalte auch als reines Markup eingeben und auf diese Weise barrierefrei machen – an dieser Stelle soll aber ausschließlich der Rich-Text-Editor beurteilt werden.
Grafiken
Hier schlägt sich der Inhalts-Editor recht wacker. Ein Alternativtext kann angegeben werden, die grundlegende Voraussetzung ist also schonmal erfüllt. Die Länge des Inhaltes ist zwar statt 80 Zeichen (Empfehlung der BITV) auf 130 Zeichen begrenzt – aber ob das nun gut oder schlecht ist, ist Ansichtssache. Pflichtfeld ist der Alternativtext nicht. Auch hier gilt jedoch: wir gehen davon aus, dass der Benutzer barrierefrei arbeiten will. Selbst wenn der Alternativtext Pflicht wäre – kein Automatismus kann beurteilen, ob der eingegebene Text aussagekräftig ist und z.B. bei einem Foto dessen Inhalt, bei einem Symbol jedoch dessen Aussage wiedergibt. Felder für eine ausführliche Beschreibung (Attribut longdesc) oder einen Titel (Attribut title) existieren nicht – diese werden von der BITV aber auch nicht vorgeschrieben.
Inhaltstabellen
Tabellen sind ja ein durchaus streitwertiges Thema – wann nimmt man z.B. für Überschriften th oder td und ab wann benötigt man scope oder id. Der MOSS Editor reduziert das Thema praktischerweise auf ein Minimum: er kann einfach gar nichts davon.
Dass ältere Rich-Text-Editoren kein scope und id beherrschen, ist ja irgendwo noch nachvollziehbar. Aber dass man eine Tabellenzeile nicht mit th korrekt als Überschrift deklarieren kann (BITV Priorität 1), ist schon bitter. Daher muss man leider sagen, dass mit dem Inhalts-Editor Webpart von MOSS keine BITV-tauglichen Tabellen erstellt werden können. Einziger positiver Aspekt: eine Beschreibung der Tabelle kann als summary angegeben werden – das reißt es allerdings auch nicht mehr raus.
Wäre noch interessant herauszufinden, wie viel Aufwand es bedeuten würde, das bestehende Tabellentool z.B. den Tabelleneditor von TinyMCE einzubinden. Aber dazu später mehr.
Links
Hier sieht der MOSS Editor gar nicht mal schlecht aus. Ok, es gibt auch nicht viel falsch zu machen, die Hauptarbeit ist ja von den Inhaltsautoren zu leisten. Hier können jedenfalls ein title sowie ein Dateiformat angegeben werden – BITV Priorität 1 steht also nichts im Wege.
Textauszeichnung
… sollte theoretisch auf ein Minimum beschränkt sein, Stichwort: Trennung von Inhalt und Layout. Trotzdem werden in Rich-Text-Editoren natürlich Textformatierungen angeboten. Das macht der MOSS Editor meiner Ansicht nach leidlich passabel. Zunächst das Positive: er verwendet strong und em statt b und i und bietet das automatische Entfernen von Inline-Formatvorlagen an. Verschiedene Listen (Nummerierungs-, Aufzählungs-, Definitions-, Verzeichnis-, Menülisten) werden sauber formatiert. Im Vergleich mit dem TinyMCE wird dann aber deutlich, was dem MOSS Editor fehlt um als barrierefreies Werkzeug durchgehen zu können. Am meisten vermisse ich dabei die Auszeichnung von Zitaten, anderssprachigen Wörtern und Absätzen sowie von Abkürzungen und Akronymen. Ebenfalls negativ: für den Texteinzug wird blockquote verwendet und es werden mitunter veraltete Elemente (z.B. font) und Attribute (z.B. align, u) verwendet.
Validität
Gemäß BITV Punkt 3.2 sind „Mittels Markup-Sprachen geschaffene Dokumente […] so zu erstellen und zu deklarieren, dass sie gegen veröffentliche formale Grammatiken validieren“ (Anm. des Autors: der Schreibfehler in „veröffentliche“ ist unverändert aus dem Juris-Text übernommen). Der entsprechende Prüfschritt gilt als erfüllt, wenn das Ergebnis des W3C-Validators für das getestete Dokument positiv ist.
Meiner Ansicht nach ist es dabei unerheblich, ob man sein Dokument als XHTML oder z.B. als HTML Transitional auszeichnet und entsprechend validiert. Gehen wir also vom einfachen Fall – HTML 4.01 Transitional – aus.
Bei einfachen Dokumenten, die nur aus Text mit ein paar Grafiken und Formatierungen bestehen, erzeugt der MOSS Editor durchaus valides HTML. Bei komplexeren Dokumenten oder zahlreichen „Bearbeitungen“, also Ausschneiden, Löschen, Kopieren usw., schleichen sich dann allerdings Fehler ein. Es kann dann z.B. passieren, dass eine Tabelle in eine nicht mehr existenten Liste eingefügt wird, weil der Editor beim entfernen der Liste zwar deren Inhalte gelöscht hat, nicht aber die öffnenden und schließenden Listentags. Damit besteht das Dokument den W3C-Test nicht mehr.
Fazit
Das MOSS Inhalts-Editor-Webpart bietet meiner Ansicht nach eine solide Grundlage, um einfach strukturierte Inhalte mit Texten, Bildern und Aufzählungen korrekt auszuzeichnen und zugänglich darzustellen. Kleinere Mängel, wie die mitunter veralteten Attribute, sind dabei – auch gemäß der BITV – zu verschmerzen.
Sollen jedoch komplexere Inhalte erstellt werden, kommt der Editor schnell an seine Grenzen. Als Stichworte seien dabei nochmal die fehlende Auszeichnung von Tabellenüberschriften, Zitaten, Abkürzungen und Sprachwechseln genannt, sowie der schnell invalid werdende HTML-Quellcode. Um also komplexe und trotzdem zugängliche Inhalte erstellen zu können, sind entweder Anpassungen am Editor selbst, oder Alternativen für den Editor notwendig. Dafür sehe ich bisher die folgenden Optionen:
Alternative 1: nachträgliches Validieren
Der vom Inhalts-Editor erzeugte Quellcode kann nachträglich auf seine Validität geparst werden. Dafür existieren bereits verschiedene Ansätze:
- Das Accessibility Kit for Sharepoint (AKS) bringt die „Compliant Code Engine“ mit. Diese wird als Feature in MOSS installiert und validiert den kompletten Quellcode, bevor dieser an den Nutzer gesendet wird. Aber Achtung: die Engine funktioniert nur mit WCM/ECM Seiten.
- Das ARF-Framework beinhaltet mit dem „compatibility panel“ einen Container für MOSS-Controls, der den von Controls ausgegebenen HTML-Code nachträglich validiert.
Alternative 2: Einbinden eines anderen Editors
Warum das Rad neu erfinden, wenn mit dem TinyMCE und dem FCKEditor bereits exzellente Rich-Text Editoren zur Verfügung stehen. Eine Lösung könnte also darin bestehen, denn MOSS Editor durch einen der beiden genannten Editoren zu ersetzen. Dafür existieren bereits Anleitungen. Problematisch – und für den Behördeneinsatz leider ausschlaggebend – ist dabei allerdings der Umstand, dass der TinyMCE / FCKEditor dann nur für nicht-Internet-Explorer-Nutzer angezeigt wird. Im Internet Explorer wird weiterhin der MOSS-Editor verwendet.
Meiner Meinung nach muss der MOSS-Editor aber auch nicht ersetzt werden. Es reicht völlig, wenn der TinyMCE oder FCKEditor als barrierefreie Alternative angeboten bzw. in entsprechende Templates eingebunden wird.