Gastvorlesung Barrierefreiheit

Letzte Woche war ich eingeladen, an der Johannes Gutenberg-Universität Mainz einen Gastvortrag zu barrierefreien Websites zu halten. Nach dem im November sehr erfolgreich verlaufenen Barcamp an der Uni Mainz hatte der damalige Geschäftsführende Leiter des Instituts für Informatik, Prof. Dr. Herbert Göttler, die Idee, diesen Kontakt fortzuführen. Und so gibt es nun eine kleine Reihe zu aktuellen Internetthemen aus der Praxis.

Ich beleuchtete zuerst den sich gesellschaftlich und politisch wandelnden Begriff der Behinderung, leitete dann über zur demographischen Entwicklung und damit zu Barrierefreiheit als wirtschaftlichem Imperativ, zeigte einige Barrieren und Techniken aus der Praxis als „virtuelle Rollstuhlrampen“ und endete mit einem Ausblick auf die Herausforderungen, denen wir uns gerade in der HTML Accessibility Task Force im W3C stellen.

Die Folien gibt’s wie immer auf Slideshare, auch zum Download (15 MB). In der PowerPoint-Datei sind übrigens Notizen als Ersatz für die „Tonspur“.

Und die Geschichte geht noch weiter: Ab nächstem Wintersemester habe ich einen Lehrauftrag, um den Studierenden nachhaltige Frontend-Entwicklung mit aktuellen Techniken nahezubringen. :-)

Web Performance Optimierung (WPO)

Gestern hielt ich auf dem Webmontag in Frankfurt einen Vortrag über Web Performance Optimierung. WPO wird nach Vorhersagen in den nächsten Jahren wie SEO eine eigene Industrie werden. Tenni Theurer und Steve Souders begannen 2006 bei Yahoo!, die Performanz von Webseiten eingehender zu untersuchen. Entsprechend der Prämisse, dass man am Ende mehr profitiert, wenn man seine Erkenntnisse mit anderen teilt, publizierte Yahoo! diese Ergebnisse auf Konferenzen und Blogs noch im selben Jahr. Souders veröffentlichte in der Zwischenzeit zwei Bücher zum Thema und arbeitet heute bei Google. Bei Namics befassen wir uns mit WPO seit Sommer 2006 und teilen auch gerne.

Ziel von Web Performance Optimierung ist es, schneller und kleiner zu werden: Studien von Yahoo! und Google haben ergeben, dass nur 10-20% der Ladezeit vom Server abhängig ist. Bis vor wenigen Jahren dachte man bei Geschwindigkeit ausschließlich an den Server. Tatsächlich werden aber 80-90% der Ladezeit im Frontend fällig. Darum ist WPO im Frontend effizienter.

Zwei wichtige Schwachstellen sind JavaScript-Dateien und die schiere Anzahl von Dateien: JavaScript lädt sequentiell und blockiert sämtliche nachfolgenden Inhalte. Darum sollte es nicht im Kopf, sondern im Fuß einer Seite stehen. Zweitens können ältere Browser, vor allem der Internet Explorer, nur 2-4 Dateien parallel laden. Dateien bilden eine Warteschlange, die nur langsam abgearbeitet wird. Ziel ist es darum, durch Zusammenfassung von Dateien die Anzahl der HTTP-Requests zu reduzieren.

Verschiedene internationale Unternehmen haben Studien angestellt oder einfach den Effekt von Optimierung getrackt.

Effekte von Langsamkeit

Effekte von Geschwindigkeit

  • Mozilla hat seine Downloadseite um 2,2 Sekunden schneller gemacht, was durch 15,4% mehr Downloads belohnt wurde.
  • Google Maps reduzierte das Dateivolumen um 30% und beobachtete daraufhin 30% mehr Kartenaufrufe.
  • Netflix schaltete Gzip auf dem Server ein; alleine dadurch wurden die Seiten um 13-25% schneller und sie sparten 50% Dateivolumen ein!
  • Shopzilla schaffte es, die Ladezeit von 7 auf 2 Sekunden zu reduzieren, wodurch die Conversion Rate um 7-12% stieg, 25% mehr Seitenaufrufe beobachtet wurden, 50% der Server in den Ruhestand geschickt und entsprechend Energiekosten eingespart werden konnten.
  • AOL beobachtete die Anzahl der Page Views auf verschiedenen Websites. Während die schnellsten User 7-8 Seiten aufriefen, waren es bei den langsamsten durchschnittlich nur 3-4.

Als Sahnehäubchen hat vor kurzem Google angekündigt, künftig die Ladezeit als Parameter im Suchmaschinenranking zu berücksichtigen.

Am Ende werden die Seiten schneller, die Kunden sind glücklich, generieren mehr Umsatz und Page Views, und gleichzeitig sinken Stromverbrauch und CO2-Ausstoß. Wieder einmal die Welt gerettet! Und wer dazu beitragen möchte, beginnt am besten damit, sich die Regeln bei Yahoo! anzuschauen. Ein paar Tricks, die darüber hinaus gehen, gibt’s in der Präsentation.

Heroes – Transmedia Storytelling

Ein anderes inspirierendes Panel auf der Internetkonferenz SXSW hatte Tim Kring als Interviewpartner. Er ist Drehbuchautor und begann seine Karriere mit Episoden für Knight Rider, erzielte seinen Durchbruch mit der Kultserie Crossing Jordan und seit 2006 mit Heroes. In einer Alternativen Realtität entdecken die Protagonisten darin, dass sie Superkräfte besitzen.

What would Rupert do?

Das gängige Schema für eine erfolgreiche Serie wäre bisher, Lizenzprodukte zu verkaufen. Da gibt’s dann eine lieblose Website, T-Shirts, Kaffeetassen, DVDs, Comics, und am Ende produzieren die Stars noch einen mittelmäßigen Popsong. Fanseiten werden abgemahnt, und die Branche jammert über schlechte Umsätze wegen der bösen Piraten. Wir haben es aber auch schon erfolgreicher erlebt, etwa wenn die Fantasy- und Science-Fiction-Romanserien zu Forgotten Realms oder Shadowrun populärer werden als das original Rollenspiel. Am Ende haben all diese Produkte die gleiche fiktive Welt zum Hintergrund, in sich bleiben die Medien aber weitgehend geschlossen: Zum Verständnis der Romane ist es nicht erforderlich, dass ich das Spiel kenne.

Was ist dann Transmedia? Hier im Schnelldurchlauf eine Einführung:

Heroes Transmedia Storytelling Extensions

“Heroes provides the most innovative and immersive interactive TV experience on the web.”

The Long Tail: Jugendliche mit Flammenwerfern

Einer der unterhaltsamsten Vorträge bei SXSW letzte Woche war What We Learned Watching Kids With Homemade Flamethrowers. Für diejenigen unter uns, die mit diesem Microgenre noch nicht vertraut sind, eine kleine Einführung:


"Mega Secrets" Homemade Flamethrower Music Video
YouTube Video

Was können wir daraus lernen?

Ada Lovelace Day 2010

Heute ist Ada Lovelace Day, ein internationaler Blogging-Tag, um die Errungenschaften von Frauen in Technologie und Wissenschaften zu feiern. Augusta Ada King, Gräfin von Lovelace, schrieb die ersten Programme für Charles Babbage’s mechanischen Computer.

Die Zukunft des Webs

Letzte Woche habe ich meinen Orakel-Hut aufgesetzt und einen Vortrag auf der WebTech-Konferenz in Karlsruhe zur Zukunft des Webs gehalten. Natürlich habe ich wieder ein T-Shirt bekommen, was der eigentliche Grund dieses Blogeintrags ist, ;-) aber ehrlich gesagt finde ich es nicht so schön. Es ist einfarbig blau, und auf der Brust prangt groß das Wort „Speaker“, was ich etwas reißerisch finde.

Auch negativ das Rekordtief des Frauenanteils auf der Konferenz: von 65 Vortragenden nicht eine, null, zero Frau! Entsprechend gab es auch im Publikum einen Frauenanteil, der geringer war als der in einer Schwulendisco, und die wenigen anwesenden Frauen gehörten meist zum Catering-Team. Gleichberechtigung geht anders.

822-webkrauts-webtech-thumb-500x342-821.jpg

Schön war aber insbesondere der Thementag der Webkrauts (Foto). Während Eric Eggert sich mehr um CSS3, Webfonts und Browser APIs kümmerte, habe ich in meinem Vortrag heutige und zukünftige W3C-Technologien vorgestellt, hier die Links dazu. Darunter stechen insbesondere das HTML5 Canvas-Element, Video und 3D hervor:

Canvas kann Inhalte verzerren, drehen, wölben, filtern und einige Dinge mehr, und es ist dynamisch per JavaScript programmierbar.

<video>

direkt im Browser ohne Flash ermöglicht Unabhängigkeit von Adobe, was gerade für Geschäftsmodelle wie das von YouTube, Dailymotion oder die BBC wichtig ist. Darüberhinaus können Canvas und Video in Kombination spannende Effekte erzielen. Dailymotion hat ein paar davon in der Demo eingebaut.

Und 3D im Browser eröffnet völlig neue Möglichkeiten für Spiele und andere Anwendungen, bei denen per WebGL dreidimensionale Daten und Modelle effizient übertragen werden können. Stereoskopische Effekte wie im Film „Oben“ habe ich allerdings noch in keiner Browser-Demo gesehen.

Bislang ist Barrierefreiheit von den Browserherstellern in den neuen Technologien kaum berücksichtigt worden, aber die neugegründete HTML Accessibility Task Force, deren Mitglied ich bin, wird sich der Themen annehmen.

Uns steht jedenfalls eine sehr aufregende Zukunft bevor!

Mozilla Camp Europe

Irgendwie hat Namics einen Fetisch für T-Shirts. Es bloggen nicht nur manche Personen obsessiv darüber, mein Arbeitgeber möchte nun auch noch, dass ich jedesmal darüber blogge, wenn ich selbst ein T-Shirt bekomme!? Also, ich habe zwei T-Shirts geschenkt bekommen:

611-mozcamp-shirt.jpg 610-mozcamp-mobile.jpg

Das eine T-Shirt gehört zur Mozilla Mobile Community und hat auf der Vorderseite diesen verzweifelt gegen die Scheibe seines Sputnik hämmernden Weltraumbiber, auf der Rückseite den Spruch “You took back the Web. Now take it with you.” (eine Referenz auf das andere Shirt, “Take back the Web”), das zweite T-Shirt zeigt die Silhouette von Prag auf olivgrünem Grund mit schönen Jugendstil-Elementen.

Die Jugendstil-Elemente waren auch in Prag zu finden, denn dahin mußte ich reisen, um die beiden T-Shirts in Empfang zu nehmen. Von diesem bedeutenden Übergabeakt abgesehen mußte ich zuvor an einer Podiumsdiskussion über HTML5 teilnehmen und dabei etwas über die Barrierefreiheit des zukünftigen Standards erzählen. Ich weiß, Ihr interessiert Euch eigentlich nur für T-Shirts in diesem Blog, darum verzeiht, wenn ich ein wenig off-topic zu diesem Thema langweile:

615-mozcamp-tag.jpg Ich bin Invited Expert in der HTML-Arbeitsgruppe des W3C. Außerdem befasse ich mich seit ungefähr zehn Jahren mit dem barrierefreien Web. Wie kommt das nun zusammen? Vorerst gar nicht. Denn im Moment sind die neuen HTML-Elemente wie

<section>

oder

<nav>

für Blinde unsichtbar, denn sie werden noch nicht vom Browser maschinenlesbar-semantisch auf die Betriebssystemebene „übersetzt“. Hingegen erfasst der Browser die Rolle als Navigation hervorragend und lässt Screenreader „Menü“ vorlesen, wenn diese mit einem anderen Standard des W3C übermittelt wird, ARIA. Da muss also noch etwas getan werden. Ebenso weitgehend undefiniert sind die Bedienmechanismen für Video und Audio im Browser oder das Universaltalent Canvas. Die gute Nachricht: eine gemeinsame Task Force mit HTML– und Barrierefreiheitsexperten wird sich beim W3C dieses Themas annehmen. Denn wie wir alle wissen, profitieren Projekte davon, frühzeitig Barrierefreiheit ins Konzept zu zu integrieren, statt später aufwendig „ein bißchen“ Barrierefreiheit grob dranzudübeln. Und Euer bescheidener Gastgeber wird versuchen, dazu beizutragen. Dazu möchte ich zum Beispiel Mozilla-Genie Paul Rouget zu einem Panel bei der Konferenz South by Southwest einladen, wo er ein paar seiner progressiven Demos zeigen kann, mit deren Hilfe sich innovative Mensch-Computer-Schnittstellen realisieren lassen.

Ansonsten kann man sich das MozCamp ungefähr so vorstellen wie ein internationaleres, geekigeres Namics-Camp. Hier noch ein paar meiner Randnotizen von twitter:

  • Eine Mozilla-Kampagne zum Internet-Gesundheitscheck greift bereits das Zitat von Microsoft-Managerin Amy Bazdukas auf: “friends don’t let friends use IE6”. Zwar sind der größte Hemmschuh nach wie vor die großen Dinosaurier Unternehmen, deren IT-Abteilungen lieber auf ungeschützten Browserverkehr setzen als auf Updates ihrer internen, zehn Jahre alten Software. Aber wenn wir zumindest unseren Freunden und Verwandten einen ordentlichen Browser installieren, kommen sie ja vielleicht auf den Geschmack und lassen sich nicht mehr ewig am Arbeitsplatz vertrösten.
  • Damit Mozilla sich gegen die zunehmend agiler werdende Konkurrenz, und hier vor allem gegen Adobe, Silverlight und Gears, durchsetzen kann, müssen die Entwicklungszyklen schneller werden. Ziel ist es, alle 6 Monate ein großes Release zu machen. Darum müssen interne Prozesse entkoppelt werden, was nicht nur positive Auswirkungen auf die Testbarkeit von Nightly Builds hat, sondern auch auf die Stabilität des Browsers.
  • Firefox 3.6 ist für November geplant und wird skinbar über Personas sein, Video im Vollbildformat haben, CSS-Gradienten, JavaScript Ctypes. 3.7 könnte schon auf Android laufen. Und 4.0 kommt in einem Jahr mit Jetpack.
  • Jetpack lohnt sich etwas näher anzuschauen, denn dabei handelt es sich um eine Middleware für Mozilla-Extensions. Programmierer von Add-Ons müssen also nicht mehr bei Null beginnen, sondern haben einen bestimmten Grundumfang von Funktionen zur Verfügung. Dadurch steigt die Sicherheit, aber ich denke auch, dass die Qualität und Barrierefreiheit besser werden. Die Tastaturbedienbarkeit der Menüs sollte dann etwa selbstverständlich sein. Relevant für Webentwickler ist dabei, dass eine Seite ein Jetpack einfach per
    <link>

    einbauen kann. Du möchtest in einem Shop die Webcam des Besuchers verwenden, um ein T-Shirt-Motiv direkt im Browser mit

    <video>

    und

    <canvas>

    als augmented reality auf die Brust des Nutzers zu projizieren? Ein Jetpack hat die Rechte dazu.

  • Mozilla arbeitet an Multitouch-Events und wartet noch auf Feedback der anderen Browserhersteller.
  • Artzilla widmet sich vermeintlich „nutzlosen“ Extensions: die offene Browser-Software als Kunstwerkzeug.

616-mozcamp.jpg

Fast hätte ich noch ein drittes T-Shirt bekommen mit dem pupsenden Maskottchen von Mozilla Songbird darauf. Damit hätte ich mir noch mehr von der großartigen Musik von Jiří Wehle anhören können, einem begnadeten Straßenmusiker in Prag’s Altstadt (die übrigens voller Teehäuser ist – ein Traum!), aber dann musste ich auch schon wieder zum Flughafen. Am nächsten Tag hielt ich nämlich einen Vortrag beim Webmontag Mannheim, wozu ich allerdings die Folien aus London recycelte. Und es gab dort auch kein T-Shirt, weswegen ich auch keinen Blogeintrag schreiben muss. ;-)

ARIA und HTML 5

Warnschild, das einen Rollstuhlfahrer auf abschüssigem Gelände zeigt, der auf ein Krokodil zurast.

Vorgestern hielt ich beim IKT-Forum an der Johannes-Kepler-Universität in Linz einen Vortrag über ARIA und HTML 5 in freier Wildbahn. ARIA ist ein fast fertiger Webstandard des W3C, der bereits weite Unterstützung in Browsern und assistiven Technologien wie Screenreadern hat. Auch wenn der Standard noch nicht final verabschiedet ist, sollte man die Techniken einsetzen, da sie jetzt Menschen mit Behinderungen die Zugänglichkeit zu Websites ermöglichen.

Wie immer steht meine Präsentation bei Slideshare zur Verfügung, auch zum Download. Da es dort aber gerade technische Probleme mit den Vortragsnotizen gibt, die zum Verständnis wesentlich beitragen, gibt es die gesammelten Werke einfach hier:

  1. Die Wahrnehmung von Barrierefreiheit und HTML5 ist oftmals, als wären sie natürliche Feinde.

  2. Lego Superman Minifig

    … oder kann im Gegenteil Barrierefreiheit zusammen mit HTML5 Superkräfte entwickeln?

  3. NVDA, Orca, Jaws, Window Eyes + Firefox, Internet Explorer, Safari, Opera

    ARIA wird ungefähr seit 2006 von vielen Screenreadern und Browsern unterstützt, und es kommen immer mehr hinzu.

  4. Projekte von Namics

    Im Folgenden möchte ich einige Beispiele aus der Praxis vorstellen, in denen wir ARIA eingesetzt haben.

  5. Website bahn.de

    Insbesondere auf der Startseite von bahn.de sind viele Elemente mit ARIA angereichert. Namics hat das Konzept, Design und die Frontend-Umsetzung realisiert, während die Bahn die Integration in das CMS, ins Buchungssystem und Backend vorgenommen hat (online seit Dezember 2008, weitere Entwicklungsphasen sind vorgesehen).

  6. Website fraunhofer.de

    Die neu designten Seiten der Fraunhofer Gesellschaft sind im Juni 2009 online gegangen. Sie enthalten recht viel ARIA, was nicht weiter verwundert, denn Webstandards und Barrierefreiheit sind bei Fraunhofer nicht zuletzt durch die langjährige Leitung des deutschen W3C-Büros ein wichtiger Punkt.

  7. Website der Schweizerischen Bibliothek für Blinde und Sehbehinderte

    Die neue Website der Schweizerischen Bibliothek für Blinde und Sehbehinderte wird voraussichtlich im August 2009 online gehen. Selbstverständlich ist ARIA integriert.

  8. Accessible Rich Internet Applications (ARIA)

  9. Niedrig hängende Früchte an einem Baum

    Zuerst sollten die niedrig hängenden Früchte geerntet werden. Einige Früchte bei ARIA hängen so niedrig, dass sie einem fast in den Mund fallen.

  10. Eingabefelder mit den Labels Vorname, Nachname und Adresse, die ersten beiden sind als Pflichtfelder gekennzeichnet

    Mit

    aria-required

    werden Pflichtfelder ausgezeichnet. Ein Screenreader liest dann vor: „Eingabefeld, erforderlich“. Noch ein weiterer Pluspunkt: die Sprache passt sich automatisch an, ein englischer Screenreader würde also vorlesen: „input, required“. Somit sinken die Aufwände für eine Lokalisierung.

    Video:

  11. Eingabefelder für Name und E-Mail, beides sind Pflichtfelder, die angegebene E-Mail-Adresse ist ungültig.

    Ähnlich einfach zu integrieren ist

    aria-invalid

    . Ein Formular wird serverseitig validiert, und bei ungültigen Feldern wird das Attribut

    aria-invalid="true"

    eingefügt. Ein Screenreader liest vor: „Eingabefeld, ungültig“.

    Video:

  12. Warnschild mit einem kippenden Rollstuhl auf unebenem Gelände

    Aber selbst bei diesen einfachen Schritten können Fehler unterlaufen. ARIA ist für viele Entwickler, insbesondere im Backend, noch immer eine neue Technologie. Sie sind damit nicht vertraut und übersehen vielleicht relevante Anpassungen. Das sollte man nicht unterschätzen. Als Frontend-Entwickler haben wir also die Aufgabe, diese Techniken zu erklären.

  13. Hier als Beispiel das Kontaktformular von Fraunhofer. Vorgesehen ist eigentlich, dass man per Tastatur auf den Absende-Button tabben kann, das Formular mit der Eingabetaste absendet und auf der neuen Seite Fehler unter anderem mit

    aria-invalid

    markiert werden. Umgesetzt ist aber ein Formular mit einem aus Usability-Sicht überflüssigen „Zurücksetzen“-Button, und der Absendebutton funktioniert ausschließlich mit dem JavaScript-Event

    onclick

    , woraufhin sich ein JavaScript-Alert öffnet. Damit wurde aber unwissentlich eine unüberwindbare Barriere für Menschen geschaffen, die keine Maus benutzen. Nur mit der Tastatur (oder ohne JavaScript) ist dieses Formular nicht mehr abzusenden. Um Spam zu vermeiden ist JavaScript eine ungeeignete Methode, weil sie Barrieren schafft und schlechte Usability für alle Nutzer bedeutet.

  14. Sehr gut funktioniert hingegen die Navigation, in der sogar ARIA-Landmark-Rollen wie „Menü“ vorgelesen werden.

  15. Navigation bei Fraunhofer

    In der Navigation haben wir sowohl die ARIA-Rolle

    navigation

    angegeben als auch


    GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-files/wp-content/plugins/codecolorer/lib/geshi/) (code 2)

    , das im XHTML Role-Modul spezifiziert wird.

  16. Aufklappmenü bei Fraunhofer mit angepaßtem Cursor (Pfeil nach oben und unten)

    Für das Aufklappmenü haben wir einen Link benutzt, weil diese im CSS bereits gestylt sind. Mit ARIA haben wir aber die Rolle

    button

    zugewiesen, damit ein Screenreader ihn als „Schaltfläche“ erkennt. Zusätzlich wird ein

    tabindex="0"

    benötigt, damit der Button per Tabulatortaste fokusierbar wird. Mit

    aria-controls="Ziel-ID"

    kann eine Beziehung zu einem anderen Element hergestellt werden, das von dem Button gesteuert wird. Allerdings wird diese Beziehung noch nicht von assistiven Techniken unterstützt. Macht aber nichts, in der Zukunft ist das vielleicht der Fall, und dann steht die Beziehung schon drin.

  17. HTML 5: Canvas

    Nun kommen wir zu vermeintlichen Feinden von Barrierefreiheit, dem HTML 5-Element

    canvas

    . Es ist richtig, dass derzeit Canvas von Screenreadern nicht erkannt wird und selbst Alternativtexte nicht vorgelesen werden. Bei Fraunhofer haben wir das Element aber als Verzierung eingesetzt, was unproblematisch ist.

  18. Fraunhofer Startseite: Teaser mit schrägen Ecken

    Auf einigen Seiten von Fraunhofer.de gibt es zwischen der Navigation und dem Textinhalt Teaser-Elemente, die schräge Kanten oben und unten besitzen.

  19. Teaser mit schrägen Ecken in vielen verschiedenen Farben und Schattierungen

    Es gibt sehr viele davon in unterschiedlichen Farben und Schattierungen. Entweder hätte man also zig Hintergrundbilder produzieren müssen …

  20. Canvas mit schrägen Ecken, wird in Firefox als PNG mit Data-URL angezeigt

    … oder man verwendet Canvas. Wir haben hier zunächst in der Box ein

    <span>

    -Element in den Hintergrund gelegt. Das hat per CSS eine Hintergrundfarbe, eine Transparenz (opacity) und ist rechteckig. Per JavaScript werden die Farben ausgelesen und das

    <span>

    -Element durch ein

    <canvas>

    -Element ersetzt, das schräge Ecken hat. Das wird in allen aktuellen Browsern unterstützt außer im Internet Explorer. Dazu gibt es eine Alternative, die wir gleich erfahren werden.

  21. CSS 3

  22. Runde Ecken auf Buttons

    Bei der Website der Schweizerischen Blindenbibliothek gibt es einige Bedienelemente mit runden Ecken. Hier haben wir das CSS 3-Attribut

    border-radius

    verwendet. Das ist schnell und flexibel einzusetzen und wird in fast allen Browsern unterstützt.

  23. Runde Ecken auf Buttons

    Natürlich wird

    border-radius

    nicht vom Internet Explorer unterstützt. Hierzu erzeugen wir Hintergrundbilder mit runden Ecken mit dem proprietären Standard VML (Vector Markup Language), Microsoft’s Antwort auf SVG (Scalable Vector Graphics). Zunächst wird per Conditional Comment abgefragt, ob der Browser VML versteht. Wenn das der Fall ist, setzen wir eine Variable in JavaScript und erzeugen das VML-Element. Schließlich wird es per CSS gestylt.

    Hierbei ist zu bemerken, dass im Internet Explorer 8 eine Breite oder Höhe von 100% für VML-Elemente nicht mehr funktioniert. Der Browser unterstützt nur noch Pixel- oder

    em

    -Werte. Interessant, dass Microsoft selbst seine eigenen „Standards“ bricht. Leider ist es etwas mühselig, dann für jeden Button je nach Textlänge eine feste Breite anzugeben. Alternativ kann man den IE8 auch in den IE7-Kompatibilitätsmodus zwingen.

  24. Im Opera Browser Version 10 sind die Ecken nicht rund, sondern eckig

    In Opera 10 sieht die Seite derzeit ungefähr so aus: mit eckigen Ecken statt runden, aber das stört auch nicht wirklich.

  25. HTML 5: Geolocation

    Seit wenigen Wochen unterstützen Firefox 3.5 und der Safari-Browser auf dem iPhone mit OS 3.0 einen fast finalen Standardentwurf des W3C, Geolocation.

  26. Google Map mit Geolocation

    Bei der Schweizerischen Blindenbibliothek haben wir Geolocation eingesetzt entsprechend den Prinzipien des Progressive Enhancements. Nutzer, deren Browser Geolocation unterstützt, bekommen die Option, ihren Standort auf der Karte anzeigen zu lassen. Gedacht ist das vor allem für Sehbehinderte oder Blinde, die ein iPhone 3G S nutzen und die damit ihren Standort erfahren können auf dem Weg zwischen S-Bahn-Haltestelle und Bibliothek.

  27. ARIA + JavaScript

    Oft benötigt man über die ARIA-Attribute in HTML hinaus noch JavaScript, um die Tastatursteuerung zu unterstützen. Man kann dazu Widgets verwenden, z.B. von jQuery UI, dojo oder YUI, die oft bereits ARIA eingebaut haben. Oder man muss diese Schritte selbst programmieren.

  28. Ausschnitt: Reiternavigation mit Buchungsformular

    Auf bahn.de werden Registerkarten zur Navigation verwendet. Mit der Tabulatortaste kommt man auf den aktuellen Reiter. Tabbt man weiter durch, gelangt man in den offenen Reiterinhalt. Auf dem Reiter liest ein Screenreader aber auch vor: „Bahn, Registerkarte, eins von vier“. Somit weiß ein Nutzer, dass es sich um eine Reiternavigation handelt, auf der man wie in den Tabs im Browser mit den Pfeiltasten (und anderen Tasten) auf den nächsten Reiter kann. Auf der aktuellen Bahn-Seite ist leider noch eine ältere Version, die weniger intuitiv funktioniert. Aber die Entwicklung der Website geht weiter. ;-)

    Video:

  29. Ausschnitt Reiternavigation auf bahn.de

    Vereinfachter Code. Bei der Bahn haben wir noch Hintergrundbilder, die per

    <span>

    eingefügt sind. Wenn zwischen dem Element mit der Rolle

    tablist

    und dem Kinder-Element mit der Rolle

    tab

    andere Elemente liegen, können diese im Screenreader mit der Rolle

    presentation

    ausgeblendet werden.

  30. Ausschnitt Reiternavigation auf bahn.de

    Damit die Reiternavigation per Tastatur funktioniert, muss per JavaScript ein

    tabindex

    gesetzt werden. Die entsprechenden Tastatur-Events werden abgefangen. Dabei muss man differenzieren, ob eine Taste nur alleine oder zusammen mit Shift, Alt oder Strg gedrückt wurde, das macht einen Unterschied. Der Reiterinhalt wird dann eingeblendet, am besten, indem man eine Klasse hinzufügt oder entfernt.

    Dann muss noch das Event-Bubbling verhindert werden. DOM-Elemente sind sehr mitteilungsbedürftig und sagen sofort ihren Eltern, wenn etwas passiert ist, immer so weiter bis zum Document-Root. Wenn ich aber mit der Pfeiltaste den Reiter wechsele, möchte ich vermeiden, dass beim Drücken der Pfeiltaste die Seite nach unten scrollt.

    Schließlich muss man für ältere Screenreader noch den virtuellen Buffer aktualisieren. Beim Laden der Seiten wird die Seite in einem Puffer abgelegt. Ändert man später ein Element von

    display: none

    auf

    display: block

    , bemerkt das der Screenreader nicht. Im Formularmodus ändert sich der Inhalt aber ständig, der Puffer wird aktualisiert. Also schreibt man einfach per JavaScript in ein hidden Input-Feld irgendwelche Zufallszahlen.

  31. Merkzettelfunktion bei der Schweizer Blindenbibliothek mit AJAX und ARIA Liveregions

    Auf der Seite der Blindenbibliothek haben wir eine Merkzettelfunktion eingebaut. Blinde können sich schlecht mal eben Notizen auf einem Zettel machen, weswegen wir auf jeder Seite einen Button haben „zum Merkzettel hinzufügen“. Die Seiten werden sich dann in einem Cookie gemerkt. Die Bestätigung wird mit AJAX und dynamischer Textersetzung eingefügt, was Nutzer von assistiven Technologien nicht bemerken würden. Mit einer ARIA-Liveregion liest der Screenreader aber Änderungen in einem Abschnitt vor. (Anmerkung: hier sieht man einen funktionalen Prototypen, zum Zeitpunkt des Vortrags war das noch nicht „hübsch“ final umgesetzt).

    Video:

  32. Designer-Uhr mit Braille-Zeile als Beispiel für gelungene Verknüpfung von Barrierefreiheit, Design und Technik.

    Fazit: Barrierefreiheit und Technik (oder ansprechendes Design wie in diesem Uhrenentwurf von David Chavez) können sich sehr gut ergänzen.

  33. Danke

Standards.Next: HTML5

i-3690926435a649caafaaaf5cfbd7ec16-apple2c-thumb.jpg Am Samstag durfte ich in London bei Standards.Next einen Vortrag über das HTML5 Canvas-Element halten. Die Vorbereitung war schon ziemlich aufwendig, denn das Thema ist sehr vielfältig: anders als der Name impliziert, ist ein HTML5-Canvas nicht einfach nur eine Fläche, um darauf zu malen, sondern „wie ein kleiner Apple ][ im Browser“. Entwickler haben darin die unglaublichsten Sachen gemacht: vom Font-Rendering à la sIFR über einen kompletten Code-Editor, Google Maps, Navigation, Bildmanipulation, Diagramme, Coverflow, einen Emulator für den Original-Code von Space Invaders, Spiele, bis hin zu 3D, Video und Video-Filter. Entsprechend umfangreich war die Vorbereitung, denn fast jede der 67 Folien enthält einen Link und Screenshots, auf 21 Folien sind Screencast-Videos eingebettet, weil es sich statisch einfach nicht darstellen lässt (und weil man sich erfahrungsgemäß nie auf das WLAN am Vortragsort verlassen darf).

Zudem war es erst mein zweiter Fachvortrag auf englisch vor muttersprachlichem Publikum, weswegen ich ehrlich ein wenig nervös war. Auch wegen der übrigen Sprecher: Neben mir waren da Bruce Lawson und Remy Sharp von Opera Software, Steve Faulkner von der Paciello Group, die umwerfende Molly Holzschlag und der geniale Dean Edwards, der übrigens

html5.js

präsentiert hat, mit dem automagisch auch ein Internet Explorer plötzlich HTML5-Tags interpretieren kann. Aber es lief sehr gut, die knapp 60 Teilnehmenden waren echt beeindruckt und ließen sich zu (für Briten überschwenglichen) twitter-Kommentaren wie „brilliant“ hinreißen. I’m delighted.

i-74e8bcb4d1179f9740410fcc6ee27897-firefox-3.5-canvas-video-thumb.jpgDie Folien liegen jetzt inklusive Anmerkungen auf Slideshare, allerdings sind die eingebetteten Videos nicht enthalten. Darum habe ich diese bei flickr hochgeladen. Und sämtliche Links aus dem Vortrag finden sich bequem bei delicious. Schaun’ Sie rein, denn die Zukunft des Internets ist berauschend!

Prüfkriterien für BIENE ’09 veröffentlicht

Einige von uns haben darauf lange gewartet, denn der eine oder andere Kunde von Namics würde gerne eine gewinnen: die Prüfkriterien für die BIENE ’09 wurden heute veröffentlicht.

Die BIENE, bis vor kurzem bekannt als Biene-Award, ist der wichtigste Preis für barrierefreie Websites im deutschsprachigen Raum. Anbieter von Websites nutzen den Preis gerne als Marketinginstrument, um sich, ihren Chefs und der Welt zu beweisen, dass sich der ganze Aufwand gelohnt hat ihr Engagement gegenüber Menschen mit Behinderungen zu zeigen. Und für Agenturen ist es der Ritterschlag: Spätestens dann muss man bei öffentlichen Ausschreibungen nicht mehr zwanghaft beweisen, dass man echt, ganz wirklich etwas von Barrierefreiheit versteht und kein Scharlatan ist (wovon es wahrlich genug gibt) – und der Platz in der Jury der nächsten BIENE ist gesichert.

Interessant sind die Prüfkriterien aber auch für Entwickler, denn sie werden jedes Jahr weiterentwickelt und sind so ein Spiegel von dem, was gerade State of the Art in Sachen barrierefreies User Interface ist. Die Biene hat sich beispielsweise lange vor den WCAG 2.0 mit der Zugänglichkeit von Web 2.0-Applikationen befasst und dies in ihren Prüfkriterien berücksichtigt. Die Lektüre ist also auf jeden Fall empfehlenswert!

Letztes Jahr war der Wettbewerb allerdings dominiert von (N)GOs; ich würde mir sehr wünschen, dass sich die Relevanz dieses Preises wieder mehr unter kommerziellen Anbietern herumspricht. Denn verdient hat es das Thema, und verdienen kann und darf ein Unternehmen von besserer Zugänglichkeit ebenfalls. Wir haben alle etwas davon.