Ausgewählter Vortrag:
Das richtige Content Management System für einen barrierefreien Webauftritt

• 21.11.2008, 15:40–16:25 Uhr, Raum 2

  • Michael Stenitzer

  Eine falsche Entscheidung für ein Content Management System (CMS) oder ein Web Development Frameworks kann im schlimmsten Fall nachhaltige und weitreichende Folgen aus Sicht der Barrierefreiheit haben. Frühzeitig die richtigen Kriterien einzubringen ist daher essentiell und darüber hinaus ein Schlüsselfaktor für die Kosten barrierefreier Lösungen. Auf der anderen Seite ist das Label „Accessibility inside“, das viele CMS für sich beanspruchen, noch Lange keine Garantie auf eine barrierefreie Website.

  Der Vortrag soll Ihnen helfen, die richtigen Fragen zum richtigen Zeitpunkt zu stellen und Ihnen damit eine zukunftsfähige CMS-Entscheidung erleichtern.

  Unterlagen

  • Vortrag anhören (MP3)

  Transkription:

  Moderation Martin Ladstätter:

  Wir kommen jetzt zum zweiten Vortrag an diesem Nachmittag und der hat ein sehr interessantes Thema, finde ich. Der verspricht nicht weniger als, wir erfahren jetzt das richtige CMS für die Barrierefreiheit. Gehalten wird er von Michael Stenitzer, was mich persönlich sehr freut. Wie Sie wahrscheinlich wissen, gehört die Agentur WIENFLUSS und das sei jetzt eine private Meinung von mir überhaupt zu den Shooting Stars der letzten Jahre. Die haben alles, was Rang und Namen hat in Österreich gewonnen und umso mehr bin ich auch persönlich sehr interessiert, was uns der Michael erzählen wird zu dem Thema „das richtige CMS“. Michael, darf ich dir das Mikrofon geben, nachdem ich noch sage, damit ich es jetzt nicht vergesse, entschuldige, nachdem ich noch sage: wenn Ihnen die Veranstaltung heute gefällt, dann gibt es eine gute Information für Sie. Auf die Initiative von Michael gibt es monatlich einen Stammtisch von Accessible Media seit ich glaub 1,5 Jahren. Und das ist so wie dieser Tag nur in drei Stunden und behandelt jedes Mal ein interessantes Thema und auch dafür sei einmal Danke gesagt, Michael, dass du die Initiative machst und die ja sensationell ankommt. Und jetzt kriegst du wirklich das Mikrofon.

  Vortrag Michael Stenitzer:

  Danke Martin, für die freundliche Einleitung! Ja, das richtige CMS, das Thema meines Vortrags. Vielleicht vorweg, gibt es Vegetarier im Raum? Sonst würde ich, ah da hinten ja, also Sie sitzen eh gleich beim Ausgang, falls es Ihnen zu viel wird, bitte es tut mir leid. Also es ist nicht persönlich gemeint. Das Zweite, wenn Sie Interesse an der Kurzversion haben, sprich wenn Sie einfach nur wissen wollen, ob Typo3 barrierefrei ist, dann können wir das schnell abhandeln. Nein, im Ernst, aus verständlichen Gründen werde ich Ihnen keine Liste an CMS-Systemen nennen können, die barrierefrei sind oder nicht. Warum werden Sie in meinem Vortrag aber erfahren und wie Sie das richtige CMS selbst aussuchen können, das für Ihre Zwecke passt. Das soll dabei soll Ihnen mein Vortrag eben helfen.

  Zur Theorie am Anfang, also sozusagen eine Art Begriffsdefinition. Wir reden hier von CMS. Was heißt denn überhaupt CMS? Content-Management-System, d.h. das ist ein System, mit dem ich meine Webinhalte und sprich damit meine Website, meine Webplattform verwalten kann. Ich möchte den Begriff etwas aufweichen hier und hier vom klassischen CMS, das ja auch nicht so ohne Weiteres greifbar ist, das kann ein CMS für eine kleine Homepage sein bis hin zu einem Enterprise-CMS, das zur Verwaltung von vielleicht 100.000 Seiten geeignet ist. Also da haben die Systeme auch relativ wenig miteinander zu tun. Im Wesentlichen kann das CMS sozusagen als Hilfestellung für das Publizieren von Webseiten, von Webinhalten angesehen werden betrachtet werden, ohne dass sie selbst fließend HTML sprechen müssen. Ich hab erwähnt, ich möchte das CMS etwas aufweichen und auch andere Systeme, die im Prinzip ähnlich funktionieren oder ähnliche Aufgaben haben, aber vielleicht spezielle Zielgruppen herausgreifen, da auch mit ins Boot holen, nämlich z.B. Blog-Systeme, Wiki-Systeme, die jetzt eher Community-orientiert sind. Also da geht es auch darum, dass die User selbst Content beitragen können.

  Auch ein Webshop ist im Prinzip ein ganz spezielles System, wo ich ein spezialisiertes System, wo ich bestimmte Arten von Content publizieren kann in bestimmter form. Und das lässt sich mehr oder weniger beliebig weit fortsetzen. Ok, betrachten wir einmal das CMS in einer idealen Welt. Leider leben wir nicht in einer solchen, aber trotzdem in einer idealen Welt. Wir haben hier so ein Foto von einem CMS. Ich glaub, jetzt wissen Sie, warum ich vorher die Vegetarier vorgewarnt habe. In CMS füllen Sie Ihren super feinen Content ein, im Idealfall kommt unten Ihr super feiner content wieder raus, Ihre super feinen Webinhalte in einer gut verdaulichen form, wie es sich die User wünschen und wie Sie selbst das verdauen können. Wie gesagt, wir leben in einer nicht idealen Welt, in einer sehr gefährlichen Welt und das CMS in der Realität ist meistens so, dass nicht unbedingt das rauskommt, was Sie sich wünschen und das auch nicht immer verdaulich ist ohne Weiteres. Da müssen Sie schon was dazu beitragen. Wenn wir jetzt das Ganze uns im Detail anschauen, dann gibt es wie immer zwei Seiten, von denen Sie eine Ding betrachten können, nämlich von vorne und von hinten. Fangen wir an bei dem, was hinten rauskommt, also hinten heißt im Englischen Front-End, eh klar, weil das die Seite ist, die den Usern zugewandt wird. Wesentlich ist, dass ist wirklich das Allerwichtigste beim CMS, dass das, was eben da hinten am Front-End rauskommt, feinste Sahne aus Sicht der Barrierefreiheit ist. Also z.B. nach den Richtlinien WCAG, am besten in der Geschmacksrichtung 2.0 AA.

  Das ist unser wesentliches Ziel für das Content-Management-System. Hier können wir einfach keine Abstriche machen. Es gibt da ja wie gesagt auch noch die andere Seite. Das ist die, dass man das Content-Management-System selbst als ein System betrachtet, das auch barrierefrei bedienbar sein soll, d.h., dass überhaupt Menschen mit Behinderungen in dieses Content-Management-System Inhalte einpflegen können. Das ist eine doch recht spezielle Anforderung und eine nicht zu unterschätzende Herausforderung, dass das möglich ist. Je nach Ihren Anforderungen in Ihrem Projekt müssen Sie das berücksichtigen oder sollten Sie das berücksichtigen oder können Sie, weil Sie vielleicht ein kleines Team sind mit zwei, drei Leuten, das klar definiert ist, unter Umständen einmal zumindest vorerst, so lange das nicht so einfach zu lösen ist, auf die Seite schieben. Wenn Sie hingegen für die öffentliche Verwaltung ein CMS bereit stellen und da mehrere tausend RedakteurInnen dran arbeiten sollen, dann können Sie davon ausgehen, dass unter diesen RedakteurInnen natürlich auch Menschen sind, die die eine oder andere körperliche Einschränkung haben oder Behinderung haben. Und daher sollte dieses CMS auch für diese Menschen bedienbar sein.

  Wenn Sie ein Community-System haben, d.h. wenn Ihre User auch Inhalte einpflegen können, dann müssen Sie davon ausgehen, dass unter diesen Menschen auch Menschen mit Behinderungen sind und dann wird ja das Back-End, die Seite, wo man Inhalte einpflegt, zum Front-End, weil Sie es der Welt zugewandt haben. D.h. in dem Fall wird man sich der Herausforderung zumindest für einige Teilbereiche jedenfalls stellen müssen. Ok, schön der Reihe nach. Widmen wir uns zuerst dem rechten Teil, also sozusagen dass wir sicherstellen, dass das, was aus dem Content-Management-System an Webinhalten rauskommt, auch zugänglich ist. Da gibt es mehrere Anforderungen im Wesentlichen. Ich habe das jetzt wirklich auf die wesentlichen Punkte reduziert. In Wahrheit ist das je nach Projekt natürlich eine sehr komplexe und umfangreiche Herausforderung, das zu analysieren. Als Erstes und wesentliche Aufgabe, ist es überhaupt technisch möglich, barrierefreie Inhalte in dieses Content-Management-System einzupflegen. Ist es überhaupt möglich, z.B. Bilder mit einem Alt-Attribut zu versehen? Ist es gibt es überhaupt ein Eingabefeld für diese Alt-Texte? Gibt es überhaupt die Möglichkeit, auf den HTML-Code Einfluss zu nehmen, der da rauskommt? Ja also sozusagen die technische Möglichkeit ist hier alles entscheidend. Aber diese technische Möglichkeit nützt mir natürlich nur dann was, wenn die RedakteurInnen dabei unterstützt werden, dass diese Eingabe gut möglich ist.

  D.h. ich muss den Leuten auch ein auffindbares oder ein prominent platziertes Eingabefeld für den Alt-Text bieten. Ich muss ihnen die Möglichkeit geben, Videos mit Untertiteln zu versehen. Ich muss ihnen die Möglichkeit geben, semantisch strukturierte Texte einzupflegen, ohne dass sie z.B. im HTML-Code herumfuhrwerken müssen. Und ich muss ihnen auch sozusagen mitgeben, warum das notwendig ist und wie sie das am besten machen. Also ich muss sie dabei unterstützen. Ein Beispiel hier aus einem Dialog in einem CMS-System, das hier z.B. für den Alt-Text beim Bild einfügen oder Bild bearbeiten automatisch ein Feld anbietet, darüber hinaus auch für die Long Description. Jetzt würde ich diesen Dialog nicht unbedingt als Idealfall und als Idealbeispiel heranziehen, weil da sind sehr viele Sachen möglich und das ist nicht unbedingt die Art, wie ich die User also die RedakteurInnen in diesem Fall dazu forciere, dieses Alt-Textfeld auszufüllen. Ich meine, da stehen so viele Sachen herum, das wird man mit ziemlicher Sicherheit übersehen. Da wäre es ganz gut, wenn solche Dialog angepasst werden können von den Leuten, die das CMS implementieren. D.h. ich kann das so eventuell vereinfachen anpassen mit den Feldern, die wirklich Sinn machen für mein Projekt, die wirklich wichtig sind. Z.B. auch an das Niveau der Barrierefreiheit anpassen, also ob ich jetzt Level A, Level AA oder AAA erreichen möchte, muss ich ja unterschiedliche Anforderungen berücksichtigen. Alternativtext ist ja A und ist wirklich sozusagen eine der Minimalanforderungen für Barrierefreiheit, daher würde ich den auf jeden Fall prominent platzieren und drinnen lassen. Andere Sachen wie z.B. horizontaler Abstand und vertikaler Abstand sollten ja eigentlich über CMS geregelt werden und nicht den Redakteuren überlassen bleiben. D.h. das sollte man ausblenden können in so einem Dialogfeld. Auch über die Sinnhaftigkeit des Longdesc-Attributes lässt sich trefflich streiten. Dritter wesentlicher Punkt bei der Auswahl des CMS ist, werden die Inhalte, die Sie mit viel Liebe und Mühe barrierefrei eingepflegt haben, auch ordentlich vom CMS verarbeitet. D.h. wird nicht das beim Verwurschten so weit wieder kaputt gemacht, dass am Ende ein HTML-Code herauskommt, der eigentlich aus Sicht der Barrierefreiheit und auch vielleicht anderer Sicht unbrauchbar ist? Das ist eine wesentliche Anforderung, die hier hat sich sehr viel getan ich kommt dann gleich noch einmal darauf zurück.

  Die CMS sind sicher in dem Bereich besser geworden, aber in den Randbereichen hier gibt es ganz massive Probleme noch. Ein spezieller Fall ist, wenn die Inhalte nicht über klassische Editoren eingepflegt werden, sondern wenn die Inhalte vom CMS selbst aus Datenbanken, aus vielleicht externen Quellen, verarbeitet werden und das automatisch passiert. Y.B. denke man an Wetterberichte, denke man an Kalender, Suchergebnisse, Warnlisten oder Sonstiges. Da tun Sie ja nicht die Warnliste selbst bearbeiten, sondern Sie bearbeiten die Eigenschaften der Waren die Information über einzelne Waren und die werden dann automatisch zusammengefügt. In diesem Fall muss sicher sein, dass a) die notwendigen Inhalte für eine barrierefreie Darstellung von vornherein erfasst werden in den Grunddaten. Also z.B. das was bei Bildern, dass bei Bildern automatisch auch die Alternativtexte erfasst werden bei der Eingabe und dass b) bei der Transformation in diese Listen, in diese Ausgabeformate das alles so zusammengesetzt wird, wie Sie das aus der Sicht der Barrierefreiheit wünschen. So, das waren jetzt so theoretische Punkte, jetzt schauen wir uns das an, was heißt das denn in der Praxis, wo finden sich diese Punkte denn im CMS wieder. Und da sind wir erstens ganz, ganz wichtig, bei den so genannte WYSIWYG-Editoren. WYSIWYG ganz kompliziertes Wort, steht im Prinzip nur für “what you see is what you get” oder auch Rich-Text-Editor genannt.

  Das sind im Prinzip Eingabeeditoren, die so funktionieren wie das Word oder das Open Office. D.h. Sie können formatierte oder Texte formatieren, wenn Sie es eingeben. Sie können sie strukturieren mit Überschriften usw. Sie können Bilder in den Text einfügen. Da gibt es ein paar wichtige Punkte dabei beim WYSIWYG-Editor. Sie müssen, wie schon öfter erwähnt, Alternativtexte zu den Bildern angeben können, Sie sollten diese Texte in einer semantisch, also sinn gebenden, Struktur verfassen können, d.h. Überschriften als Überschriften auszeichnen können und nicht über “fett” und bestimmte Schrifttypen anwählen und große Schrift. Sie sollten Paragraphs als Paragraphs auszeichnen können als Absätze und nicht einfach über mehrere Linebreaks. Sie sollten Listen nicht über Sternderln machen, sondern über echte HTML-Listen. Sie sollten im WYSIWYG-Editor dieses schöne Absatz einrücken Zeichen sollte nicht als Absatz einrücken Zeichen verstanden werden, sondern als Block Quote, d.h. als Zitatblock. Das ist wichtig, dass die WYSIWYG-Editoren hier einerseits diese Unterstützung anbieten und andererseits auch entsprechend das im HTML-Code abbilden. Hier gibt es eigentlich relativ wenige Typen, wenige WYSIWYG-Editoren, die das wirklich sauber machen. Die werden eh immer wieder eingesetzt, aber man muss halt genauer schauen sich anschauen, wird dieser Editor von meinem CMS unterstützt oder ist er ohnehin von vornherein eingebaut. Kann ich ihn gegebenenfalls austauschen gegen einen anderen? Das ist eine Aufgabe, die ziemlich heikel ist und nicht zu unterschätzen. Wenn Sie z.B. Inhalte, Texte hin- und herschieben im WYSIWYG-Editor, dann schauen Sie sich nachher den HTML-Code an, der ist dann sehr oft verwurschtelt.

  Dann haben Sie entweder ungültige Verschachtelungen oder Sie haben jede Menge leere HTML-Elemente drinnen, womöglich mitten im Wort, was dazu führt, dass der Screen-Reader dann stockt beim vorlesen, weil er das nicht mehr als ein Wort erkennt. Also da probieren Sie ordentlich herum, machen Sie ordentliche Stress-Tests, damit Sie sehen, ob das auch wirklich so passt. Und genau, bezüglich HTML-Code ist auch noch wichtig, der HTML-Code sollte sich nach Ihren Vorgaben richten. D.h. wenn Sie XHTML strikt vorgeben, dann sollte auch der WYSIWYG-Editor solches produzieren und nicht den HTML-Code, den der WYSIWYG-Editor für sich als den richtigen auserkoren hat. Und dann noch ein Punkt, wo unserer Erfahrung nach auch wo es immer wieder Bröseln gibt, das ist dass das manchmal in einem Browser ganz gut funktioniert, aber im anderen überhaupt nicht oder ganz anders.

  Sehr oft greifen diese WYSIWYG-Editoren im Internet Explorer auf Internet Explorer eigene Funktionalitäten zurück, die sie in den anderen Browsern nicht zur Verfügung haben und dort wird das dann implementiert und z.B. wird aus einem Strong-Element ein Span mit Style Bold, nicht ganz optimal. Also schauen Sie sich das wirklich genau an, was das CMS hier unterstützt oder nicht. Und am fast am Allerwichtigsten ist natürlich, dass diese WYSIWYG-Editoren konfigurierbar sind bei der Implementierung. Wenn wir uns hier ein Beispiel ansehen von einem an und für sich ganz guten Editor, dann hat der dermaßen viele Funktionen, dass Sie mit Sicherheit davon ausgehen können, dass a) innerhalb von wenigen Tagen Ihre Redakteurinnen und Redakteure hier die Seite optisch kaputt machen werden und b) dass einfach missbrauchen werden. Also hier man kann die Farbe der Schrift verändern, man kann die Schriftgröße über Font-Size einstellen. Man kann die Schriftart wählen. Dann werden die Leute ihre Comic-Schrift wählen, die sie so lustig finden und Kontraste kaputt machen und natürlich nicht die vorgegebenen semantisch strukturierten Styles verwenden. Aber möglich ist es hier. Sie müssen nur die entsprechenden Buttons, die Sie nicht haben wollen, alle ausblenden. Unter Umständen auch je nach Rolle der Redakteurin/des Redakteurs weniger oder mehr erlauben, weil wenn ich hier selbst wenn ich hier die Möglichkeit habe, barrierefreie Datentabellen einzufügen, dann werden viele der RedakteurInnen, die das nie machen, nicht verstehen, wie sie das richtig machen. D.h. standardmäßig eher Tabellen nicht erlauben. Standardmäßig auf keinen Fall z.B. den die Bearbeitung von HTML erlauben. Aber einem Administrator/einer Administratorin kann man das durchaus zumuten oder eine/r ChefredakteurIn oder was auch immer oder wie auch immer Ihre Rollen aussehen.

  Zweiter Punkt, die Template-Engine: also das ist im Prinzip dieses Zauberwerk an Technik, das aus Ihren Inhalten Websites macht oder Webseiten macht, die so aussehen, wie Sie es geplant haben mit der schönen Navigation, gleich richtig eingeordnet, die Ihnen all das schön zusammensetzt. Das Wesentliche ist hier, dass hier dass Sie hier die volle Oberhoheit als Implementierer über über das, was hinten rauskommt, behalten. Also das heißt, Sie bauen super feine XHTML-Templates strict und das CMS darf sich hier nicht einmischen. Das CMS soll hier nicht eigenen Code reinrendern oder Attribute verändern oder sonst irgend etwas, sondern soll im Prinzip das nur transformieren, gewisse Bereiche ersetzen, gewisse Regeln dabei beachten, die Sie vorschreiben. Da muss man sagen, da hat sich einiges getan in den letzten Jahren. Viele dieser Template-Engines funktionieren inzwischen ganz gut, aber die kritischen Bereiche das sind jene Templates, die diese Template-Engines nicht verwenden oder nicht sauber verwenden. Nämlich das sind die Templates, die das CMS mit sich mitbringt. Sie werden jetzt sagen, naja, ich verwende ja keine Templates, die da mitgeliefert werden, ich mach ja professionelle Websites. Nein, eh nicht die Seiten, wo Sie Ihre Artikel publizieren, aber es handelt sich hier z.B. um Suchergebnislisten. Viele Templates haben viele CMS haben hier überhaupt nicht die Möglichkeit, eigene Templates dafür anzubieten und wenn ist das vielleicht sehr schwierig. Oder das Front-End-User-Management, also eine Benutzerverwaltung für Externe, für Kunden oder sonst irgend etwas. Da gibt es dann Anmelde-Dialoge, da gibt es Passwort-vergessen-Funktionalitäten, Registrieren-Funktionalitäten, das ist alles vielleicht schon fertig implementiert in Modulen. Wenn Sie sich das anschauen, sehr oft aus Sicht der Barrierefreiheit “a Schmoan”, einfach unbrauchbar.

  Da passieren, also wir haben da ein Beispiel vor kurzem gehabt, da passieren ganz fürchterliche Roundtrips, wo für die Validierung der Eingabe dann da ständig http hin- und hergeschickt wird, man auf andere Seiten verwiesen wird und da kann man als Implementierer von diesem CMS kaum wirklich eingreifen und wenn, dann wird es ziemlich kompliziert und dann haben Sie ziemlich viel Mühe damit. Ein weiterer Punkt, der, muss man ehrlicher Weise sagen, die Open Source CMS sehr stark betrifft. Ich meine, ich bin überhaupt nicht gegen Open Source CMS und ich bin in Wirklichkeit ein großer Freund der Open Source Bewegung. Da passiert sehr viel und da gibt es ausgezeichnete Produkte, aber es bringt natürlich mit sich, dass eine große Community Beiträge zu einem CMS externe Beiträge liefert und die unter Umständen nicht die entsprechende Qualität haben. Das betrifft einerseits die Security und das betrifft andererseits natürlich auch solche Dinge wie die Barrierefreiheit. Schauen Sie sich das genau an. Viele dieser Plug-Ins muss man damit rechnen, dass man sie selbst nachbauen muss ordentlich. Leider ist das nicht immer so einfach, weil wenn Sie so Spezialtemplates oder –applikationen hernehmen wie z.B. ein Forum, das haben Sie wahrscheinlich nicht mitkalkuliert in Ihrem Anbot, dass Sie das nachprogrammieren. Das ist auch nicht unbedingt ein großer Spaß. Oder einen Shopping also einen Einkaufswagen für ein Webshop-System, auch das nachzubauen ist nicht lustig, wenn das nicht zugänglich ist. Also das sind Templates, da werden Sie ziemlich sicher auf das, was im CMS vorhanden ist, zurückgreifen wollen/müssen/können.

  Ein weiterer Punkt, nicht zu unterschätzen bei größeren Websites, ist die Medienverwaltung, d.h. die Verwaltung Ihrer Bilder, Ihrer eventuellen Videos. Sehr hilfreich ist es hier, wenn Sie die Bilder uploaden und diesen Bildern gleich Alternativtexte vergeben können, d.h. dass Sie nicht jedes Mal diese Aufgabe in die Verantwortung der RedakteurIn beim Einfügen eines Bildes zuordnen. Da können Sie regelmäßig Ihre ganze Bildverwaltung durchchecken, wo noch Alternativtexte fehlen, können diese Aufgabe einer gut eingeschulten Person, die versteht, was es heißt, Alternativtexte zu verfassen, überlassen und damit haben Sie schon die halbe Sache gewonnen. Es kann natürlich sein, dass in manchen Anwendungen Sie die Alternativtexte in manchen Anwendungsfällen Sie die Alternativtexte ändern müssen. Da wäre es ganz praktisch, wenn man diese Vorgaben overrulen könnte. Ein Beispiel, dass aus einem Projekt aus einem von uns aktuellen Projekt grad aufgetreten ist, da haben wir eine Website, die in zwölf Sprachen veröffentlicht wird. Da ist es natürlich sinnvoll, wenn Sie diese Alternativtexte gleich in den zwölf Sprachen zu dem Objekt ablegen können. Und damit verhindert man, dass die Redakteurinnen und Redakteure dann jedes Mal das Bild mit dem deutschen Alternativtext auf der arabischen Website eingeben, weil das ist natürlich witzlos. Aber Sie werden es sich gut vorstellen können, wie oft so was passiert.

  Frage aus dem Publikum: [nicht verständlich]

  Antwort Herr Stenitzer: Bitte? Also von vornherein ich nehme es schon an, dass es das gibt. Also ja. Also viele CMS können einfach bei jedem Objekt, das man definiert, die Eigenschaften auch internationalisierbar machen. Das ist eine sinnvolle Vorgehensweise. Also wenn man Objekte definieren kann, deren Eigenschaften, egal ob das jetzt Bilder sind oder Seiten, und dort alle Eigenschaften internationalisierbar macht. Ob das von Vornherein vorgegeben ist, kann ich jetzt nicht 100%ig sagen.

  Frage aus dem Publikum: [nicht verständlich]

  Antwort Herr Stenitzer: Nein, ist kein EU-Projekt.

  Anmerkung aus dem Publikum: [nicht verständlich]

  Antwort Herr Stenitzer: Ja, wenn sie Videos anbieten, dann müssen Sie schauen, dass Sie auch Videos mit Untertiteln verwalten können. Wenn Sie das immer mit der Hand machen müssen, ist das lustig, wenn sie fünf oder zehn Videos auf Ihrer Website haben, wenn das das 10- oder 100-fache ist, ist das dann nicht mehr lustig, wenn das nicht von vornherein vorgesehen ist. Ob es hier schon fertige Systeme gibt, weiß ich nicht, aber jedenfalls ist das eine Sache, die Sie mitbedenken sollten.

  Gut, jetzt kommen wir zum zweiten Aspekt, nämlich die Frage, dass das CMS selbst zugänglich ist und selbst barrierefrei benutzt werden kann. Sie sehen es schon an der Maschine. Also die kann man super mit einer Hand bedienen, ohne dass man viel Kraft aufwendet und da brauche ich keine Maus dazu. Aber dieses Ding, dass Sie für dieses Ding viel Geld in die Hand nehmen müssen oder viel Zeit investieren müssen, können Sie sich wahrscheinlich auch vorstellen, weil ein barrierefrei bedienbares CMS out of the box, wird vielleicht mit Abstrichen für kleinere Projekte möglich sein, aber für die großen Projekte gibt es das meines Wissens noch nicht, aber hoffentlich wird sich da auch bald was tun. Was heißt das ein barrierefrei bedienbares CMS? D.h., es sollte bedienbar sein für alle. Da stellt sich mal als erste Frage, ist es z.B. Screen-Reader-tauglich? Kann ich das Interface überhaupt mit dem Screen-Reader bedienen? Ist es mit der Tastatur steuerbar?

  Das ist sehr oft ein kritischer Punkt bei der Art, wie die implementiert sind. Das ist auch eine Sache, die sehr wohl praktisch ist für normale RedakteurInnen. Leute, die sehr viel damit arbeiten mit einem System verwenden oft lieber die Tastatur als die Maus für manche Tasks und das kann sehr hilfreich sein. Auch Shortcuts können bei so einem System, mit dem ich tagtäglich arbeite, hilfreich sein. Auf einer Website selbst werde ich das vielleicht hinterfragen, ob Shortcuts wirklich Sinn machen. Aber bei einem Intranet oder einem im Prinzip ist es ja eine Software, die Sie immer wieder benutzen. Da ist es wirklich sinnvoll, wenn Sie z.B. mit STRG+S speichern können oder so. Das ist eine coole Sache, die auch der Barrierefreiheit hilft. Sind grafische Buttons, oft werden diese Systeme mit grafischen Buttons und Icons nur so aufgepeppt, dass es schon fast nicht mehr auszuhalten ist, haben die überhaupt ordentliche Alternativtexte, ganz wichtig, sonst kann ich ja diese Steuerelemente überhaupt nicht bedienen. Ein sehr, sehr schwieriger Punkt ist sicher die Skalierbarkeit.

  Je komplexer ein Interface ist, desto schwieriger wird es mit dem Skalieren. Da kann ich mir vorstellen, dass es wirklich schwierig wird und ein wichtiger Punkt, den ich hier nennen möchte ist, welche Techniken werden denn eingesetzt? Sind die überhaupt von der Barrierefreiheit unterstützt. Es gibt CMS, die für ihr Back-End Java einsetzen und da wird es schnell einmal schwierig mit dem Screen-Reader. Es gibt praktisch alle CMS nutzen im Back-End intensiv JavaScript, was ja, wie wir heute gehört haben, nicht an sich böse ist. Böse ist nur höchstens die Art, wie JavaScript eingesetzt wird. Das kann zu großen Problemen in der Bedienbarkeit führen. Viele CMS nutzen ein eine Unmenge an verschachtelten Frames und Frame-Sites im Back-End. Das macht es auch nicht gerade einfach in der Bedienung mit für Menschen mit Behinderungen z.B. mit Screen-Reader sich da zurechtzufinden. Und damit sind wir eigentlich auch schon beim nächsten Punkt, nämlich das Interface muss nicht nur technisch bedienbar sein, sondern es muss auch verständlich sein. Und gerade so komplexe Interfaces, also Sie werden sich selbst oft, wenn Sie mit so CMS-Systemen vielleicht arbeiten, geärgert haben, wie kompliziert es ist, manche Aufgaben da zu erfüllen. Und stellen Sie sich einmal vor, Sie sehen das Interface nicht, sondern Sie müssen das sozusagen blind erfahren und sich da zurechtfinden in einer Unmenge von nicht strukturierten Links, die womöglich alle nur in irgend welchen Diff- und Span-Elementen angeordnet sind ohne Zwischenüberschriften. Das wird sehr, sehr schwierig. Die Benutzerführung sollte so sein, dass sie von Menschen, die den Content als ihre Hauptaufgabe sehen und nicht die Programmierung, verständlich sein und intuitiv und nachvollziehbar.

  D.h. es kann durchaus sinnvoll sein, gewisse Arbeitsschritte in so genannte Wizards, also Schritt für Schritt abzuarbeiten mit erläuternden Texten zu versehen, mit kleinen Hilfe-Informationen, die unmittelbar bei den Eingabefeldern sind und dass man halt verzichtet auf Technik lastige Beschriftungen, wo einfach z.B. das HTML-Attribut als Beschriftung für ein Eingabefeld dort steht, ist vielleicht nicht hilfreich, wie wir es vorher gesehen haben, Longdesc, welche Redakteurin/welcher Redakteur kann sich unter Longdesc irgendwas konkretes vorstellen? Es wäre vielleicht sinnvoll, wenn dort stehen würde: Pfad zu einer Datei mit ausführlicher Bildbeschreibung. Ich meine, dass ist jetzt nicht kurz genug, aber da lässt sich sicher was Griffiges finden. Und die Eingabe sollte, wie es eben auch die Web-Content-Accessibility-Guidelines auch für normale Websites vorsehen, fehlertolerant sein. D.h. sie sollte Eingaben sollten wieder rückgängig gemacht werden können und Eingaben sollten z.B. also wenn ich Seiten lösche, sollte das auch abgefragt werden, ob ich das wirklich tun will, um einfach möglichst Fehler zu verhindern bzw. Rückgängig zu machen.

  In der Praxis heißt das, ich muss aufpassen bei der Tastaturbedienbarkeit, das ist ein ganz kritischer Punkt und wie gesagt, das hilft auch Menschen ohne Behinderung in der Praxis sehr schnell. Dass Formulare ordentlich umgesetzt sind, wenn Formulare nicht HTML-mäßig ordentlich beschriftet sind, dann wird man sich in diesem Wust an Formularen im Back-End wohl kaum zurecht finden. Ein kritischer Punkt wie auch bei den barrierefreien Inhalten ist die Bedienbarkeit des WYSIWYG-Editors. Das ist oft ein großes Problem, das nicht leicht zu lösen ist. Hier gibt es Ansätze interessante, aber die wirklich wunderbare Lösung habe ich noch nicht gesehen. Wie gesagt, auch die Java-basierten Interfaces und all diese Widgets, die halt so mit dem Web 2.0 aufgekommen sind, also Date Picker also wo man ein Datum für eine Veröffentlichung für ein Offline Stellen einstellen kann. Diese Dinge sind schnell einmal nicht ordentlich umgesetzt und nicht barrierefrei. Oder wenn ich die Sortierung über Drag and Drop im Interface machen kann, dann ist das natürlich super easy für Leute, die eine Maus bedienen können. Ich muss aber auch berücksichtigen, dass es Leute gibt, die keine Maus bedienen können und die müssen halt andere Möglichkeiten haben, um Inhalte zu sortieren.

  Ja und als letzte und wirklich wichtige Message möchte ich Ihnen mitgeben, dass sich Redakteurinnen und Redakteure beim Back-End, bei der Bedienung eines CMS auf das Wesentliche konzentrieren können und das Wesentliche das ist einfach der Inhalt. Und das, wenn Sie das können, wenn Sie das sicherstellen mit der Auswahl Ihres CMS, dann können Sie davon ausgehen, dass die Leute sicher qualitativ bessere Inhalte publizieren und dass das sicher auch der Accessibility, der Zugänglichkeit von Inhalten nutzt. Jetzt möchte ich ganz zum Schluss noch sozusagen die Theorie dazu erwähnen, damit ich da nicht ganz dran vorbei gehe. Und zwar geht’s um A-Tag und nicht um den A-Tag. ATAG heißt einfach “Authoring Tools Accessibility Guidelines”, Shadi Abou-Zhara hat es heute schon erwähnt, es ist auch so ein Webstandard, der vielleicht für Sie in der täglichen Arbeit nicht so wichtig ist, aber das ist der Standard, der sozusagen festschreibt, wie solche “Authoring Tools”, also Content-Management-Systeme, HTML-Editoren wie Dreamweaver oder Eclipse oder solche Dinge funktionieren sollen, damit man a) barrierefreie Inhalte damit erzeugen kann und b) damit se auch selbst barrierefrei bedienbar sind. Das können Sie da nachlesen, diese Authoring Tools sind auch in der Version 2.0 demnächst verfügbar. Ist noch nicht ganz so weit wie WAICAG, aber da ist man auch schon nah am Ziel, aber für Ihre tägliche Arbeit brauchen Sie sicher wahrscheinlich handfestere Kriterien, wie ich versucht habe, sie rüberzubringen als die Theorie von W3C. Dann sage ich herzlichen Dank für Ihre Aufmerksamkeit! Für Fragen stehe ich gerne zur Verfügung. [Applaus]

  Moderation Martin Ladstätter: Michael Stenitzer, danke für deinen Vortrag! Du hast uns vielleicht, wie manche von uns hoffen, nicht das perfekte CMS genannt, aber du hast uns zumindest gezeigt, auf was wir aufpassen müssen. Gibt’s ergänzende Fragen zum Vortrag?

  Frage: Ja, es war jetzt ein wunderbarer Requirement-Katalog für Entwickler von CMSen. Es stellt sich für mich trotzdem jetzt die Frage: gibt es irgendwo Bewertungen von existierenden CMSen, wo man einmal sieht, wie gut die diese Liste erfüllen?

  Antwort Herr Stenitzer: Ja danke für die Frage! Es gibt so ein paar Blog-Beiträge und Tests von CMS-Systemen. Ich habe mir da ein paar Links zusammengesucht. Ich werde mir wieder einmal vornehmen, dass ich einen Blog-Beitrag zu dem Ganzen veröffentliche und wo ich auch dann diese Links veröffentliche. Die meisten von diesen Artikeln schauen sich halt die eine oder die andere Seite an. Also z.B. auf juicystudio.com einen Blog aus England von Gez Lemon wird untersucht, in wie weit das Back-End bedienbar ist. Es gibt auf, ja was war das, ja, tut mir leid, ich weiß es jetzt nicht auswendig, aber ein paar Links habe ich gesammelt, die kann ich auch gerne zur Verfügung stellen, kann ich Ihnen gerne per Email schicken.

  Frage: Ich habe auch eine Frage. Auf der einen Folie war zum Thema Bildbeschreibungen etwas. Dazu habe ich noch mal eine Frage. Da war das eingeringelt mit den Long-Text- und dem Alternativtext-Sachen, also mit den Langbeschreibungen und den Alternativbeschreibung und mir ist nicht ganz klar eben, wieso man die Definition eben also was man da genau sozusagen was der Unterschied ist zwischen dem Alternativtext und dem Long-Text?

  Antwort Michael Stenitzer: Der Alternativtext ist ein HTML-Attribut, der bei Bildern und bildbasierten Buttons gibt es das und dort sollte eine kurze Beschreibung, Information über das Bild, über den Button drinnen stehen. Wenn ich z.B. eine sehr komplizierte Grafik habe, ein Diagramm, wo so eine kurze Bildbeschreibung nicht in so einem Alt-Attribut Platz hat, dann gibt es über das Longdesc-Attribut einen Pfad zu einem anderen zu einer anderen Datei, wo ich eine ausführliche Bildbeschreibung habe z.B. in Worten, möglicherweise zusammen mit einer Datentabelle, die die Basis des Diagramms ist. Das Problem am Longdesc-Attribut ist, dass das nicht implementiert ist in den Browsern und damit eigentlich wertlos ist. Und darum ist es besser, solche Sachen entweder im begleitenden Text zum Bild zu definieren, wenn das dort hinpasst und wenn das dort Sinn macht, oder z.B. unmittelbar nach dem Bild einen Link zu setzen, der dann heißt z.B. “detaillierte Bildinformation” oder “Bildinterpretation” oder was auch immer und das auf eine Seite führt. Das ist dann für alle Menschen nutzbar und auch ersichtlich und eigentlich meiner Ansicht nach zur Zeit die bessere Lösung.

  Anmerkungen Martin Kliehm: Zu dem Longdesc muss man aber auch sagen, das verwendet einfach auch überhaupt niemand. Also neulich gab es diese Studie von Opera MAMA, wo sie ich glaube 3 Millionen Seiten getestet haben und nur eine Handvoll hatte glaube ich dieses Longdesc-Attribut. Also weil das wird einfach nicht unterstützt. Ich habe mal irgendwas gelesen, dass der Alternativtext, dass man in einem Alt-Text zu einem Bild eigentlich nicht mehr als 80 Zeichen verwenden sollte. Und das heißt, wenn man darüber hinaus geht, dann könnte man so einen Longdesc nehmen. Wo ich das tatsächlich schon einmal angesetzt habe, war, wenn ich ein Bild habe und eine also so eine Bildunterschrift, dann kann ich dieser Bildunterschrift eine ID geben. Ich kann in dem Longdesc, das kann ja nur ein Pfad sein, kann ja auch ein interner Pfad sein, geb ich dann einfach so einen Fragment-Identifier, so ein Doppelkreuz und dann die ID ein und dann ist damit auch Genüge getan.

  Antwort Michael Stenitzer: Ja, aber damit ist eigentlich nur den Standards Genüge getan, wenn es nicht unterstützt wird. Also ein bisschen eine vergebene Liebesmüh, aber es ist natürlich, wenn man es perfekt machen will, geb ich dir ganz Recht.

  Frage: Ich hätte eine Frage zum Konzept von WYSIWYG, also das ja ursprünglich aus dem könnte man behaupten Desktop Publishing kommt, dass die Variante, die man am Bildschirm sieht, auch wirklich 1:1 am Drucker in der Form herauskommt, ist ja im Prinzip doch ein ganz anderer Ansatz als jetzt den Text zu strukturieren, wie das bei SGML und später HTML versucht wird. Jetzt gibt es da nicht ein gewisses konzeptuelles Problem, WYSIWYG-Editoren mit strukturiertem Text zusammen zu führen, den man dann gerne auf den Benutzer einer eines CMS-Systems abwälzt, indem man behauptet, er versteht nicht, welche Knöpfe er da eigentlich drückt, wenn er den Text fett macht und vergrößert und meint, er hat jetzt eine Überschrift gemacht? Denn selbst, wenn man sich länger mit HTML-Tags auseinander gesetzt hat, ist es ja nicht wirklich ganz klar, was jetzt der Unterschied zwischen einem “Anthesize Text”-Tag, einem “Italix” oder einem “Span”, der den Text schräg stellt, ist und eine Parallele hat sich doch jetzt in den letzten Jahren auch die MediaWiki, also diese so eine Art von abgespeckter HTML-Form entwickelt. Man muss zwar keine TAGS vorne und hinten setzen, aber man muss trotzdem eine neue Strukturierungssprache lernen, um überhaupt Inhalte erstellen zu können. Ist es jetzt zu viel verlangt, wenn man potentiellen Benutzern das nahelegt, lieber so etwas zu lernen, anstatt auf WYSIWYG zu hoffen?

  Antwort Herr Stenitzer: Ja also erstens muss ich Ihnen vollkommen Recht geben, dass es natürlich vom Konzept her WYSIWYG eigentlich ganz anders gedacht war und ganz anders ganz andere Intentionen hat, die unseren Bestrebungen, semantisch strukturierten Code zu produzieren, widerlaufen. Andererseits ist es ein Konzept, mit dem die Redakteurinnen und Redakteure vertraut sind. Sie kennen das aus der täglichen Arbeit und sie haben keine Scheu davor, so was zu verwenden und ich glaube, dass wenn der WYSIWYG-Editor einigermaßen gut funktioniert und wenn Sie ihn reduzieren auf sehr wenige Möglichkeiten und das machen wir üblicherweise. Wie bieten zwei Überschriftenebenen an oder manchmal auch nur eine, weil die Hauptüberschrift ist sowieso ein eigenes Feld. Wir bieten Strong an, wir bieten Kursiv eventuell an. Wir bieten Links an, Bilder einfügen unter Umständen und Listen. Und das ist es meistens. Da kann man nicht so viel falsch machen und da kann man aber andererseits eigentlich damit 97 % der üblichen Fälle bei üblichen Organisationen an Inhalten abdecken. Und das Ergebnis ist dann ganz brauchbar. Zu den MediaWiki-Editoren, also d.h. da habe ich im Prinzip z.B. zwei Sternderln, um was strong zu machen oder ich habe Sternderln oder ein Minus am Anfang einer Zeile, um das Auflistungszeichen zu machen oder Doppelraute für durchnummerierte Listen und solche Sachen. Ich persönlich arbeite irrsinnig gerne mit so was. Ich finde das viel schneller zu bearbeiten als so WYSIWYG-Editoren, aber ich glaube trotzdem, dass wir damit eher ein Technik affines Publikum erreichen. Ich finde es eine gute Alternative, die vielleicht auch unter Umständen besser zugänglich ist und unter Umständen in den User-Settings kann ich einstellen, welchen der zwei Editoren ich verwende. Also das finde ich gar nicht so eine dumme Lösung. Wir haben vor im Rahmen von einem Projekt das einmal auch die Usability von so einem MediaWiki-Editor zu testen. Es gibt auch Tests. Ich habe irgendwo einmal was gelesen. Ja, also ich bin ein bisschen skeptisch, ob die Leute ohne Weiteres damit umgehen können und wollen, wollen auch, ja. Können Sie das Mikro weiter geben? Ah, haben Sie es schon.

  Anmerkung aus dem Publikum: Ich meine, wir haben jetzt alle mittlerweile begriffen, dass es DAS CMS nicht gibt. Wir sollten genauso gut begreifen, dass es DEN Kunden nicht gibt, weil ein großes Problem ist eben, z.B. dass also so Randbereiche wie z.B. Sprachauszeichnung, im Prinzip nicht wirklich voll automatisiert werden können und damit nicht als Werkzeug in ein CMS implementiert sein können, das voll automatisch für einen völligen „No-know“ es möglich macht, alles auszuzeichnen. Es gibt CMS wie z.B. Papoo, die lernfähig sind, die dann also einmal ausgezeichnete englische Begriffe in die Datenbank übernehmen und wenn dieser Begriff wieder auftaucht, automatisch dann im Quellcode eine Ausgabe als Sprachauszeichnung „En“ machen. Aber das bedarf eben, dass auch der Redakteur oder derjenige, der den Text bearbeitet, diese Funktion kennt und auch bedienen kann. Das kann ich nicht erwarten bei einem Kunden wie eine kleine Gemeinde, wo nur eine Person, die grade Word bedienen kann, da ran gesetzt wird, die Inhalte dieser Gemeinde auszutauschen. Das ist wichtig zu begreifen, wenn wir solche Aufträge übernehmen oder eben übernehmen wollen, dass wir uns genau so klar machen, dass es nicht DAS CMS gibt, genau so wenig DEN Kunden gibt.

  Antwort Michael Stenitzer: Ich geb Ihnen vollkommen Recht natürlich und ich würde Sie auch davor warnen, sich mit solchen Dingen zu verzetteln, nämlich der Sprachauszeichnung innerhalb von einem Artikel da Akronym- und Abkürzungsauszeichnungen innerhalb von einem Artikel. Die wesentlichen Punkte bei der Auswahl von CMS liegen auf einer anderen Ebene und wir bewegen uns hier bei WCAG 2.0 auf AAA-Ebene, also Sprachauszeichnung in Textblöcken und Akronyme und „Abbreviation“. Das sind natürlich trotzdem wichtige Punkte, aber das sind nicht die Punkte, die ich als erstes angehe und wo ich mit meinen Kunden tagelang drüber diskutiere, ob das jetzt im CMS möglich ist oder nicht. Drum habe ich es auch absichtlich vorher einmal beiseite gelassen. Natürlich ist es super, wenn mein CMS ein Plug-In hat, wo ich Fachausdrücke oder ein Glossar verwalten kann, super Sache. Aber das Allerwichtigste ist, dass ich die Redakteurinnen und Redakteure schule, dass sie verständliche Inhalte schreiben, dass sie einfach diese Fachbegriffe, diese Abkürzungen, die niemand kennt, einfach entweder weglassen und ausschreiben oder dass sie es erläutern beim ersten Mal verwenden. Und da nützt mir auch das Abbreviation- oder Akronym-Element nichts, weil das den Normalusern einfach nicht wirklich hilft. Die müssten mit der Maus drüber fahren, damit sie es lesen können usw. Also es gibt da einige Probleme damit. Und eine gute Schulung der Redakteurinnen und Redakteure ist einfach eine ganz, ganz wichtige Voraussetzung, dass es überhaupt zu barrierefreiem Content kommt. Viel also mindestens genau so wichtig wie diese ganzen technischen Fragen, die wir uns stellen.

  Martin Ladstätter: Und das klingt glaube ich sehr nach einem Schlusswort. [Lachen] Ich danke für Ihre Fragen und Aufmerksamkeit und dir, Michael, danke ich für den tollen Vortrag. Wir gehen jetzt in unserem Programm weiter mit der Kaffeepause.

  Und dann, im anderen Raum, weil hier geht es nicht mehr weiter, wird Chris Heilmann sagen, warum es für die Barrierefreiheit eigentlich nur zwei Dinge gibt. Und er wird das 10 Minuten vor 5 im anderen Raum beginnen, zu erklären. Danke! [Applaus]

  Michael Stenitzer: Ein Applaus auch an die Gebärdensprachdolmetscher! [Applaus]

  Tags:

  • cms