Für einen ausführlichen manuellen Test verwende ich dabei den BITV-Selbsttest des BIK-Projektes. Mit seinem exzellenten Verzeichnis der Prüfschritte wird man Schritt für Schritt durch den Test geführt und angeleitet. Auf diese Weise lässt sich ein sehr ausführliches und je nach persönlicher Erfahrung des Testenden auch stichhaltiges Ergebnis erzielen.

Die persönliche Erfahrung habe ich an dieser Stelle mit erwähnt, da ein solcher Test immer auch subjektive Elemente beinhaltet. Wann ist z.B. die textuelle Beschreibung eines Bildes “sinnvoll”? Welche anderssprachigen Wörter müssen als solche gekennzeichnet werden? Ist ein Linktext aussagekräftig oder nicht? Der BITV-Test unterstützt einen bei der Beantwortung dieser Fragen ausgezeichnet und erläutert z.B. für jedes Kriterium, was genau getestet wird, warum es getestet wird und wie getestet wird.

Als große Hilfe bei der Durchführung eines solchen Tests haben sich auch Online-Testverfahren bzw. Web Accessibility Tools erwiesen. Inzwischen gibt es eine so große Vielfalt davon, dass sich für jeden Geschmack und jedes Kriterium das passende Werkzeug finden lässt. Mein Favorit ist derzeit das Truwex Web Accessibility Testing Tool. Nicht nur lassen sich alle WCAG 1.0 und Section 508 - Kriterien testen, sondern auch Sicherheitsaspekte (z.B. Test auf Third-Party-Cookies) sowie die generelle Qualität der Webseite (z.B. Metainformationen, ungültige Links oder Scriptfehler) werden überprüft. Außerdem ist dieser Test einer der wenigen, mit dem explizit auch die BITV-Kriterien getestet werden können. Der eigentlich Clou ist für mich aber die Auswertung. Die Liste mit gefundenen Fehlern ist übersichtlich und beschreibt sehr gut, warum es sich um einen Fehler handelt . Einzig die Angabe der entsprechenden Zeile im Seitenquelltext würde ich mir hier noch wünschen. Dafür steht allerdings die sogenannte “Map” zur Verfügung. Dabei wird die getestete Seite zusammen mit der Fehlerliste dargestellt und jeder Fehler mit einem Pfeil markiert.

Ein ebenfalls sehr bekannter Online-Test ist das Cynthia Portal von HiSoftware - die Firma wird dem ein oder anderen vielleicht durch das Accessibility Kit for Sharepoint bekannt vorkommen. Der Test umfasst die WCAG 1.0 sowie die Section 508. Die Auswertung ist schlicht, aber im großen und ganzen übersichtlich. Für jeden gefundenen Fehler wird die entsprechende Zeile im Quelltext angezeigt. Ergänzende Erläuterungen oder Hinweise fehlen hier leider, man erählt einfach eine Liste mit allen zu beanstandenden Inhalten.

Eines der wenigen Tools, die bereits auf WCAG 2.0 - Kriterien testen, ist der ATRC Web Accessibility Checker. Die Auswertung ist zwar ebenfalls eher schlicht, aber zweckdienlich. Bei Fehlern werden sowohl die entsprechende Zeile im Quelltext angegeben als auch der passende Abschnitt dargestellt. Zudem wird - wo möglich - ein Vorschlag gemacht, wie das Problem zu beheben ist.

Ein weiteres hilfreiches Tool ist das bereits vor einigen Monaten vorgestellte Bookmarklet YAML Debug. Es testet auf fehlende bzw. leere Alt - Attribute und auf die Verwendung von Inline Styles. Außerdem stellt es die semantische- sowie die Layoutstruktur der Seite dar. Gerade für den Test der eigenen Seite ein wunderbares Tool, vergleichbar auch mit dem Quick Accessibility Page Tester.

Ursprünglich wollte ich an dieser Stelle noch auf  Tools zur Analyse von Farbkontrasten eingehen, aber aufgrund der Länge des Artikels gliedere ich das einfach mal in einen extra Beitrag aus.

Mich hat allerdings überrascht, dass die 4 Befragten anscheinend keine großen Probleme im Umgang mit Web 2.0 - Inhalten haben. In der Screenreader-Umfrage von WebAIM im vergangenen Jahr konnten noch 54% der Befragten keine Aussage über die Zugänglichkeit des Web 2.0 machen. Schön, dass sich da etwas zu ändern scheint - immerhin gibt es auch schon blinde Blogger.

Alles in Allem ein äußerst lesenswertes Interview, nicht nur für Webdesigner oder Accessibility-Experten.

• einen Private Browsing Modus, bekannt vom IE, Chrome und Safari,
• partielles Löschen der History,
• Wiederherstellen der zuletzt geschlossenen Tabs (diese Funktion gibts in 3.0.11 allerdings auch schon?),
• Unterstützung des <video> und <audio> Tags von HTML 5,
• automatischen Download der im CSS angegebenen Fonts und
• Location-Aware Browsing.

Nach dem Gespräch mit den Firefox Leuten auf der Cebit war mir zwar eigentlich klar, dass außer besserer HTML-5 und CSS-3 Unterstützung in nächster Zeit nicht viel passieren wird. So richtig umwerfend finde ich die Neuerungen aber trotzdem nicht.

Der “Private Browsing Modus” musste nach IE und Chrome irgendwann auch im FF nachgezogen werden, wobei Google als Hauptsponsor von Mozilla da sicher nicht ganz einverstanden war. Für die Tabverwaltung gibts zwar schon TabMixPlus und vermutlich noch 100 andere AddOns, aber eine bessere interne Sitzungsverwaltung kann prinzipiell nicht schaden. Wobei das Wiederherstellen geschlossener Tabs wie gesagt auch schon in 3.0.11 funktioniert - bei mir zumindest.

Das Location-Aware Browsing finde ich dagegen sehr spannend. Es arbeitet zwar mit den Google Location Services - mit was auch sonst, siehe Google als Hauptsponsor von Mozilla -, aber damit können wirklich sinnvolle Sachen angestellt werden. Der Busfahrplan weiß schon, wo ich mich gerade befinde, der Routenplaner und die Restaurantbuchung auf meinen Wunsch hin genauso. Praktisch einsetzbar dürfte es allerdings nur mit der Einbeziehung von WLAN-Netzen o.ä. werden, denn die IP allein reicht für eine sinnvolle Ortserkennung nicht aus. Dabei muss sich aber sowieso noch zeigen, ob ein solcher Service für die Dienstanbieter überhaupt interessant ist.

Ich bin wirklich gespannt, unter welchen Bedingungen sich Firmen bereit erklären werden, ihre Daten im Netz und insbesondere bei Google zu speichern. Ausgerechnet bei demjenigen globalen Data-Mining Unternehmen, dem das halbe Netz gehört und das mit Chrome einen pseudo-Open-Source Browser auf den Markt geworfen hat. Dem Unternehmen, dem alle Welt - bewusst oder unbewusst - seine persönlichen Daten zur freien Auswertung und Verknüpfung hinterherwirft.

Man kann wohl davon ausgehen, dass sich Firmenkunden mit Geschäftsbedingungen und Datenschutzrichtlinien auseinandersetzen werden, bevor sie ihre Daten einem fremden Unternehmen anvertrauen. Bleibt also abzuwarten, wie Google mit diesen neuen Anforderungen umgehen wird.

Die insgesamt 94 Prüfschritte basieren auf 7 Prinzipien:

• Verständlichkeit,
• Wahrnehmbarkeit,
• Bedienbarkeit,
• Orientierung,
• Nachhaltige Nutzbarkeit,
• Inhaltliche Relevanz und Integration,
• Design.

Eigentlich wollte ich an dieser Stelle die neue und die alte Version der Prüfkriterien miteinander vergleichen und auf Verbesserungen eingehen. Nach einem kurzem Studium der neuen Kriterien bin ich allerdings etwas verwirrt. Auf der Webseite des Awards steht geschrieben:

Der Fachliche Beirat des Wettbewerbs und die Veranstalter haben das Testverfahren nach Abschluss des Wettbewerbs 2008 vollständig überarbeitet. Insbesondere Kriterien und Prüfschritte, die nicht mehr dem aktuellen Stand der technischen Entwicklung entsprachen, wurden entweder aktualisiert oder aus dem Kriterienkatalog entfernt.

In Erwartung auf einen überarbeiteten und der WCAG 2.0 angepassten Kriterienkatalog habe ich also (unter Zuhilfenahme von DiffDaff, einem Programm mit dem man Textdateien direkt gegenüberstellen kann) die Version von 2008 mit der Version von 2009 verglichen. Von einer “vollständigen Überarbeitung” konnte ich dabei absolut nichts erkennen. Meiner Zählung nach wurden gerade einmal 4 Unterkriterien neu eingeführt:

• Lesbarkeit der Textinhalte bei ausgeschalteten Hintergrundgrafiken,
• Vermeidung von langen Aufzählungen in Sätzen,
• Unmittelbare Zuordnung der Bilder, Illustrationen etc. zu dem zu erklärenden Inhalt,
• Einfache und intuitive Handhabung erklärender Videos und Audiodateien.

Entfernt wurde kein einziges Kriterium (?). Ich will damit natürlich nicht sagen, dass die Kriterien von 2008 schlecht wären. Im Gegenteil, im Vergleich zur damaligen WCAG 1.0 waren sie bereits wesentlich technikunabhängiger und offener formuliert. Trotzdem finde ich es etwas befremdlich, wenn auf der BIENE-Webseite und in Blogs von einer “vollständigen Überarbeitung” gesprochen wird, owohl sich quasi nichts geändert hat. Alles was ich an Überarbeitung erkennen konnte, waren zumeist geringfügige Änderungen der Formulierung und die 4 erwähnten neuen Kriterien.

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

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

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.

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.

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.