Im ersten Teil Webfonts in der Praxis – auf Fontsuche geht es darum, welche Möglichkeiten stehen uns zur Verfügung, um eine vom Kunden oder von uns ausgewählte Schrift ins Web zu bringen. Dabei geht es rein um die Fülle der Services, wie Schriften ins Web kommen – sei es durch Selbst- oder Fremdhosting, sei es eine Gratis-Font oder eine kommerzielle. Allein im kommerziellen Bereich sind die Webfont-Services aufgeblüht, doch man sollte mit Vorsicht an die unterschiedlichen Preis-Leistungs-Modelle rangehen. Im zweiten Teil wird es dann ernst: Da teste ich diese ganzen Möglichkeiten auf Webtauglichkeit – ich kann jetzt schon sagen, Typekit wird durchaus auch überschätzt, da nehme ich mich nicht aus.

Um einen Überblick über die Preis-Leistungs-Verhältnisse der Webfont-Services vorzuhalten, habe ich ein tabellarische Übersicht erstellt: Webfont-Services Overview.

Allein der preisliche Unterschied zwischen einem Per-Font-Modell plus minus zusätzlicher Limitierungen wie Brandbreite oder einen Jahres-Hosting wie bei Typekit fällt bei mehreren Schriften schon ins Gewicht. Vor allem dann wenn man die Webtauglichkeit der Schrift ja nicht wirklich vorher testen kann – auch die 30-Tage-Testaccounts laufen irgendwann aus. Das ist schon der definitive Font-Goldrush, was wir jetzt erleben. :)

Webfonts in der Praxis – Teil 1 – Auf Fontsuche (02.09. 2010)

Meine Präsentationen auf slideshare.

Feel free to Flattr this post at flattr.com, if you like it.

Das Betahaus: interessantes Gebäude

Auf die eher provisorischen Gegebenheiten des Betahauses wurde ja schon hingewiesen, als Bruchbude würde ich es denn nicht bezeichnen, freilich war es etwas gewöhnungsbedürftig. Ich bin ja in einer alternativen (Arbeits-)kultur aufgewachsen quasi und bin da schon ziemlich offen, was das Ambiente betrifft. In Kombination mit der Hitze waren die Räume im 4. Stock eher nicht zu benutzen, alleine sitzen war schweiss-fördernd. :) Durchaus Wohnzimmercharme hat der Raum im Erdgeschoss, intimer und individuell mit Sitzgelegenheiten ausgestattet. Leider waren einige der Stühle schon so klapprig, dass ich dachte, sie würden die erste Session nicht überstehen – haben sie aber. Jemand verglich das Betahaus mit dem Unperfekthaus in Essen und meinte, das seien ja dann doch sehr große Unterschiede. Ich denke aber auch, dass das Betahaus vielleicht auch andere Funktionen erfüllt als das Unperfekthaus. Auch glaube ich mittlerweile – ich habe ja lange in Berlin gelebt und bin nun nur noch ab und an Zaungast -, dass man an einer Location wie dem Betahaus sehen kann, wie es Berlin an Geld fehlt.

Also, ja – die Location hätte besser gewählt werden können, aber in Mitte oder Prenzlauer Berg ist das wohl dann eher ne Geldfrage für so ein Barcamp. Denn, ich denke, was wirklich schick und hip ist in Berlin, kostet halt auch mittlerweile. Das wäre so meine Vermutung. Aber ich fand es in Ordnung. Mikros wären schon in diesen halligen Räumen sinnvoll gewesen, in den letzten Reihen hat man kaum verstanden bzw. lesen können, was grade referiert wurde. Positiv möchte ich hervorheben, dass ich es super fand, soviel Gratisgetränke zu erhalten, das war auch dringend notwendig. Und ich fand im übrigen toll, im Cafe auch mittags was Schmales kaufen zu können. Die Kritik hab ich irgendwie nicht verstanden, dass das Barcamp auch noch Brötchen stellen soll. Ist das der Barcamp-Gedanke für 200 Leute Brötchen zu schmieren? Aber vielleicht bin ich da auch nicht so dran an diesem Gedanken. Ich halte es für völlig in Ordnung mir mittags für 4-5 Euro ein gut belegtes und überbackenes Fladenbrot zu kaufen? Verstehe ich nicht wirklich, aber vielleicht bin ich schlicht zu alt, um das nachzuvollziehen. :)

Schwierig fand ich auch den Lärmpegel, der schon einige Stunden vor dem Halbfinalspiel im Hinterhof des Cafes durch die geschlossenen Türen richtig gut zu hören war. ;) Gut, ich mach mir wenig aus Fußball, aber auch so würde ich sagen, das WordCamp war nach dem gemeinsamen Gucken des Spiels schon eher am Ende. Es hat schon einen Bruch bedeutet, zwei Stunden zu pausieren. Gut, die Veranstalter haben da halt das beste draus machen müssen, die absolute Mehrheit wollte ja das Spiel gucken. :)

Die Sessions waren durchwachsen

Das trifft ja auch auf jede andere Veranstaltung zu. Die Kritik, dass es ja nur fast Session gegeben hätte, die auf Basics abzielten und man nichts gelernt hätte, stimmt nur bedingt. Jede Session, soweit sie im Vorfeld angekündigt war, war ja mit einem Schwierigkeitsgrad versehen. Sessions wie von Thomas Boley zu tempELA – eine Template Engine für WordPress Widgets und Plugins – oder von Michael Preuß zu Xtreme One – einem auf YAML und WordPress basierendes Theme-Framework – waren durchaus sehr spannend und haben genau dort angesetzt, wo in WordPress halt seit Jahren zu wenig passiert, was Standardisierung betrifft. So ein sauberes HTML-Template wie Boley jetzt nur für Widgets und Plugins entwickelt hat, würde man sich sofort für die Themeentwicklung wünschen. Es ist einfach verwunderlich, dass sich im Themebereich da nie wirklich etwas entwickelt hat, was die Trennung von PHP und HTML wirklich ermöglicht. Auch wenn mir die Portierung der Kommentierung von Typo3 dafür nicht ganz gefällt, aber es ist mal ein Schritt in die richtige Richtung. :)

Auch Michael Preuss geht in die richtige Richtung, wenn er ein Standard-Framework wie YAML reinholt und die Standardisierung noch weiter treibt und für das Theme eine Art Metaframework für WordPress zur Verfügung stellt, mit dem man dann x-fache Layout- und Konfigurationsoptionen hat. Freilich ist das dann eher für den Webdesigner gedacht, der die Konfiguration für den Kunden erstellt und nutzt. Schon eine spannende Sache, vor allem in seiner überzeugenden Flexibilität.

Meine Session: Twenty Ten – ist das neue WordPress 3.0 Theme barrierefrei?

Mit meiner Session zur Barrierefreiheit des neuen WordPress Themes Twenty Ten war ich dann ganz zufrieden, leider musste ich erst mal Boxen organisieren. Das Screenreaderbeispiel – was ja durchaus als Ovation an die WordPress-Entwicklung gedacht war – hat bei den meisten wieder Verstörung ausgelöst. Ist mir klar, warum das immer noch so ist, aber ich gehe da schon eher drüber weg. Das müssen Zuhörer meiner Vorträge schlicht aushalten. Und mit JAWS 11 und der fast schon komfortablen Ausgabe von und Navigation mit WAI-ARIA Orientierungspunkten – wie es so schön eindeutscht heißt – ist das ja schon richtig handy und sehr wenig verstörend. Und ich finde es wichtig, dass die Leute da genau hinhören, damit es seinen Störungs-Charakter verliert.

Was mir positiv aufgefallen ist: die Leute fragen sofort nach und es wurde mehr diskutiert, als ich gedacht habe. Das kenne ich eher nur aus seminar-ähnlichen Zusammenhängen. Spannend. Und, da ich ja derzeit weiter versuche, mit den WordPress internen Mechanismen wie Child-Theme und functions.php ein barrierefreies Theme aus Twenty Ten abzuleiten – dass man quasi nach wie vor den Look und die Möglichkeiten des Default-Themes hat, aber eben auch ein barrierefreies Theme – fand ich es spannend, dass ich dazu auch gleich ein paar Tipps erhalten habe. Das ist sicherlich auch eine Qualität eines Barcamps, diese offene Atmosphäre des Teilens von Wissen – liegt mir ja ganz besonders, etwas das ich ja immer wieder hier angesprochen habe.

Die Präsentation gibt es wie immer auf Slideshare. Im Schnellschuss-Verfahren – ich bin erst knapp am Abend davor damit fertig geworden – habe ich das PDF-Dokument auch getagged. Die Präsentation daher auch als PDF-Datei (844 Kb). Das Theme Twenty Ten bleibt hier auf sprungmarker weiterhin aktiv, ist aber schon jetzt ein Ableitung davon, ein Child-Theme und ich arbeite mich dann an diesem ersten Schritt weiter in Richtung eines barrierefreien Themes, wo auch immer ich schließlich technisch damit landen werde.

Twenty Ten – ist das neue WordPress 3.0 Theme barrierefrei? (WordCamp 2010)

Meine Präsentationen auf slideshare.

Summa summarum – wenn es nicht so derart heiß gewesen wäre, hätte ich mir sicherlich noch mehr Sessions angehört und hätte mehr Austausch und Tipps mitnehmen können. Dafür können die Organisatoren aber wenig – für so eine Hitzewelle. :) Daher – mir hat das durchaus Spaß gemacht und ich bedanke mich für meinen ersten Barcamp-Eindruck bei allen, ich werde das wieder versuchen – so ein Barcamp.

Feel free to Flattr this post at flattr.com, if you like it.

Mit WordPress 3.0 ist nun seit 2005 wieder ein neues Standard-Theme – Twenty Ten – integriert, wurde auch Zeit und das werde ich mir daher nun auch hier genauer ansehen. Weil sich am offenen und praktischen Herzen nun mal am besten testen lässt. :)

Feel free to Flattr this post at flattr.com, if you like it.

Auch hier zu Beginn ein kleines Fazit: Die Unterstützung von Captions ist mittlerweile Standard geworden; nicht zuletzt durch die automatische Möglichkeit, YouTube-Videos mit Captions zu versehen, ist das Thema sehr präsent und fast selbstverständlich geworden. Freilich stehen den vielen technischen Umsetzungen immer noch ein Unmenge an Videos entgegen, die erst mit Captions versehen werden müssen. Auch sieht es mit dem Finetuning der Captions hinsichtlich Farbe, Hintergrund, Position oder Schrift recht gut aus, wenngleich sich da erst eine Standardisierung bilden muss, wer will schon eine bunte Mischung von allem auf so schmalem Grund. :)

Ein sehr erfreuliches Bild zeichnet sich bei den Playern ab, wenn es um die Einbindung von Captions geht. Ich spreche hier immer bewusst nicht von Untertitelung. Im Unterschied zur herkömmlichen Untertitel enthalten Captions Informationen zum jeweiligen Sprecher und zu weiteren wichtigen Audioinformationen.

Open versus Closed Captions

Die erste wichtige Unterscheidung bei der Einbindung von Captions ist, ob man sie permanent zugeschaltet darstellt (Open Captions) oder ob man die Möglichkeit bietet, sie zu- und abzuschalten (Closed Captions – CC). Die WCAG 2 lassen beides als hinreichend zu, man kann sich also entscheiden. :) Closed Captions wird auch von fast allen Playern unterstützt. Diese Funktion, die ja auch eine gute Usability bietet, hat sich also zum Standard gemausert. Und das ist auch gut so. Offene Captions unterstützen ohnehin alle genannten Player und bis auf den flv flash-fullscreen video player kann man in allen Playern die Captions zu- und abschalten. Auch für den Button-Namen hat sich ein Quasi-Standard entwickelt: CC für Closed Captions.

Standardisierung im Caption-Format: Timed Text

Für die Einbindung der Captions-Inhalte stehen so unterschiedliche Formate zur Verfügung wie Timed Text, SubRip oder QTtext. Die genannten Formate werden alle als externe Datei in den Player eingebunden. Eine weitere Möglichkeit ist, die Inhalte bereits im Video mit einzubetten wie mit Hilfe von cuepoints – dabei werden an bestimmten Fixpunkten im Video die Captions eingeblendet. Beide Möglichkeiten werden von den Playern unterstützt – freilich in je unterschiedlicher Ausprägung. Für die externe Einbindung hat sich ein Standard durchgesetzt: das Format Timed Text (TT). Sieht man sich die aktuelle Spezifikation an – denn im Grunde ist das alles sehr einfach angelegt (Einfache Syntax: Absätze mit Anfang- und Endzeitpunkt, die den Captions-Text enthalten) -, ist mittlerweile viel an Styling möglich, von der unterschiedlichen farblichen Hinterlegung einzelner Passagen in der Caption, über Transparenzen, Positionierung und anderen Formen der Hervorhebung, um den inhaltlichen Zusammenhang etwa einzelner Sprecher klarer zu machen. Freilich wird nur ein Bruchteil tatsächlich von den Playern unterstützt.

Der Flowplayer, JW Player und der MALT Wiki Player unterstützen auch noch das einfache Textformat SubRip (.SRT) – noch einfacher als Timed Text werden die Positionen durchnummeriert und mit Anfangs- und Endzeitpunkt und den Inhalten der Captions versehen. SubRip hat wohl nicht den besten Ruf, weil es zu sehr von der Community an allen Ecken und Enden aufgebohrt wurde. Dive into Mark formuliert das recht schön: SubRip is the AVI of caption formats. Das Styling von SubRip ist sehr rudimentär und unterstützt die Basics wie Schrift, Größe und Farbe: Formatierungen wie fett, kursiv und ein wenig Schrift. Das war’s auch schon. Mit Hilfe von Timed Text kann man weit mehr an Styling erarbeiten.

Der cc-Player unterstützt noch das Quicktime Format QTtext, ebenfalls ein einfaches Textformat, das mit einigen Deskriptoren layouttechnisch nachbearbeitet werden kann – auch wieder sehr einfach, oben die Metainformationen, dann mit Timestamp die einzelnen Captions.  Im Gegensatz zu SubRip ist layouttechnisch mit QTtext mehr möglich: Neben den üblichen Textformatierungen kann man auch die Hintergrundbox, auf der die Captions liegen, beeinflussen (Transparenz, Position, Masse), auch die Art, wie die Captions eingeblendet werden.

Integrierte Captions: Captions schon im Video einbinden

Der JW Player, Flowplayer und der ccPlayer unterstützen auch die Variante, dass man Captions bereits im Video mit einbettet. Dafür wird unterschiedliche Software empfohlen, die cuepoints in FLV-Dateien unterstützt. Der cc-Player und JW Player empfehlen die Software: Captionate, der Flowplayer wie MALT Wiki Player  RichFLV. Und auch hierbei gibt es wieder graduelle Unterschiede. RichFLV ist so gut wie nicht dokumentiert, ist aber als Air-Anwendung plattformübergreifend nutzbar. Captionate kostet zwar nicht soviel, läuft aber nur unter Windows. :) Positiv: Captionate ist sehr gut dokumentiert und mit dem Blick auf die Demo muss man sagen, das geht schon sehr smooth. Mit Captionate lassen sich mehrere Sprecher und Sprachen zuordnen und es gibt auch ein Plugin, um etwa wieder in das SubRip-Format zu exportieren. In Planung sind wohl weitere Import- und Exortformate. Das wäre dann schon ziemlich handy und spannend. Um die embedded-Variante beim JW Player zu integrieren, muss man die Variable addVariable("captions","captionate") hinzufügen.

Ich habe die verschiedenen Varianten getestet und es ist tatsächlich so, dass man sich bei jedem Player an die Software-Empfehlung halten muss. Ein Video, das mit Captionate bearbeitet wurde, kann zwar im ccPlayer integriert werden, die gleiche Datei im Flowplayer liefert aber keine Captions aus. Ich habe mal den Test gemacht und die mit Captionate erzeugte Datei in RichFLV erneut abgespeichert und schon lief sie auch im Flowplayer. Etwas unhandlich das und auch unstandardisiert. Es wäre wünschenswert, wenn sich da eine Einheitlichkeit entwickelt, weil man ja auch nicht weiß, welche Unterschiede da in Verarbeitung und Ausspielung sonst noch zu erwarten sind. Ganz abgesehen davon, das RichFLV viel weniger Optionen aufzubieten hat als Captionate.

Standardmäßig ist eher von dem Fall auszugehen, dass die Videos vorliegen und erst mit Captions versehen werden müssen, insofern greift man zu einem Textformat wie Timed Text. So ein einfaches Textformat lässt sich templatemäßig auch sehr gut dynamisieren und in ein CMS integrieren. Unterschiede gibt es dann in den Möglichkeiten, die Captions zu layoutieren – das sehen wir uns im nächsten Punkt an. So lässt das Plugin des JW Players sehr wenig zu: Die Schriftgröße lässt sich einstellen (Vorsicht – mit der Größe des Players ändert sich auch die Schriftgröße – das kann bei kleinen Playern zu einer unleserlichen Schrift führen – also lieber auf das Einstellen der Schriftgröße verzichten. Der Player skaliert ohnehin auch die Schrift der Captions automatisch mit), die Transparenz des Hintergrunds der Caption und ob Captions per default abgeschaltet sein sollen. Noch ein kleiner barrierefreier Tipp für den JW Player: Warum auch immer werden in der Standardintegration der beiden barrierefreien Plugins Caption und Audiodescription die Buttons, um beide Optionen zu- und abzuschalten, als Layer auf das Video gelegt – das nennt sich dann Dock – und sind per Tastatur so nicht erreichbar. Man kann das ändern, in dem man die Buttons wieder in die Playerleiste nach unten legt mit dem Parameter dock=false.

Captions individuell anpassen

Grundsätzlich muss man bei der individuellen Anpassung der Captions zwei Herangehensweisen unterscheiden: Zum einen gibt der Player oder das Plugin schon Defaults vor, die man meist mit Hilfe von Parametern oder Variablen anpassen kann. Zum anderen kann man im Captions-Format wie Timed Text die je eigenen Styling-Vorgaben nutzen und so Ausgabe und Aussehen der Captions individualisieren. Das gilt im übrigen auch für die im Video integrierte Variante, das Styling erledigt dann das jeweilige Programm wie etwa Captionate, wo man die individuellen Angaben dann einstellen kann. Für die externen Varianten der einzelnen Captions-Formate gilt, was das Format zulässt. Da ist Timed Text an der Individualisierungs-Spitze angesiedelt, mit etwas weniger wartet QTtext auf und eher spartanisch kommt schließlich SubRip daher. Dazu muss man einschränken, dass die Möglichkeiten der Spezifikation und Formate das eine ist, die tatsächliche Ausgabe und Interpretation durch den Player etwas andres. Wir sehen uns die unterschiedlichen Styling-Stufen nun im Detail an:

Media Player: Möglichkeiten des Stylings

Styling des Defaults nutzen

Für diese Form des Stylings kommen nur folgende Player wirklich in Frage: JW Player, Flowplayer, MALT Wiki Player und ccPlayer. Alle von diesen genannten Player unterstützen es, dass man im Default des Players oder im Plugin die Captions entsprechend styled. Beim JW Player ist das die Schriftgröße, die Transparenz des Hintergrunds und ob die Captions automatisch zugeschaltet wird. Der Flowplayer ist da noch etwas ausgefeilter im Default, ich denke das gilt auch immer für den MALT Wiki Player, da er ja auf dem Flowplayer basiert: Man kann im Default des Captions-Plugin einstellen: die Schrift, Schriftgröße, Schriftfarbe und Textausrichtung, aber ebenso Position, Breite, Höhe und Transparenz des Hintergrunds. Der ccPlayer ist im Default, soweit ich das recherchieren konnte, nicht änderbar und ist auf Verdana in der Größe 14 mit dreizeiligen Captions eingestellt, das kann man mit den Styles von Timed Text oder QTtext überschreiben.

Interessanterweise greift dieser Default auch für die im Video integrierten Captions, das heißt: Hat man in der Videodatei mit Captionate andere Styles eingestellt, werden die durch den Default des Players oder des Plugins überschrieben. Einzig im ccPlayer ist das nicht der Fall, dort überschreiben die Styles von Captionate den Default. Man darf sich auch fragen, warum das die anderen Player nicht machen. Grundsätzlich ist ein Default ja gut, aber Captionate erlaubt da viel mehr Einstellungen. Der beste Fall wäre im Grunde, wenn man das mit Hilfe eines Parameters im Player nachjustieren kann, genau für den Fall, den man eben haben möchte, welche Styles man jeweils überschreiben möchte. Aber das bietet leider noch kein Player.

Styling des Captions-Formats nutzen

Genauso stufig geht es mit der Interpretation des Stylings im Captions-Format selbst weiter: Sehr gut, weil auch sehr rudimentär, unterstützt wird einfaches HTML, das man direkt in den Captions-Text einarbeitet. Für die Anpassung der Schrift arbeitet man dann mit dem alten font-Element. Auch sonst wird etwa für kursiv oder fett auf die nicht semantischen HTML-Elemente i und bold zurückgegriffen. Ich habe zwar versucht, dafür das em- oder strong-Element zu nutzen, wird aber nicht interpretiert. Leider. So ist die Standardisierung in den Captions-Formaten letztlich noch nicht auf der Höhe der Zeit. Um diese einfachen HTML-Elemente einzusetzen, muss man im JW Player und Flowplayer alles mit CDATA umschließen, sonst wird der gestylte Inhalt nicht mehr ausgegeben. Im ccPlayer klappt das auch ohne CDATA. Ähnlich ist es mit dem br-Element. Auch da muss normalerweise CDATA angewendet werden, in einem aktuellen Supportticket des Flowplayers wird das aber aufgearbeitet. Kann auch sonst eher ziemlich mühselig sein, jedes br so auszuzeichnen.

SubRip arbeitet da ähnlich wie Timed Text, auch hier die gleichen einfachen HTML-Elemente, aber mehr ist dann auch nicht mehr möglich. QTtext hat ebenfalls sehr einfache Deskriptoren wie {bold} und auch zwei Stufen in der Anpassung – global am Anfang der QTtext-Datei und inline pro Captions-Text. Theoretisch müsste das Inline-Styling auch funktionieren, aber der ccPlayer lässt nur globale Styles für QTtext zu. Insofern ist man mit dem Styling via QTtext dann sehr eingeschränkt: Entweder die ganze Caption ist fett oder nicht. Eher sehr unhandlich.

Will man wirklich auch auf einer Mikroebene stylen, kommt man an Timed Text nicht vorbei. Erst damit hat man die Möglichkeit, global mit IDs zu arbeiten, aber auch auf einer Mikroebene etwa mit einem span-Element. Leider greifen auch bei Timed Text HTML-Elemente wie em oder strong nicht. Entweder man greift wieder auf bold oder i zurück, oder man nutzt ein span-Element und arbeitet mit den Attributen von Timed Text. Freilich ist die Interpretation dieser Möglichkeiten wiederum an den Player gebunden. Weit voraus greift hierbei der ccPlayer. Wir sehen uns das jetzt genauer an:

Media Player: Welche Möglichkeiten hat man wirklich, die Captions zu stylen?

Das Anpassen auf globaler Ebene wird vom Flowplayer und ccPlayer unterstützt, der JW PLayer kann das bis dato nicht, aber es liegt ein Support-Ticket (Ticket-692) vor. Dieses Support-Ticket hat auch das Styling via body-, div- oder p-Element und das Inline-Styling via span-Element auf dem Plan. Wenn dieses Ticket live geht, unterstützt der JW Player dann weite Bereiche von Timed Text. Sonst unterstützt die volle stufige Palette nur der ccPlayer. Freilich auch hier wieder Abzüge, die Spezifikation Timed Text hat sehr viele Optionen, die noch kein Player unterstützt. Da hätte ich noch Tage testen können, um da eine vollständige Liste zu erarbeiten. Was unterstützt wird in jedem Fall sind wieder die Basics wie Farbe, Schrift, Größe oder kursiv. Werden Attribute nicht unterstützt, steht dann schon gerne null als Ausgabe in den Captions. ;)

So kann man im style-Element im Kopf der Datei mit Hilfe von mehreren Attributen wie tts:fontSize="18" – man reiht sie einfach aneinander – globale Styles für alle Captions oder mit Hilfe von IDs eindeutig einer Caption zuordnen. Im Element im body spricht man dann die ID an mit style="1" als Beispiel. Damit erhält dann genau dieser Absatz oder div die im Kopf der Datei dafür definierten Formate. Man kann jedoch auch die Attribute wie tts:backgroundColor="purple" dann im body auf alles anwenden bis zur Mikroebene mit Hilfe eines span-Elementes. Auch hierbei können unterschiedliche Attribute schlicht aneinander gereiht werden. So würde man um einen Bereich der Caption kursiv und fett zu machen, dann im span-Element die Attribute tts:fontStyle="italic" und tts:fontWeight="bold" hinzufügen. Individualisierung von Captions ist also durchaus auch ein wenig Arbeit. :)

Weitere Besonderheiten

Die Individualisierung des CC-Buttons wird von den meisten Playern unterstützt, der Standard-Wortlaut CC für Closed Captions ist vielleicht nicht immer verständlich, wenn gleich standardisiert im Englischen. Ganz so einfach ist es dann jedoch doch nicht. Der ccPlayer bietet nur an, dass  man den Button in der fla-Datei ändert. Der Flowplayer lässt das Ändern bis dato im Captions-Plugin nicht zu. Der JW Player lässt die Änderung zwar zu, man muss aber dann das Captions-Plugin neu kompilieren, was ja eher dann in Richtung Entwicklung geht. Aber es gibt ein Support-Ticket (Ticket#692), das verspricht, den Button skinfähig zu machen. Also bis dato ist die Anpassung des Buttons eher noch ein Sonderfall.

Im Grunde war es das dann schon mit dem Individualisieren der Captions. Nur der ccPlayer bietet darüber hinaus noch weitere spannende Funktionen an. So kann man die Captions auch durchsuchen. Dafür steht der Button search zur Verfügung, der öffnet einen Layer über dem Player und kann dann nach Worten oder Phrasen in den Captions suchen. Die Suche bezieht sich immer auf die grade angewählte Sprache und findet Wörter aus anderen Sprachen dann nicht. Mit Klick auf Suchen wird das gesuchte Wort dann direkt im Video angesprungen. Funktioniert ziemlich gut. Kann man auch in meinem Beispiel testen.

Wie schon angeführt, kann der ccPlayer auch mit unterschiedlichen Sprachen arbeiten. Dazu muss man schlicht nur das div- oder p-Element mit dem lang-Attribut versehen für jede Sprache und schon kann man die Sprache im Player anwählen. Mit Klick auf den Button languages öffnet sich wieder ein Layer über dem Player und man kann im Select die Sprache auswählen. Auch das kann man in meinem Beispiel testen, ich habe mal die Captions für Deutsch – okay ist eher Lorem Ipsum Latein – und Englisch angepasst. Das funktioniert auch gut. Freilich ist das jetzt die lang-Methode des ccPlayers nicht wirklich aus der Spezifikation von Timed Text ableitbar, wie sie betonen, aber ich finde das lang-Attribut ist ja schließlich durchaus bekannt und lässt sich verlässlich einsetzen. Der JW Player hat ebenfalls ein Support-Ticket (Ticket#692) für Mehrsprachigkeit, gelöst wird das wohl, indem man mit mehreren Timed Text Dateien arbeitet, für jede Sprache eine.

Eine weitere interessante Option im ccPlayer ist, den Darstellungsmodus für das Erscheinen der Captions – also wie sie in den Videorahmen reinlaufen – einzustellen. Der Default ist klassisch Popup, jede Caption ersetzt die andere. Aber man kann auch den Rollup-Modus einstellen und die Anzahl der Zeilen dafür. Die Zeilen der Captions rollen dann wie im Film rein, die erste Zeile bleibt immer nur solange, bis eine weitere am unteren Rand reinrollt. Wie im klassischen Filmabspann. Ich habe das mal angetestet, funktioniert aber nur teilweise. Eventuell gibt es da auch wieder Darstellungsprobleme, wenn man bestimmte Attribute von Timed Text verwendet. Aber prinzipiell funktioniert der Rollup-Modus.

Beispiele

Ich habe für den JW Player, Flowplayer und ccPlayer Beispiele mit Captions-Formaten erarbeitet. Die Player liegen im Standardmodus vor, also könnte es beim Flowplayer in der Bedienung Probleme geben, was die Barrierefreiheit betrifft. Dafür muss man ja erst immer noch weitere Plugins einbauen. Bei den anderen beiden dürfte es eigentlich keine Probleme geben. Die jeweilige Captions-Beispiel-Datei kann man sich auch ansehen und herunterladen:

• JW Player mit SubRip-Format
• JW Player mit Timed Text (einfaches HTML)
• FlowPlayer mit SubRip Format
• Flow Player mit Timed Text (einfaches HTML)
• Flowplayer mit Timed Text (gemäß Spezifikation – globale Styles)
• ccPlayer mit QTtext
• ccPlayer mit Timed Text (einfaches HTML)
• ccPlayer mit Timed Text (gemäß Spezifikation)

Feel free to Flattr this post at flattr.com, if you like it.

Da ich in diesem Sektor immer wieder auch auf der Suche bin, ob es nicht doch eine All-in-one-Lösung gibt, habe ich mich mal auf den Weg gemacht. Ein knappes Fazit gleich zu Beginn – im Grunde sind es gleich zwei: Captions – ich spreche bewusst nicht nur von Untertitelung – haben sich zu einem Quasi-Standard gemausert, die sind fast immer im Player integriert oder als Plugin integrierbar. Im Bereich der Captions unterscheidet sich Einbindung und Finetuning in den Playern eher sehr graduell.

Ganz anders sieht es für die Einbindung von Audiobeschreibungen aus, da sieht es eher finster aus und von einer Standardisierung ist man noch weit entfernt. Leider, muss man dazu sagen. Weil grade – sieht man sich das aktuelle WCAG 2 an – wird die Audiobeschreibung bereits auf Level A und AA gefordert. Gänzlich ohne Entsprechung in der Player-Landschaft ist die Integration einer Extended Audiodescription, gut die parallele Einbindung ist auch nicht so trivial, vor allem auch, weil das Format SMIL es eher komplexer angeht, als es für Standards eigentlich notwendig wäre.

Und das zweite, weitaus kürzere Fazit: Es gibt schlicht zu wenige Standard-Player, die sich auch auf die Barrierefreiheit einlassen. Gut, alle werden jetzt wieder in Richtung JW-Player nicken und das auch zurecht, aber es bewegt sich minimal auch in anderen Playern was Richtung Barrierefreiheit und das sehen wir uns jetzt hier genauer an:

Media Player und Barrierefreiheit: eine Kurzübersicht

In meiner Kurzübersicht für den generellen Überblick, welche Player überhaupt in Frage kommen, bin ich neben der Einbindung von Captions und Audiobeschreibungen auch der Möglichkeit der Integration eines Trankskripts und von Gebärdensprache nachgegangen. Und – schließlich geht es ja um einen umfassenden barrierefreien Zugang – habe ich getestet, ob die Player jeweils tastaturbedienbar und mit Screenreader (JAWS) nutzbar sind – aber freilich ist das nur ein Kurztest.

Welche Player kommen für Barrierefreiheit nun in Frage?

Den JW Player muss man ja fast nicht mehr vorstellen, findet man ihn fast auf allen BIENE-Seiten. :) Er hat immer damit bestochen, dass er eine Rundum-Lösung geboten hat, Captions und Audiobeschreibung waren schlicht im Default des Players integriert. Das hat sich mittlerweile etwas verändert, Caption und Audiobeschreibung sind nun Plugins und müssen extra integriert werden. Prinzipiell kein Problem, das einzige Manko ist, dass sich die barrierefreien Plugins immer mal wieder weiterentwickeln – etwa ändern sich die Parameter-Namen und die Update-fähigkeit leidet darunter etwas. Das absolute Plus ist jedoch der Entwickler des Players, der sehr offen ist, diese beiden Plugins auf Anfrage auch weiter zu entwickeln – ich habe gerade einen kurzen Kontakt mit ihm geknüpft, um das Plugin für die Audiobeschreibung etwas voran zu bringen. Aber dazu mehr in den Details. :) Der JW Player ist mit dem Screenreader nutzbar und auch tastaturbedienbar.

Der Flowplayer wird gerne eingesetzt, weil er trendy ist und schlicht immer schon etwas besser anpassbar war, was die Oberfläche betrifft. Da hat der JW Player im übrigen mittlerweile aufgeholt, die gesamte Oberfläche lässt sich jetzt inklusive Grafiken mit Hilfe einer XML-Datei individualisieren. Aber der Flowplayer bedient sich ebenso der Plugin-Architektur und bietet so Captions an. Aber dann wird es eher haarig, sieht man sich nach der Audiobeschreibung um, wird auf das Audio-Plugin verwiesen. Was meint, man führt schlicht eine Mp3-Datei synchron zum Video. Mehr aber auch nicht. Der Flowplayer ist von Haus aus nicht tastaturbedienbar, kann aber mit Hilfe des Plugins Controlbar tastaturbedienbar gemacht werden und ist dadurch auch mit dem Screenreader nutzbar.

Der MALT Wiki Player ist ein durch die Community vorangetriebenes Projekt und basiert auf dem Flowplayer. Leider kann man online bis dato nur Beispiele des Players mit Captions sehen, aber sie weisen darauf hin, dass die Beispiele für Audiobeschreibungen noch integriert werden. Der Player bietet auch einen ziemlich umfangreichen Einstellungsbereich, wo man seine allgemeinen Präferenzen anwählen kann – etwa Captions, Audiobeschreibung oder Transkript. Das ist schon eine ziemliche Weiterentwicklung des Flowplayers. Der MALT Wiki Player ist tastaturbedienbar und mit Screenreader nutzbar.

Der ccPlayer hat bis dato noch keine Integration von Audiobeschreibungen, ist aber hinsichtlich Captions ziemlich ausgefeilt. Ich denke, diesen Player sollte man auch beobachten, was sich da noch entwickelt. So ist für Captions eine Suche integriert und es sind auch mehrsprachige Captions möglich. Wichtig ist dem Player die Tastaturbedienbarkeit und er ist auch mit Screenreader nutzbar.

Den Nomensa Accessible Media Player habe ich immer mal am Rande wahrgenommen, es gab früher auch noch mehr Einsicht in die Funktionen des Players. Mittlerweile sind nur noch wenige Infos zu diesem Player online erhältlich, auf alle Fälle unterstützt er Captions. Es ist wohl auch von der Integration eines Transkripts die Rede, aber Beispiele kann man davon leider nicht finden. Ich fand das Projekt aber immer schon recht spannend, vor allem weil sehr viel Wert auf Tastaturbedienbarkeit und Nutzbarkeit mit Screenreadern gelegt wird.

Um auch mal das typische Mittelfeld in der barrierefreien Optimierung quasi als Vergleichsgröße einfließen zu lassen, habe ich mir den flv flash-fullscreen video player angesehen. Außer der Unterstützung von Captions und einem minimalen Durchkommen per Tastatur ist der Player sonst nicht barrierefrei. So, das war jetzt die berühmte Kontrollgruppe. ;)

Ein absolutes Gusto-Stück unter den Playern ist der ODI Player. Ich werde da mal anfragen, wie und ob man den kommerziell einbauen kann. Im Interview ist zu hören, dass sie eine kommerzielle Nutzung erwägen, das wäre sehr wünschenswert. Würde man eine All-in-one-Lösung suchen, hat man sie mit diesem Player tatsächlich gefunden. Der Player unterstützt – und das ziemlich smooth bedienbar – Captions, Audiobeschreibung, Erweiterte Audiobeschreibung, Gebärdensprache, Transkript, ist tastaturbedienbar und mit Screenreader nutzbar. Gut, nicht jede Webseite will so einen mächtigen Player, der auch ziemlich Raum einnimmt, aber vom integrativen Ansatz her ist das schon ziemlich weit vorn. Alle Funktionen und Formate sind im Flash des Players integriert, daher ist es schwer zu sagen, wie die Einbindung genau funktioniert und welche Formate unterstützt werden. Eine Frage, die man ja auf Anfrage klären kann, ist, ob der Player auch schmaler einsetz- und individualisierbar ist.

Und das war’s auch schon von der Player-Seite her. Würde man sich jetzt auch noch jene Player, die ausschließlich YouTube integrieren, ansehen, könnte man da auch noch mehr Player bieten wie etwa den Easy YouTube Player von Chris Heilmann. Im übrigen gibt es gerade für den YouTube-Bereich durchaus einige barrierefreie Ansätze. Aber: ich habe aus einer agenturtypischen Sichtweise Player gesucht für Kunden, die ihre Videos auf der Webseite präsentieren wollen, nicht via YouTube. Auch gibt es durchaus Unterschiede im Preis, die Preislage des JW Players oder Flowplayers hält sich ja in Grenzen, wenn es sich etwa nur auf eine Domain bezieht. Und bei einigen Playern muss man schlicht anfragen, wie viel die Nutzung letztlich kosten würde. Eine kleine Übersicht dazu:

Media Player und Barrierefreiheit: Allgemeine Infos

Diese Kurzübersicht der Standard-Player hat uns gezeigt, dass die Auswahl, je diffiziler die barrierefreien Anforderungen werden, immer kleiner wird. Das ist sehr schade, schließlich gibt es die Anforderung einer Audiobeschreibung nicht erst seit heute. Aber wie der Entwickler des JW Players auf meine Anfrage zum Plugin für eine erweiterte Audiobeschreibung meinte, da würde der Aufwand nicht wirklich in einem Verhältnis zur tatsächlichen Nutzung stehen. Ich hoffe aber, dass er sich trotzdem das noch einmal durch den Kopf gehen lassen wird. Diese Argumente hört man ja öfter – das typische massenkompatible Argument -, wenn eine barrierefreie Optimierung nur wenige nutzen, warum sollte man dann den Aufwand treiben. Ich sage dann immer, wenn es auch nur wenige nutzen, können es zum einen immer noch mehr werden und im Web geht es schließlich auch um Spezialisierung. Wie viele Spezialfeatures setzen wir denn sonst ein und kein Mensch fragt, wer das alles nutzen wird. :)

Barrierefreiheit & Media Player: im Detail

Wir sehen uns nun im Detail an, was die Player im Bereich der Captions und Audiobeschreibung wirklich zu bieten haben:

• Media Player und Barrierefreiheit: Captioning – Teil 2
• Media Player und Barrierefreiheit: Audiobeschreibung – Teil 3 (In Kürze)

Feel free to Flattr this post at flattr.com, if you like it.

Es war zwar ein kleines Hauruck-Unternehmen, weil der erste Vortrag sehr knapp terminiert war, aber da die Vorträge ja nun turnusmäßig stattfinden, kann ich die Präsentation Schritt für Schritt ausbauen und entlang der Erfahrungen optimieren. Die jeweils aktuelle Präsentation packe ich dann auf Slideshare.

Als barrierefreie Entwicklerin, das war die erste Erfahrung aus den beiden Vorträgen der letzten Wochen, muss ich wieder lernen, auf einen allgemein verständlichen Erklärungslevel zu kommen. Daher fand ich ganz direkte Fragen gut wie ist ein Screenreader nun Hard- oder Software. Oder wie funktioniert jetzt nun genau eine Braillezeile oder wie formuliere ich denn wirklich einen Alternativtext für blinde Nutzer. Und nicht alles ist wirklich einfach zu beantworten, schließlich kenne ich Braillezeilen auch nur aus zweiter Hand. :) Aber – und das ist halt das spannende für mich – ich nehme das zum Anlass, um mir eben so ein Arbeiten mit Braillezeile genauer anzusehen, kaufen kann ich mir freilich keine, weil zu teuer (auch bei Ebay nicht billiger zu haben ;) ) und auch nicht braille-kundig. Immerhin weiß ich jetzt, was ein anerkanntes Hilfsmittel ist und was von der Krankenkasse bezahlt wird.

Und was mir am besten gefallen hat, waren die vielen direkten Fragen, fast schon Debatten. Das hat mich mitunter auch ein wenig aus der Vortragsraison gebracht, weil ich ja durch die Debatten im Galopp schon fast dann quer durch den Vortrag war. Aber – und auch das macht durchaus Spaß – die Vorträge haben halt auch diesen überlappenden Seminarcharakter. Am Ende des Vortrags – nach einer angemessenen Pause natürlich – hätte ich gerne noch einen Aufbauvortrag gehalten. :)

Insofern harre ich der Vorträge, die da nun immer wieder kommen werden … :)

Was ist Barrierefreiheit? (18.05. 2010)

Meine Präsentationen auf slideshare.

Meine Vorträge arbeiten sehr intensiv mit Screencasts, die sind natürlich in slideshare nicht enthalten. Und weil ich ja in Übung bleiben will, werde ich auch die in slideshare integrierte und herunterladbare PDF-Datei so weit wie möglich barrierefrei gestalten. Ich werde die dann auch hier verlinken. Gerne dann Rückmeldung zum barirerefreien PDF, wenn es Probleme damit gibt, gerne auch ganz direkt. :)

Update

So, jetzt habe ich die PDF-Datei barrierefrei aufgearbeitet: Was ist Barrierefreiheit? Ein Kurztest (PDF-Datei, 2,8 Mb). An Sprachauszeichnung und Abkürzungs-Einbindung habe ich mich nach Stunden jetzt nicht mehr herangetraut. Die Umfliessen-Ansicht ist nicht zu empfehlen. ;) Ich denke, da muss ich mich erst genauer heranarbeiten, weil ich fürchte, dafür sollte man wohl am Ausgangspunkt ansetzen: am generellen Layout der Präsentation.

Feel free to Flattr this post at flattr.com, if you like it.

Angst ist ein schlechter Ratgeber. Auch so eine Binsenweisheit, an die man sich auch noch hält. Als ich gestern frühmorgens angekündigt hatte, dass ich – wenn ich das Heft schon mal lese – auch gleich eine Rezension mache, kam via Twitter vom Webstandards-Magazin zurück: Ganz Düsseldorf duckt sich schon mal ;). Gut, was soll ich sagen – sie haben recht und auch wieder nicht. Was nicht von mir zu erwarten ist, eine Rezension, die sich bedeckt hält. Warum auch, das Webstandards-Magazin hat nichts zu verstecken, es hat freilich noch einiges versteckt, aber darauf komme ich in meinem Fazit zurück.

Ich habe lange überlegt, wie man das Heft am besten in eine Rezension packt und mich für eine thematische, subjektive Auswahl entschieden mit einem kleinen, ebenso subjektivem Ausblick, was mir noch fehlt.

Warum ich das Magazin nach Hause genommen habe?

Zum einen sicherlich, weil die letzte Ausgabe, die ich auch wirklich gelesen habe, Ausgabe 2 war. Das spricht jetzt weder gegen das Magazin, noch für mich. :) Ich bin nur manchmal so im Umgang mit Geschenken, dass ich sie schlicht ziemlich lang liegen lasse. Und Abos, speziell in Agenturen, sind nun mal Geschenke. Zum anderen hat mich der aktuelle Schwerpunkt mobil schlicht dazu verführt, weil ich da in den letzten Monaten ein wenig affiziert wurde durch zwei Webinare zum Thema.

Entsprechend zielgerichtet habe ich auf den Schwerpunkt hin gelesen, okay – zugegeben – zuerst lese ich immer die Artikel zum Thema Barrierefreiheit. Aus dem ganzen Heft hat mir der schmale bis kurzweilige Artikel zu Location Based Games am besten gefallen und damit will ich keinesfalls dem Herausgeber schmeicheln. ;) Wer schon auf harmlosen Sonntagsspaziergängen erlebt hat, wie der Partner plötzlich das Wort Geocaching ins Rennen wirft und unbedingt Verstecktes via iPhone suchen will, weiß, dass die in diesem Artikel vorgestellten Play-Caching-Sessions um einiges verschärfter sind. Selten so gelacht, ich sag dazu ja immer, ein Waldstreifen ist mir da immer um einiges interessanter. Oder um es mit ein wenig mehr Medientheorie zu sagen – Raymond Williams nannte das schon sehr früh die Tendenz zur mobilen Privatisierung -, man hat immer sein Wohnzimmer dabei und kommt aber trotzdem viel rum. ;) Freilich hat der Anspruch, warum man sich solchen Reality-Spielen hingeben soll, etwas eher wellnesshaftes. Aber womöglich ist es das genau, die Wellness. Ich hätte mir da ein wenig mehr Anarchismus gewünscht, schließlich operieren diese Spielansätze tatsächlich auf einer historisch gängigen Praxis der Realitäts- und Stadterkundung jenseits gängiger Routen und Vorgaben – als Beispiel wären die Techniken der Situationisten hier zu nennen. Aber wie schon gesagt, habe mir sofort einiges notiert und werde mich da weiter damit beschäftigen. Danke dafür!

Der Artikel zu Mobile Tagging von André Wussow war sehr passend, hätte ich keinen iPod Touch, würde ich das sicherlich massiv nützen, schon weil ich Codes sehr mag. Das Thema Browserweichen (Tim Böttiger) wird besonders für mobil wieder wichtiger. Ich hätte mir da aber einen Zugang gewünscht, der sich mehr mit Standards beschäftigt. Freilich können wir auch wieder anfangen, diese Voll-PHP-User-Agent-Lösungen zu nutzen, aber davon waren wir doch eigentlich schon wieder weg. Der Artikel zieht das argumentativ durchaus richtig durch, aber er bleibt in der unterschiedlichen Gewichtung dann doch zu wage. Aber auf diesen Punkt komme ich in meinem Ausblick noch zu sprechen – dem mitunter Fehlen einer Webstandards-Perspektive. Das erwarte ich nicht von jedem Artikel, aber gerade in der Browserweichen-Debatte würde ich einen speziellen Fokus auf Webstandards erwarten.

Der mobile Praxisbericht von Marco Zehe in Sachen iPhone und VoiceOver ist spannend und gibt vor allem auch Einblick in die taktile Handhabung etwa einer Datentabelle, die von VoiceOver leider bis dato nicht so gut interpretiert wird wie etwa von JAWS. Spannend ist auch das konkrete Ergebnis für Webentwickler, war aber eher zu erwarten in dieser vertrauten Kombination von Safari und VoiceOver.

Was mir noch gefehlt hat im mobilen Schwerpunkt, sind Artikel, die den klassischen Webentwickler wie mich dort abholen, wo er zuhause ist: Bei den Webapps, die mit Hilfe von HTML, CSS und etwa einem Plugin wie jQTouch arbeiten. Nichts gegen native Apperstellung mit Xcode oder Objective-C – zwei Artikel arbeiten auch diese Themen gut auf, nur fehlte mir der Brückenschlag zum sinnvollen Einsatz von Webstandards ein wenig. Grade mobil ist da schon eine weitere Herausforderung. Und meine C-Zeiten liegen schon arg lang zurück, da war der knappe Ausflug im Webinar in den Xcode-Bereich schon wesentlich komfortabler. :)

Für den klassischen Webworker wie mich war doch einiges dabei …

Spannend sowohl der Artikel von Eric Eggert zu den CSS3 Animationen als auch von Stefan Asemota zu RGBa, die einfachste Transparenz überhaupt, würde ich sagen. Man spürt in beiden Artikeln und generell grade, um wie viel einfacher und zugleich präziser CSS3 daherkommt. Die Transparenz-PNGisierung hat dann ja bald ein Ende, dank IE 9. ;)

In den beiden Artikeln zu WYSIWYG von Maik Wagner und Nicolai Schwarz ist der Anspruch, konform und valide zu arbeiten, sehr präsent – sehr gut. :) Auch wenn sich die Artikel etwas überschneiden und beide eine schlechte Praxis und Ausgabe von WYSIWYG-Editoren voraussetzen, die so auch wieder leicht speziell anmutet und etwa durch ganz andere Ansätze wie dynamische CMS-Maskenerstellung, die heute ja problemloser möglich ist, umgangen werden kann. Damit kann man entweder den Editor gänzlich entfernen oder reduziert ihn auf die Befüllung von Absätzen mit der entsprechenden Minimalkonfiguration des Editors. Die Option, ein Bild in den Editor zu integrieren, ist dann nicht mehr zwingend notwendig. Konformität und Validität lassen sich durch eine kleinteiligere Maskenbildung viel einfacher erreichen. Freilich sind diese Lösungen nur möglich, wo Masken so frei erstellt werden können. Die von Maik Wagner genannten Beispiele wie Blogsysteme bieten diese Möglichkeit nicht, hier greifen die beiden Lösungen dann durchaus: Textile (Maik Wagner) als einfache Auszeichnungssprache für Texte, vor allem bekannt aus der Wikinutzung und kollaborativen Werkzeugen wie Confluence, und der HTML-Filter auf PHP-Basis HTML Purifier (Nicolai Schwarz).

Wo für mich noch etwas fehlt …

Wenn ich jetzt von der konkreten inhaltlichen Linie etwas abweiche, dann nur aus einem Grund: Ein Heft ist auch eine Gefühlssache, das heißt, ein Heft setzt sich für mich auch aus einem Mosaik von unterschiedlichen Formaten, Mustern, Ansätzen und Angeboten zusammen. Jeder Baustein darin ist wichtig und muss rund sein. Das Mosaik des Webstandards-Magazin ist noch nicht ganz rund für mich als Leserin – das mag für andere dann gänzlich anders sein. Aber das hier ist eine subjektive Lesereise.

Was mir am meisten fehlt, ist der größere Bezug zu Webstandards. Das mag in den vorhergehenden Heften präsenter gewesen sein, im aktuellen Heft muss ich eher ein wenig danach suchen. Dann bin ich ein absoluter Fan von Interview-Formaten, weil die so eine Mischform zwischen Stringenz und Lockerheit mitbringen. Das aktuelle Heft bietet da eine ziemliche Spanne an, nicht immer ganz rund. Hier würde ich schlicht den Ball an die Redaktion zurückspielen: Traut Euch da mehr zu. Es ist kein einfaches Format – so ein Interview -, da hat sich das aktuelle Heft auch viel vorgenommen. Gut so – ein wenig kantig noch, ab und an zu trocken und mitunter reißt der Bezug zwischen Frage und Antwort ab. Kritischer wird es dann, wenn ein Interview mit eigener Zuspitzung zusammengefasst dargestellt wird wie im Fall von Patrick H. Lauke. Ich hatte schlicht immer wieder Schwierigkeiten zu unterscheiden, wer was gesagt hat. Und dass es Web Evangelisten auch schwer haben, wissen wir ja alle. ;)

Der schwierige Spagat zwischen kurzweiligen, knappen Formaten – ich fand die Favicon-Doppelseite doch recht witzig – und tiefergehenden Fachartikeln geht immer noch auf. Ein ganz kleinwenig war es mir zu kurzweilig mitunter. Aber das mag stimmungsabhängig sein. Respekt muss man ebenso der unglaublichen inhaltlichen Bandbreite zollen, das steht das Heft ganz gut durch – andere Magazine wären da schon längst zerfasert. :)

Mein Fazit

Man muss und darf die Frage immer wieder stellen, was das Webstandards-Magazin nun von anderen Magazinen wie etwa die WEAVE unterscheidet. Ich würde sagen zweierlei: Zum einen das starke Beharren auf und das Handling der eigenen Themen. Das mag nicht immer so aufgehen, aber diese Suchbewegung bildet sich für den Leser durchaus positiv ab. Und zum anderen spürt man, dass das Magazin sich in dieser Suchbewegung immer in Bewegung hält. Diese Bewegung kann man gut an den Ecken und Kanten des Heftes erkennen und damit meine ich nicht herkömmliche Eselsohren. :) Der Balanceakt zwischen Blattlinie und immer noch irgendwie Aufbruch lässt sich gut aushalten. Etliches dabei noch unfertig, ganz klar. Auch hier wieder denke ich, kann sich die Redaktion mehr zutrauen.

Für ein Magazin, das sich immer ein Stück weiterentwickeln will, ist es wichtig, sich beständig zu häuten. Am Cover des Webstandards-Magazin kann man dieses Häuten mit jeder neuen Ausgabe mitverfolgen. Und das wird spannend bleiben.

Feel free to Flattr this post at flattr.com, if you like it.

Screenreader und Zitate: das Gesamtergebnis

Um gleich mit der argumentativen Tür ins Haus zu fallen: Es sieht durchwachsen aus mit der Ausgabe von Zitaten – nur Langzitate werden standardmäßig vorgelesen – aber auch nicht immer. Leider muss man sagen, die gesamte Semantik eines Artikels geht dann doch verloren. Der Weg kann nicht sein, jedes Zitat als blockquote-Element umzusetzen . Vor allem wenn man bedenkt, wie alt die semantische Auszeichnung von Zitaten ist. Die Verwendung reicht quasi ins HTML-Urgestein zurück: Kleine Geschichte des blockquote-Elements anhand der Spezifikationen.

Vor allem kann man die Unterstützung in der Ausgabe bei Screenreadern an der konkreten Browserunterstützung des jeweiligen Elements ablesen. So sitzt das Langzitat mit Hilfe des blockquote-Elements schon weitaus fester, auch wenn man mitunter das explizite Vorlesen erst hinzuschalten muss. Das Kurzzitat mit Hilfe des q-Elements, das ja lange Zeit nur von wenigen Browsern unterstützt wurde – IE 8 hat da ja endlich nachgezogen, hat das Nachsehen. Die Unterstützung wird dauern, da haben Screenreader eindeutig Nachholbedarf. Gänzlich abgeschlagen dann die Angabe der Quelle mit Hilfe des cite-Elements. Einzig als Attribut im Langzitat wird cite von JAWS vorgelesen. Befüllt man das cite-Attribut mit einer URL, sollte man darauf achten, dass sie nicht lang ist, denn JAWS liest das dann wirklich bis zum letzten Zeichen vor. ;) Einzige Ausnahme ist Window-Eyes, das auch über das Kurzzitat – das q-Element – informiert.

Die Testumgebung

Ich habe eine einfache Testseite erstellt, in der ich im ersten Absatz den alleinigen Einsatz eines Kurzzitats und dessen Quelle und darauf folgend das Langzitat – ein blockquote-Element mit gefülltem cite-Attribut – teste.

    <p>Der <cite>Blindtext-Generator</cite> sagt, dass <q>esse est percipi</q> ein Gassenhauer ist:</p>
    <blockquote cite="Blindtext-Generator"><p>Überall dieselbe alte Leier. Das <span lang="en" xml:lang="en">Layout</span> ist fertig, der Text lässt auf sich warten. </p></blockquote>
   <p class="quelle">Quelle: <cite><a href="http://www.blindtextgenerator.de/">Blindtext-Generator</a></cite></p>

Diese Testseite habe ich dann mit folgenden Screenreadern und Browser-Erweiterungen getestet:

• JAWS 11 mit IE 8 (Windows) und Firefox 3.6 (Windows)
• NVDA 2010.1 mit Firefox 3.6 (Windows) und IE 8 (Windows)
• Window-Eyes 7.1. und IE 8 (Windows)
• COBRA 8.1. und IE 6 (Windows)
• HAL 11 und IE 8 (Windows)
• Thunder und WebbIE (Windows)
• VoiceOver mit Safari 4.0.4 (Macintosh)
• Webscreenreader WebAnywhere
• Fangs Screenreadersimulator (Firefox)
• Fire Vox Screenreader-Plugin (Firefox)

Die Einstellungen der Screenreader und Erweiterungen sind typisch, also auf eine Default-Installation eingestellt, um festzustellen, ob die semantische Auszeichnung defaultmäßig auch aktiviert ist.

Vergleich Screenreader und Interpretation von Zitaten

Sieht man sich nun in der vergleichenden Tabelle die Ergebnisse im Detail an, ist der Interpretationsvorsprung von Langzitaten deutlich erkennbar. Pro Screenreader wird getestet, ob das Langzitat vorgelesen wird und auch bei einer Standardinstallation aktiviert ist, ob die Quelle als Attribut im Langzitat, das Kurzitat und das alleinstehende cite-Element mit entsprechender Info vorgelesen wird. Denn natürlich wird der entsprechende Text des Elementes immer vorgelesen, aber viel wichtiger ist, dass der Textabschnitt auch als Zitat gekennzeichnet wird.

Screenreader und Zitate: die Ergebnisse im Einzelnen

Das Langzitat

Standardmäßig aktiviert ist der Hinweis auf ein Langzitat nur bei JAWS und NVDA. Bei JAWS wird das Langzitat mit Zitatblock-Anfang und -Ende angesagt, NVDA setzt vor und hinter das Langzitat Zitatblock. Window-Eyes hat die Ansage des Langzitats nicht standardmäßig aktivert. In den Ausführlichkeitseinstellungen wählt man > Browsermodus > Hervorhebung / Bereichshervorhebung aus und hakt an, dass vor und nach dem Langzitat eine Nachricht eingefügt wird. Entsprechend hört sich das dann auch an: am Anfang Bereichshervorhebung und am Ende des Langzitats Bereichshervorhebung Ende. So ganz konsistent funktioniert das nicht, im Testbeispiel wird das Ende des Langzitats nicht angesagt.

Abbildung: Testseite mit Voiceover und Ausführlichkeit hochgesetzt

Auch VoiceOver geht für das Ansagen von Auszeichnungen über die Ausführlichkeitseinstellung. Dort kann man für unterschiedlichste Elemente die Ausführlichkeit erhöhen. Man kann für alles die Ausführlichkeit auf hoch setzen oder für einzelne Elemente. Aber auch wenn man die Ausführlichkeit für alles auf hoch setzt, wird die Zitatinformation noch nicht vorgelesen. Man muss erst den Textblock anwählen und dann wird die Zusatzinformation Zitatblock Ebene-1 vorgelesen. Etwas sehr gewöhnungsbedürftig, aber das ist ja VoiceOver im Allgemeinen. :) VoiceOver versucht ja auch mit dem Konzept der Webspots fehlende Semantik zu ersetzen – ein verständliches, aber auch schwieriges Konzept. Mit VoiceOver arbeite ich immer noch verhältnismässig langsam, die Lernkurve ist trotz schneller Anfangserfolge für mich recht hoch. :)

Abbildung: Testseite mit Fangs: Zitaterkennung

In Screenreadern wie Thunder, die nicht direkt mit dem Browser arbeiten, sondern mit einem Browserersatz wird das Zitat als solches nicht vorgelesen, aber durch Anführungszeichen gekennzeichnet, die auch vorgelesen werden. Ähnlich stellt das der Screenreader-Simulator Fangs dar, er markiert ganz richtig für das Langzitat den Anfang mit Block quote start und das Zitatende mit Block quote end.

Das Langzitat in Kombination mit einer Quellenangabe liest nur JAWS verständlich und verlässlich vor. NVDA scheint zwar das cite-Attribut zu erkennen, aber gibt für die Testseite kein verständliches Ergebnis wieder. Man müsste noch testen, ob NVDA nur bestimmte Werte für das cite-Attribut zulässt, etwa nur eine URL.

Tonbeispiele: Langzitat

• Zitaterkennung: Tonbeispiel JAWS (102 Kb)
• Zitaterkennung: Tonbeispiel NVDA (70 Kb)
• Zitaterkennung: Tonbeispiel Window-Eyes (66 Kb)
• Zitaterkennung: Tonbeispiel VoiceOver – nur Zitatende (45 Kb)

Das Kurzzitat

Wie schon ausgeführt, ist das Kurzzitat mit Hilfe des q-Elements noch ein Stiefkind der Ausgabe. Nur Window-Eyes gibt es genauso wie das Langzitat hervorgehoben wieder. Thunder liest auch für das Kurzzitat die Anführungszeichen vor, was wenigstens markiert, dass es sich um ein Zitat handeln könnte. Ansonsten wird ausnahmslos über das Kurzzitat hinweg gelesen. Es erfolgt auch keine Zuordnung zur Quelle des Kurzzitats, das cite-Element wird schlicht überlesen. Ich habe auch sonst keine Einstellungen gefunden, um auch noch das Kurzzitat erkennbar zu machen. Aber ich lasse mich da gerne korrigieren. :) Als Variante hatte ich noch dem q-Element das cite-Attribut testweise hinzugefügt, aber das wurde von Window-Eyes ebenfalls ignoriert.

Fazit

Man könnte jetzt den irrigen Schluss ziehen und alle Zitate – auch Kurzzitate – als Langzitate kennzeichnen. Im Einzelfall kann man das sicherlich noch entscheiden – wann beginnt schon ein Lang- und endet ein Kurzzitat. :) Aber das ist natürlich keine wirkliche Lösung. Und man muss anmerken dürfen, dass eine gängige semantische Auszeichnung wie das Kurzzitat einfach zum Standard gehören sollte, auch und gerade für das Repertoire eines Screenreaders. Also muss man sich einfach wieder auf die Wartebank setzen und hoffen, dass nach der aktuellen Browserunterstützung auch die Screenreader nachziehen werden, Window-Eyes hat das ja schon.

Überrascht hat mich NVDA, der ja für seine Standardkonformität bekannt ist, dass er das Kurzzitat schlicht ignoriert. Ebenso wichtig wäre es, dass Semantik wie die Ansage eines Zitats schlicht immer voreingestellt ist. Schließlich trägt diese Semantik wesentlich zum Verständnis eines Textes bei. Und – das sei abschließend auch angemerkt, muss man Erweiterungen wie Fire Vox, die ja einen Screenreader nur simulieren, immer wieder und noch mit Bedacht nutzen. Sieht man sich die Ergebnisse im Vergleich zu JAWS oder NVDA an, lassen sie sich nicht mit einem realen Screenreader vergleichen. Man sollte also immer mit einem Screenreader testen, Erweiterungen und Simulationen sind bis dato nur Annäherungen.

Update

Das q-Element kann auch noch verschachtelt werden. Window-Eyes, das ja das Kurzzitat entsprechend markiert vorliest, macht das auch für verschachtelte Kurzzitate. Freilich wird ab einer gewissen Verschachtelungstiefe es schwer, die Informationen zur Bereichshervorhebung noch wirklich nachzuvollziehen. Vor allem auch, weil ja die korrekte inhaltliche Zuordnung zur Quelle für das Kurzzitat nicht ausgegeben wird.

Feel free to Flattr this post at flattr.com, if you like it.

Das war 2009 für mich

Auch wenn ich hier vom barrierefreien Thema etwas abschweifen muss, aber nach all den Jahren meines Doppellebens müssen meine Leser auch mal aushalten können, dass sich nicht immer alles um Barrierefreiheit dreht. :) Das letzte Jahr habe ich damit verbracht, mein Buch Still Dialing Alice zu konzipieren, in einem Affenzahn und unter lautstarken Eigenverschwünschungen – nach dem Motto, warum tu ich mir das alles nur an ;) – zu schreiben und dann auch die Druckfahnen mehrfach haarklein durchzugehen – dafür opfert man schon gerne mal seinen gesamten Urlaub an der Küste. ;) Nach einigen Verzögerungen im Druck ging es Ende des Jahres endlich in die Buchhandlungen. Eine kleine Leseprobe für die Mutigen gibt es nun auch: Leseprobe Still Dialing Alice (PDF-Datei, 620 Kb – nicht barrierefrei).

Und für die absolut Wagemutigen hab ich auch noch 3 Belegexemplare zu vergeben, den Verteilerschlüssel – also wer das Belegexemplar erhält – lege ich nach Lust und Laune fest. :) Einfach melden mit einer DM auf twitter oder schlicht über das Kontaktformular hier im Blog oder auf welchem Weg auch immer (ich freue mich auch immer über Postkarten ;). Und wenn keiner eins will, dann behalte ich alle selbst und mach schöne Scherenschnitte draus – nee, dann gehen die wieder an so Rezensenten. ;) Ach so ja – und es gibt keine signierten Exemplare – auch wenn es schon Anfragen dazu gab, ich lehne derartige bildungsbürgerliche Attitüden und Beiwerk schlicht ab – oder ich mach ein Projekt draus, dann kann ich aber für das Buch nicht mehr garantieren. ;)

Apropos Scherenschnitt: das Zerschneiden eines meiner Texte immer genau nach 140 Zeichen war ein wichtiges Element meiner Grazer Performance Laut Computing. Eine Netzkünstlerin – also ich – sollte mit einem Komponisten eine Aktion machen – mir fiel natürlich nur wieder twitter ein. :) Samt meiner bei Ebay erstandenen lebensnahen Bewegungsmelder – einer Vogelschar, die die Besucher auf Schritt und Tritt entnervten ;) -, dem etwas hakeligen Twitterstream, den sehr guten Soundpieces von Norbert Math und dem etwas schöpfintensiven Trockeneis-in-ein-Computergehäuse-Verfrachten war das eine wirklich lustige Performance. Und Dank an den NCC09 für die tolle Einladung.

Es wird wohl noch die eine oder andere Lesung aus und zum Buch geben, aber eher weniger als mehr, das ist aber in Ordnung. :) Obwohl ich doch recht gut performiere. ;) Sei’s drum. Ich arbeite schon an einem weiteren Buch, da bin ich aber noch mehr im inhaltlichen Konzipieren, ich lass mir da Zeit. Derzeit arbeite ich mit der freien Tanzszene zusammen und wir erarbeiten den Background für ein neues Stück. Für mich was ganz neues und vor allem ein spannendes Thema. Also um es abzukürzen: Das Jahr 2009 hat für mich seit langem mal wieder richtig Arbeit im Literaturbereich gebracht, das hat ne Weile eher still gelegen und hat mich daran erinnert, dass ich da etwas säumig war in meinem Doppelleben. Mal sehen, was die Zukunft da weiterhin bringt. Absolut spannend – auch wenn es nicht um Barrierefreiheit geht. :)

Aber keine Angst, die Barrierefreiheit bleibt mir erhalten. :) Das Jahr 2009 war auch für die Barrierefreiheit ein gutes Jahr. Ich habe mich sehr über den Vortrag auf dem Wiener A-TAG gefreut, man könnte sich doch tatsächlich an so was gewöhnen. Auch die beiden Technikwürzen zu Formularen habe ich dann Ende des Jahres noch gemacht, das hat das Jahr ganz gut abgeschlossen.

Das wird 2010

Was meine ich mit meiner Art von Sabbatical: Damit meine ich jetzt keine wirkliche Auszeit – was ja Sabbatical ursprünglich meint -, sondern ich muss mich ein wenig wieder dorthin begeben, wo das Frontend sich entwickelt, sprich – mir fiel das letzte Jahr auf, dass es viele neue Themen gibt, die ich mal aufarbeiten, richtig aufarbeiten möchte. Dazu mache ich mal aus meinem Blog hier eine kleine Baustelle, um die Themen auch mal real und für die Barrierfreiheit durchzutesten: HTML 5, neuer Schrifteinsatz, WAI-ARIA, Optimierung für Mobile, mal Video genauer durchtesten, vor allem den Flowplayer mal abklopfen und und und. Es wird mal wieder Zeit für mich, mich zu vertiefen. Ich versuche das alles hier soweit wie möglich am Funktionieren zu halten, aber es kann durchaus sein, dass es Phasen gibt, wo die Barrierefreiheit eher kippt oder alles etwas durchhängt. Aber wenn ich das hier nicht machen kann, auf meinem Privathanger. :)

Mit der mobilen Optimierung habe ich schon angefangen, zwei Webinare hinter mir, das eine vom W3C – Introduction to W3C’s Mobile Web Best Practices – war eher schlicht und grundlegend, aber wenn man sich mit den Hausaufgaben Mühe gegeben hat, dann konnte man schon einen ersten Eindruck kriegen, welche Bandbreite einen da erwartet. Da ist ein Browserwar ein Spaziergang dagegen. Das zweite von O’Reilly – Learn to Build iPhone Apps with HTML, CSS, and JavaScript – war dann speziell nur für das iPhone und natürlich ungleich spannender, weil man nur den Fokus auf einen Aspekt legen kann. Webinare habe ich schlicht für mich entdeckt, die Qualitäten variieren dabei, ganz klar. Aber trotzdem fand ich das so spannend, dass ich da dran bleiben will.

Ich hab auch noch ein paar Ideen, was im barrierefreien Sektor an Standardisierung noch fehlt, daran werde ich dieses Jahr auch arbeiten und das dann entsprechend hier anbieten. :)

Okay, mal sehen, ob ich das alles so schaffe dieses Jahr, aber wir haben ja erst Februar. ;)

Feel free to Flattr this post at flattr.com, if you like it.

In unserer barrierefreien Arbeit fehlen uns immer praktische Daten. Der herkömmliche Kontext ist ja, dass wir als Entwickler die ersten Nutzer sind, dann geht noch der Controller ran, danach der Kunde und irgendwann nach Launch der eigentliche Nutzer. Hat der Kunde noch Feedbackschleifen eingebaut, erhalten wir wieder von den Nutzern Rückmeldungen, wenn sie mit der Benutzung der Webseite Schwierigkeiten haben. Das hört sich oftmals dann eher sehr allgemein an, unsere Aufgabe ist es dann, diese allgemeinen Aussagen zu überprüfen, die Schwierigkeiten zu finden – das heißt immer so schön debuggen -, den Aufwand zu schätzen und dann wieder in die Entwicklungsschleife einzubinden. Das ist quasi der 08/15 Prozess bei den meisten Agenturen.

Daher bin ich immer doppelt gespannt und erfreut, wenn ich Ergebnisse von Nutzertests lesen und sie mit den bisherigen Ergebnissen, seien sie nun theoretischer oder praktischer Natur, abgleichen kann. Ich bin einerseits zufrieden mit den Ergebnissen, nicht viel neues würde ich sagen, und andererseits auch ein wenig verwirrt, warum die altgediente Schere zwischen Theorie und Praxis wieder aufgemacht wurde. Aber nun mal alles der Reihe nach.

Der Kontext des Usability-Tests

Vielleicht ist es ja allen bekannt, vielleicht dann aber wieder nicht, die Agentur Aperto ist auch verantwortlich für Design und Frontend-Programmierung des Webauftritts einfach-teilhaben.de und der Test beschränkt sich im Wesentlichen auf das Frontend. Die Umsetzung des Webauftritts ist explizit barrierefrei und auch für Menschen mit Behinderung realisiert, also ist schon ein hohes Niveau in der Umsetzung zu erwarten. Liest man sich die Informationen zur barrierefreien Umsetzung von einfach-teilhaben.de durch, dann wird klar, warum etwa im Usability-Test explizit auf WAI-ARIA und JAWS getestet wird. Auch wird der spezielle Fokus auf die beiden dann doch konkurrierenden Suchmöglichkeiten auf einer Seite – der generellen Suche und der Spezialsuche von Arzt und Kliniken – deutlicher. Spannend auch das Thema der Farbkontraste.

Was ich hier vorausschicken will, ist, dass man einen expliziten Vergleich zwischen den Ansprüchen der eigentlichen Umsetzung von einfach-teilhaben.de und den Ergebnissen aus dem Usability-Test ziehen kann. Im Video Noch einfacher teilhaben, das wichtige Funktionen und barrierefreie Umsetzungen des Webauftritts erklärt, wird nochmals speziell auf die guten Kontraste – vor allem auch auf die Möglichkeit, den Kontrast zu wechseln, hingewiesen, auf die unterschiedlichen Suchmöglichkeiten und, was ja besonders gut und präsent umgesetzt ist, die Videos in Gebärdensprache und die Möglichkeit, die Inhalte auch in leichter Sprache zu lesen. Wahrscheinlich werden die Ergebnisse des Usability-Tests noch umfassender dokumentiert werden und dann vielleicht vergleichender angelegt sein. Gerade damit würde sich für mich die angemahnte Lücke zwischen Theorie und Praxis schließen, wenn man die real programmierten Ergebnisse mit praktischen Nutzertests abgleicht.

Nicht viel neues aus der Praxis

Sieht man sich die angeführten Ergebnisse des Usability-Tests an, ist nicht viel neues zu lesen, fast alle Ergebnisse sind soweit bekannt. Dass eine Überschriftenhierarchie, wenn gut durchdacht und logisch, auch eine gute Nutzung bietet, dass Inhalte einer Webseite übersichtlich, einheitlich und gut strukturiert angeboten werden sollen und sich durchaus gängige und bekannte Semantik wie Summary, Listen und Zwischenüberschriften positiv bemerkbar macht und lesbarer ist, war zu erwarten. Hier stelle ich mir eher die Fragen, in wieweit die Option für Inhalte in leichter Sprache auch angenommen und genutzt wurde. In den Ergebnissen werden sie nur im Kontext der Gebärdensprachvideos erwähnt, dass es optimal sei, zusätzlich zu den Gebärdensprachvideos noch ein Inhaltsverzeichnis in leichter Sprache anzubieten.

Formulare und deren Nutzbarkeit sind ja immer noch ein heikles Kapitel. Dass dabei oftmals die Formulierung ein Pferdefuß sein kann – senden für eigentlich suchen ist auch eher suboptimal, kann aber passieren -, ist bekannt. Gerade bei komplexeren Formularen wie Arztsuchen – also Suchanfragen in komplexen, oftmals Drittanbieter-Datenbanken – kann zu nicht immer alltagssprachlich verständlichen Formulierungen führen. Hier auch wieder der Hinweis in den Testergebnissen, Komplexität aufzulösen. Das genannte Beispiel hätte auch ich falsch genutzt und schön die Schrägstriche gesetzt. ;) Dass das erste Suchfeld – damit ist immer die generelle Suche über die ganze Webseite gemeint – möglichst weit oben und gerne im Kopf der Webseite erwartet wird, ist aus der Usability bekannt. Zu gerne werden auch merkwürdige Layoutkonstrukte generiert, nur damit die Suche ja ganz am Anfang der Seite steht. Dass mehrere Suchangebote auf einer Seite verwirren, ist nachvollzieh- und erwartbar, schließlich steigt die Komplexität der Webseite dann insgesamt gehörig. Bei der Vorschlags-Suche sollte vielleicht erwähnt werden, dass sie stark browserabhängig ist, ich müsste dafür wohl erst meine virtuelle Umgebung anwerfen. Aber klar – gerade die Suggest-Suche gehört zu jenen Features, die sogar das WCAG 2 empfiehlt.

Die diskussionsfreudigen Ergebnisse

Vorsichtiger sollte man jedoch an jene Ergebnisse herangehen, die sich so in der Form nicht wirklich verallgemeinern lassen oder zumindest diskussionswürdig sind. Anschauliche Wissensvermittlung ja, aber alles jetzt auf Videos zu verlagern, weil es einfach sei, einen Play-Button zu drücken, halte ich für eher wenig praxisnah. Das Zitat des Nutzers bezieht sich dabei auf das Lesen langer Texte. Ich stelle mir gerade vor, lange Text ins Videoformat zu transferieren. Alles möglich, keine Frage, aber weder robust in die Zukunft noch sinnvoll. Videos können ergänzen, aber sollten nicht ersetzen. Sich auf den Back-Button zu 100% zu verlassen, mag ja eine gute, alte Angewohnheit der Nutzer sein, aber ich würde hierzu lieber mehr Praxisdaten haben wollen, bevor man hochdynamische Seiten wieder so runterregelt, dass der Back-Button auch wieder auf die Vorseite zurückführt. Irgendwie erinnert mich das an die Anfangszeiten des Webs und der PHP-Programmierung …

Dass der Screenreader in seiner aktuellen Version nicht immer Standard ist, ist bekannt. Aber der Weg kann doch nicht sein, dass man auf WAI-ARIA Landmarks verzichtet, weil einige Nutzer noch JAWS 4 haben. Die Darstellung der Testergebnisse erwecken etwas ungeschickt jedoch den Eindruck, wir sollten uns jetzt wieder mehr nach unten hin orientieren, dabei ist ein Einsatz von Landmarks nach unten ja kompatibel, der alte Screenreader ignoriert das einfach. Ein generelles Verdikt gegen den alleinigen Einsatz von WAI-ARIA auszusprechen, ist derzeit doch gar nicht notwendig. Ich denke, niemand setzt WAI-ARIA derzeit ausschließlich ein, die Frage ist doch, ist WAI-ARIA dafür überhaupt gedacht?

Mich würde in diesem Zusammenhang interessieren, mit welchen Screenreadern wurde getestet und sind Opensource-Reader wie NVDA überhaupt eine Option für die Nutzer? Gerade bei so einer spezialisierten Webseite wie einfach-teilhaben.de wäre die Nutzung von Screenreadern interessant, vielleicht wäre eine Umfragemöglichkeit da spannend. Wir haben ja für den deutschsprachigen Raum immer noch zu wenig Daten zur Screenreader-Nutzung, ist JAWS wirklich Marktführer. Sieht man sich im Vergleich dazu die Screenreader-Umfrage von WebAIM für den englischsprachigen Bereich an, fällt auf, dass JAWS auch Marktführer ist, aber NVDA als Zweitreader durchaus gängiger wird. Die Updatefreudigkeit liegt viel höher bei über 80% und sieht man sich die Nutzung von WAI-ARIA Landmarks an, liegt die fehlerhafte Nutzung nur zu 5% daran, dass der Screenreader sie nicht interpretiert. Über 40% der Nutzer wissen schlicht nicht, dass es Landmarks gibt. WebAIM summiert daraus, dass es eben eine bessere Informationspolitik dahingehend geben muss.

Ein weiteres schwieriges Terrain ist tatsächlich die Kontrastproblematik. Zwar haben wir jetzt durch das WCAG 2 eine neue Kontrastformel, sämtliche Tools testen auch schon wunderbar darauf ab. Aber – und das ist für mich wirklich das einzige wirklich spannende Ergebnis des Usability-Tests – was ist, wenn zwar alles richtig zahlentechnisch validiert, aber der Nutzer nach wie vor meldet, dass der Kontrast undeutlich oder zu schwach ist? Interessanterweise erhalte ich, wenn ich die entsprechenden Farbwerte in den Colour Contrast Check eingebe, wieder andere Werte als die in der Studie ausgewiesenen im Kontrastchecker, vor allem validieren sie nicht auf AA für normale Texte. Ein weiterer problematischer Punkt bei diesen Kontrasten ist, dass sie auf einem Verlauf liegen. Dadurch kann man gut nachvollziehen, dass Nutzer von Flimmern sprechen. Immer eine problematische Geschichte: Fliesstext auf Verläufen.

Barrierefreiheit ist alles zusammen: Theorie, Technik und Praxis.

Ein wenig schade ist, dass die Testergebnisse dann auf diese Schere zwischen Theorie und Praxis zusammengestutzt werden. Dabei fußt der Test doch auf beidem: Theorie und Praxis. Es wäre doch arg verkürzt zu sagen, wir entwickeln Webseiten aus einer, wenn auch gängigen Theorie? Ich denke, diese Schere beruht auf einem Missverständnis von Theorie. Vielleicht ist das auch das falsche Wort dafür – eher meint es so was wie etablierte Standards. Und etablierte Standards entstehen und entwickeln sich weiter aus beidem: Theorie und Praxis. Wenn uns freilich immer eher Input aus der konkreten Nutzerpraxis fehlt.

Ohne diese etablierten Standards könnten wir barrierefreie Seiten niemals professionell umsetzen. Wir müssen uns auf Standards und deren Werkzeuge verlassen können. Bei der Kontrastproblematik fehlt mir oft der ganze praktische Rahmen, also muss ich mich auf die Testwerkzeuge verlassen können. Und wir haben mittlerweile gute Standards, wir haben ein WCAG 2, das uns die Standards auch noch technisch unterfüttert, uns Werkzeuge, Best Practice liefert und uns auf Fehler aufmerksam macht. Nur auf diesem etablierten Standard können die Testergebnisse dann kritisch hinterfragt und bewertet werden. Ich bin völlig einverstanden mit der Aussage, dass sich jeder Test mit Nutzern lohnt. Aber wir sollten immer daran denken, dass sich Theorie aus Praxis und umgekehrt speist.

Insofern plädiere ich immer zuallerst für eine barrierefreie Theorie, auch wenn der Nutzer – wie im WAI-ARIA Landmark-Fall – noch nicht davon gehört hat. Ich bin Entwicklerin.

Feel free to Flattr this post at flattr.com, if you like it.

Den W3C Validator zu nutzen, um eine Webseite auf ihre Validierung zu prüfen, ist ja für uns alle Tagesgeschäft, wir sollten aber, wenn wir eine Webseite prüfen, uns auch das Prüfprotokoll genau ansehen und die aufgeführten Fehler in einen entsprechenden Kontext setzen. Und weil es mir gerade Spass macht, greife ich ein wenig plagiathaft dabei auf Wittgensteins Tractatus Logico-Philosophicus zurück – sehr bescheidene Reminiszenz an mein Salzburger Philosophiestudium. ;)

Im Quellcode ist nichts zufällig

Sehen wir uns doch mal genauer an, was im Quellcode bei Manufactum nicht validiert. Oliver Heeger hat das nur kurz angerissen, hier ein wenig detailierter: Nicht-maskiertes Javascript (1x), Schachtelungsfehler (5x) und Doctype-Warnungen (25x). Führt man die Fehler und Warnungen des Validators so auf, relativiert sich schon einiges.

Geht man nun noch genauer an die einzelnen Fehlerquellen ran, kann man gut festmachen, woher die Fehler kommen. Gut, das nicht-maskierte Javascript muss schlicht maskiert werden, das tritt an einer Stelle auf und ist schnell behoben. Spannender wird es bei den Doctype-Warnungen. Fast ein Klassiker dürfte es sein, das Meta-Element von Google in der XHTML-Variante schlicht zu kopieren. Die Seite selbst nutzt ja den Doctype HTML 4.01 Strict, daraus ergeben sich sämtliche Doctype-Warnungen. Ein weiterer, mir sehr bekannter Klassiker ist das Input-Feld type=hidden, das xhtml-konform mit Slash geschlossen und so eingebaut wird. Höchstwahrscheinlich kommen die Formularelemente xhtml-konform aus einer dynamischen Engine.

Für die Überschriften wird ein System verwendet, dass den Inhalt der Überschrift aus dem CMS in eine Grafik rendert. Leider schließt diese Grafik auch wieder mit einem Slash xhtml-konform ab und wirft daher eine Doctype-Warnung. Auch hier vermute ich, dass dieses System die Grafik automatisch ins Template packt, eventuell kann man im Backend an die Generierung rangehen und den Slash entfernen. Wenn es im Template dynamisiert ist, dann geht das quasi sofort. :) Da die Überschrift natürlich mehrmals auf der Webseite eingesetzt ist, ergeben sich daraus dann mehrfache Warnungen. Auch br-Elemente sind immer mal wieder xhtml-konform geschlossen, aber – soweit ich das erkennen kann – immer nur in Teiltemplate-Kontexten. Daraus lässt sich schließen, dass hier wohl ein Editor, der xhtml-konform arbeitet, im Einsatz ist.

Bei den Schachtelungsfehlern, dass etwa in ein p-Element ein div-Element verschachtelt ist – da kommen sich zwei Blockelemente in die Quere -, bin ich noch unsicher, wie die wirklich zustande kommen. Sie treten innerhalb Teiltemplates auf und das p-Element umschließt dabei stets andere Blockelemente wie div. Zuerst dachte ich, dass das p-Element eventuell durch den Einsatz eines Editors entsteht, aber es ist eher unwahrscheinlich, dass im Editor fest benamte div-Elemente eingebaut sind. Okay, möglich ist immer alles. :) Sieht man sich jedoch den gesamten Aufbau der Seite an, fällt diese Block-in-Block-Schachtelung eher singulär auf. Interessant wäre für mich, wie das genau in der Templategenerierung passiert.

Der Quellcode gehört nur zur Aufgabe, nicht zur Lösung

Zugegeben das ist jetzt Wittgenstein sehr zugespitzt formuliert, aber es soll darauf hinweisen, dass Quellcode Aufgaben erfüllt und nicht Selbstzweck ist. Es ist natürlich wunderbar, wenn die Aufgabe soweit erfüllt wird, dass sie auch gelöst und valide ist. :) Sehen wir uns jedoch die Validierungsprobleme von Manufactum genauer unter diesem Aspekt an, fallen uns zwei Stichworte ein: Dynamisierung und Fremdsysteme. Manufactum wurde von der Agentur neuland bereits 2007 realisiert, die sich auf Shopsysteme spezialisiert und den Relaunch auf der Basis von spring/hibernate realisiert hat. Abgesehen davon, dass Shopsysteme lange Zeit – wer schon damit Erfahrung gewonnen hat, wird mir zustimmen – ohnehin oft eine Webstandards-Wüste waren, scheint die Kombination von Spring- und Hibernate-Framework in der Ausgabe richtig gut anpassbar zu sein. Leider kenne ich beide Frameworks nicht, aber ich nehme an, dass da – sieht man sich die Kommentare an – auch ein Templatesystem zur Verfügung steht. Und was da an Teiltemplates ausgegeben wird, ist durchaus sehr semantisch, weitgehend reduziert und standardkonform.

Templatesysteme bringen uns endlich Dynamisierung und daher kann man die Validierungsprobleme bei Manufactum auch sicherlich schnell beheben. Nimmt man die Fehler und Warnungen nur 1x, sieht das dann wirklich schon fast beiläufig aus: Nicht-maskiertes Javascript (1x), Schachtelungsfehler (2x) und Doctype-Warnungen (5x). Es ist schlicht wichtig, sich die Anzahl der Fehler im Hinblick auf den dynamischen Aspekt anzusehen. Schließlich wird der schließende Slash dann x-mal durch die mehrmalige Templateeinbindung ausgegeben. Andererseits muss der Slash dann auch nur an einer Stelle in einigen Teiltemplates entfernt werden, auch so ein wunderbares Ergebnis des Templating.

Und außerhalb der Validität ist alles Zufall?

Nein. :) Aber seit Jahren warten wir auf BIENE-Preisträger die hochkomplexe, dynamische Systeme barrierefrei gestalten. Und wer mit hochdynamischen Systemen täglich arbeitet, wird mir wieder zustimmen, dass das für die Barrierefreiheit zweierlei bedeuten kann: einen Fluch und einen Segen. Zum einen wird es mit Templatesystemen und Engines etwa für Formulare einfacher, an genau abgegrenzten Stellen Barrierefreiheit einzuarbeiten und in hoher Dynamik dann auch verlässlich auszugeben und zur Verfügung zu stellen. Andererseits steigt durch hochdynamische Systeme auch die Fehlerhäufigkeit, die Komplexität von Modulen und Techniken oder auch die Einbindung von Fremdanteilen. Mitunter hat man auf etliche Module und Anteile dann kaum oder gar keinen Zugriff mehr.

Was bleibt? Oliver Heeger hat natürlich recht, Validitätsprobleme einzuklagen. Aber – und da sollten wir einfach mal mindestens einen Schritt in der Argumentation zurückgehen – angesichts dessen, was an Dynamik hinter Manufactum steht, sind die Validitätsfehler und -warnungen doch minimal. Das finde ich spannend an so einem Preisträger, zu verfolgen und mir genau anzusehen, wie er mit diesen komplexen Anforderungen im Hinblick auf Webstandards und Barrierefreiheit umgeht. Und es gibt ja noch mehr Preisträger dieses Jahr, die mit hochdynamischen Systemen arbeiten. Eben genau auf solche Ergebnisse und Preisträger haben wir doch gewartet oder?!

Insofern kann man Wittgenstein nur zustimmen: Einen a priori wahren Quellcode gibt es nicht. Wir müssen ihn immer wieder mit der (dynamischen) Wirklichkeit vergleichen.

Update

Mathias Schäfer hat hier in seinem Kommentar sehr richtig darauf hingewiesen, dass es sich bei p > div nicht um Schachtelungsfehler handelt, sondern das schliessende p in HTML 4 optional ist und daher im Validator nur der Hinweis auf ein schliessendes p steht, das keine Entsprechung mehr zu einem öffnenden hat.

Feel free to Flattr this post at flattr.com, if you like it.

Februar: transmediale (Berlin)

Da ich arbeitsbedingt Anfang Februar in Berlin sein werde, habe ich mich gleich zur transmediale aufgerafft. Da werde ich dann vom 2.-7.2. Performance, Film, Ausstellung und Konferenz in Sachen Futurity Now genießen – endlich mal wieder ein richtiger medialer Kulturlandschaftsstrich. Vor allem für mich spannend meinen ehemaligen Medientheorie-Professor wieder zusehen – Siegfried Zielinski. Grade erfreut gesehen, dass er erst am Samstag seinen Vortrag hält, freitags wäre das kritisch gewesen, weil ich da ja den ganzen Tag arbeitsbedingt okkupiert bin, aber die haben Long Conversation bis 22:00 Uhr – da kann ich ja danach mich in den Konversations-Chair setzen. Ach so, weiß ja kaum einer, ich habe Medientheorie und -geschichte mit Schwerpunkt Geschichte der Medien studiert, deswegen freu ich mich bannig auf die Ausstellung zur Futura Obscura. Das erinnert mich wieder daran, dass mein Aufsatzentwurf zu Goethes Wahlverwandtschaften und dem Camera-Obscura-Motiv noch immer unfertig in der Schublade liegt. Für mich ist die transmediale quasi wieder eine Rückkehr zu meinen medientheoretischen Wurzeln, die vernachlässige ich derzeit sehr, leider.

April: re:publica (Berlin)

Hatte ich ja letztes Jahr nicht geschafft, die re:publica. Ich könnte jetzt sagen, ich hab schon gebloggt, da hieß das noch gar nicht so. ;) Nee, wirklich – ich kenne sogar die Vor-Nucleus-Zeiten. ;) Insofern ist es endlich ein Muss, als Urgestein da mal aufzutauchen und sei es nur, um alles ganz schön langweilig und kommerzialisiert vorzufinden. Und ist ja auch in Berlin, da weiß ich mir sonst schon zu helfen – hab mich ja jahrelang in Berlin gut durchgebracht. Nee, ich freu mich wirklich drauf, werde mich da wieder ne Woche in Berlin an- und einschließen. Fein.

Herbst: stARTconference (Duisburg), Webkongress Erlangen (Nürnberg), A-TAG (Wien) und Fronteers 2010 (Amsterdam)

Irgendwie bündelt sich immer dann alles in Richtung Herbst, das scheint schon fast ein Konferenzgesetz zu sein. ;) Letztes Jahr habe ich es nicht auf die stARTconference geschafft, dieses Jahr habe ich ja auch zu meinem Kulturjahr ernannt, also habe ich da auch so meine Verpflichtungen (transmediale, re:publica) und fahre im September nach Duisburg. 2 Jahre haben wir ja nun gewartet auf den Webkongress Erlangen, nun ist es wieder soweit, diesmal dann wohl in Nürnberg und zum Thema Lösungen / Solutions. Ergo also mustergültige Lösungen, Best Practices. Ich fand den Kongress schon vor 2 Jahren sehr spannend und unkompliziert im Umgang, daher freu ich mich auf ein Update.

Der A-Tag in Wien ist ja immer eine Reise wert, nicht nur wegen Wien. ;) Im Twitter war zu lesen, dass es auch dieses Jahr wieder einen A-Tag geben wird, also werde ich schon mal einen Timeslot freimachen von Oktober bis November … Die Fronteers 2010 ist ein Musstermin für mich – wahrscheinlich wieder November -, letztes Jahr war das meine erste ausländische Konferenz und bis auf ein paar Abstriche fand ich das sehr spannend. Auf ihrer Konferenzwebseite haben sie ihre Besuchererwartungen noch mal um 100 Teilnehmer hochgeschraubt. Gut, spätestens dann brauche ich ein größeres Hotelzimmer in Amsterdam (mein Bericht aus dem letzten Jahr lässt dahingehend und überhaupt nichts zu wünschen übrig).

Höchstwahrscheinlich werde ich noch auf der Webtech sein, weil unsere Programmierung festgestellt hat, dass letztes Jahr auch was für uns Frontend-Entwickler da dabei gewesen wäre. Ach nee! ;) Wenn ich mir das grade jetzt noch mal so durchsehe, ist das im Grunde schon wieder alles zu üppig, aber was soll’s, ich habe mich letztes Jahr schlicht an dieses unstete Leben gewöhnt und finde es irgendwie auch gut so. Auch wenn mich dann nachts im Hotelzimmer der Katzenjammer einholt und ich mir vornehme, endlich diesen vermaledeiten Aufsatz zu Goethes Wahlverwandtschaften durchzuarbeiten. Aber irgendwie ahne ich, der wird auch dieses Jahr nicht fertig werden. ;)

Feel free to Flattr this post at flattr.com, if you like it.

Die übersetzten Dokumente – derzeit sind es schon 7 – werden auf der Webseite von Einfach für Alle jeweils angekündigt, sind Rohfassungen und können jederzeit von allen im Kommentarbereich kommentiert und verbessert werden. Ich habe schon damit begonnen, immer wenn ich ein wenig Zeit habe, die Texte durchzukommentieren. Das geht recht flott und es würde helfen, wenn sich da mehr aufraffen würden. Je mehr Leute sich ein wenig Zeit nehmen, desto weniger ist es insgesamt für den Einzelnen. :) Also wirklich, bis dato hat kaum einer versucht, da ein wenig gegenzulesen. Schliesslich hat man selten die Gelegenheit, aktiv an Übersetzungen für den eigenen Fachbereich mitzuarbeiten und auch noch so einfach mit ein paar Kommentaren.

Also los und danke! :)

Feel free to Flattr this post at flattr.com, if you like it.

Kurz kommentiert: Die Implementierung von WAI-ARIA ist ohne Screenreader-Test zwar machbar, aber wenig sinnvoll. Abgesehen davon zeichnet sich barrierefreie Entwicklung großteils durch das Testen mit Screenreadern aus. WAI-ARIA ist ein aktueller Standard, der von Elementen und Attributen her unterschiedlich gut schon von assistiven Technologien unterstützt wird – das konnte ich vor kurzem bei den Attributen für Formulare feststellen. Es war nicht immer einfach zu entscheiden, liegt es am gewählten Screenreader, Browser oder an einer Kombination von beidem, dass das WAI-ARIA-Attribut nicht vorgelesen wurde. Man hat sich also immer auf dem Laufenden zu halten, was die Implementierungstiefe betrifft, insofern muss man auch mit den aktuellsten Updates arbeiten.

Ob man jetzt eher mit der konkreten Spezifikation von WAI-ARIA oder dem von der WAI ebenso zur Verfügung gestellten Best-Practice-Dokument, sollte man jedem dann selbst überlassen. Ich fand letzthin der Gang durch die WAI-ARIA-Spezifikation sehr spannend, weil mir klar wurde, wie umfassend und detailliert der Standard letztlich dann ist. Durch die allgemeine Diskussion laufen ja eher nur die landmark roles, die live regions zu einem gewissen Teil und ein paar Attribute für Formulare – das war es dann aber auch schon. Aber davon gleich abzuleiten, gut – der gestandene barrierefreie Entwickler setzt dann das schnell irgendwo ein und hübscht sich seine barrierefreien Seiten auf, ohne sich intensiver sowohl mit Standard als auch der praktischen Ausgabe auseinandergesetzt zu haben, ist schlicht nicht stimmig. Und ich kenne nun doch schon einige barrierefreie Entwickler.

Letztlich glaube ich, dass ein Missverständnis bei Farkas vorliegt, was das Thema Liveregions und sein Verständnis bei den barrierefreien Entwicklern betrifft. Ich denke, jeder der sich mit dem Thema beschäftigt, sich die Ausgaben angehört und die Spezifikation oder ähnliches dazu gelesen hat, weiss, dass der Nutzer nur über Änderungen auf der Webseite informiert wird, aber auch nicht mehr – also keine sonstigen Aktionen oder Fokusänderungen daran gebunden sind. Nichts andres besagt der Abschnitt in der Best-Practice – aber ich lasse mich gerne korrigieren:

Live regions enable assistive technologies, such as screen readers, to be informed of updates without losing the users’ place in the content. Live region settings provide hints to assistive technologies about how to process updates. Note that the assistive technology is responsible for handling these updates and enabling users to override these hints.

Quelle: 5.2. Implementing Live Regions

Ich denke trotzdem, dass die Reihe von Farkas wichtig ist, weil es eben gerade bei Standards, die noch nicht vollständig in der Praxis umgesetzt sind – Browser, Screenreader – eben Graubereiche gibt, geben muss. Das meint nicht, dass wir als barrierefreie Entwickler mal wieder nicht alles gelesen oder fertig implementiert haben, sondern dass wir uns sehr wohl der Graubereiche bewusst sind und erst lernen, wie man damit am besten umgeht. Hat man sich mehrmals das Attribut aria-required in Screenreadern angehört, kann man dieses Attribut dann getrost in die Breitenwirkung geben. Erst wenn assistive Technologien auch Attribute aus HTML 5 auslesen – wie etwa required – muss man sehen, wie man mit dieser Mehrfachbelegung dann umgeht, geht es wieder darum, Standards abzuwägen. Und: ich halte es für wichtig, das immer wieder zu tun.

Feel free to Flattr this post at flattr.com, if you like it.

Sascha Postner sprach mich vor einiger Zeit an, ob wir nicht eine Spezialsendung zu Formularen machen sollten. Daniel Jagszent hat sich spontan dazugesellt. Für mich diesmal – weil bald klar war, dass das Thema für eine Sendung zu umfangreich ist – recht intensive Vorarbeit für zwei Sendungen. Für Sendung 1 zur Usability von Formularen hatten wir uns vor allem auf die drei in den letzten zwei Jahren erschienen Bücher von Luke Wroblewski (Web Form Design), Jarrett und Gaffney (Forms that work) und Featherstone, Connell und Bolton (Fancy Form Design) konzentriert. Für Sendung 2 zur Barrierefreiheit von Formularen habe ich mir einen zugleich festen und offenen Rahmen vorgenommen: Es sollten die klassischen Standards für barrierefreie Formulare abgehandelt werden, aber auch – weil mir das immer wichtig ist, einen Schritt über meinen eigenen Tellerrand zu gehen – Aktuelles und Neues einzuarbeiten wie das WCAG 2, einen Ausblick auf HTML 5 und WAI-ARIA zu machen. Selbst für mich war das mitunter halb Neuland und halb Glaskugel. Um dem auditiven Medium gerecht zu werden und weil Beispiele ja unterstützen, habe ich einige Screenreader-Beispiele mit JAWS und NVDA erstellt.

Technikwürze Formulare total 1 (Formulardesign)

Jedes der drei Bücher hat seinen eigenen Schwerpunkt, auch wenn sich alle drei unter dem Aspekt Usability fassen lassen. Nach wie vor halte ich das Buch Web Form Design für das stärkste Buch in diesem Bereich, weil es sehr in die Tiefe geht und auf Usability- und Eyetracking-Studien basiert, Luke Wroblewskis Blog Functioning Form bietet ja immer wieder Updates zum Thema und Luke W kann schreiben. :) Was Functioning Form so spannend macht ist die Genauigkeit etwa an die Position eines Label-Elements heranzugehen – ob nun über, links- oder rechtsbündig neben dem Inputfeld, immer unterfüttert mit Eyetracking-Ergebnissen.

Fancy Form Design ist schick gemacht, verliert sich in der zweiten Hälfte ein wenig zu sehr in der Praxis, wie man Formulare mit HTML, CSS und Usability im Blickwinkel umsetzt, hat jedoch eine spannende erste Hälfte und versucht darin, aktuelle Formulare zu klassifizieren. Formulare sind mittlerweile sehr ausdifferenziert, neben den klassischen Elmenten wie Inputfeld, Select oder Checkbox gibt es sogenannte enhanced elements wie:

• Split Buttons: Für mich lange Zeit ein reines Button-Element, dass ich traditionell schlicht geklickt, aber immer übersehen habe, dass da noch ein kleiner Pfeil auf eine Auswahlmöglichkeit hinweist. Seit mir das bewusst wurde, hab ich dazugelernt, ;)
• unterschiedliche Formen von Slidern in Formularen,
• Toggle Switches: Schalter, mit denen Zustände verändert werden können wie an oder aus,
• aber auch Begleiterscheinungen wie Kalender- und Farbauswahlen oder Drag & Drop-Möglichkeiten.

Fancy Form Design finde ich gerade in diesem Klassifikationsversuch stark, weil man einerseits seinen Blick auf Formulare erweitern kann – das hat nur noch wenig mit unseren klassischen Kontaktformularen zu tun – und andererseits man besser über Formulare sprechen kann, wenn man sich eines gemeinsamen Vokabulars bedient – ansonsten kann es zum Thema schnell sehr allgemein werden. Bei weitem habe ich das Vokabular in Sachen Formularen nicht komplett durchdrungen – dazu war die Vorbereitungszeit auch zu knapp, aber es war mal ein Anfang. :)

Forms that work ist für meine Lesebegriffe ein wenig zu allgemein unterwegs. Andererseits fand ich Themen wie Grids für Formulare und ein Konzept wie Personas sehr spannend, leider wurde es nur kurz angerissen. Insofern ist das Buch ein Einsteigerbuch in unterschiedlichste Usabillity-Aspekte, die das Vorfeld von Formularen betreffen, also bevor man mit HTML und CSS rangeht. Das Personas-Konzept formt den Nutzer vor als eine Art Archetyp, damit man sich unterschiedliche Nutzergruppen besser vorstellen kann beim Entwickeln eines Formulars. Spannendes Konzept, werde ich mir genauer ansehen.

Wie man vielleicht aus meinen Anmerkungen erkennen kann, eine sehr diverse Sendung, weil eben sehr umfangreich vom Thema, aber ein erster guter Einstieg.

Und jetzt weiter zur Technikwürze Formulare total 1 (Formulardesign)

Technikwürze Formulare total 2 (Barrierefreie Formulare)

Für eine Technikwürze versuche ich mich konzeptionell sehr streng vorzubereiten, weil man sich sonst sehr schnell inhaltlich verlieren kann. Daher habe ich einen relativ strengen Aufbau für die Sendung zu barrierefreien Formularen gewählt und Aufbau ist so streng gemeint, dass die Sendung auch inhaltlich aufeinander aufbaut: Zuerst sehen wir uns die klassischen barrierefreien Formulare an, wie wir sie täglich erstellen mit ihrem starken Konnex zu Webstandards. Anhand des Newsletter-Formulars des diesjährigen BIENE-Gold-Gewinners Manufactum gehen wir diese klassischen Elemente und Strukturen durch und hören uns das Formular im Screenreader JAWS an.

Von diesem klassischen Formular gehen wir aus und vergleichen es mit den aktuellen Vorgaben hinsichtlich Formularen im WCAG 2, machen dann einen Ausblick, was sich in HTML 5 mit Blick auf das klassische Formular verändern wird und schließlich bauen wir das klassische Formular mit WAI-ARIA Elementen und Attributen aus, was ja jederzeit und sofort von uns allen integriert werden kann und soll. Also ein fast klassischer Auf- und Ausbau, aber mir war wichtig, dass es eben praxisnah barrierefrei wird und möglichst jeder an seine Formulare nach der Sendung geht und zumindest das WAI-ARIA Attribut aria-required einbaut. :)

Klassische barrierefreie Formulare

Setzt man Webstandards ein, ist man in der barrierefreien Optimierung von Formularen schon sehr gut am Punkt: Der korrekte Einsatz von label mit for/id-Verknüpfung, fieldset und legend für abgrenzbare, inhaltliche Bereiche eines Formulars, die korrekte barrierefreie Optimierung von Buttons etwa für type="image", das Formular für die Tastaturnutzung mit Hilfe eines erkennbaren und nutzbaren Fokus optimieren und die sinnvolle und nachvollziehbare Fehlerkennzeichnung und -behandlung in Formularen sind schon ne ganze Menge und bereiten ein barrierefreies Formular so auf, dass unter anderem ein Screenreader-Nutzer damit gut arbeiten kann. Freilich hört man sich Einsatz und Ausgabe von WAI-ARIA in einem Formular mit einem Screenreader an, erkennt man schnell, wo die Optimierung mit WAI-ARIA ansetzt – das hört sich einfach besser an. Genau so soll es sein – ich wünschte mir das durchaus auch für alle Nutzer – das Arbeiten mit einem Formular soll ja auch Spaß machen. :)

Schon etwas älter ist die Artikelserie von Einfach für Alle Reine Formsache, aber es hat sich, was das klassische barrierefreie Formular betrifft, nicht sonderlich viel geändert. Interessanterweise wurden schon damals – 2007 – die strittigen Punkte für barrierefreie Formulare klar benannt, Punkte, die historisch gewachsen heute auch tatsächlich kaum mehr – aus den unterschiedlichsten Gründen – in Verwendung sind wie der Einsatz eines Tabindex oder von Accesskeys, der Vorbelegung von und der Einsatz des title-Attributs in Formularfeldern.

WCAG 2 und Formulare

Aus dem WCAG 2 habe ich mir nur einige interessante Themen rausgesucht, vor allem die Behandlung von Fehlern in Formularen ist spannend. Ganz klar ist, dass der Einsatz von label (for/id), fieldset bereits auf der ersten Stufe – Level A – zwingend ist. Wie auch sonst, schließlich ist das ja die Basis eines barrierefreien Formulars. Viele spannender finde ich den Versuch des WCAG 2, auf die aktuelle Praxis einzuschwenken:

• So werden Standards erkannt wie ein gängiges Suchfeld auf Webseiten und es ist erlaubt, dafür kein Label zu setzen. Das kommt immer auf das konkrete Layout an, aber wie oft haben wir nur ein Suchfeld und einen Button vorliegen? Hier ist es dann hinreichend, im Suchfeld das title-Attribut zu nutzen. Das WCAG 2 ist jedoch kein Freibrief für Moden. ;)
• Besonderes Augenmerk wird im WCAG2 auf die Fehlerbehandlung gelegt, so wird sogar auf die clientseitige Validierung Wert gelegt, weil sie den Nutzer sofort auf einen Fehler aufmerksam macht. Natürlich soll es als Fallback immer noch die serverseitige Validierung geben. Auch stark durch die Praxis beeinflusst ist der Wunsch, dass es eine direkte Fehlerfokussierung geben soll und eine Möglichkeit zwischen den Fehlern zu navigieren – wie man das auch immer in der Praxis dann umsetzt.
• Das WCAG 2 unterscheidet die Fehlerbehandlung in drei Stufen: Auf Level A (Fehlererkennung) muss ein Fehler zumindest erkennbar sein mit Hilfe von Semantik, Text und / oder Farbe. Auf Level AA (Fehlererläuterung) sollen die Fehler nicht nur erkennbar, sondern auch mit Beispielen und Hilfen etwa nahe am Formularfeld erläutert werden. Auf Level AAA (Fehlerprävention) liegen dann erst jene Schritte und Bestätigungen, die für uns bei ausführlicheren Formularprozessen ohnehin längst gängige Praxis sind. Formulare, die in Schritten durchlaufen werden, müssen auch in Schritten erkennbar und benutzbar sein und Bestätigungsseiten anbieten, die dem Nutzer entweder noch einmal eine Möglichkeit geben, die Inhalte zu bestätigen, oder schlicht die Ergebnisse des Formulars noch einmal klar anzeigen. Folgerichtig wird hierbei der Level bei finanziellen und rechtlichen Transaktionen dann auf AA gehoben.

HTML 5 Formulare

HTML 5 bringt für Formulare viel neues, wenn es denn dann auch vom Browser interpretiert wird. Aber ich sag es mal so, das wird schon noch alles. :) Interessant fand ich, wie unterschiedlich die Interpretation von Attributen und Elementen ist – also was geht schon in Safari und Opera. Wichtig ist, dass es schlicht endlich neue Typen gibt für Email, Datum oder Suchfeld. Schließlich hat in HTML 5 auch die Praxis endlich rückgewirkt, denn ein Email-Feld unterscheidet sich schlicht von einem herkömmlichen Formularfeld. Neue Attribute wie required, autofocus und placeholder (Vorbelegung eines Formularfeldes) werden sicherlich bald flächendeckend eingesetzt werden – vor allem required für ein pflichtiges Feld.

Bruce Lawson hat in seinem Artikel The accessibility of HTML 5 autofocus bereits mit dem Attribut autofocus zu kämpfen. Mit diesem Attribut setzt man nach dem Laden der Seite den Fokus direkt auf das Feld. Mag das bei Formularen direkt am Anfang der Seite oder speziellen Formularbereichen wie etwa einer Fahrplanauskunft durchaus sinnvoll sein, kann das bei Seiten, die einen erklärenden Text vor dem Formular haben, zum Problem werden. Beim Fokus auf ein Formularfeld geht etwa ein Screenreader in den Formularmodus und der vorherige Inhalt wird dann nicht vorgelesen, enthält womöglich aber wichtige Vorinformation.

Ein Manko derzeit ist, dass assistive Technologien wie Screenreader die neuen Attribute wie ein required noch nicht auslesen. Irgendwo hab ich gelesen, die präferieren derzeit einfach den Einsatz und die Ausgabe von WAI-ARIA. Klingt zwingend. Aber – warum sollte man nicht ein Attribut wie required schlicht so ausgeben wie eben sein WAI-ARIA-Pendant? Vor allem weil so ein Attribut wie required dann eben in einem Standard ohnehin implementiert ist und man sich mit WAI-ARIA dann an zusätzlichen Ausgaben und Features erfreuen kann?

WAI-ARIA und Formulare

WAI-Aria hat mich wirklich überrascht, wie Screenreader – etwa JAWS und NVDA – da wirklich eine Serviceleistung in Formularen anbieten. Man muss einfach sagen, so macht es Spaß, mit einem Formular zu arbeiten. Wie schon gesagt, ich würde mir das durchaus für alle Nutzer wünschen, grade Formulare sind ja nicht so mit einem Spaßfaktor belegt. ;) Vor allem die Kombination von Attributen kann dann wirklich einen Wow-Effekt erzeugen. :) Aber, da stimme ich Alexander Farkas, der derzeit in der Reihe WAI-ARIA – Epic Fail aufzeigt, was kann man alles mit WAI-ARIA machen, aber was kann dann auch zuviel oder gar kontraproduktiv sein, zu, wir müssen uns der Servicequalität von WAI-ARIA immer bewusst sein und testen, testen und testen. :) Vor allem in Kombination mit HTML 5 wird WAI-ARIA dann durchaus noch zu einer Herausforderung an die Standarisierung. WAI-ARIA und HTML 5 haben mitunter gleiche Attribute erarbeitet wie aria-required (WAI-ARIA) und required (HTML 5) für pflichtige Felder, aber WAI-ARIA hat auch wichtige Attribute erarbeitet, die zusätzlichen Hilfestellungen und Informationen anbieten und uns in der Praxis auch Arbeit abnehmen können wie die Attribute aria-describedby oder aria-labelledby.

So lässt sich ein beliebiges Element oder Inhalt als Label eindeutig zu einem Formularfeld zuordnen mit aria-labelledby. Das soll nicht heissen, dass wir jetzt auf ein Label und die eindeutige Verdrahtung mit for/id verzichten. Es meint nur, dass man in komplexen Formularstrukturen schlicht noch eine weitere Möglichkeit hat, die Semantik zu verdrahten und die Ausgabe etwa an einen Screenreader noch anzureichern. Hier gilt also auch wieder, sich das Ergebnis genau anzusehen und durchzutesten.

Das Attribut aria-describedby liest den Inhalt eines anderen Elements ein im Formularfeld. Das können zusätzliche Informationen oder Hilfestellungen sein. Verdrahtet wird das durch eine eindeutige id im Element. Vor allem für Tooltip-Strukturen und Fehlermeldungen interessant. Ein weiteres interessantes Attribut aria-label kann als Alternative in Standards wie Suchfeldern verwendet werden, wenn man auf ein Label verzichtet. Als Einstieg für das Anreichern bestehender Auftritte mit WAI-ARIA empfehle ich die Easy ARIA Tips von Marco Zehe. Die lassen sich immer recht flott und einfach integrieren.

Und jetzt weiter zur Technikwürze Formulare total 2 (Barrierefreie Formulare)

Feel free to Flattr this post at flattr.com, if you like it.

Diese Lust hat auch wettgemacht, dass ich im kleinsten aller möglichen Hotelzimmer einquartiert wurde – 1,5 x 2,5 Meter – immerhin hat das Bett fast das ganze Zimmer ausgefüllt und das WLAN war hervorragend. ;) Amsterdam ist ja von Köln aus dann doch eher ums Eck und man fährt quasi mit der Bahn direkt ins Zentrum. Eine schöne, wenngleich sehr putzige Stadt – wie das Holländische im allgemeinen. Ja, ich mag das Holländische, fahre da ja auch jedes Jahr ans Meer, aber in so engen Kanalstädten find ich es ja immer zu kleinstädtisch. Aber nun zur Konferenz …

Die Fremde entspannt!

Es war – und bitte jetzt sollen nicht wieder alle aufschreien – ganz wunderbar entspannt zu konferenzen – im Felix Meritis, so in der Fremde, weil man eben kaum jemanden trifft oder kennt. Man kann sich genüsslich den Inhalten widmen, okay auch dem üppigen Buffet – aber nur, wenn man bis mittags mit einem Keks und ner Tasse Kaffee auch tapfer durchgehalten hat. ;) Ich fand es auch überhaupt nicht zwingend, nach bekannten Gesichtern zu suchen – freilich hab ich mich dann doch gefreut, @codepo8, @yatil, @screenorigami, @soophie, @dantz, @migrosch und @stereobit zu treffen, man hat halt einfach interessiert teilgenommen, hat den fast luftleeren und gleichzeitig schweißtreibenden Raum – sonst wohl ein Konzertraum – ertragen und die Sitzgelegenheiten dann doch mental immer früher verlassen, die waren sicherlich noch Überbleibsel aus den 70ern.

Es war alles sehr gut durchorganisiert, auf die ständigen Mitbringsel – seien es Sticker von Mozilla oder Kugelschreiber mit dem Namenszug der Konferenz – könnte man gerne auch mal verzichten. Aber das gehört ja irgendwie dann doch immer zum Product Placement. Hervorheben muss man den super flinken Check-In, da konnte man sein doch eher eingerostetes Englisch mal wieder hervorholen – das hat sich aber gut wieder eingespielt mit dem Englischen, auch eine positive Erfahrung – schon deswegen sollte man das viel öfter machen. Der Abendausklang mit dem üblichen Get-together war sehr entspannend, wenngleich dann doch sehr voll und laut. Und meine Frage ist ja immer, warum muss man dann stundenlang an schmalen Tischen oder am Nebenan gelehnt stehen? Ich weiß, das ist halt immer eine Frage des Räumlichen, aber ich find das eher selten gemütlich – bin halt eher der Sofatyp. ;)

Webentwicklung mit Webstandards macht richtig Spaß!

Gerade der erste Konferenztag hat mich richtig für sich eingenommen, es war aber auch die Abfolge der Vorträge sehr gut aufeinander abgestimmt – ich glaube das nennt sich, ein Highlight jagt das andere. Sicherlich unterscheidet sich eine Konferenz mit so vielen Evangelisten schon von nationalen. Weil man zum einen natürlich mal die alle live erleben will und zum anderen – obwohl ich es ja weniger mit dem Kanon habe – die alle eine unglaubliche Verve mitgebracht haben. Das hat sich irgendwie einfach übertragen, eine Kombination von sehr viel Kompetenz und Begeisterung. Jeder von uns kennt das ja, die Jahre etwa im Agenturgeschäft schleifen einen dahingehend schon ab, man ist schwerer begeisterungsfähig, wiegelt schneller ab und kennt das ja alles zur Genüge: Fehlende Zeit, lose Briefings, ungeduldige Kunden und und und. Hört man Leuten wie Steve Souders, Peter-Paul Koch, Stephen Hay oder Jonathan Snook zu, dann weiß man plötzlich wieder, warum man Frontendentwicklung macht, man ist wieder auf diesem wichtigen Punkt – ja genau das will ich machen, dazu hab ich wieder Lust – im Grunde immer gehabt, ich habe es nur ab und an vergessen.

Etwas schwieriger war der zweite Konferenztag, weder war er so aufeinander abgestimmt noch war er von solcher Verve getragen. Dazu kam – anteilig gab es das auch schon auf dem ersten Konferenztag – die starke Präsenz von Javascript. Klar, wir nutzen das alle, setzen das ein, aber man hat gemerkt, ein Vortrag in der Tiefe etwa von Thomas Fuchs zu Émile (Roll your own javascript effects framework – PDF Datei) – so amüsant er auch vorgetragen war – jetzt weiß ich endlich, dass script.aculo.us aus Wien kommt ;) – mit beamer-vollflächigen dunklen Javascript-Anweisungen war dann für die meisten zu trocken und oftmals nicht mehr ganz nachvollziehbar. Im Twitter-Stream der Teilnehmer – auch eine schöne Idee der Fronteers – konnte man das Aufmerksamkeits-Barometer bei diesen oftmals zu speziellen Vorträgen durchaus fallen hören, besser mitlesen. :) Oder um 9 Uhr früh einem durchaus interessanten Vortrag von Douglas Crockford (Ajax Security, Powerpoint-Datei, 1 MB) zu AJAX, Cross Site Scripting und Stichworten wie Quality Modularity Reliability oder Maintainability Security zu folgen, war schon auch nicht unanstrengend. Ich erinnere mich, dass es jemand in Twitter – was man auch immer mitgelesen hat – eine lustige Sache im übrigen – ganz gut für den Vortrag auf den Punkt gebracht hat: schon das Vokabular hat einem mitunter etwas matt gesetzt. :)

Großteils waren die Vorträge sehr professionell gehalten, ich habe mir auch vieles notiert für meine eigene Praxis. :) Da konnte man richtig gut sehen, was die Profis so anzubieten habe – also rein performance-technisch. Etliche waren wohl gesundheitlich sehr angeschlagen, Molly Holzschlag hatte zwar die Aufgabe, wohl eine Art Keynote zu halten, die war dann aber doch eher ein dünner Spagat zwischen Motivation der Anwesenden und etwas unstrukturierter Information. Das fand ich besonders schade, weil ich mich auf sie sehr gefreut habe. Schließlich hat man wenig Möglichkeiten, so was wie weibliche Vorbilder in dem Bereich zu erleben. Wie an anderer Stelle schon erwähnt, hat sie uns wenige Frauen – es waren so 10-15 oder so – mit ihrem Anspruch, es müsse zu ihren motivierenden Fragen auch unbedingt eine Frau Stellung nehmen, ganz schön ins Schwitzen gebracht. ;) Auch Nicole Sullivan – bekannt durch Object Oriented CSS – hat mich wenig überzeugt, vor allem weil sie teilweise sehr merkwürdige Argumente für durchaus interessante Fragestellungen geliefert hat.

Was aber am meisten Spass gemacht hat und davon hätte ich gerne jede Woche einen Vortrag zu: der Blick in die Zukunft. Stephen Hay stellt in The Future State of Layout drei unterschiedliche Modelle – CSS3-layout, CSS3-flexbox und CSS3-grid – dar, wie man mit CSS Grid/Spalten-Layout erzeugen kann, keiner weiß noch wirklich, welches Modell oder vielleicht sogar ein ganz anderes sich durchsetzen wird. Das war einfach spannend, weil es zwar noch in Entwicklung ist, aber eben schon einen interessanten Ausblick geliefert hat auf etwas, war wir schon seit Jahren brauchen würden. Von diesen Ausblicken und Einblicken in aktuelle Werkstätten gab es einige auf der Fronteers. Und nun noch zu einigen Vorträgen ein paar Anmerkungen:

Peter-Paul Koch – The Mobile Web, or the masochist’s guide to gleeful self-flagellation

Im Grunde müsste es für solche Vortragstitel und den Einleitungsteil zur Spanischen Armada schon hinreichend Bonuspunkte geben, noch dazu finde ich die Art und Weise, wie Peter-Paul Koch vorträgt, ziemlich interessant – spannende Intonation. :) Da ich ja grade einen etwas durchwachsenen W3C Kurs in Sachen Mobile mache (Introduction to W3C’s Mobile Web Best Practices), hat mich der Vortrag natürlich sehr interessiert. Es war zwar eher ein Parforceritt durch sehr viele mobile Browser und Problemstellen, aber trotzdem ist das Aufzeigen der Vielfalt mobiler Browser- und Usererfahrung dann schon auch immer wieder überraschend. Seine Präsentation stellt er wohl erst nach dem 20.11. ein – nach der Full Frontal Konferenz, aber auf Slideshare gibt es eine ähnlich zusammengestellte Präsentation mit den Beispielen: State of the Mobile Browsers. Das Motto der Selbstgeißelung (self-flagellation) findet sich dort auch schon: Die Entwicklungsarbeit für Desktop-Browser wird doch nun langweilig, selbst für den IE. Glücklicherweise kommen jetzt die mobilen Browser zum Zug und machen uns mit ihrer Vielfalt das Leben wieder richtig schön. ;)

Die Liste der mobilen Browser spricht dann ja auch wirklich für sich. Das was ich bis dato im Kurs gelernt habe, hat mir zwar nicht das Fürchten gelernt, aber mir dann schon eine gewissen Hang zur Selbstgeißelung schmackhaft gemacht. Ich glaube, ich dachte immer, ah auf dem iPhone oder iPod Touch sieht das doch ganz gut aus, vor allem im mobilen Zoom Modus. Aber wie man an den Beispielen der Präsentation und wie ich nun auch aus meinem mobilen Debuggen weiß, just awesome. ;) Aber so leicht lasse ich mich ja nicht in die Flucht schlagen, ich steh das durch. :)

Stephen Hay -The Future State of Layout

Hays Vortrag hatte ich ja schon hervorgehoben als Spielwiese unterschiedlichster Layoutmodelle in CSS3. Und wer würde ihm schon nicht recht geben, dass wir endlich ein Layoutmodell brauchen, dass Struktur und Präsentation noch besser unterscheidet – nicht unser Float-Lego, dass wir seit Jahren praktizieren – , besser portierbar und endlich unabhängig von der Reihenfolge im Quellcode arbeitet – eben Layoutprinzipien, die auf einer Metaebene schon viel früher greifen. Diese Metaebene, die noch bevor dem Positionieren einzelner Elemente auf der Webseite greift, nennt sich explicit grid (CSS3-grid). Gut, auf den Backlash zu Layouttabellen hätte er auch verzichten können. Ich sage ja immer, was man seit Jahren nicht mehr nützt, sollte man einfach auch nicht mehr in der Debatte halten, sonst erinnert sich noch jemand daran. ;) Sein Vortrag arbeitet dann ziemlich anschaulich die 3 Working Drafts auf dieser Metaebene durch: CSS3-layout (W3C), CSS3-flexbox (Mozilla) und CSS3-grid (Microsoft).

Lustig fand ich, dass er in den Nachteilen bei fast jedem Ansatz aufführt, dass sie doch sehr mit Denkeinsatz verbunden sind. Ja, die Zahlenspiele von CSS3 Layout haben so auf den ersten Blick auch viel von philosophischen Logiksystemen, aber es ist auch aufgeräumt, wenn gleich ich meine, man sollte dann die Redundanzen pro Reihe noch in den Griff kriegen. Hay schließt seinen Vortrag gut ab: A solid layout mechanism will change the face of the web. Dem kann man nur noch die absolute Dringlichkeit hinzufügen!

Jonathan Snook – The Type We Want: Using Fonts on the Web

Von Snooks Vortrag hatte ich mir eigentlich mehr erwartet, andererseits versuche ich mich in Sachen Font-Entwicklung, die ja aktuell sehr stark im Umbruch ist, auf dem Laufenden zu halten. Deswegen war da weniger neues für mich dabei, er hat mehr so den groben Überblick geboten, was man mit Schrift im Web aktuell machen kann, wo die Probleme sind und wo es weiter gehen kann. Auch er hätte sich etwa das font-face-Beispiel am Anfang sparen können, ich bin schon genug frustriert, das Element in einem HTML-Newsletter für Outlook 2007 einsetzen zu müssen. Für mich noch nicht so präsent war der Begriff complex font stakes, was meint, wie man in CSS font-family optimal nach unterschiedlichsten Kriterien wie Verfügbarkeit, Kontext, Rendering und typographische Vorgaben anlegen kann. Nice Web Type hat dazu eine gute Zusammenfassung der bisherigen Ergebnisse: Roundup: CSS font stacks.

Dann geht er die aktuellen Schriftersetzungen wie sIFR, Cufón und Typface.js durch. sIFR will ich grade nicht mehr verlinken. :) Nur weil wir jahrelang neben der PHP-generierten Schriftgrafikenerzeugung nicht viel andres als sIFR hatten, sollten wir uns schlicht schnell wieder davon verabschieden. Auch von allen ähnlichen Derivaten. Wie bei der Dringlichkeit von Layout-Modellen muss man einfach sagen, wir sollten möglichst schnell in den @font-face-Einsatz gehen. Es kann uns nichts besseres passieren. :) Klar wird es auch richtig lustig, unterschiedliche Schriftformate wieder berücksichtigen zu müssen. Folie 32 der Präsentation Bulletproof @font-face hatte dann auch alle Lacher auf ihrere Seite: das traditionsreiche font-family, gefolgt vom Schriftformat .eot, von jeweils local-Versionen, dem Web Open Font Format WOFF, dem bekannten TTF-Format und dann das Schlusslicht SVG. Perfekt! :)

Hay macht es auch bis zum Schluss spannend, wenn es darum geht, Schriften auch in die entsprechenden Formate zu konvertieren. Erst fast am Ende präsentiert er uns den Konverter Font Squirrel, der TTF- und OTF-Formate in EOT, SVG und WOFF konvertiert. Vor allem bietet dieser Konverter auch an, Subsets in den Schriften auszuwählen, sonst hat man alleine durch die Schrifteinbindung 100 kB gleich mal zusammen – ähnlich wie bei sIFR schließt man dann schlicht bestimmte Bereiche und Inhalte der Schrift aus, zum Beispiel nur Latin-1. Font Squirrel zeigt das gut in der Vorschau an, wie der Zeichensatz dann jeweils aussieht.

Am Schluss geht Hay noch marginal auf die aktuellen Font Embedding Services wie TypeKit. Im Grunde ist das eine interessante Entwicklung, aber im realen Agentureinsatz kaum zu integrieren. Kunden werden ja schon fast panisch, wenn sich Ressourcen – etwa Skripte – von anderen Servern als dem ihren landen. Ganz abgesehen davon, wie Hay ja auch hervorhebt, was macht man, wenn der Hosting-Server der Schriften mal down ist?

Und am schönsten fasst die aktuelle Problematik der Lizenzierung die Checkbox bei Font Squirrel zusammen: Yes, the fonts I’m uploading are legally eligible for web embedding. Ganz egal, wie wir mit Schriften arbeiten im Web jetzt und in Zukunft, Lizenzierung ist immer noch Knack- und Schwachpunkt. Aber angeblich kann man ja den Schrifthersteller schlicht mal anklingeln. ;)

Steve Souders – Fast by default

Witzigerweise fragte Souders am Anfang, wer seinen Blog High Performance Web Sites lesen würde, ich fürchte, ich war fast die einzige. Das hat mich dann schon sehr verwundert. Vor allem, weil das Thema Performance einfach immer wichtiger wird – vor allem im Frontend und das ist auch Souders Thema. Was Seiten langsam macht, so Souders, ist, dass sie kein progressive rendering nutzen und umsetzen. Um den Renderprozess zu beschleunigen bzw. die wesentlichen Inhalte bereits zu Beginn zu laden, schlägt Souders unter anderem vor, Skripte wenn möglich zu splitten. Und sonst das bekannte, alles zu reduzieren und zu optimieren, Skripte eher nach unten packen. Interessant vor allem der Hinweis wieder auf den Einsatz von @font-face. Wenn Skripte über @font-face-Anweisungen stehen, blockieren sie das Rendern im IE. Überhaupt scheint @font-face Browser im Rendern ziemlich zu beschäftigen (Folie 60). :)

Ich fand den Vortrag spannend, vor allem weil mich dieses Thema auch immer wieder real im meiner Agenturarbeit betrifft. Da immer ein progressive rendering hinzukriegen mit allen wunderbaren Ingredienzien heute, nicht immer einfach.

Fazit

Fronteers 09 ist eine absolut empfehlenswerte Konferenz und für viele hier im Westen Deutschland eigentlich ziemlich komfortabel erreichbar. Ich werde sicherlich nächstes Jahr wieder teilnehmen, schon um Amsterdam und seiner Hotellerie noch eine Chance zu geben. ;) Zu Nicole Sullivans Object Oriented CSS werde ich noch einen gesonderten Artikel schreiben. Hatte ich ja auch schon mal begonnen, als es bei den Webkrauts eine Replik zu Sullivans Konzept gab. Heute bei der Nachbereitung zur Konferenz habe ich meinen Draft von damals dazu noch gefunden: Hurray!

Feel free to Flattr this post at flattr.com, if you like it.

Rückblick auf den A-Tag ’08: ein Déjà-vu

Ich habe in meinen Archiven geblättert und meine Wünsche noch einmal Revue passieren lassen, die ich dem letztjährigen A-Tag hinterher geschickt habe: Schon letztes Mal war der Wunsch überpräsent, dass Barrierefreiheit cooler werden und auch mehr Spaß machen soll. Der Frauenanteil auf Konferenzen und in der barrierefreien Szene soll sich endlich erhöhen – und damit meinte ich nicht, dass es keine Frauen gäbe, die barrierefreies Webdesign machen. Nein, es ging mir darum, dass sie sich zu wenig in der Öffentlichkeit positionieren. Ich selbst durfte ja auf der Fronteers 09 vor kurzem erleben, was es heißt, von Molly Holzschlag wieder mal sehr intensiv darauf aufmerksam gemacht zu werden, dass Frauen öffentlich sprechen müssen. Sie hat uns wenige Frauen dort ziemlich in die Bredouille gebracht.

Noch interessanter ist, dass ich letztes Jahr schon eine einheitlichere barrierefreie Szene, die sich in welcher Form auch immer einem gemeinsamen Accessibility Commons verschreibt, gefordert habe. Freilich stand das noch stark unter der Erfahrung der Social Accessibility Bewegung, die letztes Jahr mit etlichen Projekten schlicht sehr präsent geworden ist. Das Projekt Accessbility Commons – wieder einmal mit initiiert von dem umtriebigen Jeffrey Bigham – den meisten wahrscheinlich durch seinen Webscreenreader WebAnywhere bekannt – soll eine Art Metadatenbank sein, in der Informationen zur Barrierefreiheit aus unterschiedlichsten Projekten zusammenlaufen, gespeichert und wieder von allen genutzt werden können.

So etwas ähnliches hätte ich mir für die deutschsprachige Szene auch immer gewünscht, eine Art Informationsdatenbank – auch mit Austausch- und Diskussionsmöglichkeit -, wo man sich über aktuellste Ergebnisse auf dem Laufenden halten und austauschen kann. Klar, kann man das alles individuell bloggen, Informationen lesen wir ja eh täglich an und durch, unterhalten uns marginal in Twitter darüber, ab und an auch noch in Kommentaren. Aber ein richtiger Austausch ist das nicht. Nein.

Und auch diesen immer wieder heiklen Punkt hatte ich schon letztes Jahr nach dem A-Tag notiert: In der barrierefreien Szene ist rückhaltlose Kritik nötig und wichtig. Dabei meint rückhaltlos nicht, dass wir jetzt hingehen und überall ad personam argumentieren nach dem Motto, dass hat der oder die ja wieder nicht hingekriegt. Fachliche Kritik ist aber innerhalb der Szene notwendig, sonst glauben wir, wir polstern Webseiten nur noch mit barrierefreiem Samt aus. Wenn wir uns mit dem fachlichen Stand der barrierefreien Szene so wohl fühlen würden, wie es sich nach aussen immer mal wieder kommuniziert, dann hätten wir blühende barrierefreie Landschaften. ;) Das sollte jetzt jedoch kein konservativer, politischer Schulterschluss werden. Es meint aber, dass wir uns immer noch nach dem alten Motto verstecken, es wird schon alles gut: Sei es durch das alte BITV, durch das neue, durch die WCAG 2 oder durch das Herbeiholen, ja Herbeiwünschen eines Ansatzes von Christian Heilmann, der sich nun mal mehr der Social Accessibility verpflichtet fühlt.

Wir können uns gerne auch weiterhin bewusst missverstehen

Heiße Debatten, die sich an Chris Heilmanns Vortrag auf dem A-Tag ’09 entzündet haben, haben im Grunde nur eins gezeigt, dass wir uns nicht mehr richtig zuhören. Wir arbeiten weder ohne Gesetzgebung – sind also beileibe keine Vogelfreien der Barrierefreiheit -, noch frönen wir nur noch – getreu dem Motto der Spassgesellschaft – einem barrierefreien Hedonismus und fühlen uns ganz auf der Höhe des barrierefreien Booms, der uns schon mal alle vier grade und den Rest hinter uns lassen lässt, und schon erst recht nicht agieren und votieren wir gegen Menschenrechte. Was für ein Unsinn, diese ganzen Kommentare – mitunter auch extrem persönlich – in den letzten Debatten mit- und nachzulesen. Was soll das bringen? Oder ist es eine notwendige Pattstellung, die schon seit längerem gegärt hat in der Szene und sich jetzt schlicht Luft verschafft hat? Also ich war sehr überrascht über diese Debatte, mir waren so die Problemlinien nicht bekannt.

Wenn Jens Grochtdreis nun eine Etatismusstreit aufmacht, dann komme ich mir schon arg ins barrierefreie Mittelalter versetzt vor. Seit wann arbeiten und argumentieren wir in dieser Schere, wo wir seit Jahren nach und mit BTIV und WCAG arbeiten? Und Tomas Caspers versteht ihn auch noch ein wenig miss, wenn er im Kommentar davon spricht, dass wir ohne entsprechende Sanktionen, die es ja durchaus in anderen Ländern wie etwa Österreich gibt, nicht wirklich weiter kommen. Ich denke, genau das will Grochtdreis grade nicht. Aber egal – auch wieder nur so ein Zeichen dafür, dass wir alle in dieser Diskussion aneinander vorbeireden. Dabei würde es gerade in so einer Situation nötig sein, die unterschiedlichen Standpunkte und Herangehensweisen – etwa von Entwicklern, Gesetzesvorgaben, Behörden und Initiativen – klar zu sehen. Auch Chris Heilmann arbeitet nach den Vorgaben des WCAG 2, aber er würde es auch ohne mit gleicher Vehemenz und Intention tun. Das trifft doch auf die meisten von uns zu.

Auf dem A-Tag habe ich dieses Jahr vor allem mitgenommen, dass es doch etwas ganz anderes ist, in einem gesetzlichen Umfeld zu arbeiten, in dem eben auch und vehement geklagt wird. Das spürt man sowohl an den realisierten und präsentieren Projekten als auch an den Machern. Da steckt ein ganz anderes Selbstbewusstsein dahinter, vor allem in Gesprächen mit Martin Ladstätter und Jo Spellbrink konnte man das gut erkennen, da liegt einfach schon ein ganz anderes Klageverständnis und -praxis vor. So was ist für mich in Deutschland kaum vorstellbar – aber vielleicht sollten wir wirklich auch darauf hinarbeiten, dass es in Deutschland dafür ein Reglement und eine Praxis gibt. Diese Klagepraxis in Österreich kann einem schon auch ziemlichen Schwung vermitteln, also mir hat es das jedenfalls.

Ich will damit nur sagen, ich kann mir das vorstellen – so eine Klagepraxis, auch die Notwendigkeit ist ja leider immer noch gegeben. Gerade weil sich die Privaten in Deutschland nur in Einzelfällen von Barrierefreiheit überzeugen lassen, es sei denn, man verkauft sie so, dass sie sexy, möglichst viele positive Nebeneffekte und vor allem preiswert bleibt. Muss man nicht weiter ausführen, ist ja bekannt. Das ist halt immer noch der Stand der barrierefreien Praxis im allgemeinen privaten Mittelfeld, in Agenturen, die ihren Fokus nicht nur auf barrierefreiere Arbeit haben und bei Kunden, die endlich und schnell eine Webseite haben wollen. Da sind wir halt mehr oder weniger immer noch am Anfang.

Vom A-Tag habe ich aber mitgenommen, dass so Großprojekte wie wien.info und linz.at auch von einer Klagepraxis für Private profitieren. Da geht man selbstverständlicher voran und greift in das barrierefreie Volle. Das war mein Eindruck und das hat mir auch Schwung gegeben und hoffe, ein wenig vom Wiener Selbstbewusstsein mitgenommen zu haben. Man merkt mittlerweile halt auch – die barrierefreie Wiener Szene um accessible media hat sich konsolidiert, was meint: Da ist eine gute, intensive Vernetzung zu spüren, auch wenn sie auf Wien zentriert ist. Aus Gesprächen mit Salzburgern wurde mir das bestätigt, dass der barrierefreie Fixpunkt dann doch in Wien zu finden ist, in Salzburg sei die Vernetzung sehr gering. Das neue Selbstverständnis, wie ich es nennen möchte, der Wiener barrierefreien Szene zeigt sich etwa auch in der Artikelreihe von Wienfluss, in der sie sehr praxisnah über die unterschiedlichen Aspekte des Launches von wien.info berichten: Making of wien.info – ein Blick unter die Tuchent. So etwas würde ich mir überhaupt mehr wünschen, vor allem auch für die deutsche Szene. Leider haben wir hier nicht alle die Freiheit, über interne Abläufe zu berichten, aber Agenturen haben da ja andere Möglichkeiten und könnten die auch verstärkter nutzen. Das wäre eine Möglichkeit, mehr Transparenz zu erreichen und Reaktion von anderen einzufordern.

Ich allein kann und will das nicht mehr stemmen

Auch wenn ich mich durchaus innerhalb der barrierefreien Szene positioniere, sehe ich mich trotzdem als einzelner Entwickler, der eben alleine eine barrierefreie Szene nicht öffnen kann. Schon gar nicht, wenn sie – wie im deutschen Bereich – so versprengt und meisthin – bis auf die bekannten Größen – still vor sich hin entwickelt. Auch wenn Chris Heilmann in einem Kommentar nun erwartungsvoll auf die deutschsprachige Szene blickt und meint, jetzt würden doch einige aufstehen und was machen, habe ich meinen x-ten Versuch, eine flammende Fürsprache für mehr lustvolle und interaktive barrierefreie Entwicklungsarbeit, in den üblichen Leerlauf gesetzt. Freilich in Twitter wird das schön oft retweeted, in einigen Kommentaren wird einem beigepflichtet, in anderen Kommentaren genau das Gegenteil, schließlich sind wieder einige Wochen vergangen.

Das mag sich jetzt nach Lamento anhören, ist es auch in gewisser Weise. Ich mache diese Versuche, andere – vor allem Praktiker – zu mehr Zusammenarbeit und Interaktion aufzurufen, einfach schon zu lange. Ich alleine kann und will das nicht mehr stemmen, schließlich habe ich einen Fulltime-Job, der nur bedingt immer barrierefreie Arbeit bedeutet. Ich mache diese für mich wichtige Weiterarbeit von barrierefreien Techniken und Themen nebenher und weil es mir so am Herzen liegt. Da ich dieses Jahr aber durchaus gemerkt habe, dass mein Herz zu groß ist – ganz abgesehen davon, ob ich überhaupt ein Herz habe ;) – und ich mich als Einzelperson dann auch gerne mal übernehme, muss ich auch daraus Konsequenzen ziehen. Nicht nur aus der Stille, die sich aus der barrierefreien Szene immer wieder nach erneuten Debatten, Ansätzen, gegenseitigen Wünschen und doch, sollten wir endlich ja! ausbreitet. Wir hatten ja auch mal ein alternatives Netzwerk angedacht, ja auch das.

Ich für meinen Teil verzichte nun eher auf barrierefreie Grundsatz- und Volksreden. Ich kann auch weniger an Großprojekten wie der Übersetzung des WCAG 2 mitwirken – durchaus ein wichtiges und vor allem dringendes Projekt -, nicht mal die Durchkommentierung des neuen BITV-Tests habe ich geschafft. Damit will ich nur sagen, ich lerne langsam mit meinen Kräften zu haushalten, ich muss es lernen – und ich beginne Realitäten in der barrierefreien Szene zu akzeptieren: Es kann und wird nicht sein, wenn es keiner will – sich beständig und vor allem gemeinsam zu aktualisieren.

Ich hatte ja meinen Ansatz im Schlichtungsversuch klar gemacht, ich sehe meinen Aufgabe in einer Barrierefreiheit von unten – als eine Basisarbeit, die Wege weiterführen kann – auch wenn ich sie nur in kleinen Schritten realisieren kann. Weil ich denke, dass wir im deutschsprachigen Raum weit in der Basisarbeit hinterherhinken. Das ist schade. Ich werde auch versuchen, mich mehr internationalen Projekten anzuschließen, vor allem im Bereich der Social Accessibilty, weil ich zum einen glaube, dass sie meinem basis- und praxisnahen Ansatz näher ist und zum anderen mir offener nach aussen scheint als hier. Freilich kann ich auch dort nur schmale Anteile mitrealisieren, aber besser dort als hier immer nur ins Off zu sprechen.

Und ich würde dann Heraklit schon ummünzen wollen: Man sollte schlicht nicht zweimal in denselben Fluss steigen. Es lohnt sich nicht wirklich. ;)

Feel free to Flattr this post at flattr.com, if you like it.

• Das Transkript meines Vortrags
• Der Vortrag als Mp3-Datei (ca. 35 Minuten)
• Der Vortrag auf Slideshare – meine erste Präsentation auf Slideshare. :)
• Den Vortrag als PDF-Datei – aus Slideshare generiert (5,5 Mb)

Was jetzt noch fehlt, ist der Vortrag mit den Screencasts. Gerade die Screencasts, machen die Anwendung der erwähnten Werkzeuge zum Debuggen der Tastaturbedienbarkeit klarer und auch die Probleme bei der Nutzung der Tastatur. Bewegtbild hat eben auch entscheidende Vorteile. :) Daher hier nun das ganze Paket – beides ist jedoch nicht barrierefrei:

• Der Vortrag mit Screencasts als Powerpoint-Datei gezippt (49 Mb)
• Der Vortrag mit Screencasts als Mac Keynote-Datei gezippt (67 Mb)

Falls Probleme mit den Dateipaketen auftreten, einfach einen Kommentar hinterlassen. Noch ein paar Infos zu jedem Screencast:

• Screencast – Tastaturbedienung Detailseite: Man kann sehr schön die Werkzeuge Focus Inspector und LogFocus in Aktion und Interaktion sehen. Am unteren Rand läuft während der Tastataturbedienung das Bookmarklet LogFocus und zeigt jeweils den aktuellen Fokus in der Konsole von Firebug an. Auf der linken Seite – in der Sidebar – zeigt Focus Inspector das aktuelle fokussierte Element namentlich an und macht es auf der Webseite gleichzeitig mit Hilfe einer farbigen Markierung sichtbar. Die Probleme in der Tastaturbedienbarkeit werden erkennbar, die Hauptnavigation wird in Gänze übersprungen und wesentliche Bereich der Detailseite ebenso, also sind per Tastatur nicht erreicht wird.
• Screencast – Tastaturbedienung my yasssu: Man sieht diesmal in Aktion und Interaktion wieder links in der Sidebar Focus Inspector und auf der Webseite selbst Mouseless Browsing, das die fokussierbaren Elemente der Webseite durchnummeriert hat. Auch hier wieder das Problem, dass beim Tabben die Hauptnavigation übersprungen wird und der gesamte Hauptbereich my yasssu, also per Tastatur nicht erreicht wird.
• Screencast – Tastaturbedienung eines Layers mit jmpopups: Mit Hilfe des jQuery Plugins jmpopups lassen sich Layer semantisch sehr gut ineinander schachteln, ist tastaturbedienbar und der Fokus liegt immer auf dem ersten fokussierbaren Element. Der Screencast zeigt den typischen Ablauf beim Durchtabben.
• Screencast – Tastaturbedienung eines YUI – Dialog Quickstart Example: Mit Hilfe des YUI Beispiels Dialog Quickstart lässt sich ein Layer tastaturbedienbar integrieren und der Fokus liegt auf dem ersten Formularelement. Der Screencast zeigt den typischen Ablauf beim Durchtabben.
• Screencast – Tastaturbedienung Drag & Drop von yasssu.com: Der Screeencast zeigt die Nutzung von Drag & Drop bei yasssu. In den Auswahlseiten wird diese Funktionalität hauptsächlich genutzt, seltener hat man Alternativen, auch ohne Maus ausgewählte Elemente auch dem my yasssu-Bereich zuzuordnen.
• Screencast – per Tastatur bedienbares Drag & Drop Beispiel: Der Screencast zeigt das tastaturbedienbare Drag & Drop Beispiel von Opera mit Hilfe von WAI ARIA. Es basiert auf Javascript und nutzt die WAI ARIA Attribute aria-grabbed und aria-dropeffect. Der Screencast zeigt die Bedienung per Maus und Tastatur.

Leider schaffe ich es grade zeitlich nicht, einen ausführlichen Bericht über den A-Tag, seine wieder sehr schöne Atmosphäre, die vielen netten Gespräche und (neuen und bekannten) Gesprächspartner und die inspirierenden Vorträge zu machen. Irgendwie hat sich die Zeit schon ein wenig gegen mich verschworen. ;) Aber ich fand es sehr schön am A-Tag und auch in Wien, wächst mir langsam schon auch wieder ans Herz – nach einem Abstand von fast 20 Jahren, entdecke ich die Stadt jedes Jahr wieder ein Stück neu und anders. Daher habe ich wieder ein paar Fotos geschossen und auf Flickr eingestellt.

Ich möchte dem Team des A-Tags danken, ich weiß auch nicht, wie ihr das immer macht: Aber es wird jedes Mal familiärer und so schön österreichisch entspannt. :) Ja, ich weiss, gerade sollte man ja nicht regionalisieren, aber in diesem speziellen Fall und weil ich ja auch selbst letztlich so entsetzlich österreichisch geblieben bin, darf ich das hoffentlich. Und vielleicht schaffe ich es ja doch noch, die A-Tag Informationen und Impressionen hier aufzuarbeiten, aber versprechen kann ich grade nichts mehr. :)

Ach, das interessanteste habe ich ja wieder vergessen: Kurz nach dem Vortrag erhielt ich eine interessierte Mail von yasssu, die sich nun bemühen werden, ihren Auftritt barrierefreier zu gestalten. Ich bin aufgefordert, in einigen Monaten die Tastaturbedienbarkeit noch einmal gegen zu prüfen. :) So soll es sein und es freut mich, dass mein Vortrag nun auch eine ganz reale Grundierung erhalten hat.

Feel free to Flattr this post at flattr.com, if you like it.

Barrierefreiheit von unten

Ich denke, das Grundproblem der Auseinandersetzung ist, dass die Diskutanten unterschiedlich an Barrierefreiheit und das barrierefreie Arbeiten / Realisieren herangehen. Die Stich- oder Schnittpunkte reichen dann von der Nutzer-, Gesetzes-, Kunden- bis zur Entwicklersicht. Ja, da sind sie alle wieder, die Knackpunkte, aber je nach Ausgangspunkt kann sich das barrierefreie Erarbeiten eben doch unterscheiden.

Das was die Arbeit und Herangehensweise von Heilmann für mich – und ich denke für viele andere auch – so spannend macht, ist, dass er barrierefreie Arbeit von unten macht. Das ist eine anarchische Perspektive und geht durchaus bewusst konform mit Ansätzen der Social Accessibility wie Open Source Screenreader, Firefox-Plugins wie Webvisum und ähnlichen Versuchen, das Web jetzt und für viele zugänglich zu machen. Anarchismus lebt ja gerade von einem Jetzt und einer gewissen Portion Utopie. Auch das findet sich in Heilmanns Vorträgen immer wieder, sie leben geradezu davon, dass sie sich immer wieder nach vorne orientieren, positive Beispiele sammeln, quasi positive Basisarbeit machen.

Die Entwicklerperspektive

Und zu einer Barrierefreiheit von unten gehört der richtige Protagonist, das ist – wie auch immer anarchisch der dann sein kann – der Entwickler, die konkreten Basisarbeiter, die Barrierefreiheit täglich erarbeiten, voranbringen – mal sind es Minischritte, mal sind es Riesensprünge, Sprungbretter. Ich denke, das ist der Fokus und der Ausgangspunkt von Heilmanns Arbeit und für mich als Frontendentwicklerin ist das eine wichtige Perspektive. Eine Perspektive, die auch immer wieder vernachlässigt wird. Als Beispiel: die Gesetzgebung, die sich lange von den Entwicklern isoliert hat, uns zu Erfüllungsgehilfen gemacht hat.

Erst das WCAG 2 hat das realisiert, was man eine Initialzündung für die Webentwicklung nennen kann, es hat uns und unsere Lösungen mit einbezogen, wir sind das erste Mal in der barrierefreien Entwicklung mit gefragt, an anderen, besseren und wie Heilmann so schön formuliert – einfacheren, sprich: standardisierten und schnell einsetzbaren – Lösungen mitzuarbeiten. Auch das WCAG 2 hat erkannt, es muss einen Rückkanal geben, eine Barrierefreiheit von unten wird dadurch endlich ermöglicht. Das BITV 2 wird das nicht möglich machen können, soweit war der letzte Konsens seinerzeit auf der Tagung Einfach für Alle. Gut, wir brauchen auch nicht x Kanäle, Standardisierung heißt auch, es reicht ein Gesetzeskanal, der sich permanent aus den Erfahrungen der Entwickler speist.

Das Geduldpotential

Auch so ein Streitpunkt ist, dass man doch mehr Geduld haben sollte mit Designern und Entwicklern. Das wurde dann in eine Grundsatzdebatte umgelegt, die so nicht stimmig ist. Wir haben doch alle immer noch genug Geduld, sonst würden wir doch längst die barrierefreie Arbeit an den sprichwörtlichen nächsten Nagel gehängt haben. Wenn dem so wäre, wie die aktuelle Diskussion vermuten lässt, dass wir alle längst keine Geduld mehr hätten, dann würde es schon noch viel finsterer um den Zustand der Barrierefreiheit aussehen. Ich denke, auch hier argumentiert Heilmann von einer Barrierefreiheit von unten. Nicht aus einer legeren Haltung heraus, dass wir die Windmühle nur immer wieder kräftig treten müssen, auch wenn sie längst nur noch ein Schaustück für die barrierefreie Touristik ist. Es geht wieder ganz konkret um die Verantwortung des Einzelnen, des einzelnen Entwicklers mitzuhelfen und mitzubauen an der Barrierefreiheit.

Der eine kann da mehr bewirken und vermitteln, der andere Entwickler dann vielleicht nur eine kleine barrierefreie Ecke umbauen und weiterentwickeln. Wir müssen doch auch zugeben, neben unserer durchaus gesetzestreuen Basisarbeit nach BITV oder WCAG scheren wir immer wieder aus, loten alte Ergebnisse noch mal durch, testen Ansätze für Sprunglinks neu, halten uns im internationalen Diskurs möglichst entwicklerorientiert am Laufenden, sind begeistert, dass es so was wie WAI ARIA gibt und entdecken immer wieder Frameworks neu und anders – wie es mir mit YUI passiert ist in meiner Vortragsbearbeitung. Über manches traut man sich noch nicht drüber, anderes kann man schon im Schlaf, entdeckt dabei aber, dass man das besser, kompakter und einfacher machen kann. Denn wir alle sind ziemlich findige Standardisten, kennen das Handwerk und durchaus und gerne seine Grenzbereiche.

Aus dieser anarchischen Basisarbeit jetzt Dispute abzuleiten, die uns quasi wieder Jahre zurückpfeifen? Das kann es doch nicht sein oder? Wir gehen doch immer von einem gewissen Standard-Konsens aus, den wir nicht unterschreiten wollen, weil er einfache und standardisierte Lösungen bietet, die funktionieren. Aber die barrierefreie Basisarbeit ist nun mal in schnellem Wandel, da hat Heilmann schon recht. Wir dürfen uns nicht auf feste Podeste zurückziehen, wir müssen die Potentiale, Barrierefreiheit für viele und gleich zu ermöglichen, halt auch erkennen, durcharbeiten und dann einsetzen. Validiert das dann oder eben noch nicht. Das meint aber nicht, wie vielfach verstanden wurde, wir machen jetzt alles schlicht dreckig.

Viele barrierefreie Züge

Und es kann ja auch keiner überlesen haben, dass Heilmann auf den barrierefreien Prozessgedanken alles festzurrt? Versuchen wir das nicht schon seit Jahren in unserer Agentur- und Entwicklungsarbeit zu realisieren? Warum wird das jetzt grade überlesen? Etwas uns durchaus Vertrautes, auch wenn es nicht immer so einfach dann aufgeht, wie Heilmann das sagt. Sitzen wir wirklich noch so zwischen allen Stühlen? Kann man nicht sagen, die Verbindung zu den Designern und dem Designprozess hat sich verbessert, das Verständnis ist gewachsen. Hat nicht das Projektmanagement tatsächlich aufgeholt und kann dem Kunden in Sachen Barrierefreiheit schon besser vermitteln? Ja und nein, kommt immer darauf an, wie wir Entwickler Bereitschaft und Möglichkeit haben, da zu vermitteln – mit viel Geduld, ganz klar, aber das Verständnis ist gewachsen, auch die realisierten barrierefreien Standards sind größer. Ich denke, was man von Heilmann lernen kann, ist tatsächlich ein utopisches Denken, das ganz positiv und real wird, sobald man eben sich immer wieder klar macht, was man geschafft hat über die Jahre.

Ja, auch ich neige dazu – österreichische Maserung – auch so ein Thema, das man leicht übersehen kann in der Diskussion grade -, das Negative eher wahrzunehmen und kritischer an Realisiertes heranzugehen, als es mir und der Barrierefreiheit oft gut tut. :) Blödes Korrektiv eben. Aber ich kann dann immer noch einen Schritt zurückgehen und Heilmann zuhören, verstehen, welchen wunden Punkt er grade bei mir getroffen hat. Wir haben alle unsere betriebsbedingten blassen Flecken, was unsere barrierefreie Arbeit betrifft, sind zu oft mürbe und vergessen den Spaß zu reaktivieren. Weil – ist es nicht tatsächlich so, ohne Spaß an der barrierefreien Arbeit verlieren wir selbst irgendwann alles, wofür wir arbeiten.

Daher sind wir dann doch immer wieder so begeistert, wenn Heilmann uns auf unseren mitunter verschütteten Spieltrieb aufmerksam macht. Und der Spieltrieb zeigt sich ja auch darin, dass wir an eine Gesetzgebung so herangehen, dass sie gleichzeitig erfüllt und praktisch im Einsatz sein kann. Das nennen wir dann nach einiger Zeit barrierefreie Standards und wenn wir als Entwickler dann Glück haben, schlägt sich das auch wieder rück in die Gesetzgebung. Aber im Grunde ist dieser Rückkanal sekundär, wenn der barrierefreie Entwicklungsprozess alle einbezieht, die spielen wollen und können. Sicherlich immer wieder ein Geduldsspiel, aber auch Geduldsspiele können einen enormen Reiz ausüben, auch für mehr als einen Spieler. :)

Die Diskussionsbeiträge bis dato – auch die Kommentare dazu sind interessant:

• Rückblick: A-Tag 2009 in Wien oder Panta rhei und dann sind wir tot – hyperkontext
• A-TAG 09 – Ein Rückblick – Robert Lender
• Barrierefreiheit, Geduld und Zwang – Behindertenparkplatz
• Barrierefreiheit: Geduld mit Entwicklern und Designern? – xwolf
• Barrierefreiheit nachhaltig verankern – Eric Eggert
• Yes, we need accessibility laws – Eric Eggert
• Frustrationsobjekt Barrierefreiheit? – Barrierekompass
• Christian Heilmanns Antwort: Barrierefreiheit Konferenzen – One speaker slot free

Feel free to Flattr this post at flattr.com, if you like it.

Modifizierter Klassiker: Unzugängliche Sprungmarken

Die Stadt Herford hat barrierefrei gerelauncht: Barrierefrei, übersichtlicher, offen für Kritik. Der Anspruch auf Barrierefreiheit wird eingeschränkt, es sei nur weitgehend barrierefrei. Und es würden vor allem Sehbehinderte und Blinde davon profitieren. Das mag sein, ein Tastaturnutzer hat aber wenig Freude mit den realisierten Sprungmarken.

Screenshot Webseite Stadt Herford

Der Klassiker, dass Sprungmarken schlicht mit display:none versteckt werden, wurde hier zwar umgangen, die Liste der Sprungmarken wird ganz richtig aus dem sichtbaren Bereich geschoben. Jedoch gibt es bei Fokussierung der Links keinen Weg zurück, die Sprungmarken bleiben außerhalb des sichtbaren Bereichs. Insofern würde ich das einen modifizierten Klassiker nennen. :) Auch ansonsten wird bei Links nicht auf den Fokus geachtet, außer im Adressen-Seitenbereich, dort wird explizit in CSS der :focus definiert, aber auch nur durch eine farbliche Unterscheidung.

Das Taberlebnis ist daher auch eher merkwürdig – ich nenne es Ghost-Tabbing. Ganze 6 Sprungmarken warten unsichtbarerweise auf den Tabeinsatz – etwas zu üppig ohnehin geraten. Sprungmarken zum Seiteninhalt, zu Hauptnavigation und Volltextsuche sind ja noch verständlich – schön auch die Formulierung Sprungpunkt. Die Seitenoptionen sind auch eher noch einzuordnen. Aber der Unterschied zwischen Subnavigation und Quicknavigation ist eher schwer erkennbar. Unter Quicknavigation versammeln sich dann klassische Inhalte einer Metanavigation wie Impressum und Suche, aber auch Hilfestellungen wie Barrierfrei Hilfe, was auch eher verzweifelt fordernd klingt, und normale Inhaltsbereiche wie Stadtplan und Veranstaltungen. Und die Subnavigation scheint die Hauptnavigation nur zu doppeln, gut – hat man gleich zweimal die Möglichkeit, in die Webseite einzusteigen. Aber ich halte das eher für zu verwirrend. Man könnte dann einfach eine Sprungmarke einsparen.

Interessanterweise werden vor dem Kopf- und dem Inhaltsbereich noch zwei weitere Sprungmarken zur Verfügung gestellt, die auf das Schnellmenü zurückführen, das die Sprungmarken enthält. Leider sind auch diese Sprungmarken wie erwähnt nicht tastaturbedienbar, weil der Fokus sie nicht in den sichtbaren Bereich zurückholt. Die einzige Sprungmarke, die funktioniert, ist auch sichtbar und führt nach dem Inhalt wieder nach oben.

Es gibt doch noch eine Variante des Klassikers zu entdecken auf der Startseite. Dort wird eine interessante Version angeboten, um einzelne Teaser schnell zu überspringen, quasi von Überschrift zu Überschrift, was etwa bei Screenreader-Nutzern ohnehin intern ausgeführt wird, da muss man nicht als Entwickler noch ein zusätzliches Konstrukt bauen. Nach jeder Überschrift h4 wird ein DIV-Element mit display:none versteckt, das eine Sprungmarke auf einen Anker nach dem Teasertext enthält. Abgesehen von der Problematik, dass man diese absolute Form des Versteckens für Screenreader-Nutzer nicht nutzen soll, ist das ein codetechnischer Overhead – es wird der Link auch oben und unten noch mit einen BR-Element abgesetzt -, den man nicht braucht, schon gar nicht für Nutzer, die mit Überschriftenhierarchien arbeiten. Das ist gut gemeint, aber schießt weit am barrierefreien Ziel vorbei.

Für zusätzliche Verwirrung sorgt noch, dass nach dem Ghost-Tabbing der Fokus auf das Logo rechts unten auf der Seite springt, das – warum auch immer, mit absoluter Positionierung nach unten gesetzt ist. Dadurch springt man ganz nach unten und danach wieder ganz nach oben zum zweiten Logo. Diese Zick-Zack-Technik sollte wirklich vermieden werden. Der Tastaturnutzer ist ohnehin schon verwirrt genug. :)

Feel free to Flattr this post at flattr.com, if you like it.