So findet Nico Brünjes in seiner Leselinks auf der Flucht zu meinem Artikel in Sachen reine Textvergrößerung und WCAG 2.0 / BITV 2.0 die blumigen Worte:

Den barrierefreien Entwickler lernen wir unter »WCAG 2 und die reine Textvergrößerung« kennen. Aber mal im Ernst: ein trockenes Thema. Wer wissen will, wie Barrierefreiheit tickt, braucht nur diesen Post zu lesen. Und dann schnell weg…

Quelle:Nico Brünjes – Leselinks auf der Flucht.

Dazu fällt mir nur zweierlei ein: Zum einen ist es schlicht so, dass Barrierefreiheit und deren Techniken sich immer schneller weiterentwickeln. Da kommt eine Gesetzgebung wie die BITV ohnehin nicht mehr nach, selbst das WCAG 2.0 mit ihren offenen Techniken hat da gut zu tun. Daher ist die Aufgabe des barrierefreien Entwicklers (gut: ich kann auch die Entwicklerin betonen), am Puls der Entwicklung Temperatur zu nehmen und jeweils Vergleiche zu ziehen, Veränderungen aufzuzeigen und sich selbst dabei mit zu entwickeln. Zum anderen ist es nun mal so, dass nicht alles Fun sein muss, aber letztlich ist die Beschäftigung und Weiterentwicklung eines Empfehlungsinventars wie das WCAG 2.0 durchaus spannend – wenn auch zeit- und debattenintensiv.

Mein barrierefreies Entwicklerleben kennt diese Begegnung mit dem Langeweilebonus, der stets von außen herangetragen wird, von jeher. Mir ist noch nie aufgefallen, dass intensive Beschäftigung – mit was auch immer – langweilig sein kann. Aber vielleicht ticke ich da letztlich einfach anders und verstehe unter Fun auch was andres.

Sei’s drum.

WCAG 2.0 und BITV 2.0: Textvergrößerung im Vergleich

Bevor wir uns jedoch mit der reinen Textvergrößerung beschäftigen, ist es notwendig, kurz auf die Textvergrößerung allgemein einzugehen. Auch nach dem kürzlichen Inkrafttreten der BITV 2.0 stellt sich diese Frage nicht wirklich neu, aber die Erfolgskriterien der WCAG 2.0 entsprechen im wesentlichen der BITV 2.0 zur Textvergrößerung: Veränderbare Textgröße (1.4.4 BITV Priorität I, WCAG 2.0 AA) und Visuelle Präsentation (1.4.8 BITV Priorität II, WCAG 2.0 AAA).

Die Unterscheidungen liegen im Detail – aber da Details in der Barrierefreiheit durchaus einen großen Unterschied machen können, zeige ich diese auf. Nach BITV 2.0 ist es auf Priorität I nötig, dass sich Text ohne assistive Technologie auf bis zu 200% vergrößern lässt. Wichtig dabei ist, dass inhaltlich nichts verloren geht und noch alles funktioniert. Die Frage dabei wird sein, wie definiert man Verlust? Inhaltlich ist das leichter verständlich, funktional wird es schon haariger.

Der Text lässt sich ohne assistive Technologie bis auf 200 % vergrößern, ohne dass es zu einem Verlust von Inhalt oder Funktionalität kommt.

Quelle:BITV 2.0: 1.4.4 Veränderbare Textgröße

Die WCAG 2.0 schränkt gerne ihre Erfolgskriterien weiter ein und so trifft diese Vergrößerung von Text auf 200% auf Captions und Schriftgrafiken nicht zu. Für Schriftgrafik, die man ohnehin nicht wirklich verwenden soll, ist das einleuchtend. Wird sie mit dem Page Zoom hochgezogen, wird die Grafik dadurch nicht besser und fast immer schwerer lesbar. Warum Captions etwa bei Videos nicht ebenso vergrößerbar sein sollen, ist weniger klar. Ist der Player flexibel gebaut, werden auch die Captions mit vergrößert und in HTML5 Playern skaliert beides im Page Zoom mit. Aber interessant sind die Einschränkungen allemal, weil sich die Frage stellt, ob die BITV 2.0 dann für beides eine hinreichende Vergrößerung fordert.

Textvergrößerung = Page Zoom?

Ist auf dieser Stufe (WCAG 2.0 AA, BITV 2.0 Priorität 1) nun denkbar, dass mit Textvergrößerung nur der Page Zoom gemeint sein kann. Und genau hier hake ich jetzt ein und ich kann verraten: Ja, genau der Page Zoom ist auf dieser Stufe gemeint.

Das Problem mit den WCAG 2.0 ist, dass sie mitunter durchaus zu unterschiedlichen Interpretationen einlädt – jeder kann da sein eigener Exeget werden. Was dann bei so wichtigen Fragestellungen, wie denn nun mit der reinen Textvergrößerung umgehen, zu erhitzten Debatten führt. Der BITV-Test hat in seinem Artikel Textvergrößerung: warum Zoom-Vergrößerung nicht ausreicht auf diese Schwierigkeit hingewiesen, die ausführlichere englische Version hat dann einige Debatten ausgelöst.

Das Problem im Umgang mit dem WCAG 2.0 ist, dass man nicht etwa aus einem Fehlerbeispiel hochrechnen kann und den darin dargestellten Fehlerfall und seine Lösung als ausreichende Technik für das Erfolgskriterium nutzen kann. Unter verbreitete Fehler für 1.4.4. veränderbare Textgröße findet sich das Beispiel F69. Die Beispiele, die darin aufgeführt werden, sprechen dafür, dass auch die reine Textvergrößerung mit gemeint sein könnte. Beide Code-Beispiele spiegeln die Problematik wieder, dass der Text flexibel vergrößert werden kann, aber der ihn umgebende Behälter eine feste Breite und  - was problematischer ist – eine feste Höhe hat.

Nutzt man den Page Zoom für diese beiden Beispielfälle, gibt es keine Probleme. Voraussetzung ist natürlich, dass der Browser diesen auch implementiert hat. Bei der reinen Textvergrößerung, die einige Browser zusätzlich anbieten, läuft der Text entweder über den Behälter hinaus und über den nächsten Text oder wird schlicht abgeschnitten. Auch das erwähnte Beispiel bei Vergrößerungen von absoluten Positionierungen kann zu diesen Problemen führen, aber weit weniger im Page Zoom. Suggeriert wird in diesen Fehlerbeispielen, dass der reine Textzoom hierbei eine tragende Rolle spielt.

Und daran hat sich auch die Debatte entfacht: an diesem Interpretationsspielraum zwischen Fehler F69 und der Aussage des Erfolgskriteriums. Der BITV-Test sieht da durchaus eine Verbindung – und es ist ja nicht von der Hand zu weisen, wenn auch nur eine implizite und keine, die über die hinreichenden Techniken weiter angesprochen wird. In den Kommentaren aus dem englischsprachigen Bereich kam daher auch sofort die Kritik, dass das eine Überinterpretation sei und man das Erfolgskriterium Textvergrößerung so verstehen sollte: Hinreichend ist es, wenn eine Seite mit Page Zoom entsprechend skaliert, aber wenn die reine Textvergrößerung genutzt wird – was von der Projektanforderung abhängig gemacht wird, dann muss auch diese funktionieren.

Wir sind dann also bei der letzten Interpretation wieder auf dem Level des IE 6 angekommen – wenn der Kunde eine reine Textvergrößerung für sein Projekt wünscht, dann wird zum Standard – Page Zoom – auch noch die reine Textvergrößerung optimiert. Durchaus ein Standpunkt – und wenn ich mal unken darf – einer, der sich durchsetzen wird.

Reine Textvergrößerung = Level AAA und Priorität 2?

Auf Level AAA und Priorität 2 stimmen WCAG 2.0 und BITV 2.0 hinsichtlich Textvergrößerung überein:

der Text kann im Vollbildmodus ohne assistive Technologie bis auf 200 % vergrößert werden, ohne dass die Nutzerinnen oder Nutzer eine Textzeile horizontal scrollen müssen.

Quelle:BITV 2.0 – 1.4.9 Visuelle Präsentation

Auf Level AAA und Priorität 2 kommen also folgende Bedingungen hinzu: der Vollbildmodus und dass bei 200% nicht horizontal gescrollt wird. Vollbildmodus meint die jeweils aktuelle Standardauflösung des Browsers (ich würde das heute nicht mehr nur auf den Desktop reduzieren wollen). Interessanterweise wird das Erfolgskriterium 1.4.9 Visuelle Präsentation nur auf Desktop- und Laptop-Browser angewendet.

Das horizontale Scrollen ist nur pro Zeile zu verstehen und wird nicht auf mehrspaltiges Layout bezogen. Ist der Hauptbereich im sichtbaren und lesbaren Bereich ohne Scrollen, ist das hinreichend. Für den Seitenbereich scrollt man dann horizontal nach rechts und liest dort innerhalb des sichtbaren Bereichs. Das ist eine wichtiger Punkt, weil man daran gut erkennen kann, dass es auch hier hauptsächlich um den Page Zoom geht.

Freilich finden sich auf diesem Level dann mehr ausreichende Techniken, die nicht nur den Text sondern auch das ihn umgebende Layout flexibler machen wie etwa Erfolgskriterium G146 liquides Layout. Zwingend dazu muss jedoch noch eine weitere flexible Technik dazu kombiniert werden wie Schriftgröße in Prozenten (C12).

Man kann deutlich den Anforderungsanstieg von AA auf AAA für die Textvergrößerung erkennen. Auf AA kann man noch wählen zwischen:

• man unterstützt nur den bestehenden Page Zoom (G142)
• man macht sowohl Schriftgröße als auch sie umgebende Layoutcontainer flexibel (Hier findet man auch schon die Option für Liquides Layout – G146)
• man kann einen Text-Switcher einbauen, der unterschiedliche Vergrößerungen zulässt (G178)
• G179 scheint sehr ähnlich G146.

Man hat also auf AA noch die Wahl, kann jedoch ebenso schon auf ein liquides, flexibles Layout setzen.

Auf Level AAA hat man dann im Grunde nur noch die Option des liquiden Layouts (G146) oder man hat einzelne Bereiche oder Seiten, die horizontal scrollen müssen wie etwa Diagramme (C26). Diese Einzelseiten versieht man dann mit einem Layout-Switcher, um zwischen dem liquiden Standardlayout und dem Layout, das horizontal scrollt, zu wechseln.

Die Fehlerbeispiele aus Level AA F69 würden dann auch besser für AAA passen, wenn es darum geht, sowohl Text als ihn umgebendes Layout flexibel zu halten.

Geht es um die Flexibilität der Textvergrößerung findet sich diese als eine von mehreren Optionen auf Level AA, auf AAA ist sie unumgänglich, will man ein komplexeres Layout als den Beispiel-Zweispalter wirklich lesbar halten auf 200% Vergrößerung. Der Page Zoom ist da dann auch nur noch sehr bedingt eine nutzbare Option, wenn der jeweils fokussierte Lesebereich pro Zeile ohne horizontales Scrollen klappen soll.

Insofern wird auf Level AA letztlich nur der Page Zoom gefordert, aber es überlässt dem Entwickler oder dem Entscheider, welche ausreichende Technik gewählt wird. Das lässt sich ja an den Überscheidungen der Techniken ablesen, auch wenn für AAA der Page Zoom dann nicht mehr reichen wird.

Detlev Fischer vom BITV-Test hat diese Debatte um die reine Textvergrößerung an die WAI weitergetragen und einen Konflikt gemeldet (Comment LC-2513). Vor einigen Tagen kam von der WAI die Antwort, dass das Fehlerbeispiel F69 nicht nur auf die reine Textvergrößerung bezogen sei sondern auch auf den Page Zoom. Der Fehler beziehe sich auf beides. Sie werden daher ein weiteres Beispiel für einen Fehler mit Page Zoom zur Verfügung stellen. Aber: Für die Erfüllung des Erfolgskriterium sei der Page Zoom ausreichend.

Wir befinden uns bereits auf Level AA in flexiblen Zeiten

Ich denke, es ist nicht wirklich sinnvoll, die reine Textvergrößerung vom Page Zoom zu separieren. Beides kann, wie man in Hellbusch / Probiesch Barrierefreiheit verstehen und umsetzen in Beispielen nachlesen kann, durchaus auch kombiniert werden. Spätestens dann wird es für beide Zoom-Techniken eng bei zu wenig Flexibilität.

Und mit unseren aktuellen Layout- und Contenttechniken wie Mobile First oder Responsive Web Design und CSS Flexible Box Layout Module findet ohnehin eine Renaissance des Flexiblen statt. Sich dabei noch mit dem Desktop-Modell aufzuhalten, ein fixes Layout mit x-fachen Media Queries für x-Auflösungen zu stützen, dass der Page Zoom dann irgendwie schon noch überall passt und man dann irgendwie Level AA erreicht hat, das kann es letztlich nicht sein, das ist weder aktuell robust noch nach vorne stabil.

Mag auch die reine Textvergrößerung nicht mehr wirklich im barrierefreien Debatten-Fokus bleiben, kann sie einfach mal so nebenbei schlicht in die Flexibilität mitgenommen werden. Sicherlich gibt es in der Kombination unterschiedlicher Browser, Media Queries und der reinen Textvergrößerung ein paar Aha-Erlebnisse, aber mehr als ein kurze Lernphase ist nicht nötig, um diese Zoom-Option flexibel zu gestalten und zu integrieren.

Klar – für den BITV-Test stellt sich tatsächlich die Frage, ob der Prüfschritt 1.4.4.a Schriftgröße variabel wirklich in dieser Form beibehalten werden kann bzw. wie die Prüfung auf Level AA und Priorität da aussehen kann.

Und letztlich ist die Debatte Page Zoom versus einfache Textvergrößerung eine irreführende. Es geht darum, wie flexibel lege ich Inhalt und Layout für aktuelle und zukünftige Ausgaben an. Der Page Zoom unterstützt fix und flexibel, die reine Textvergrößerung auch. Die Frage ist dabei nur, wie gut les- und nutzbar ist das Ergebnis.

Skurriles Update zum Schluss: Page Zoom reicht auch auf AAA?

Heute liest man eine erneute Antwort in der WAI Liste zum Thema Erfolgskriterium 1.4.4 von Gregg Vanderheiden, der wohl aus WAI-Sicht argumentiert: Es würde vom Layout der Seite abhängen, ob der Page Zoom nicht auch für AAA – also Erfolgskriterium 1.4.8 – hinreichen kann, wenn der Hauptbereich jeweils lesbar bleibt ohne horizontales Scrollen.

Screenshot: Schriftmanipulation lettering.js - Vorlage

Schriftersetzung ist noch immer aktuell, wenn es sich um Lizenz- oder Darstellungsfragen dreht. Leider möchte man aus mehreren Gründen sagen: Zum einen sind mit dem verstärkten Einsatz von font-face alternative Schriftersetzungs-Lösungen fast obsolet geworden und, entwickelt man im Hinblick auf Barrierefreiheit, waren diese alternativen Lösungen nie wirklich eine Option.

War früher in Sachen Schriftersetzung sIFR Marktführer, übernahmen später Javaskript-basierte Lösungen die Führung. Die bekanntesten sehen wir uns nun im Hinblick auf Barrierefreiheit genauer an: cufón, typeface.js und eine Methode der Schriftmanipulation –  lettering.js.

Technik

Im BIK-Test des Monats März 2011 spielt die Schriftersetzung mit Hilfe von cufón eine nicht unbedeutende Rolle: Das Bundesministerium für Gesundheit setzt in großen Teilen auf diese Schriftersetzung, setzte muss man nun sagen. Das problematische Testergebnis, am dem cufón einen nicht unbeträchtlichen Anteil hat, scheint Wirkung gezeigt zu haben. Es befinden sich zwar noch Code-Reste mit dem Verweis auf cufón im Quellcode oder in Skripten, aber cufón erzeugt keine Ersetzung mit Hilfe des canvas-Elements mehr.

Screenshot Schriftersetzung Vorlage Cufon

Damit sind wir schon beim technischen Stichwort: Sowohl cufón als auch typeface.js nutzen die Möglichkeiten des Browsers, Vektorgrafiken zu rendern. Die Ausgangsschrift wird mit Hilfe eines Konverters in eine Javaskript-Datei umgewandelt. Der Browser stellt den Text dann entsprechend seiner Möglichkeiten mit Hilfe des canvas-Elements oder als Internet Explorer vor Version 9 als VML dar.

Bei lettering.js liegt der Fall etwas anders: Hier wird mit Hilfe von Javaskript um jeden Buchstaben eines Wortes ein span-Element gesetzt, damit man jeden Buchstaben per CSS einzeln manipulieren kann. Dieses Verfahren kann man auch auf größere Einheiten ausweiten, etwa einzelne Wörter manipulieren oder ganze Zeilen. Hier handelt es sich auch nicht um eine Schriftersetzung, sondern um eine -manipulation.

Barrierefreiheit

Sicherlich sind die beiden Schriftersetzungsmethoden im Vergleich etwa zu sIFR ein Gewinn gewesen. Lange gab es zur  Darstellung von sIFR kaum Alternativen. Freilich blieb die Lizenzfrage die gleiche, längst haben die Schriftenhersteller in ihren EULAs nachgezogen und legen die Lizenzen auch explizit für sIFR oder cufón fest. Wie für sIFR gilt, sieht man sich die Barrierefreiheit solcher Lösungen an, kann es ganz schnell unschön werden.

Wir sehen uns daher alle drei Methoden unter folgendem barrierefreien Blickwinkel an:

• Kommen Screenreader damit klar?
• Wie sieht es mit der Skalierbarkeit aus?
• Was passiert im Kontrastmodus oder bei benutzerdefinierten Farben?
• Der ewige Knackpunkt all dieser Techniken: Verlinkungen

Für den Test haben wir einen einfachen Text ausgewählt: eine Überschrift und einen Absatz.

<h1>Überall dieselbe alte Leier.</h1>

<p>Das Layout ist fertig, <a href=”http://sprungmarker.de” title=”weiter zum sprungmarker Projekt”>der Text</a> lässt auf sich warten. Damit das Layout nun nicht nackt im Raume steht und sich klein und leer vorkommt, springe ich ein: der Blindtext.</p>

Screenshot Schriftersetzung Vorlage typeface.js

Nur bei typeface.js wird die Überschrift durch einen Absatz ersetzt, da keine Überschriften unterstützt werden – zumindest keine semantischen Überschriften. Die Webseite von typeface.js arbeitet mit visuellen Überschriften, die aber nur mit Hilfe von div-Elementen und CSS hergestellt sind. Im Grunde hat sich typeface.js damit schon für eine weitere barrierefreie Prüfung disqualifiziert.

Dort wird es dann auch alle weiteren Updates und Informationen zu meinen bisherigen Entwicklungen Accessible 1.0 und dem Plugin MCE Accessible Language Change geben. Die Projektumgebung ist dann sowohl Vorschau für Themes als auch Testumgebung – vor allem mit der neusten Entwicklungsversion von WordPress.

Um mit dem Thema schlicht mehr Leute zu erreichen, versuche ich mich mal im konsequenten Englisch – was mir jetzt nicht leicht fällt, ich spüre schon, dass das noch etwas hakelig läuft – aber ich werde mich schon improven. ;)

Damit wird auch sprungmarker.de wieder frei von Twenty Ten werden – dem Default-Theme von WordPress. Ich finde es weder sonderlich ästhetisch in Aussehen und Codequalität, noch halte ich es für innovativ. Nun heisst es die HTML 5 Kenntnisse mobilisieren und endlich was Schickes hier bauen – da freu ich mich richtig drauf.

Durchgezogen ist auch das richtige Wort. Als dann doch Anfängerin zog der Kurs in nur 5 Wochen eine Unmenge an Themen durch. Dazu hatte man stets Teile der Spezifikation, des Online-Materials und des verknappten, vereinfachten Materials durchzuackern. Dann jeweils Hausaufgaben zu erledigen, die sich nicht unbedingt direkt aus dem gerade noch gelesenen Material ergaben. ;) Also schlicht – man war oft ziemlich auf sich allein gestellt.

Aber: da SVG ja mittlerweile direkt in HTML5 integriert und bearbeitet werden kann und der IE9 es auch unterstützen wird, fand ich das schon spannend damit zu arbeiten. Wenngleich die SVG-Unterstützung für einzelne Bereiche wie Text oder Animation noch sehr je nach Browser unterschiedlich ist und mitunter auch noch zu wünschen übrig lässt. Auch ist das Anlegen eines Pfades einer komplexen Figur auch eher was für Leute, die gerne redundant arbeiten. :) Aber das einfach auch einmal per Hand angelegt zu haben, hat was, auch wenn es mühsam ist, da noch den Überblick zu behalten. Klasse find ich, wie einfach es ist zu animieren – und das ganz ohne Scripting.

SVG Animationen als Maschine

Als quasi Abschlussarbeit sollte man dann mit Hilfe des Gelernten etwas machen, was einem selbst gefällt und irgendwie auch besonders sein sollte. Auch wieder so eine Aufgabe, die mich nach dieser knappen Spanne an Wissensaneignung dann doch etwas gefordert hat. Aber letztlich habe ich mich auf meine künstlerischen Roots besonnen und eine kleine SVG-Maschine gebaut. Auch um Animationen als das zu zeigen, was sie letztlich auch sind: Maschinen. :) Den vollen Genuss der SVG-Machine erhält man mit aktuellen Browsern wie Safari 5, Chrome oder Opera. Die Textanimation etwa – das fallende A – läuft nicht in allen Browsern, im aktuellen Firefox läuft gar nichts, aber schon in der 4er Version laufen einige der Animationen, aber nicht die Text-Animationen und -Effekte.

Jetzt werde ich mich damit beschäftigen, wie SVG auch barrierefrei zu machen ist und meine neuen Kenntnisse im kleinen Rahmen immer mal vertiefen. Meine SVG-Machine hat wohl auch Anklang gefunden, sie wurde als gelungenes Beispiel im W3C Blog hervorgehoben. Das W3C bietet den Kurs erneut an ab 10. Januar 2011. Wenn er diesmal etwas Fahrt aus den Lektionen nimmt, ist er meine absolute Empfehlung. Zur ausführlichen Kursbeschreibung.

Im ersten Teil ging es darum, sich einen Überblick zu Webfont-Services zu schaffen, im zweiten Teil geht es nun um die konkrete Praxis – egal ob es sich um selbst- oder fremdgehostete Fonts handelt – wie sieht das konkrete Ergebnis aus, wo treten die Probleme auf, auf was muss man acht geben, was kann man noch nachjustieren.

Um es möglichst anschaulich, vergleichbar und einfach zu halten, habe ich die Webfont Lobster ausgewählt. Die Schrift kann man für beide Hosting-Formen nutzen und eignet sich daher gut für Vergleichergebnisse. Verglichen werden:

• Rendering Engine und Browser (Win – GDI, Direct Write / Mac – Core Text)
• Webfont-Services wie Google Fonts und Typekit

Ich gehe aber auch auf noch reichlich experimentelle Font-Features ein wie Kerning mit Hilfe von CSS (text-rendering, font-kerning), font-size-adjust oder OpenType Features. Teilweise ist das schon übergreifender implementiert, teilweise kaum wie die OpenType Features, die in geringen Anteilen in aktuellsten Versionen von Firfefox und Webkit laufen sollen (mitunter reicht auch die Alpha- oder Beta-Version dazu nicht). Manches konnte ich nicht nachstellen, obwohl es schon in diesen Versionen laufen sollte.

Webfonts in der Praxis – Teil 2 – Beispielfont Lobster

Meine Präsentationen auf slideshare.

Screenshot Accessible 1.0 child theme for Twenty Ten

WordPress 3.0 came out with a new default theme: Twenty Ten. The theme is compared to Kubrick an improvement, but still has mostly the same accessibility issues as its forerunner, e.g. not enough contrast in colors, few improvements for keyboard users and you get no real information about user’s location within a web page.

Screenshot: Accessible 1.0 file structure

This is where Accessible 1.0 get’s into: a child theme for the default theme Twenty Ten to get the parent theme more accessible. You get all functionality of Twenty Ten plus accessible features of the child theme. That’s a nice deal. :)

And: the child theme uses no templates, only a css file and some programming in functions.php. That’s all. Accessible 1.0 should only be a small accessible enhancement.

You find all informations about Accessible 1.0 on a new site – Accessible WordPress. Please follow updates and download the accessible child theme there: WordPress Child Theme for Twenty Ten: Accessible TwentyTen.

Thanks. :)

Screenshot: Buttons MCE Accessible Language Change

One thing I always missed in WordPress editor TinyMCE is to add language change. So I made my first plugin. :) This was somehow hard because it’s not only to get a plugin in WordPress running, you also have to get into programming with TinyMCE. So keep in mind when you use the plugin, I am a novice …

The Plugin MCE Accessible Language Change – now in the WordPress Plugin directory – adds two buttons to the editor: one for changing the language of a word or phrase within a span element and one for changing or adding the language of already existing block elements as paragraphs or headlines. Furthermore you can add the target language to a link:

Language change within a span element

Screenshot: Popup add language change

To change the language of a word or phrase, just select the word or phrase, klick on the button LANG and fill in the language adequate  code, e.g. for a word or phrase in french fr. If you have to be If you need to be XHTML compliant, just fill in the language code again. You can modify of delete your entry at any time. Language change is highlighted in the editor, but not on the website.

Add or change language attributes of existing block elements

Screenshot: Popup add language change for block elements

You can add language change to existing HTML elements as paragraph or headlines. To add or edit the language of a e.g. a paragraph, just klick in the paragraph and on the button LANG ATTR and fill in the language code  (e.g. for a french word or phrase  fr) . If you need to be XHTML compliant, just fill in the language code again. You can modify of delete your entries at any time. To delete your entries, just empty the fields. If you need to add the target language to a link, just mark the link text and add the target language

Add a target language to a link

If your link target is in a different language, you can add a target language to the link. Just klick in the link and on the button LANG ATTR and fill in the language code for the target language. You can modify of delete your entry at any time. To delete your entry, just empty the field.

Plugin informations

The plugin is localized for english and german, please let me know if you would like additional localizations added.

Requirements: WordPress 3.0 and above
Tested up to: WordPress 3.1 on all modern browsers als IE 7/8, Safari, Chrome, Firefox and Opera (Windows, Mac)
TinyMCE is not yet running with IE 9.
Version: 1.0
Licence: GNU General Public License v2.0

Hoping to add more features in future updates, e.g. backwards compatibility.

Installation

1. Just download MCE Accessible Language Change in the WordPress Plugin directory.
2. Upload mce-accessible-language-change folder to the “/wp-content/plugins/” directory
3. Activate the plugin through the “Plugins” menu in WordPress
4. To show your language change visually in the editor – not on your website: If you have already a file named editor-style.css in your WordPress theme, you have to copy the styles below into this file editor-styles.css to get your language changes visible in the editor.
   If you don’t have a file named editor-styles.css in your theme, you have to do nothing – MCE Accessible Language Change Plugin will do this for you.

span[lang],
.lang {
    background: #f8f8f8;
    border: 1px solid #d2d0ce;
    padding: 2px;

Changelog

1.0 – first release
* Minor changes renaming files according to the name of zip file

Upgrade notice

No upgrades right now.

If you didn’t get the plugin running, please download it again and replace the installed plugin. Plugin folder and file had not the same name. :) Sorry for the mingle-mangle.

Download

MCE Accessible Language Change in WordPress Plugin Directory

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.

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.

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. :)

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)

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)

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.

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 viaTwitter 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.

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.

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. ;)

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.

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.