Ausgewählter Vortrag:
wien.info – Wiens neues Tourismusportal
-
16.10.2009, 13:00–13:30 Uhr, Raum 1
Der Relaunch einer großen Website wie jener von WienTourismus stellt Auftraggeber, Redaktion und Agentur vor große Herausforderungen, insbesondere wenn dabei höchste Ansprüche an die Barrierefreiheit gestellt werden. Ein Blick hinter die Kulissen beleuchtet unterschiedlichste Aspekte:
- Warum Barrierefreiheit aus Sicht des WienTourismus höchste Priorität hat
- Barrierefreiheit als redaktionelle Herausforderung
- Die Herausforderungen einer Website in zwölf Sprachen
- Accessibility als Kostenfaktor
- Moderne Frontendentwicklung: flexibles Design, der Einsatz von Javascript, WAI-ARIA und Multimedia
- Die Grenzen und Herausforderungen der Barrierefreiheit
Unterlagen
Transkription:
Moderation Eric Eggert: Manula Vergud ist Online-Marketing-Managerin bei Wien Tourismus und war da auch Projektleiterin bei dem Redesign für die neue Wien Infoseite und Michael Stenitzer ist Geschäftsführer der Biene-prämierten Wienfluss-Agentur und ist auch unter anderem im W3C in zwei Taskforce, Taskforces, Taskforci aktiv. Und er organisiert auch den Accessory -Media-Stammtisch, dass wollte ich nur noch gerade schnell sagen, der fast monatlich ist, wenn nicht gerade At-Tag ist. Und da kann man auch hinkommen und sich informieren. Bitte!
Manuela Vergud: Gut. Wir begrüßen Sie jetzt zu unserer Präsentation zum neuen Tourismus-Portal für Wien: www.wien.info, das wir im Juni diesen Jahres gerelaunched haben. (lacht) (leise) Danke. Also, ich werde in einem ersten Schritt eigentlich überhaupt nicht technisch. Ich werde mal darauf eingehen wie wichtig Wien als Destination europaweit eigentlich ist. Was für einen Stellenwert wir hier haben. Was natürlich auch die Bedeutung von www.wien.info ein bisschen darstellt. Und ich werde auch darauf eingehen wie wir den Zugang zur Barrierefreiheit bewältigt haben. Und was aus unserer Sicht den Nutzen der Barrierefreiheit ist. Und wie wir die Kosten quantifizieren. Michael Stenitzer wird dann noch ein paar technische Details beleuchten und ein paar Tipps und Tricks verraten, wie wir die Website interaktiv barrierefrei gestaltet haben. Wien als Destination ist unter den Top-Destinationen in Europa wenn man sich die Nächtigungen anschaut. Wir haben 2008 die zehn Millionen Marke geknackt, das war eigentlich erst unser Ziel für 2010, darauf sind wir sehr stolz. Dieses Jahr gehen die Nächtigungen ein bisschen zurück, wie es aber überall ist aufgrund der Krisensituation. Da sind wir aber auch noch im Durchschnitt, ja. Wir haben Minus von fünf Prozent – sind da also noch im grünen Bereich.
Und die touristische Wertschöpfung in Wien ist doch beachtlich mit rund vier Milliarden Euro jährlich. Deshalb auch die wien.info in ein paar Zahlen gefasst, damit Sie Sich den Umfang ein bisschen vorstellen können. Und zwar – es gibt die wien.info in dreizehn Sprachen, Zielgruppe sind hier ausschlie- oder vor allem die Touristen, die nach Wien kommen, oder potenziell nach Wien kommen. Wir haben 5500 Artikel, rund zweitausend Events und fast 400 Hotels, die auch zum Großteil online buchbar sind. Momentan haben wir im Durchschnitt rund 320000 Visits pro Monat und generieren 1,7 Millionen Pageviews, was doch sehr beachtlich ist. Und aufgrund der Sprachenvielfalt ist auch das Thema Barrierefreiheit bei uns eigentlich noch komplexer. Bei den Sprachen ist nur zu erwähnen, das die einzige Sprachversion, die auszunehmen ist bei uns ist Chinesisch, weil unsere chinesische Website in China läuft und wir diese noch nicht nachgezogen haben. Und unser Hauptziel beim Relaunch dieses Jahr, war es die www.wien.info als, noch stärker als online Wien-Reiseführer zu positionieren. Und unsere Hauptziele dabei waren emotionaler und interaktiver zu werden. die Benutzerfreundlichkeit zu verbessern, aber auch die Barrierefreiheit. Also überhaupt barrierefrei zu werden.
Ich glaube schon allein dass das eines unsere Hauptziele war zeigt, wie wichtig uns die Barrierefreiheit ist – und das ist nicht nur aus rechtlichen Gründen so – aber darauf gehe ich nachher noch ein. Wir hatten auch den Ansporn quasi vorne mit dabei zu sein, was in europaweit schon durchaus eine Herausforderung ist, wenn man sich andere Städtedestinationen anschaut, in ganz Europa – da gibt es nicht viele, die da von sich behaupten können, dass die, dass ihre Webseiten barrierefrei sind. In Österreich sind wir da verhältnismäßig gut aufgestellt. Wie wir jetzt auch gerade beim Vortrag vorher gehört haben. Bei uns ist es auch eine relevante, oder bedienen wir auch eine relevante Zielgruppe, durch die Barrierefreiheit. Wir haben über ein Viertel unserer Gäste, die über 50 sind. Und denen wir auch den Zugang und den Nutzen der Website erleichtern. Für uns war auch die Barrierefreiheit eine Grundlage für das Servicedesign. Und zwar durch den ganzheitlichen Ansatz, also einfach da auch das Aufbau und Technik ganzheitlich durchdacht wurden und optimal aufeinander abgestimmt wurden, haben wir es geschafft den Fokus auch (verspricht sich) immer wieder auf den Nutzer zu ziehen und nicht interne Belange in den Vordergrund (verspricht sich) zu rücken. Und letztendlich ist die Barrierefreiheit für uns, oder bietet die Barrierefreiheit für uns vor Allem Vorteile für alle Nutzer, aber auch für Suchmaschinen. Hierzu ein Zitat von google: “You can think of google bot as the most influential blind user.” Das ist eigentlich das Erste, was ich über Suchmaschinen gelernt habe. (lacht) Und deshalb haben wir das auch beim, beim ganzen Prozess des Relaunchs berücksichtigt und haben da auch erste positive Ergebnisse, wo wir einfach besser platziert sind unter relevanten, also für uns relevanten Keywords.
Bei uns hat die Barrierefreiheit auch im ganzen Ausschreibungsverfahren schon einen großen Stellenwert eingenommen. Und zwar wir hatten auch, ähnlich wie Linz, einen, einen geladenen geladenen Realisierungswettbewerb mit anschließendem Verhandlungsverfahren. Und da haben wir an drei Stellen einen Experten von Accessible Media eingebunden. Und zwar einmal, bei den Präsentationen selbst. Als die Agenturen zu uns eingeladen wurden und ihre Vorschläge präsentiert haben. Unser Experte hat die einzelnen Vorschläge geprüft, viele Fragen gestellt und letztendlich die Jury beraten. Beim Verhandlungsverfahren wurde dann das Pflichtenheft nochmal vor der Beauftragung genau in Richtung Barrierefreiheit überprüft. Und dann letztendlich gab es nach der Umsetzung nochmal eine finale Überprüfung und Nutzertests der Hotelbuchung sind jetzt gerade noch am Laufen. Wir haben aber jetzt nicht nur technisch unseren Auftritt barrierefrei fit gemacht. Sondern haben auch viele Inhalte die für den, für unsere Wiengäste relevant sind. (lacht) Beispielsweise zu Anreise und öffentlichen Verkehr, zu den Hotels und Sehenswürdigkeiten. Wir haben auch Informationen über Heilbehelfe und Servicestellen, aber auch zu spezialisierten Stadtführungen. Wir sind eben sehr froh darüber, weil diese Inhalte hatten wir großteils auch vor dem Launch schon auf der Website, nur war es eben nicht für Alle möglich, dort einfach zuzugreifen. Aus unserer Sicht zu den Kosten: Wir können die Kosten auch nicht in Zahlen nennen.
Vor Allem, weil wir das Webportal wirklich von Grund auf neu gebaut, also neu, komplett neu überdacht haben eigentlich, komplett neu aufgebaut haben. Ein neues CMS, jetzt im Einsatz haben. Aber was bei uns in der laufenden Arbeit zu sehen ist, ist dass es auf jeden Fall, einerseits intern eine gewisse Sensibilisierung und erhöhter Schulungsaufwand nötig ist. Aber dass auch ein gewisser Mehraufwand bei der Einwartung von Texten besteht, oder von Inhalten generell. Zum Beispiel wenn es um Alternativtexte geht. Der wird bei uns auf circa 30 Prozent Mehraufwand geschätzt. Wobei das natürlich schwer zu vergleichen ist mit der Situation vorher, weil wir auch das CMS gewechselt haben. Und auch wesentlich mehr Features auf der Website haben, die natürlich auch redaktionell betreut werden müssen. Durch unsere Vielsprachigkeit, also durch diese dreizehn Sprachen, entsteht natürlich durch solche Dinge wie Alternativtexte, auch ein erhöhter Übersetzungsaufwand. Aber, wenn man sich anschaut, was wir insgesamt an Übersetzungsaufwand haben, dann ist das eigentlich marginal was da durch die Barrierefreiheit hinzukommt. Und eigentlich schon fast nicht mehr erwähnenswert. Auf der anderen Seite dazu, steht aus unserer Sicht der Nutzen der Accessibility. Eben, wie vorher erwähnt, einerseits durch die relevante Zielgruppe, andererseits durch das ganzheitliche Service-Design was wir erreicht haben und eben die Optimierung für Suchmaschinen.
Ich habe versucht, das einmal in Zahlen zu fassen und habe hier in einer Tabelle einerseits qualitative Kriterien, wie die Besuchsdauer und die Seitenaufrufe und als quantitatives Kriterium die Seitenzugriffe dargestellt. Einmal vor dem Launch, also das sind die Zahlen aus aus dem September 2008. einmal nach dem Launch, die Zahlen September 2009. Bei der Besuchsdauer sind wir von durchschnittlich von vier Minuten 25 auf rund fünf Minuten gestiegen. Bei den Seitenaufrufen von 4,86 im Durchschnitt Seiten pro Besuch auf 5,62 und bei den (verspricht sich) Seitenzugriffen von 1,6 Millionen auf 1,7 Millionen. Das sind schon sehr beachtliche Steigerungszahlen, also bei der Besuchsdauer rund 18 Prozent mehr, bei den Seitenaufrufen dreizehneinhalb Prozent mehr und bei den Seitenzugriffen fast fünf Prozent mehr. Natürlich spielen hier viele Faktoren rein und man kann es nicht nur auf die Barrierefreiheit hinzu, also nicht nur auf die Barrierefreiheit zurückführen, aber ich bin der Überzeugung, dass die Barrierefreiheit hier einen wesentlichen Beitrag leistet. Ja und somit übergebe ich an den Michael Stenitzer.
Michael Stenitzer und Manuela Vergud bei ihrem Vortrag.
Michael Stenitzer: Danke Manuela. Ich darf im Folgenden ein paar Punkte herauspicken. Ein paar Punkte, die so wie beim Michael Barthofer, auch dazu geführt haben, dass im Laufe des letzten Jahres meine Barthaare ergraut beziehungsweise weiß geworden sind. Ja, insgesamt sind natürlich sehr, sehr viele technische Accessibility-Aspekte in dieser Site eingebaut und integriert und ich möchte ein paar rausgreifen, die auch gut transportiert werden können, wo ich nicht zu technisch werden muss. Und wo ich Ihnen ein bisschen das Konzept dahinter, die Überlegungen dahinter, hoffentlich vermitteln kann. Der erste Punkt, wie wir heute schon einmal am Vormittag gehört haben – es geht um Tastaturnutzung. Ein sehr, sehr wichtiger Punkt aus Sicht der Accessibility. Und leider allzu häufig auch unterschätzt. Das kommt sicher eben auch aus der Zeit, wo man noch nicht so intensiv mit JavaScript gearbeitet hat.
Und gerade durch JavaScript muss man hier eben aufpassen, dass haben wir heute Vormittag gehört. Zum Beispiel, wenn ich Events auf nicht fokussierbare Elemente setze. Typisch zum Beispiel ein Click-Event-Handler auf einem Bild. Das erreiche ich mit der Tastatur nicht. Dasselbe Problem habe ich, wenn ich gewisse Inhalte erst, zum Beispiel bei einer Reiter Navigation sukzessive einblende. Wenn ich das mit der Tastatur nicht erreichen kann, gibt es gröbere Probleme. Ein Beispiel, das ich zeigen möchte, das ist die Sprachnavigation. Manuela hat es vorher erwähnt, es gibt dreizehn Sprachen auf der Website. Und das ist eine Navigation, ich könnte natürlich diese dreizehn Sprachen nebeneinander, untereinander, wie auch immer, auf der Seite darstellen.
Aber diese Navigation werde ich üblicherweise einmal benutzen. Da werde ich mir die Sprache, die bevorzugte Sprache einstellen. Das heißt, eigentlich möchte ich hier ein bisschen Platz sparen – es gibt sehr viele Infos auf der Website. Und ich kann eine aufklappbare Sprachnavigation umsetzen. Die Frage ist, wie setze ich das um? Aufklappbar – da denkt man wahrscheinlich als erstes einmal an die Select-Box. Typisches Formularelement zum aufklappen. Die Alternative – oder ja, bleiben wir bei der Select-Box. Die Select-Box ist aber ein Formularelement und hier geht es eigentlich aus semantischer Sicht nicht wirklich um ein Formular abzusenden. Sondern es geht einfach darum, um Links zu alternativen Seiten zu haben. Nämlich um Seiten, von Seiten in anderen Sprachen. Darüber hinaus habe ich mit der Select-Box sehr häufig ein Problem mit einem – ich weiß nicht, ob Sie diesen Browser aus Redmont kennen – aber – ein sehr lästiges Ding! (lacht) Also die Select-Box im Zaum zu halten mit CSS, das ist nicht immer ganz lustig. Die Alternative ist einfach eine unordererd List zu nehmen, eine, ein UL-, HTML-Element, also eine Linkliste. Die kann ich mit CSS relativ einfach beliebig gestalten – ich mache das ja auch bei anderen Navigationen. Das Problem an dieser Linkliste ist natürlich nur, dass die Funktionalität eigentlich noch nicht da ist. Und diese Funktionalität, die muss ich nachbauen. Ich zeige Ihnen das jetzt einmal kurz. Das finde ich super! (versucht etwas zu präsentieren) (....) Auch so. (...) Ungewohntes Notebook …
(Pause – da Notebook-Probleme)
Aus dem Publikum: (aus dem Publikum) Das wird Nichts!
Michael Stenitzer: Gut, das schaut nicht gut aus. Nein.
Aus dem Publikum: (Zuruf aus Publikum)
Michael Stenitzer: Wunderbar!
Aus dem Publikum: (Zuruf aus Publikum)
Michael Stenitzer: (.....) Typischer Vorführeffekt!
Aus dem Publikum: (Zuruf aus Publikum)
Michael Stenitzer: Ja. Haben wir, haben wir schon gemerkt! Also, ich versuche es Ihnen in Worten kurz zu erläutern – ist natürlich nicht so super! Wenn ich mit dem Tabulator am Beginn der Seite durchtabbe, dann bekomme ich zuerst die Zielgruppennavigation. Also Besucherwebsite, B2B-Website, Presseportal. Und komme dann auf die Sprachnavigation. Und würde dann mit der Tabulatortaste einfach weitergehen, damit man nicht die ganzen Sprachen durchtabben muss. Komme dann zu Kontakt – was auch immer. Wenn ich nicht durchtabben möchte, sondern die Sprache auswählen. Dann wäre sozusagen visuell die aktuelle Sprache, also im gewählten Beispiel Deutsch, sichtbar markiert. Aber das macht nicht viel Sinn, Deutsch erstens einmal als Link drinnen zu haben, weil ich bin ja auf der deutschen Seite. Und auch, der Linktag, zum Beispiel für Screenreader-User, der mit Deutsch sagt, wird mir nicht klarmachen, dass ich hier die Sprache auswählen kann.
Das heißt, in Wahrheit ist der Linkfokus auf einem nicht sichtbaren, aber lesbaren Element, das heißt, Sprache auswählen. Visuell ist er aber offensichtlich auf Deutsch. Und habe dort auch diesen, dieses Dreieckchen nach unten, das ich üblicherweise habe, wenn ich Listen aufklappen kann. Wenn ich diesen Link betätige, öffnet sich die Liste und ich kann ganz normal innerhalb dieser Liste die Sprachen wählen. Komme ich mit meinem Link-Fokus wieder raus aus dieser Liste, dann schließt sich dieses Klipp-Klapp-Dingens. (...) Wir haben auch überlegt, soll man da eine Pfeiltasten, mit den Pfeiltasten innerhalb dieser Liste navigieren können, oder mit dem Tabulator. Und das Wesentliche scheint uns dann doch die Tabulatornavigation. Weil, (lacht) der Chris sagt nein. Ich meine man kann natürlich schon Beides nutzen. Aber die User sind innerhalb einer Linkliste gewohnt – wenn sie das als Linkliste erfahren – mit einem Tabulator im Web von Link zu Link zu springen. Und das ist uns schon ein, als ein wichtiger Usability-Punkt auch erschienen. Also wir glauben, dass einfach die Pfeilnavigation im Web noch eine sehr ungewohnte Sache ist. Und daher scheint uns das schon wichtig, dass die Tabulatornavigation hier funktioniert. Das haben wir schon durchgenommen.
Ein zweiter Punkt, der immer wieder diskutiert wird, das ist sozusagen die Effizienz für Tastatur-Nutzerinnen und Nutzer. Auf so einer Seite hat man natürlich jede Menge Links. Das geht dann schnell einmal über die hundert hinaus. Und das macht es unter Umständen eben langwierig und mühsam sich darinnen, darin zurechtzufinden. Da gibt es die Sprungmarken. Also gleich am, am Beginn zum Inhalt springen und zur Navigation springen. Aber das alleine hilft noch nicht immer. Wir haben hier eine Navigation umgesetzt, bei der ich aus jedem Navigationspunkt, zumindest mit der Maus, auch alle Sub-Navigationspunkte erreichen kann, ohne die Seite wechseln zu müssen. Das ist ganz typisch eben ohne Style-Sheets hier mit einer verschachtelten unordered List umgesetzt. Das heißt, Sie sehen, Sightseeing, Musik und Bühne sind Haupt-Navigationspunkte und die Punkte, die da eingerückt stehen, Sehenswürdigkeiten, Museen, Ausstellungen und so weiter sind die zugehörigen Sub-Navigationspunkte. Das kann für Mouse-User die Benutzung beschleunigen. Wir haben aber mit einigen Tastaturbenutzern gesprochen vorher im Umfeld und haben uns das überlegt und abgewogen. Und sind zu dem Schluss gekommen, dass wir für die Tastatur ein konventionelles Verhalten bevorzugen. Nämlich wo ich nur aus dem aktuellen Bereich die Subnavigationspunkte direkt auf der Seite erreiche. Und wenn ich in einem anderen Bereich, also zum Beispiel im Bereich “Wien für”, den Unterpunkt Familien erreichen will, dann muss ich eben über diesen Wechsel des Bereiches dann erst dorthin gelangen.
Das ist das Verhalten, was man ja auch durchaus von Navigationssystemen gewohnt ist. Und aufgrund des User-Feedbacks ist uns das als praktikabler für TastaturnutzerInnen erschienen. Der dritte Punkt – auch eine Sache, die heute schon angesprochen wurde – ein barrierefreier Mediaplayer – also für Audio und Video. Wir haben schon gehört, die Flashintegration ist nicht immer einfach zu nutzen. Es hat erst vor einiger Zeit eine Screenreader-Umfrage in den USA gegeben, wo Flash als Barriere Nummer Eins von den Usern genannt wurde. Und das liegt einfach daran, unter anderem – also es gibt da natürlich vielfältige Gründe – unter anderem, dass der Umgang mit der Tastatur hier nicht immer ganz einfach ist. Entweder man kommt nicht ins Flash rein, man kommt nicht raus. (lacht) Was noch schlimmer ist. Und man findet sich drin nicht zurecht. Darüber hinaus gibt es bei Flash bei, bei Mediaplayers gleich einmal, also wenn ich so einen fertigen Mediaplayer nehme unter Umständen Probleme mit der Lokalisierung. Das heißt, dass alle Buttons übersetzt werden in die dreizehn Sprachen, die wir haben. Dass das einwandfrei funktioniert, das ist nicht immer so leicht umzusetzen. Wir haben auch den JW-Mediaplayer verwendet, an und für sich ein sehr gutes Produkt mit dem wir auch zufrieden sind. Das eben auch den Vorteil hat einer API einer Programmierschnittstelle, die ich über JavaScript erreichen kann.
Und wenn der Player mit JavaScript eingebettet wird beim Laden einer Seite, dann werden auch unter dem Player einfache HTML-Elemente nämlich im konkreten Fall Links eingefügt, mit Images, die Alternativtexte haben. Und habe hier sozusagen eine voll tastaturzugängliche Steuerung des, des Players. Ein Ding muss man dabei noch berücksichtigen, ich habe ja weiterhin das Flashobjekt in der Seite drinnen und muss verhindern natürlich, dass man aus versehentlich mit der Tastatur da rein kommt. Das heißt, das Objekt, dass mir hier das Flash einbindet bekommt einen, einen Tab-Index Minus Eins. Das ist so ein Attribut, das verhindert, dass man mit der Tastatur da den Fokus daraufsetzen kann, das geht dann nur mehr über JavaScript. Und wir werden diese Lösung auch, sobald wir dazukommen, einmal in unserem Blog anbieten. Es gibt auch andere solche Player, die haben halt für uns nicht so gut gepasst, auch weil wir eben, weil Sie zum Beispiel ein anderes JavaScript Framework verwenden als wir. Wir haben jQuery, aber das ist sowieso das verbreitetste glaube ich auch. Ja, vierter Punkt. auch hier geht es noch einmal um das Thema JavaScript. Wir haben eben nicht auf JavaScript verzichtet – sehen auch nicht wirklich einen Grund dazu – sondern haben wir uns eben nach dem System Progressive Enhancement, das wir heute schon gehört haben, an dem orientiert. Vielleicht in anderen Worten noch einmal gesagt: Progressive Enhancement, anhand von diesem Sandwich, von diesem Super-Sandwich: Wenn Sie das Brot alleine – oder das Laberl alleine – erhalten werden Sie auch satt.
Das JavaScript bringt halt den mittelalten Gouda, die Salami aus der Toskana, die Eier, den Salat, Gurke und Tomate hinein. Also macht es besser benutzbar, macht es geschmacklich etwas, wertet es geschmacklich etwas auf. Das ist jetzt auch schon ein bisschen, jetzt beginnt die Einstimmung auf die Mittagspause. (lacht) Also wenn Sie es ein bisschen brummen hören, dann ist das mein Bauch. Das heißt, ohne JavaScript, wenn Sie (lacht) Ja, ja, ich habe es angekündigt! Die Seite, die ich vorher aufrufen wollte, wäre übrigens auch so etwas gewesen. Wenn Sie die Seite ohne JavaScript anschauen, dann sehen Sie hier oben die Sprach-Navigation als horizontal angeordnete Liste. Genauso gut benutzbar, braucht halt ein bisschen mehr Platz, Sie sehen noch zusätzliche visuelle Elemente. Aber es ist einfach – es funktioniert. Ohne JavaScript habe ich dieses Klipp-Klapp-Dingens. Dabei muss man aufpassen in der Praxis natürlich, dass das beim Laden dann nicht springt. Da kann man ein paar einfache Tricks sich behelfen. Ja, da lesen Sie am besten in unserem Blog dann die technischen Details nach.
Ein anderes ein anderer Punkt ist ein Star-Rating-Dingens, also um das Bewerten von Artikeln mit so einem eins bis fünf Sterne System zu ermöglichen. Man glaubt gar nicht wie kompliziert so ein Star-Rating-Widget sein kann. Ohne JavaScript habe ich eine Beschriftung, habe die aktuelle Bewertung – die ist hier Null Sterne, weil das System erst in den nächsten Tagen online gehen wird – ich habe eine, eine Select-Box, wo ich auswählen kann welche Bewertung ich möchte und habe einen Okay-Button. Schaut nicht besonders sexy aus – aber es funktioniert. Braucht auch relativ viel Platz. Wenn ich JavaScript habe, dann habe ich so ein kleines Dingens wo bewerten steht, die Sterne, kann das mit der Maus, mit der Tastatur bedienen. Und habe, sobald ich das bediene auch ein kleines, eine kleine Info-Box, die mir hilft sozusagen die Bewertung durchzuführen und zu interpretieren. Das ist Progressive Enhancement! Und der letzte Punkt auf den ich eingehe, das ist dieses Akronym. Auch das ist heute schon gefallen, WAI-ARIA, was ist eigentlich WAI-ARIA, ganz kurz: Es ist ein W3C-Standard in Vorbereitung. Wird hoffentlich in Bälde erscheinen. Es ist sozusagen ein Plug-in für HTML und ähnliche Markup-Languages.
Und zwar ein Plug-in, das mir die Barrierefreiheit verbessern soll. Insbesondere von Websites, die halt etwas dynamischer und komplexer gestaltet sind. Überall dort, wo HTML seine Grenzen hat. Und zwar mit den Zielgruppen, ganz konkret Screenreader-User und TastaturbenutzerInnen. Und im Prinzip ist WAI-ARIA nichts anderes als gelebtes Progressive Enhancement. Das heißt, kann Ihr Browser, Ihr Screenreader, WAI-ARIA nicht interpretieren, wird er es einfach ignorieren. Und die Seite kann halt die Vorteile nicht nutzen, sollte aber trotzdem benutzbar sein. Das bringt mir auch den wesentlichen Vorteil, ich kann es bereits heute einbauen, auch wenn es noch nicht in allen Technologien funktioniert. Und es geht auch relativ leicht. Also der, der Anfang – und ich möchte hier die einfachsten Nutzungsmöglichkeiten nur vorzeigen, es geht auch viel komplexer – die können Sie wirklich recht schnell und mit geringem Aufwand erreichen. Noch einmal die Seite, diesmal ist es die geröstete Kalbsleber. (lacht) Kommt man als blinde NutzerIn auf die Seite, wird man unter Umständen ein Problem haben sich zurechtzufinden. Das ist alles kompliziert und Navigationen sind mit unordered Lists umgesetzt, ich meine das lernt man mit der Zeit dann in der Nutzung, dass das wahrscheinlich eine Navigation ist, aber wirklich ein echtes Navigationselement gibt es nicht. Es gibt auch keine Navigationselemente, die mir sagen, das ist der Haupt-Content und das sind die Marginalspalten, das sind sekundäre Inhalte. Diese Rollen muss ich zurzeit mit verborgenen Überschriften zum Beispiel zuordnen. Das heißt, ich habe in der Seite drinnen verborgene Überschriften, die für Screenreader aber lesbar sind, wo dann steht Hauptnavigation (räuspert sich) oder andere Informationen.
Mit WAI-ARIA kann ich diesen Bereichen Labels geben, die visuell nicht sichtbar sind, die mir aber diese Rollen zuordnen und die in geeigneten, modernen Screenreadern dann durchaus vorgelesen werden. Diese Labels sind Banner, das ist der Standard für einen Headerbereich, diese Labels können Navigations sein, complementary – das heißt, dass es sekundäre Inhalte sind – und Main ist der Haupt-Content. Und ich kann auch mit dem Screenreader diese Bereiche gezielt ansteuern. Ein anderer Nutzungsbereich, wo wir WAI-ARIA einsetzen, ist bei Formularen – ich kann im HTML nicht wirklich verpflichtende Formularfelder oder Fehleingaben auszeichnen, ich kann das nur mit Text machen – das ist unter Umständen relativ schwierig zu nutzen für Screenreader wieder. Mit WAI-ARIA habe ich ein Attribut, das heißt, area required = true, und das sagt mir einfach das Eingabefeld ist verpflichtend. Und genauso gibt es ein Attribut area invalid = true, das mir sagt, die Eingabe hier war ungültig. Das wird auch von einem geeigneten Screenreader kommuniziert an die User. Das Problem ist eben WAI-ARIA ist ja kein Teil von HTML und damit würden unsere Seiten nicht mehr validieren. Jetzt ist die Validierung im Prinzip keine heilige Kuh, aber eine valide Seite ist sozusagen ein wichtiges Element einer Qualitätssicherung. Und wenn ich nur sehe, im Browser oder wo auch immer, die Seite ist invalid, dann muss ich erst unterscheiden – was sind denn die, die braven und die bösen Fehler da drin, das wird schnell ziemlich nervig. Und jetzt haben wir uns einfach mit einem Trick beholfen.
Wir nehmen das Class-Attribute her – das ja allgemein verwendbar ist, bei praktisch allen HTML-Elementen – fügen in dieses Class-Attribute zum Beispiel den Wert aria required ein und mit einer geheimnisvollen JavaScript-Transformation wird das dort rausgenommen und ein Attribut area required = true in das HTML-Element eingefügt. Und bei der Validierung funktioniert es, zeigt mir sozusagen das grüne Häkchen, dass die Validierung okay ist an. Und trotzdem habe ich den Nutzen von WAI-ARIA. Ich sage Danke schön. Wie man in Wien sagt: “Mahlzeit”. Das sagt man in Wien schon seit ein paar Stunden. (Publikum lacht) Wir stehen gerne noch für Fragen zur Verfügung – auch per E-Mail. (zögert) Wen es ein bisschen mehr interessiert da unter die “Tuchent” zu blicken – unter die Bettdecke – wir haben in unserem Blog derzeit eine Serie laufen. Da wird es mindestens zehn Artikel dazu geben – vier sind schon online – die ein bisschen dieses Making-of von der Website beschreibt. Einerseits Accessibility, aber auch andererseits technische Sachen – CMS, Internationalisation und Lokalisation, Hosting und so weiter. (Publikum klatscht)
Moderation Eric Eggert: Vielen Dank Euch beiden für dieses Vortragsdingens, (lacht) wenn ich das mal aufgreifen darf. Wenn es noch Fragen gibt – bitte, jetzt ist die richtige Zeit dafür!
Michael Stenitzer: Ins Mikrofon-Dingens.
Aus dem Publikum: Mich würde interessieren – bei dem Vortrag, beziehungsweise beim letzten Vortrag war es bei beiden Vorträgen so, dass man gesagt hat, Kosten quantifizieren wir, aber können wir nicht quantifizieren. Mich würde generell interessieren ob bei diesen Projekten zumindest das Potenzial analysiert wurde, denn man kann man ja nicht immer nur – unter Anführungszeichen – von Screenreader-Usern und dergleichen ausgehen, die im Jetzt leben. Sondern Faktum ist, dass man im Jahr 2050 oder 2030 einen größeren Teil an älterer Bevölkerung haben werden. Ist das ein Thema? Das Potenzial generell, was da dahintersteckt?
Manuela Vergud: Also, ich muss ganz ehrlich sagen – wir haben das Potenzial vorher nicht analysiert. Ich glaube das hatte auch den Grund – dass wir – einerseits sind wir ein sehr kleines Team, was das Internet betreut bei uns. Und auch, und uns fehlen auch viele Erfahrungen in die Richtung. Also das Thema Barrierefreiheit im Web war für uns relativ neu – auch wo wir uns schon dafür entschieden haben. Ja, da haben wir viele Vorteile gekannt, aber haben es noch nicht im Detail gekannt. Ich habe vorher aber auch kurz eine Zahl genannt. Und zwar, wir haben auch jetzt schon 26 Prozent unserer Gäste, die über 50 Jahre alt sind. Wird tendenziell weiterhin steigen. Aber alle anderen Zielgruppen haben wir da nicht analysiert.
Michael Stenitzer: Es ist ja in der Praxis, in der Realität der täglichen Arbeit so, dass man kaum Maßnahmen wirklich ausschließlich für zum Beispiel für Screenreader-User macht. Ich meine WAI-ARIA ist da vielleicht eine Ausnahme, das ist aber auch eher nur beim ersten Mal ein bisschen ein Aufwand, wenn man sich einmal mit der Anwendung grundsätzlich auseinandersetzen muss. Aber dann ist es eine Standardgschicht, die nicht viel Aufwand ist. Und die Meisten, der Accessibility-Maßnahmen haben so viele andere Vorteile und sind einfach auch ein Element von qualitativen, von qualitativer Webentwicklung, Webdesign und so weiter, also …
(Pause)
Moderation Eric Eggert: Weitere Fragen?
Fritz Weisshart: Fritz Weisshart. Nur eine Detailfrage. Gemein! Die Liste mit den Sprachvarianten, hat sicher eine Überschrift. In welcher Sprache ist diese Überschrift?
Michael Stenitzer: Die verborgenen Überschriften. Ja, ja, die sind immer lokalisiert natürlich.
Fritz Weisshart: Nein!
Michael Stenitzer: Nein?
Michael Stenitzer: Nicht wirklich.
Michael Stenitzer: Nein ist es nicht so? (Publikum lacht) Also dann…
Fritz Weisshart: Woher weiß die Seite im Voraus, welche Sprache ein Besucher anschließend auswählen wird, aus der Liste.
(Pause)
Fritz Weisshart: (lacht) Ich bin gemein.
Michael Stenitzer: Ach so, nein das, das geht natürlich nicht. Nein, sondern die, die, die Überschrift ist in der Sprache der Seite. Ja, aber die, die Zielsprache …
Fritz Weisshart: In welcher Sprache, in welcher Sprache ist die Seite?
Michael Stenitzer: Ja in der, die man aus, also
Aus dem Publikum: Esperanto! (aus dem Publikum)
(alle lachen)
Michael Stenitzer: Es ist so. Wir haben eine Language Negotiation, das heißt, wenn man die Seite das erste Mal unter www.wien.info aufruft, ohne eine Sprache auszuwählen, dann wird mit dem Browser sozusagen ausverhandelt, welche Sprache die bevorzugte des Users ist. Also die bevorzugte Sprache eigentlich des Browsers in Wahrheit, weil da müsste der User das aktiv eingestellt haben. Und die wird dann ausgeliefert, sofern verfügbar. Und die Fall-Back-Sprache ist, wenn ich das richtig im Kopf habe, Englisch. Weil der Markt einfach der Größte ist. Und wenn ich mit Google suche, was ja sowieso, sozusagen wahrscheinlich der allergrößte – oder mit Sicherheit der allergrößte Teil der User macht, wenn sie auf die Seite kommen – dann wird man wahrscheinlich auch eine lokalisierte Google-Seite verwenden, die ja auch wieder auch die eigene Sprachversionen bevorzugt. und damit hat man auch wieder die Ergebnisse. Aber ganz auszuschließen ist es nicht. (lacht)
(Pause)
Moderation Eric Eggert: Okay. Tomas.
Tomas Caspers: Ja eine kurze Frage noch an Michael. Du hattest eben darüber gesprochen – über diese Sprachauswahl und die Entscheidung dafür eine Liste – ich nehme an wahrscheinlich eine UL oder irgendwie so etwas in HTML gesprochen – versus Option-Select-Konstriktionen zu bauen. Habt Ihr da irgendwie Erfahrung im Sinne eines AB-Tests mit Benutzern in irgendeiner Form? Was bevorzugt wird? Weil es ja schon eine ganz andere Art der Navigation ist. Was, welche Tasten drücke ich und wie kriege ich das präsentiert. Weil Du sprachst davon, dass der Benutzer die Liste als Liste präsentiert kriegt – sie sofort begreift. Er würde aber ja ein Option-Select-Konstrukt ja auch als solches präsentiert kriegen und müsste dann eben seine Tastendrücke, die er zur Bedienung solcher Konstruktionen. Mich würde mal interessieren, ob Ihr das getestet habt (zögert) AB? Mal Nutzer davor getestet.
Manuela Vergud: AB-Tests haben wir da nicht gemacht. Nein.
Tomas Caspers: Schade.
Michael Stenitzer: Wir haben jetzt gerade Accessibility bei einer Sub-Site laufen. Das ist aber die Hotelbuchungsseite, die eigentlich wieder eine ganz eine eigene Sache ist. Wo aber diese Sprachnavigation dann nur auf zwei Sprachen beschränkt ist. Ja, also, ich glaube es ist auch gar nicht so ein Usability-Problem, man wird das sicher mit der Select-Box auch benutzen können. Also aus semantischer Sicht scheint mir das Formular nicht ganz passend zu sein. Und natürlich auch von den Suchmaschinen her habe ich einfach Links, die mir auf die anderen Sprachversionen zeigen. Auch kein Fehler.
Moderation Eric Eggert: Bitte!
Buhecker: Ich habe eine Frage: Mein Name ist Buhecker. Sie haben Besucherstatistiken vor und nach dem Relaunch genannt. Ich denke jetzt da nur an die Besuchsdauer von vier Minuten 21 auf fünf drei – und leiten daraus eine messbare Verbesserung des Redesigns ab. Provokant gesagt könnte man auch schließen, dass ein Benutzer vorher die benötigte Information wesentlich schneller gefunden hat.
(Publikum lacht)
Manuela Vergud: Also ich weiß nicht, ob Sie die Seite vorher kennen. Ja. (lacht) Ich glaube das beantwortet die Frage!
(Pause)
Moderation Eric Eggert: Okay. einmal kurz …
Michael Stenitzer: Ich meine solche Zahlen sind sehr, sehr vielschichtig und schwierig zu interpretieren. das ist uns klar, dass das nicht so aussagekräftig alleine ist.
Moderation Eric Eggert: Okay. für eine kurze Frage hätten wir noch Zeit. Wenn nicht, hätte ich noch ein bisschen was Organisatorisches. Gut. Dann bitte ich schon einmal, während ich jetzt hier Organisatorisches rede den Tomas Caspers nach vorne, der davon noch nichts weiß – das finde ich nett.
Tomas Caspers: (lacht)
Moderation Eric Eggert: Und zwar gibt es für diejenigen, die mit Autos da sind, Parktickets zu kaufen. Wenn ich das richtig mitbekommen habe. Dann machen wir das wahrscheinlich da vorne an der, an der Anmeldung. Sechs Euro kosten die. Aber … (aus dem Hintergrund) Bis 22.Mai.
Moderation Eric Eggert: Bis 22. Mai, okay. Also falls jemand so lange braucht… (...)
Moderation Eric Eggert: Ja. Falls sie Keines kaufen, können Sie nicht raus! Das ist. (lacht) Gut. Dann, was ich noch sagen wollte, bitte die Aussteller besuchen, da hinten im Raum. Damit die auch die benötigte Aufmerksamkeit bekommen. Das ist glaube ich eine sehr sinnvolle Sache. Weil, ja, deswegen sind Sie alle hier. So und jetzt, Thomas (...) Komm mal her! (...)
Tomas Caspers: Ja, Herr Lehrer (lacht) (....) (Pause)
Moderation Eric Eggert: Sag mal was dazu …(lacht)
Tomas Caspers: Ja, gut. Also der Grund warum ich jetzt hier vorne stehe ist, wie vielleicht einige von Ihnen wissen, arbeiten einige von denen, die heute auch alle hier sind an einer deutschen Übersetzung der WCAG 2.0. Und eigentlich wollten wir die fertige Übersetzung heute veröffentlichen. Aber aufgrund von diversesten Gründen, die teilweise in, teilweise nicht in unserer Kontrolle liegen, sind wir eben doch noch nicht soweit. Ich würde Ihnen aber trotzdem jetzt nicht zumuten wollen, den schon vorbereiteten Sekt dann nicht trinken zu dürfen. Weil wir wollten eigentlich dann mit Ihnen zusammen darauf anstoßen, dass wir mit der Übersetzung der WCAG 2 fertig sind. Und wir machen es einfach trotzdem, denke ich mal. Also wir sind kurz vor fertig. (Publikum klatscht) Wir sind, wir sind – also Übersetzung ist fertig – es fehlen nur noch ein paar Formalien und darauf trinken wir jetzt Einen. (M lacht)
Moderation Eric Eggert: Okay. Und damit darf ich Sie zum Mittagessen entlassen. Mahlzeit!
Bilder von Karola Riegler. Intro von Derek K. Miller.
Manuela Vergud
Michael Stenitzer