Dynamische Inhalte werden im Internet immer bedeutsamer, nicht zuletzt durch das rasante Wachstum der Blogger-Gemeinde, die zur noch rasanteren Verbreitung von RSS beiträgt. Wir hören häufig die Frage, worin denn nun der Nutzen von RSS liegt beziehungsweise was es eigentlich ist. Diese Fragen haben wir hier bereits beantwortet. Kurz gesagt: RSS ist ein XML-Dialekt und als solches ein Standard zur Erstellung strukturierter, maschinen- und menschenlesbarer Dateien, also gewissermaßen der Grundgedanke hinter barrierefreiem Internet, der Trennung von Inhalt und Layout. Das aber bringt hinsichtlich der BITV auch Probleme mit sich.

Gar nicht so einfach für alle

Die BITV macht es Entwicklern von Internetseiten nicht immer einfach. Sie macht es sogar manchmal richtig schwierig. Vor allem immer dann, wenn eigentlich andere in der Pflicht wären, ihren Teil zur Barrierefreiheit beizusteuern. Konkret geht es um die Barrierefreiheit von XML-Streams, wie wir sie mit unserem RSS-Feed zu aktuellen Meldungen des Barrierekompass anbieten. Eben jener Link ist für Browser ohne XML-Unterstützung nicht zu verarbeiten, bringt im besten Fall eine Fehlermeldung und im schlimmsten Fall gar keine Rückmeldung.

Die BITV umschreibt es in Bedingung 3.3 etwas abstrakter: "Es sind Style Sheets zu verwenden, um die Text und Bildgestaltung sowie die Präsentation von mittels MarkupSprachen geschaffener Dokumente zu beeinflussen."

In Priorität II der BITV ist zudem noch Bedingung 14.3 beachtenswert, die besagt, dass der gewählte Präsentationsstil durchgängig beizubehalten ist. Soweit also die Theorie zur Darstellung. Was aber, wenn die eingesetzte Technik, hier also XML, von diversen User-Agents nicht unterstützt wird? Muss dann der Webdesigner dafür Sorge tragen, dass diese Scharte ausgewetzt wird? Klare Antwort: nach BITV muss er, denn von User-Agents ist hier nicht die Rede. Die UAAG bleiben ebenso außen vor, wie die ATAG.

Schöner surfen mit Firefox

Firefox und Internet Explorer 6 machen es richtig. Manchmal sogar schon der Explorer 5, wenn der entsprechende XML-Parser zur Verarbeitung von XML-Dateien im Betriebssystem installiert ist. Opera zeigt sich halbwegs kooperativ: XML-Dateien können als Nur-Text angezeigt werden, wobei der Strukturbaum jedoch in seine Bestandteile zerfällt, eine XSL-Formatierung ist aber nicht möglich.

XSL - was ist das schon wieder?

Mit XSL lassen sich XML-Dateien gestalten - auch wenn das eine charmante Untertreibung ist, sie muss hier ausreichen. Weist man einer XML-Datei eine XSL-Datei zu, passiert so etwas, wie bei den Kollegen von Einfach für Alle geschildert, nicht:

Ohne Style Sheets ist das Dokument nicht verwendbar, da der rohe Quelltext dargestellt wird: This XML file does not appear to have any style information associated with it. The document tree is shown below.

Im Idealfall erhält man eine Ansicht der angebotenen Inhalte, sprich der Daten in der XML-Datei, im Layout der Seite, auf der man sich gerade befindet. Mit modernen Browsern sollte das kein Problem sein, Opera an dieser Stelle einmal ausgenommen. Deshalb lautet unsere Empfehlung erneut Firefox, dann klappt's auch mit der BITV.

Schöner surfen für alle

Was aber, wenn man keinen Firefox nutzt? Oder gar mit einem gänzlich anderen Ausgabegerät auf die Internetseite zugreift? Jetzt müsste man wissen, ob das entsprechende Ausgabegerät über einen XML-Parser verfügt, der die verlinkte XML-Datei verarbeiten kann. Unglücklicherweise lässt sich das nicht so einfach prüfen, denn dazu müsste man dem Benutzer in die Konfiguration gucken, sprich mit JavaScript arbeiten. Was aber, wenn kein JavaScript aktiviert ist? Ein gleichwertiges Fallback ist nicht möglich, die BITV an dieser Stelle augehebelt.

Besser ist es dann, wenn man PHP auf seinem Server installiert hat. Dann kann man die Sache ohne JavaScript in den Griff bekommen. Ohne viel Aufwand. Browser, die XML und XSL verstehen, bekommen dann die entsprechende Variante mit XML zu sehen. Alle anderen Ausgabegeräte erhalten eine geparste Version der Seite, sprich eine für alle verständliche barrierefreie HTML-Version. Für diese Lösung benötigt man eventuell gleich zwei Dinge:

• eine XML-Erkennung für Ausgabegeräte (Sniffer)

• einen XML-Parser

Beides natürlich für PHP. Der Vorteil von PHP: es ist auf nahezu allen Betriebssystemen und Servertypen lauffähig, wird zur Laufzeit ausgeführt und ist in der Regel mit anderen Systemen gut verträglich. Überdies ist es kostenlos.

Praktische Umsetzung

Was im Einzelnen zu tun ist, das steht in den Installations- und Nutzungshinweisen der einzelnen Scripte. Im Prinzip handelt es sich nur um Zusatzfunktionen, auf die andere Tools zugreifen können. Alleine und für sich genommen ist zumindest die XML-Erkennung wertlos. Sie wird erst durch den konkreten Anwendungsfall zur Entfaltung gebracht und mit Leben gefüllt.

Eingebunden in eine PHP-Website funktioniert der XML-Sniffer dann in zweierlei Hinsicht: Als erstes erkennt er, welcher User-Agent genutzt wird (Browser-Sniffer). In einer internen Tabelle schaut er dann nach, welche Funktionen dieser Browser unterstützt, dazu gehört unter anderem auch die Unterstützung von XML oder CSS2. Dieses Ergebnis (xml=true) liefert das Script nun als Variable zurück. Man weiß nun also zum Einen, um welchen User-Agent es sich handelt und zum Anderen, welche Funktionen dieser unterstützt. Damit kann man eine einfache XML-Weiche konstruieren, die zwar nach dem schwarz-weiß Schubladenprinzip arbeitet, dafür aber in den meisten Fällen zuverlässige Ergebnisse liefert.

Die Guten ins Töpfchen ...

Unterstützt ein User-Agent XML und XSL, dann kann man ihm eine mit XSL formatierte XML-Datei unterschieben. Hierzu ist lediglich eine simple Wenn-Dann-Abfrage notwendig, keine große Programmierkunst also. Die Frage der XSL-Formatierung steht dann auf einem anderen Blatt, verlangt etwas Einarbeitung, ist aber alles in allem lösbar.

... die Schlechten ins andere Töpfchen

Ein User-Agent, der kein XML unterstützt, hätte in der Regel das Nachsehen. Beispielsweise erhält man im Internet Explorer 4 beim Aufruf einer XML-Datei den Hinweis:

Die XML-Seite kann nicht angezeigt werden. Die XML-Eingabe kann nicht angezeigt werden, wenn Stylesheet verwendet wird. Beheben Sie den Fehler und klicken Sie dann auf Aktualisieren, oder wiederholen Sie den Vorgang später. Zugriff verweigert.

Über das PISA-Studien erprobte Deutsch in der Fehlermeldung kann man sich später aufregen, hier geht es nur um die XML-Inhalte, nicht aber um einfache Sprache.

Ähnlichen Probleme haben Benutzer von Lynx oder aber mobile Surfer, die ihr Handy zur Online-Recherche nutzen. Wer arglos einem Link auf eine XML-Datei folgt, erhält also bisher eine Fehlermeldung. Da braucht man nicht erst eine BITV, um nach einer Lösung zu suchen. Bleiben wir also bei unserer XML-Weiche, also der Wenn-Dann-Abfrage, wie wir sie zuvor geschildert haben. Wenn das Kriterium nicht erfüllt ist, kann man eine Alternativ-Variante ausgeben. Man erweitert das Konstrukt in diesem Fall zu einem Wenn-Dann-Sonst. Wenn XML unterstützt wird, geben wir XML und XSL aus. Sonst, sprich XML wird nicht unterstützt, geben wir HTML aus. Nein, wir bauen keine gesonderte Alternativ-Version, sondern wir nutzen das bereits vorhandene Website-Layout samt CSS-Formatierungen zur Ausgabe. Wer ein Content Management System sein Eigen nennt, spart an dieser Stelle vielleicht etwas Aufwand, ebenso alle anderen Nutzer von Template basierten Systemen.

XML-Inhalte als HTML ausgeben

Damit die Inhalte als Alternativ-Version ausgegeben werden können, benötigt man einen XML-Parser. Hierfür gibt es eine Vielzahl von Möglichkeiten, von der eigens programmierten Variante, bis hin zur Profi-Lösung, bei der gleich mehrere RSS-Feeds mit verschiedenen Stylesheets kombiniert werden können. Wichtig ist nur, dass am Ende HTML-Code herauskommt und man möglichst wenig Arbeit mit der Anpassung hat. Optimalerweise integriert sich ein solcher XML-Parser in das bereits bestehende System, oder aber man hat einen guten Coder zur Hand, der die Anpassung durchführt.

Wir haben nun also zwei Varianten: Der bestmögliche Fall, bei dem ein Browser XML versteht und die Inhalte mit XSL formatiert anzeigen kann. Und den zweitbesten Fall, in dem kein XML vom Client unterstützt wird, dafür aber serverseitig eine Alternativ-Version mit Hilfe eines XML-Parsers erstellt und als HTML mit CSS-Formatierung augegeben wird.

Und was ist mit Feed-Readern?

Damit sollte doch allen geholfen sein, oder? Nein. Immer noch nicht. Was ist mit Feed-Readern, die gezielt nach XML-Dateien suchen, eventuell aber unter falscher Flagge, sprich mit falschem User-Agent oder noch unbekanntem User-Agent unterwegs sind? Diese würden im schlimmsten Fall HTML erhalten, wüssten also nichts von der Existenz des XML-Feeds. Damit wären alle Bemühungen ad absurdum geführt, sogar kontraproduktiv. Die Lösung liegt im Detail und ist simpel, denn sie wird von allen namhaften Feed-Readern unterstützt. Dazu baut man im head-Bereich des auszugebenden Quelltextes einfach folgende Zeile ein:

link rel="alternate" href="xml-rss2.php" type="application/rss+xml" title="Barrierekompass | Aktuelles"

Naturgemäß kann man nicht allen Fällen gerecht werden. Da Barrierefreiheit aber auch immer bedeutet, dass man Kompromisse eingeht, ist dies sicherlich der akzeptabelste Kompromiss zur Zeit. Es werden Zeiten kommen, in denen Standards von Seiten der User-Agents besser unterstützt werden.

Nachtrag

Sicher werden Sie sich fragen, warum wir einen derartigen Artikel schreiben, aber unseren eigenen Feed noch nicht an diese Gegebenheiten angepasst haben und somit ein praktisches Beispiel vorleben. Das liegt auf der einen Seite daran, dass die Thematik gerade sehr aktuell ist und wir einen Beitrag leisten wollen, um das Problem zu lösen. Zum anderen liegt es aber auch daran, dass die Integration in das Gesamtkonzept Barrierekompass mit zahlreichen heterogenen Systemkomponenten eine sorgfältige Vorbereitung verlangt. Wir werden uns die erforderliche Zeit nehmen und eine Lösung präsentieren. Für neue Projekte, mit denen sich die Agentur hinter dem Barrierekompass beschäftigt, wird die XML-Weiche sicherlich von Anfang an berücksichtigt.