Weblog

Anforderungen

Zunächst wären noch einmal die Anforderungen an Skiplinks zu definieren. Die WCAG 2.0 gibt unter G1 Testkriterien vor:

1. Stelle sicher, dass Skiplinks die ersten focussierbaren Elemente der Webseite darstellen.
2. Stelle sicher, dass die Linkbeschreibung eine verständliche Beschreibung des Sprungzieles enthält.
3. Stelle sicher, dass der Skiplink entweder immer oder zumindest dann sichtbar ist, wenn der Tastaturfocus auf ihm liegt.
4. Stelle sicher, dass beim Aktivieren eines Skiplinks der visuelle Focus im Viewport des Browsers auf das Ziel gesetzt wird.
5. Stelle sicher, dass nach dem Aktivieren des Skiplinks der Tastaturfocus auf das Zielelement gesetzt wurde.

Die WCAG ist unnachgiebig, was diese Kritierien betrifft: Alle 5 Testkriterien müssen erfüllt werden.

Zum Thema CSS-Sprites gibt es weiterhin eine kleine Demo von David, welche er soeben online bereit gestellt hat.

Weitere Vorträge im Netz:

• Jan Eric Hellbusch, “WCAG 2.0 und BITV2 für Einsteiger”
• Jens Meiert: HTML5: Barrierefreiheit, Performance, Wartbarkeit
• Christian Heilmann: Barrierefreiheit im Datennetz

Leider ist die Implementation dieser interessanten und nützlichen Funktion in Wordpress eher unglücklich gelöst. Die Jungs von WPEngineer haben bereits im Februar vorbildlich darüber informiert, welche Klassennamen das Tag ins Markup rendert. Darunter befinden sich zahlreiche allgemein gebräuchliche Klassenbezeichnungen wie:

• archive
• author
• blog
• category
• date
• home
• page
• search
• tag

Das Problem bei der Verwendung derart gebräuchlichen Bezeichnungen sind fast zwangsläufig Kollisionen bei der Implementation bestehender CSS-Layouts in Wordpress. Gerade heute habe ich eine Mail zu diesem Thema bekommen:

Man kann sich ja mittlerweile im BODY-Tag CSS-Klassen einfügen lassen je nachdem welcher Typ von Seite aktuelle von WordPress ausgegeben wird. Dabei gibt es auch die Klasse “page” für die Seiten in WordPress. Resultat ist, dass sich das dann mit der Klasse “page” aus YAML überschneidet.

Ich kann im Moment froh sein, dass es nur eine CSS-Klasse von YAML trifft. Schon innerhalb dieses Bloglayouts hier – würde dieses Blog mit Wordpress laufen – würden weitere Klassenbezeichnungen kollidieren, denn ich verwende in meinem Bloglayout auch Klassenbezeichnungen wie “date” oder “category”. Nur sind diese Klassen in meinem Layout nicht dafür gedacht, an das body-Element geheftet zu werden. Nun könnte ich mein CSS-Framework YAML in einer nächsten Version natürlich anpassen, um der Kollision aus dem Wege zu gehen, aber ich halte dies für den falschen Weg, denn die Welt dreht sich nicht um Wordpress und YAML ist nicht allein von diesem Problem betroffen. Wordpress als Blogtool oder CMS sollte eigenständig kein Markup generieren (soweit die graue Theorie) und es sollte ebenso die Implementation bestehender Layouts nicht durch die Kollision von Klassennamen unnötig erschweren.

Ein relativ einfacher und unkomplizierter Lösungsweg heisst: Namespacing. Wordpress könnte allen dynamisch ins Markup generierten CSS-Klassen das Kürzel “wp-” voranstellen (oder dieses sogar im Backend konfigurierbar machen). Bei anderen Content Management Systemen (Bsp: TYPO3) kommt dieses Verfahren bei den meisten Extensions zum Einsatz. Auf diese Weise ließen sich die angedeuteten Probleme leicht vermeiden, während die durchaus sinnvolle Funktionalität weiterhin uneingeschränkt verfügbar bleibt. Leider bin ich selbst zu wenig bewandert in PHP und auch nur ein Gelegenheitsnutzer von Wordpress, dennoch hoffe ich, dass diese Idee auf irgendeinem Kanal an das Entwicklerteam herangetragen wird.

Das Rendering der CSS-Tabellen funktioniert prinzipiell, es ist also kein einfacher CSS-Bug. Ich verwende diese Technik in YAML zur Erstellung gleichhoher Container per CSS. Das eigentlich perverse an diesem Bug - er ist extrem schwer nachvollziehbar. Ich habe die CSS-Tabellen mittlerweile in mehreren Real-Live-Situationen ausprobiert und dabei bereits im Winter erstmals Bekanntschaft mit diesem Bug gemacht. Allerdings war die Fehldarstellung meist nach einem Reload oder auch nur dem Versuch eines Elementchecks mit Firebug verschwunden. Die Ursachenfindung hat das extrem erschwert. Erst vor einigen Wochen hat dann im YAML-Forum ein User einen weiteren Tipp beigesteuert, der letztlich einen Testcase ermöglichte.

Gestern Abend habe ich mich nochmals hingesetzt und endlich einen - zumindest bei mir - funktionierenden Testcase erstellt, sowie den Bug bei Bugzilla gemeldet (Bug 510350) . Die Einzelheiten zum Wie und Warum sind übrigens im Testcase ausführlich beschrieben.

Im Testcase wird der Bug durch eine fast leere Script-Node getriggert, wobei diese hier direkt im HTML-Code der Tabelle steht. Es ist die einzige halbwegs verlässliche Möglichkeit, den Bug zu erzwingen, die ich kenne. In meinen Real-Life-Layouts reichte meist schon die pure Anwesenheit von JavaScript in Form von jQuery oder sonstigem.

Und abschließend: Dieser Bug ist derart fies, dass sein Auftreten auf wundersame Weise sogar vom Dateinamen des Testcases beeinflusst wird. Auf meinem lokalen Rechner tritt der Bug - genau wie in der Netzversion - sporadisch auf. Wenn ich den Testcase jedoch in “index.html” umbenenne, wird er plötzlich permanent getriggert. Das verstehe wer will. Ich hoffe daher, die Mozilla-Jungs finden und eleminieren die Ursache möglichst schnell.

Der Framework-Core

Beinahe jedes CSS-Frameworks definiert sich durch so genannte Kernbausteine. Diese stellen die grundlegende Funktionalität bereit und sorgen für deren browserübergreifende Kompatibilität. Neben diesen Kernbausteinen bieten die einzelnen Projekte mal mehr, mal weniger optionale Bausteine an (Navigationsbausteine, Textformatierung, Formulare ect.), um den Entwicklungsprozess über die grobe Layouterstellung hinaus zu erleichtern. Genau in diesem Punkt klafft die Schere zwischen den einzelnen Projekten sehr weit auseinander. Diese optionalen Bausteine erhöhen zwangsläufig für den Einsteiger beim Erstkontakt die Komplexität, berühren aber eigentlich die Kernaufgabe der CSS-Frameworks (die Layouterstellung) nicht wirklich und erschweren die Vergleichbarkeit. Ich konzentriere mich deshalb beim folgenden Vergleich jeweils auf diese Kernbausteine, den so genannten Framework-Core folgender Projekte:

• YAML 3.2 (aktuelle Entwickerversion Beta 3)
• YAML 3.1
• YUI 3.0 beta1
• 960 grid system
• Blueprint CSS 0.9