Webdesign
Freitag12. Februar 2010

Skiplinks gehören zu den grundlegenden Navigationshilfen, welche die Zugänglichkeit komplexer Webseiten verbessern können, indem sie es dem Nutzer erlauben, wichtige Elemente einer Webseite schnell und ohne Umwege zu erreichen, z.B. die Hauptnavigation, den Inhaltsbereich oder ein Formular. Aufgrund meiner Erfahrungen bei der Arbeit an und mit YAML gibt’s hier nun einen kleinen Best Practice Beitrag zum Thema.

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.

Den gesamten Beitrag lesen


Montag01. Februar 2010

Die Frage stellt sich bei jedem neuen Webprojekt: Welche Browser/Browsergenerationen sollen unterstützt werden? Grenzt man die Fragestellung auf unser aller Lieblingsproblem, den Internet Explorer, ein, so lässt sich die Frage darauf reduzieren, wie man mit dem Internet Explorer 6 umgeht. Schleppt man ihn irgendwie mit (wird bei den meisten Projekten nach wie vor gemacht) oder ignoriert man ihn. Pfiffige CSS-Entwickler setzen auf Graceful Degradation oder Progressive Enhancement, um neben der schwarz/weiß Option (ja/nein) noch ein paar argumentative Graustufen einfügen zu können.

Doch so gern und trefflich die Blogosphäre sich auch über den IE6 und dessen Schwächen auslässt so gründlich wird in der Diskussion meist außer acht gelassen, dass auch andere Browser einem Alterungsprozess unterliegen. Wer testet denn heute noch ernsthaft seine Projekte gegen den Firefox 1, Safari 2 oder Opera 8? Der Firefox 1.0 beispielsweise stammt aus dem Jahre 2004 und hat damit ebenfalls bereits 5+ Jahre auf dem Buckel. Schon mal drüber nachgedacht?

In den Focus rückt diese Fragestellung bei mir durch Googles aktuelle Ankündigung, den IE6 bei den eigenen Applikationen nicht mehr zu unterstützen - worüber auch sofort wieder reichlich berichtet wird. Nur steht in Googles Ankündigung weit mehr als das Ende des IE6-Supports. Auch die nächste Generation der “Guten” - Firefox 2.x, Opera 9, Chrome 2.x usw. nähert sich dem Ende ihrer Unterstützung. Zwar findet man diese Aussage in dieser Deutlichkeit nicht in diesem Google-Blogpost, dafür beispielsweise bei Yahoo’s Aufstellung für den abgestuften Browsersupport der YUI Library.

Interessant an der Yahoo-Tabelle ist beispielsweise, dass selbst der Firefox 3.0 unter Windows Vista/7 bereits den A-Grade Status verloren hat. Von Opera ist generell nur die aktuelle Version 10 in der Liste vertreten und auch der Safari unter Mac nur in der aktuellen Version 4 gelistet wird. Alle älteren Versionen werden aktuell als B-Grade eingestuft. Sie werden selbstverständlich weiterhin unterstützt werden - jedoch bereits heute mit geringerer Priorität. Nun dreht es sich sowohl bei Google als auch bei Yahoo in allererster Linie um die JavaScript-Unterstützung/-Performance. In Sachen CSS ist es vor allem der Internet Explorer 6, der mit zahlreichen Bugs gesegnet ist, die Webentwicklern bei den immer komplexer werdenden Applikationen mehr und mehr zu schaffen machen. Doch auch bei den modernen Browsern werden die Unterschiede momentan eher größer als kleiner. Konkretes Beispiel: Die JavaScript-Performance des aktuellen Firefox 3.6 ist nicht einmal halb so gut wie die des Chrome 4. 

Abgestufter Browsersupport bei HTML5 & CSS3?

Die Frage, die ich deshalb in den Raum stellen möchte lautet: Wie geht man mit den älteren Generationen der “guten” Browser um? Ich klammere hier bewusst den IE 6 und 7 aus, mir geht es um Firefox 1.x,2.x,3.0.x, den Opera 8.x,9.x, den Chrome 1,2 oder auch Safari 1,2. Was die immer weiter wachsende Unterstützung für beispielsweise CSS3 und HTML5 angeht, so gibt es mit den älteren Generationen sicherlich weniger Probleme. Doch was ist mit waschechten CSS-Bugs?

Der Firefox 3.6 ist beispielsweise der erste Firefox überhaupt, der CSS-Tabellen endlich fehlerfrei darstellt. Alle seine Vorgänger hatten da so ihrer Schwierigkeiten. Der Firefox 2.x ließ teilweise Labels hinter Formularelementen verschwinden. Im Gegensatz zum Internet Explorer 6, der neben seinen zahlreichen CSS-Bugs ebenso zahlreiche Parser-Bugs mitlieferte, über deren Ausnutzung viele Probleme gefixt werden konnten, steht man bei den “guten” Browsern meist im Regen. Bugfixes für deren CSS-Probleme sind Mangelware. Mit der wachsenden Verbreitung von Firefox und Co. und den immer neuen Versionen/Generationen wird auch die Streubreite bei den Anwendern zunehmen und damit wird es zwangsläufig dazu kommen, dass diese Bugs “sichtbar” werden, wenn aktuelle Webtechnologien vermehrt Anwendung finden.

Wir beginnen gerade erst, die ersten graphischen Spielereien von CSS3 in unsere Projekte einzubauen. Ein falscher Schatten oder eine runde Ecke stellen in der Regel kein Problem dar. Doch wie sieht es aus, wenn wir damit beginnen, die neuen Layout-Module zu verwenden (Mehrspaltigkeit, Alternative Box-Modells, ect)? Das sind layoutkritische Elemente, was wenn hier Bugs auftreten, weil die ersten Implementationen noch nicht ausgereift waren - aber noch nicht vom Browsermarkt verschwunden sind?

Thema HTML5: Auch hier hat die Entwicklung deutlich an Fahrt gewonnen. Im letzten Jahr gab es reichlich Tutorials, wie HTML5 schon heute angewandt werden kann. Doch auch hier werden wir bei der aktuellen Geschwindigkeit Mühe haben, dass ältere Browsergenerationen von FF und Co. bereits aus den Statistiken verschwunden sind, bevor wir damit richtig anfangen zu arbeiten - oder wir warten bis 2020 (das will niemand wirklich, oder?). Dem Firefox 2 kann man nur sehr mühevoll den Umgang mit den neuen Elementen beibringen, vernünftiges Styling ist fast unmöglich. Für den IE7 und 8 gilt das gleiche, doch beide werden uns vermutlich noch eine ganze Weile begleiten.

Es bleibt spannend und unberechenbar ...

In die Browserwelt ist sichtlich Bewegung gekommen. HTML5 und CSS3 nehmen Woche für Woche weiter Fahrt auf. Die Performance-Entwicklung der JavaSript-Engines von Google, Safari und Opera (v10.5) eröffnet Möglichkeiten, die vor 1..2 Jahren noch völlig undenkbar waren - ganz unabhängig von den zahlreichen neuen Features, die uns durch jedes Browserupdate beschert werden. Jetzt also, wo der IE6 so langsam von der Bildfläche verschwindet, haben wir nicht zwingend Eitel Sonnenschein. Stattdessen wird sich der Focus einfach etwas verschieben, weg von dem einen zentralen Problembrowser hin zu den zahlreichen alten Browsergenerationen, welche die neuen Webtechnologien unzureichend oder fehlerhaft implementiert haben.

Nach so vielen vagen Gedanken würde mich Eure Meinung interessieren:

  • Wie geht mit der wachsenden Versionsvielfalt und den damit verbundenen Leistungsunterschieden um?
  • Wie reagiert Ihr auf Browserbugs, die sich nicht mehr so leicht fixen lassen, wie im guten alten Internet Explorer 6?
  • Wie handhabt Ihr die unterschiedliche Unterstützung von Standards (HTML5, CSS3)?

Entfernen wir uns wieder von “Graceful Degradation” und “Progessive Enhancement” weil die Leistungsunterschiede im Vergleich zu heute tendentiell geringer werden oder bleiben wir als Webentwickler so tolerant wie bisher und sorgen uns in Zukunft auch um die älteren Guten, auch wenn deren Aufkommen in der Statistik geringer sein wird als es der IE6 momentan noch ist?


Sonntag06. Dezember 2009

Am 4. Dezember wurden im Rahmen einer einer feierlichen Veranstaltung im Postbahnhof Berlin die diesjährigen Gewinner des mittlerweile 6. Biene-Wettbewerbs (Barrierefreies Internet Eröffnet Neue Einsichten) ausgezeichnet . Eine Woche zuvor waren die 24 Finalisten bekannt gegeben worden, die alle formalen Kriterien und – der folgende Punkt wird vielfach vergessen – umfangreiche Nutzertests erfolgreich bestanden haben. Aus der Reihe der Finalisten kürte eine prominent besetzte Jury schließlich die besten Webauftritte und vergab insgesamt 17 Biene-Preise in Gold, Silber und Bronze.

Wie schon im letzten Jahr war auch dieses Mal YAML wieder zahlreich unter den Finalisten und Preisträgern vertreten. Insgesamt 5 der 24 Webseiten im Finale des Wettbewerbs setzen auf das bekannte CSS-Framework, drei davon wurden letztlich mit einer Biene in Bronze prämiert.

Hier noch einmal die Finalisten und Preisträger mit YAML unter der Haube:

  • Gemeinde Issum:www.issum.de – BIENE in Bronze (Kategorie ›Komplexe Informations- und Kommu­nikations­angebote‹)
  • Stadt Nettetal: www.nettetal.de – BIENE in Bronze (Kategorie ›Komplexe Informations- und Kommu­nikations­angebote‹)
  • Naturheilpraxis Angela Käßner: http://www.naturheilpraxis-kaessner.de – BIENE in Bronze (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)
  • Stadt Kevelaer: www.kevelaer.de (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)
  • Stadt Emmerich am Rhein: www.emmerich.de (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)

Dabei steuert das YAML Framework nur einen kleinen Teil zur Barrierefreiheit einer Webseite bei, die Hauptarbeit liegt nach wie vor bei den verantwortlichen Webdesignern und Redakteuren, denn so aufwändig die Erstellung einer Webseite auch ist, stellt deren Betrieb mit regelmäßigen Anpassungen/Überarbeitungen und ständigen redaktionellen Änderungen die wahre Herausforderung dar, soll der hohe Qualitätsstandard dauerhaft gehalten werden. Als Technische Basis der verschiedenen YAML-basierten Seiten kamen die Framework-Versionen 2.5.x und 3.0.x zum Einsatz. Schon daran kann man erkennen, dass der Aufbau komplexer Informationsangebote viel Zeit in Anspruch nimmt, denn die Version 3.1 (Januar 2009) sowie die aktuelle Version 3.2 waren noch nicht vertreten. Damit aber genug dazu.

Besonders beeindruckend finde ich die Tatsache, dass trotz der gestiegenen Anforderungen an die Bewerber, vermehrt komplexe Angebote ins Finale einziehen und Preisträger werden. So konnten in diesem Jahr, der Webauftritt der DHL, das Online-Banking-Portal der Credite Suisse oder auch der SWR und die Zeit Online silberne Bienen mit nach Hause nehmen. Für den Webshop Manufaktum gab’s gar eine Biene in Gold.

Ebenfalls immer mit dabei sind die zahlreichen Kritiker, die Finalisten und Preisträger im Nachhinein sezieren und dabei immer wieder vermeintliche Haare in der Suppe finden. Sei es die mangelnde Validität oder die vergleichsweise schlichte Optik mancher Seite oder oder oder. Doch die Biene bewertet keine Photoshop-Künste, sondern Zugänglichkeit. Und so stellt die Riege der Finalisten und Preisträger einen aus meiner Sicht im Bezug auf die Designqualität einen durchaus repräsentativen Querschnitt aktueller Webseiten dar. Darunter sehr schöne Seiten wie www.bund.de oder die Zeit Online und daneben eben auch weniger schicke Angebote wie die des Hamburger Verkehrsverbundes (Biene in Bronze) oder der Stadt Suttgart. Hier mag dem einen oder anderen das Bling Bling  fehlen, dafür überzeugen alle diese Seiten mit hervorragender Zugänglichkeit, was viel zu viele Hochglanz-Webseiten nicht für sich in Anspruch nehmen können. Und an dieser Stelle vertraue ich der Jury, denn ins Finale kommt man nicht allein durch das Abarbeiten von Barrierefreiheits-Checklisten sondern die Seiten müssen sich in zahlreichen Nutzertests beweisen - Design hin oder her.

Allen Kritikern sei daher angeraten: Kritik ist erlaubt, schnödes Meckern ist nur peinlich. Aber wenn Ihr es besser wisst dann geht bei Euren eigenen Projekten mit gutem Beispiel voran und zeigt, dass es besser geht. Entwickelt charmante Lösungen, erstellt attraktive Webseiten, reicht diese zur Biene 2010 ein. Dann könnte der Anteil attraktiver Angebote weiter steigen und vielleicht hört dann auch endlich mal die BF-Szene damit auf, sich selbst der der Lächerlichkeit preiszugeben, indem permanent gegenüber Berufskollegen gemeckert und Preisträger seziert werden. Tomas Caspers hat es auf der diesjährigen Webtech-Konferenz auf den Punkt gebracht.

“Auch bei Beachtung der WCAG 2.0 und dem Einsatz moderner Webtechniken wie WAI-ARIA kann man dennoch an einzelnen Details scheitern. Doch passiert dies immernoch auf einem weitaus höheren Niveau als bei jenen, die sich aus Angst vor dem möglichen Scheitern gar nicht erst auf den Weg machen.”

Und genau so sehe ich das auch: Der Weg ist das Ziel.

Abschließend sei noch die Stadtbibliothek Marzahn-Hellersdorf erwähnt, die ebenfalls mit einer Biene in Silber ausgezeichnet wurde. Dieses Projekt wurde innerhalb von 3 Jahren ausschließlich von engagierten Mitarbeitern der Bibliothek realisiert – ganz ohne eine professionelle Agentur. Eine solche Leistung verdient höchsten Respekt.


Dienstag25. August 2009

Seit der Version 2.8 bringt Wordpress das neues Template-Tag body_class mit, womit sich verschiedenste Abhängigkeiten und Statusinformationen des CMS als CSS-Klassen an das <body> Element heften lassen, um mittels CSS im Layout darauf reagieren zu können.

<body <?php body_class(); ?>>

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.

 


Montag29. Juni 2009

Ich unterbreche die temporäre Funkstille in diesem Weblog für eine kleine Diskussion, die mir nun schon seit ein paar Wochen auf dem Magen liegt. Irgendwie wird man das Gefühl nicht los, bei HTML & CSS wäre entwicklungstechnisch die Luft raus. Seit Monaten überschlagen sich Online-Magazine für Webdesigner mit Toplisten, in denen bestehende Informationen aus dem Netz nach mehr oder minder sinnvollen Kriterien immer wieder neu zusammengestellt und wiedergekaut werden. Echte Fachartikel mit “a-ha” Effekt sind in diesen Tagen äußerst selten geworden.

Nachdem nun aber auch Toplisten kaum jemand mehr sehen und lesen mag, wird insbesondere bei den zahlreichen Online-Magazinen spürbar, dass es - bedingt durch den quälend langsamen Entwicklungsprozess bei HTML & CSS - ganz offensichtlich nicht mehr viel Neues und Spannendes zu entdecken gibt. Man sucht händeringend nach unverbrauchten Themen und neuen Autoren.

Als vor 14 Tagen bei Dr. Web der umstrittene Beitrag “Hintergrundbilder eindrucksvoll mit CSS skalieren” erschien und der Autor für seine (bzw. die auf der Webseite GOTO CHINA verwendeten Lösung) Viewport-füllende und horizontal + vertikal zentrierte Darstellung einer Hintergrundgrafik doch tatsächlich eine HTML-Tabelle als Grundlage vorsah, war ihm der Proteststurm der CSS-Community sicher. Fast niemand der Kommentatoren hat sich dabei die Mühe gemacht, die vorgestellte Technik vollständig zu verstehen bevor man sie in der Luft zerriss. Denn ganz so trivial wie viele vermuteten, ist sie dann eben doch nicht. Gleichermaßen hat es der Autor versäumt, seine Entscheidung pro Layouttabelle schlüssig zu begründen.

Nun finde ich Layouttabellen alles andere als charmant. Aber ich muss auch zugeben, dass ich eine optisch zu 100% gleichwertige und ebenso robuste Variante auf reiner CSS-Basis – zumindest innerhalb einiger Stunden – nicht präsentieren konnte. Auf der anderen Seite hatte ich jedoch sehr schnell eine alternative Lösung, die ohne Tabellen dem Vorbild sehr nahe kommt und lediglich die vertikale Zentrierung bei sehr kleinem Viewport vermissen lässt. Mein Testcase ist zunächst nur ein Schnellschuss, zeigt aber, dass es auch anders geht.

Nach vielen Jahren der Diskussion um Webstandards wundert es mich dann schon, dass der Autor Adrian Bechtold kein Wort darüber verliert und dadurch die massive Kommentarflut provoziert. Es ist nämlich die Frage, ob – wie im vorgestellten Beispiel – das Ergebnis die Mittel (Layouttabelle) wirklich rechtfertigt. Genau diese Folgediskussion wäre interessant gewesen, doch leider wollten sich hier weder der Autor noch die Kommentatoren darauf einlassen. Das Team von Dr. Web ist gerade dabei ist, dem eigenen Portal neues Leben einzuhauchen. Hier wäre eine Chance gewesen, doch ohne den Bezug zu aktuellen Layouttechniken wirkt der visuell beeindruckende Effekt in der Umsetzung verdammt altbacken.

Und damit kommen wir zum zweiten Fall. Auch das in die Jahre gekommene SelfHTML versucht mit neuen Fachartikeln den Anschluss zu halten. Doch dieser scheint sowohl beim Autor als auch bei der Redaktion bereits in weite Ferne gerückt zu sein. Stein des Anstoßes ist der Beitrag “Benutzerfreundliche Viewportweiche ohne JavaScript”.  Auf dem einstigen deutschsprachigen Aushängeschild, der langjährigen Lernplattform für unzählige angehende Webdesigner veröffentlicht man 2009 invaliden HTML-Code ohne Doctype (invalid selbst nach HTML 4.01 Transitional), mit Layouttabellen, Absatztrennung mit <br><br> und haufenweise Inline-Styles. Das ganze verpackt in einem Thema dessen Relevanz um den Nullpunkt schlingert und mit haarsträubenden Argumenten und Beispielen.

Und als ob das nicht bereits genug wäre, können weder die SelfHTML-Redaktion noch der Autor selbst mit der zwangsläufig aufkommenden Kritik sonderlich gut umgehen. Diese wird vom SelfHTML-Team als das Gemeckere eines “elitär kleinen Zirkel von Semantik-Fetischisten” und vom Autor Martin Suhr selbst als Quatsch eines nörgelnden Misanthropen gekontert. Inhaltlich geht man auf die Kritik natürlich nicht ein. Stattdessen rechtfertigt sich die Redaktion wir folgt:

Wenn ich an alle unsere Artikel, insbesondere an die, die noch zu schreiben sind, die höchsten Qualitätsansprüche stelle, nur um einen elitär kleinen Zirkel von Semantik-Fetischisten zufrieden zu stellen, habe ich keine Autoren mehr, die es überhaupt noch wagen werden, uns irgendwelche Inhalte zu liefern.

Liebes SelfHTML-Team, das ist ein peinliches Armutszeugnis und wenn Ihr das wirklich so seht, wenn euch die Qualität Eurer Artikel egal ist so lange Ihr nur etwas veröffentlichen könnt, dann SelfHTML: Ruhe in Frieden. Oder wie Jens Grochtdreis es in seinem Kommentar treffend formuliert:

Diese Qualitätskontrolle erwarte ich auch bei SELFHTML. Dann sollten keine Codebeispiele Marke “Scheiss egal, was da steht, es geht erstmal ums grobe Prinzip” veröffentlicht werden.

Der nächste Entwickler, dem ich dann versuche seinen Tabellenlayouts auszureden, erzählt mir dann, daß er das bei SELFHTML gelesen hat. Und das müsse ja dann wahr sein.

Und wenn Du keine Qualitätsansprüche an Deine Publikation stellen willst, dann tut es mir um das ehemals richtig gute SELFHTML sehr leid. Dann ist es wohl wirklich an der Zeit, von diesem netten und informativen Dino Abschied zu nehmen. Die Referenzen von Sitepoint sind auf dem neuesten Stand und kommen ohne Tabellenlayouts aus.

In diesem Sinne, das war’s, was ich kurz anmerken wollte. Was meint Ihr?


Seite 4 von 13 Seiten

« Erste  <  2 3 4 5 6 >  Letzte »