HTML5 ist die Zukunft und macht das Web anwendungsfähig: als Plattform für Webanwendungen hat HTML5 die Aufmerksamkeit von Entwicklern und Anwendungsanbietern. Auf Initiative der Browserhersteller Opera, Mozilla, Apple und Google gründete sich 2004 eine Gruppe, die sich zum Ziel gesetzt hatte, das Web einen großen Schritt voran zu bringen. 2006 nahm das World Wide Web Consortium (W3C) die Entwicklung unter seine Fittiche. Microsoft hat sich ebenfalls HTML5 verpflichtet und stellt einen der Vorsitzenden der HTML-Arbeitsgruppe des W3C. Mit großer öffentlicher Unterstützung wird die Entwicklung von HTML5 vorangetrieben.
Alle größeren Hersteller implementieren diesen neuen Standard, der rein formal noch gar keiner ist, schon während seiner Entstehung in ihren Browsern und stellen so Web-Entwicklern die neuen Möglichkeiten bereit. Viele Werkzeuge und Bibliotheken schlagen die Brücke zu älteren Browsern. Als Web-Entwickler kommt man also bereits heute kaum noch an HTML5 vorbei.
Das W3C-Büro Deutschland und Österreich veranstaltet nun zum Thema HTML5 ein ganztägiges Tutorial. Am 23. November werden im THESEUS Innovation Center in Berlin-Tiergarten die Grundlagen und fortgeschrittene Themen aus HTML5, CSS3 und diversen APIs behandelt. Das Tutorial vermittelt Wissen über Hintergrund und Zielsetzung von HTML5, technische Grundlagen, HTML5 und Web-Architektur, Vorstellung der Neuerungen, Demonstrationen und Beispiele, die den Stand der Entwicklung in den unterschiedlichen Browsern zeigen und Strategien für das Entwickeln von Webseiten.
Weiterlesen …
Aus dem Inhalt:
- Evolution von HTML5
- Ziele, Prinzipien und Technologien in HTML5
- HTML5 und heutige Browser
- Neuerungen beim HTML5-Markup
- Markup Syntax
- Strukturelle Elemente
- HTML5 Formulare
- HTML5 User Interaction (Edit, Drag'n’Drop), Local Storage
- HTML5 Media
- Integration anderer Sprachen (z.B. SVG)
- HTML5 Präsentationsschicht (d.h. CSS3)
- HTML5 Pixels: Canvas
- HTML5 in der heutigen Praxis
Zu allen Themen gibt es aussagekräftige, praxisnahe Beispiele, deren Code im Detail erläutert wird.
Ort, Zeit und Teilnahme
Das Tutorial findet am 23.11.2011 von 9:30 bis 17:00 Uhr im THESEUS Innovation Center, Salzufer 6, 10587 Berlin-Tiergarten statt. Der Teilnehmerbeitrag ist 95,20€ incl. Mehrwertsteuer (80€ + MWSt). Die Teilnehmerzahl ist auf 50 begrenzt, Anmeldeschluss ist der 16.11.2011. Die Zulassung erfolgt nach Reihenfolge der Anmeldung und Zahlungseingang des Teilnehmerbeitrags. Weitere Informationen unter ict-media.de/HTML5Tutorial/announcement…
Eintippen, Knopf drücken, fertig: Diskussionen in Foren und Kommentare in Blogs, soziale Interaktion in Communities, das Hochladen eigener Inhalte in Videoportalen, Jobangebote und -gesuche in Stellenbörsen, Fahrplanauskünfte und Tickets bei der Bahn oder Bestellungen und Bezahlung in Online-Shops, ja sogar das Einstellen von Inhalten in Redaktionssystemen und Weblogs – all das funktioniert nur mit Formularen. In Zeiten des Mitmach-Webs werden Formulare immer wichtiger. Formulare sind die technische Basis interaktiver Angebote und die Grundlage der Kommunikation zwischen Anbietern und Nutzern einer Webseite.
Weiterlesen …
Gerade bei Formularen gelten die POUR-Prinzipien der WCAG 2.0 in Reinform: Formulare müssen wahrnehmbar (im Englischen: perceivable), bedienbar (engl. operable), verständlich (understandable) und robust (robust) sein. In den Richtlinien finden sich nur wenige direkte Vorgaben zu Formularen, aber fast alle Punkte der WCAG sind anwendbar – von HTML über CSS und WAI-ARIA bis zu JavaScript und der serverseitigen Verarbeitung der eingegebenen Daten. Obwohl HTML seit Jahren viele Elemente für barrierefreie und damit bedienerfreundliche Formulare enthält, setzen Webdesigner sie zu wenig ein.
Die technischen Grundfunktionen eines Formulars – erfassen, ausfüllen und abschicken – müssen mit allen möglichen Mitteln der Ein- und Ausgabe gelingen. Konkret heisst das, Anbieter von Webseiten müssen assistierende Techniken wie z.B. Screenreader, Sprachsteuerung oder Spezialtastaturen berücksichtigen. Für öffentliche Anbieter, die den Vorgaben der Barrierefreie Informationstechnik-Verordnung (BITV) unterliegen, ist der Einsatz dieser Mittel klar geregelt: die Verordnung verlangt die Verwendung der korrekten HTML-Elemente und den Einsatz von CSS für die Gestaltung, das gilt auch für Formulare. Alle anderen Anbieter profitieren ebenfalls von einer einfachen und barrierefreien Nutzbarkeit ihrer Formulare.
Die Konzeption der Formulare oder der Anwendung steht vor der technischen Umsetzung. Der Webentwickler Timo Wirth hat die Perspektive der Nutzer in einer Präsentation einmal so formuliert: »Ein Formular ist kein Datenbankprozess, es ist der Anfang eines Gesprächs«
. Damit ein gelungener Dialog entsteht, gibt diese Serie Hinweise zur barrierefreien Umsetzung von Formularen.
Die Serie ist in fünf Teile gegliedert:
Im ersten Teil »Toleranz und Rücksicht« geht es um Grundlagen und Konzeption von Formularen. Der zweite Teil – »Formulardesign: der wichtige erste Eindruck« – dreht sich um die Gestaltung, Nutzerführung und Usability. Das technische Grundgerüst und damit die Markup-Grundlage von Formularen und das Layout per CSS ist Inhalt des dritten Teils »HTML & CSS für Formulare«.
Neben den für die Struktur benötigten HTML-Elementen und CSS für die Gestaltung kommt in vielen Formularen JavaScript für das Verhalten zum Einsatz. In Teil 4 geht es um »Dynamik in Formularen – JavaScript & AJAX«.
Im letzten Teil zeigen wir, wie Sie eine erste Qualitätssicherung vornehmen können und geben Tipps für Tests mit echten Nutzern: »Testen von Formularen und web-basierten Anwendungen«.
Die Verwendung simulierter Dialogfenster oder »Lightboxes« – wie man im Englischen kurz und treffend zu sagen pflegt – ist aus dem Internet und der Web2.0-Welt eigentlich kaum noch wegzudenken, zu weit verbreitet scheint ihre Verwendung – zur Freude und zum dem Ärgernis der Nutzer.
Oliver Siemoneit zeigt in seinem Beitrag die gängigen Probleme aus Sicht der Nutzer und stellt den Prototypen einer zugänglichen Lightbox vor:
»Eine kleine Untersuchung zur Barrierefreiheit von Lightboxes«
Ergänzend zum vorstehenden Artikel hier noch ein paar zusätzliche Gedanken, Anforderungen und weiterführende Links zum Thema ›Barrierefreie Lightboxes‹.
Weiterlesen …
Kontext & Anforderungen
Manchmal muss man Benutzern ein reduziertes Interface präsentieren, das den Fokus auf die wesentlichen Informationen oder auf Formularfelder setzt und die Interface-Elemente versteckt, die für die gerade zu erledigende Aufgabe unnötig sind. Wenn dies in Form eines Overlays (auch ›Lightbox‹ genannt) implementiert wird, erscheint der Inhalt als Pop-Up-Fenster oder als simulierter Dialog. Die Lightbox überlagert den Inhalt der Webseite, der Hintergrund wird typischerweise ausgegraut.
Eine Lightbox kann modal sein, d.h. der Benutzer kann nur mit der Lightbox und deren Inhalt interagieren. Oder sie kann nicht-modal sein, d.h. der Benutzer kann in diesem Fall sowohl mit der Lightbox und ihrem Inhalt, als auch mit anderen Elementen der ursprünglichen Seite interagieren.
Hürden & Schwierigkeiten
In Sachen Barrierefreiheit bringt die Benutzung von Lightboxes einige Probleme für verschiedene Gruppen von Menschen mit Behinderungen mit sich. Mögliche Schwierigkeiten sind unter anderem:
- Die Möglichkeit, die Lightbox ohne die Hilfe einer Maus oder anderer Zeigewerkzeuge über eine Tastatur-Schnittstelle zu öffnen und zu schließen.
- Die Benachrichtigung des Benutzers über die Generierung einer Lightbox bzw. das Einfügen des benötigten Codes in die Seite (dies schließt Benutzer von Vergrößerungssoftware ein, die möglicherweise das plötzliche Erscheinen einer Lightbox nicht bemerken, da dies außerhalb ihres Sichtfeldes passiert ist).
- Der Zugriff per Tastatur auf die Lightbox selber (und auf deren Position im DOM-Tree in Relation zu dem auslösenden Element) und auf die Tab-Reihenfolge (und damit die Lesereihenfolge) zu jeglichen Formular-Elementen, Steuerelementen, Links usw., die in der Lightbox enthalten sind.
- Die visuellen Grenzen der Lightbox für Benutzer mit eingeschränktem Sehvermögen oder blinde Benutzer verständlich zu machen und die Notwendigkeit, den Zugriff des Benutzers auf Inhalte innerhalb einer modalen Lightbox zu beschränken.
- Die meisten Lightbox-Scripte setzen einen relativ großen Bildschirm voraus und scheitern bei mobilen Geräten (oder verkleinern nicht auf elegante Art und Weise).
- Die meisten Lightbox-Skripte unterstützen das Drucken nicht.
Barrierefreie Lösungen
Eine Lightbox und ihr Inhalt kann durch die Benutzung einer Reihe von Techniken barrierefrei gemacht werden, wenn man Best Practices der Barrierefreiheit (wie zum Beispiel die Techniques der WCAG 2.0) einsetzt:
- Beim Öffnen der Lightbox sollte der Tastatur-Fokus auf die Lightbox gesetzt werden (idealerweise auf das erste fokussierbare Element, bei dem es sich um einen Link, ein Formular-Label oder ähnliches handeln könnte).
- Beim Schließen der Lightbox muss der Tastatur-Fokus wieder zu der exakt gleichen Stelle zurückkehren, bei der er war, als die Lightbox geöffnet wurde (normalerweise das anfänglich benutzte Element zum Öffnen des modalen Dialogs). Die ursprüngliche Tab-Reihenfolge sollte wiederhergestellt werden und der Benutzer sollte nicht länger in der Lage sein, sich per Tab zu Inhalten innerhalb des modalen Dialogs zu bewegen (d.h. die Lightbox sollte nicht einfach nur aus dem Viewport bewegt werden, sondern sollte ganz aus dem Dokumenten-Baum entfernt werden);
- Das Lightbox-Script sollte die Bedienung per Tastatur vollständig unterstützen (z.B. Esc. zum Schließen der Lightbox, Pfeiltasten zum Blättern in einer Diaschau, Home- & End-Schaltflächen wie auf einer normalen Webseite). Es sollte ein deutlich sichtbarer Fokus-Indikator vorhanden sein und Tastaturbefehle sollten in der Lightbox dokumentiert sein (z.B. »Zum Schließen drücken Sie Esc«).
- Das Lightbox-Script sollte einen vollständigen Browser-Verlauf bieten und die Änderung des
title unterstützen (z.B. über jQuery Address).
- Der Inhalt innerhalb der Lightbox muss voll skalierbar sein (z.B. mit unterschiedlichen Textgrößen).
- Das Design der Lightbox sollte robust genug sein, damit es komplett wahrnehmbar ist, wenn benutzer-definierte Farben (z.B. ein Windows Kontrast-Schema) benutzt wird.
- In modalen Dialogen sollte der Benutzer nicht zu irgendwelchen Elementen außerhalb der Lightbox navigieren können. Stattdessen muss der Tastatur-Fokus innerhalb der Lightbox verbleiben, bis der Benutzer diese absichtlich schließt, entweder indem er Esc drückt oder auf einen Schließen-Link oder eine Schließen-Schaltfläche klickt. Vor allem wenn Formulare in einer Lightbox präsentiert werden, sollte das Tabben über die Lightbox hinaus diese nicht schließen, um einen Datenverlust zu verhindern. Dies kann allerdings in anderen Fällen, wie zum Beispiel bei einer Galerie, genau das erwartete Verhalten sein.
- Die Benutzung von ARIA-Rollen & -Eigenschaften (wie zum Beispiel
aria-role="dialog"oder role="button" für das »Schließen«-Symbol), ARIA-Live-Regions und zusätzlichen ARIA-Attributen, die Beziehungen beschreiben, wie zum Beispiel aria-owns.
Anwendbare Standards & verwandte Techniken
Literatur zum Thema
Beispiele ›aus der freien Wildbahn‹
Code-Beispiele & Downloads
Eine ganze Reihe veralteter Techniken stellen zwar keine absoluten Barrieren dar, sollten aber in der modernen Webentwicklung eigentich keine Rolle mehr spielen, weil Sie die Wartung der Seiten unnötig verkomplizieren. Welche das sind sehen Sie in den folgenden WCAG-Techniken:
Weiterlesen …
HTML-Techniken
CSS-Techniken
Typische Fehler
Die beste technische Basis nützt nichts, wenn die Oberfläche so gestaltet ist, dass viele Besucher Schwierigkeiten mit der Nutzung haben. Ein gutes Design hingegen steht den Nutzern nicht im Weg, sondern passt sich ihren Einstellungen und Bedürfnissen an. Gerade bei einer immer älter werdenden Bevölkerung und einer zunehmenden Vielzahl von Endgeräten mit unterschiedlichsten Bildschirmgrößen sollten solche adaptiven Layouts zur Regel werden, die in den folgenden WCAG-Techniken erklärt werden:
Weiterlesen …
Allgemeine Techniken
HTML-Techniken
CSS-Techniken
Client-seitige Scripting-Techniken
Typische Fehler
Das HTML & CSS-Framework YAML, auf dem auch diese Seiten hier aufgebaut sind, ist seit heute in der fertigen Version 3.2 am Start. Erst vor wenigen Tagen konnte das Projekt seinen vierten Geburtstag feiern und auch nach einer so langen Zeit ist die Luft für Verbesserungen und Weiterentwicklungen noch nicht aufgebraucht. Die vorliegende Version 3.2 bringt einige wichtige Änderungen mit sich: neben dem schlankeren Framework-Kern, der Vereinfachung der Code-Basis, der Erweiterung der Gestaltungsraster (sog. Grids) und den Performance-Gewinnen gibt es eine ganze Reihe von Verbesserungen im Bereich der Accessibility, die uns natürlich besonders interessieren.
Barrierefreiheit eingebaut
Kein Framework, auch nicht YAML, ist ein Garant für barrierefreie Webseiten (obwohl eine ganze Reihe von YAML-basierten Sites bereits mit einer BIENE ausgezeichnet wurden). Dennoch zeigt sich mehr und mehr, wie sinnvoll und richtig es ist, Webentwicklern das grundlegende Handwerkszeug innerhalb von Frameworks zur Verfügung zu stellen. In YAML 3.2 wird eine neue Darstellungsmöglichkeit für Skiplinks unterstützt, die ein Überlagern des Layouts für die eingeblendeten Skiplinks ermöglicht und dadurch die sonst üblichen Probleme bei deren Integration beseitigt. Zudem wird für Webkit-basierte Browser ein JavaScript-Fix mitgeliefert, um auch Apple’s Safari und Google Chrome dazu zu bewegen, den Fokus auf die angesprungene ID zu setzen.
Weiterlesen …
Ein weiterer Schritt ist die konsequente Einbeziehung von WAI-ARIA: sämtliche bei YAML mitgelieferte Beispiel-Layouts sind nun mit sog. ARIA-Landmark-Roles versehen. Zwar handelt es sich hierbei nicht wirklich um ein Feature des Frameworks (die korrekte Auszeichnung sollte nach wie vor der Webentwickler vornehmen), dennoch ist dieser Schritt wichtig, um trotz der noch fehlenden Validierungsmöglichkeiten im W3C-Validator die positiven Effekte des kommenden Standards hervorzuheben, denn schon heute können alle modernen Browser (einschließlich des IE 8) mit WAI-ARIA umgehen und ermöglichen somit einen deutlichen Zugewinn an Barrierefreiheit auf Webseiten jeder Komplexitätsstufe.
Das ›Accessible Tabs‹-Plugin von Dirk Ginader wird mit YAML 3.2 als Erweiterung ein fester Bestandteil des Frameworks. Die Umsetzung im Rahmen dieses Plugins ist mittlerweile ausgereift, umfangreich getestet und funktioniert auch hervorragend mit aktuellen Hilfsmitteln wie Screenreadern.
Entsorgung von Altlasten
Manchmal liegt eine Verbesserung auch im Verzicht auf ein Feature: so bot das Framework bisher die Möglichkeit, Spaltenhintergründe mit Hilfe der CSS-border-Definition von bestimmten Spalten zu erzeugen. Zwar ist diese Technik denkbar einfach in der Umsetzung, sie beschwört aber in Verbindung mit den für viele Sehbehinderte typischen Einstellungen von Benutzer-definierten Farben (z.B. den Windows-Kontrastmodi) ein Zugänglichkeitsproblem herauf, da dort Vordergrund- und Rahmenfarben auf den gleichen Farbwert gesetzt werden. Inhalte mit dahinterliegenden farbigen Rahmen (den simulierten Spaltenhintergründen) waren infolgedessen zum Teil nicht mehr lesbar. Erschwerend kam hinzu, dass diese Technik im Internet Explorer ein CSS-Anpassung benötigte, die in seltenen Fällen das Auswählen von Inhalten mit der Maus im Browser blockierte. Daher ist diese Variante nun, auch aufgrund unserer Überzeugungsarbeit, nicht mehr im Framework enthalten.
Neben diesen großen Neuerungen stehen zahlreiche kleinere Korrekturen, über die das Changelog im Detail Ausfunft gibt. Download des Gesamtpakets, Lizenzbedingungen; YAML Dokumentation: Deutsch (PDF), English (PDF)
Wenn Sie eine tagewochenlange Diskussion unter Webentwicklern lostreten wollen, dann müssen Sie nur mal in einem Forum oder bei Twitter die Frage stellen, ob man mehr als eine <h1> pro Seite verwenden darf, und wenn ja, wofür. Danach können Sie sich entspannt zurücklehnen und Wetten auf den Zeitpunkt abschliessen, an dem die Diskussion vollends aus dem Ruder läuft.
Dabei findet die ganze Diskussion nur deshalb statt, weil es historisch bedingte Lücken in der HTML-Spezifikation gibt. Warum das so ist, wo diese Lücken sind und wo sie herkommen, was man dagegen machen kann und wie das Thema in Zukunft aussehen wird zeigt der Artikel »Passende Überschrift hier einsetzen«.
Der Arbeitstag des gemeinen Web-Entwicklers beginnt ja üblicherweise damit, dass man mal eben schnell was im IE & Firefox kontrollieren will. Beim Start der Virtualisierungs-Software will diese erstmal aktualisiert werden. OK. Update durchgeführt, neugestartet und, oh Wunder, die nächsten Sicherheitsupdates für XP. Na gut, schnell mal installiert, Neustart und dann endlich Firefox geöffnet. Oh, ein Update! Mal schnell runterladen, Browser neustarten, Erweiterungen auf Updates überprüfen und, man glaubt es kaum, es gibt neue Versionen. Runterladen, installieren, Browser neustarten und …
… nichts geht mehr.
Und das alles nur um festzustellen, dass zumindest der letzte Teil des Prozederes für die Katz' war, weil ausgrechnet eine für Web-Entwickler so wichtige Erweiterung namens Firebug so dermaßen voller Bugs ist, dass nur noch das Downgrade auf die Vorgängerversion hilft. Pustekuchen, weil die ist dann nämlich nicht mit der neueren Browser-Version kompatibel und verweigert die Installation.
20 GOTO 10
Der einzige Trost: Die Suche bei Twitter zeigt, dass man nicht allein mit dem Problem ist. Dabei wollten wir eigentlich nur was zu den angeblichen Accessibility-Verbesserungen in Firebug 1.4.x schreiben, aber mangels Testobjekt muss dieser Blogpost halt bis zur nächsten Version warten. Und dann geht der Spaß wieder von vorne los …
Die CSS-Arbeitsgruppe des W3C hat eine ganze Reihe neuer Entwürfe für Module der kommenden CSS 3-Spezifikation vorgestellt. Ganz frisch am Start sind Flexible Box Layout Module und CSS Image Values Module, beide vom 23. Juli und beide erscheinen uns beim ersten Drüberlesen sehr sinnvoll zu sein. Besonders flexbox hat es uns angetan, weil es mit sehr einfachen Regeln ermöglicht, eine Menge HTML- und CSS-Hacks zu ersparen:
»In this new box model, the children of a box are laid out either horizontally or vertically, and unused space can be assigned to a particular child or distributed among the children by assignment of ›flex‹ to the children that should expand. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions.«
Bereits beim Status eines Last Call angelangt ist Ende letzten Monats der Entwurf des CSS 3-Moduls Multi-column layout, das, wie der Name schon sagt, wirklich echte mehrspaltige Layouts ermöglicht. Hier bittet die Arbeitsgruppe um Kommentare bis zum 01. Oktober diesen Jahres.
Wir hatten neulich schon mal etwas mit Multi-column layout herumgespielt und siehe da: es funktioniert sogar in modernen Browsern wie Safari 4, Google Chrome 2 oder Firefox 3.5 3.0. Zum selber ausprobieren: die Liste im Kasten »mehr zum wettbewerb:« ganz unten auf einfach-fuer-alle.de/biene-2009 basiert auf einer simplen Mehrspalten-Anordnung mit reinem CSS ohne jegliche Eingriffe ins HTML.
Weiterlesen …
Einige weitere Entwürfe aus der letzten Zeit:
Die letzten vier basieren allesamt auf Vorschlägen von Apple und funktionieren teilweise schon in aktuellen Versionen der Webkit-Engine, sind aber sicher noch nicht für den Produktiveinsatz geeignet. Und sie sind auch nicht ganz unumstritten: OK, dass von Flash-Hersteller Adobe Einwände gegen zu viel Animationen in CSS kommen mussten war vorhersehbar, aber die Frage bleibt doch, wo die Präsentations-Ebene aufhört und wo die Ebene des Verhaltens von Elementen anfängt und ob man da nicht etwas vermischt, was besser getrennt bleiben sollte.
Andererseits gibt es neben fundamentalen Fehlern noch eine Menge Löcher in den CSS-Spezifikationen aller Versionsnummern, die es zu stopfen gilt. Eine ganze Reihe von Wünschen aus der Community hatten sich schon im vergangenen Jahr aus dem WaSP Community CSS3 Feedback 2008 ergeben, wie zum Beispiel die Möglichkeit, Selektoren zu gruppieren (hier die Erklärung bei Eric Meyer) oder ein wirkliches Layout-System, dass diesen Namen auch verdient.
Und das eigentliche Problem – dass sich die CSS-Arbeitsgruppe mit geradezu Gletscher-artiger Geschwindigkeit zu bewegen scheint – ist damit auch noch nicht behoben. Zum Vergleich hier eine Liste der aktuellen CSS 3-Module mit ihrem letzten Aktualisierungs-Datum: CSS3 Module Status bei CSS3.Info – da sind schon ein paar Dinge drin, die Web-Entwickler dringend bräuchten, die aber teilweise seit 2002 (!) niemand mehr angefasst hat.
Was geht?
Gut dass zumindest ein Teil der Browser-Hersteller da etwas schneller ist und Teile der Spezifikation schon fleißig implementiert. Wenn man sich von dem Mantra verabschiedet, dass Webseiten in allen Browsern 100%ig gleich aussehen müssen (müssen sie das?), dann kann man schon vieles davon verwenden, wie die folgenden Tutorials zeigen (teilweise schon was älter, aber immer noch gut):
Wenn das noch nicht reicht: hier ist eine der zurzeit ach so beliebten Top-irgendwas-Listen: »CSS3 Exciting Functions and Features: 30+ Useful Tutorials«
Im Webentwickler-Teil von Klein-Bloggersdorf gab es in den letzten Wochen mal wieder ein beherrschendes Thema: alte und neue Browser und wie man damit umgeht. Auslöser dafür war der Markt, der zurzeit erstaunlich in Bewegung gekommen ist. Während die Browser-Landschaft vor einigen Jahren noch relativ stabil schien (IE6 = 80%, die restlichen 20% geteilt durch den Rest), haben nun einige neue Spieler das Feld betreten. Was wiederum den (ehemaligen) Platzhirschen Microsoft veranlasste, den hauseigenen Browser nach jahrelanger Vernachlässigung dann doch noch mal weiter zu entwickeln.
Nicht dass wir uns falsch verstehen: der IE6 war schon ein guter Browser. Damals. Also im August 2001. Das Problem ist nicht der IE6 – das Problem ist, dass es zwischen IE6 und heute keinen anderen IE gab, der mit den neueren Browsern einigermaßen in Sachen Standard-Unterstützung mithalten konnte. Nun würden wir nicht so weit gehen, eine Abwrackprämie für Internet Explorer 6 zu fordern, aber auch hier stellt sich die Frage, wie man mit einem Browser umgeht, der, anders als Netscape 4 selig, einfach nicht verschwinden will.
Weiterlesen …
Warum verschwindet der nicht?
Das weiss keiner so genau, noch nicht mal der Hersteller. Der seit geraumer Zeit auf dem Markt befindliche Nachfolger wurde von Microsoft sogar als kritisches Sicherheits-Update eingestuft (im Juli 2006!) und selbst der Nachfolger des Nachfolgers steht schon in den Startlöchern. Und trotzdem hat sich der IE7 nicht mit der gewünschten Geschwindigkeit verbreitet. Ein Blick in die Statistiken könnte da für Erhellung sorgen: hier bei EfA liegt der IE6 am Wochenende bei ca. 5-7%; von Montags um 9h bis Freitags um 5h steigt dann der Anteil auf bis zu 12%. Das kann nur den einen Schluss zulassen: Privatnutzer sind, zumindest was die Browser angeht, Upgrade-freudiger als Sysadmins in Firmen-Netzwerken, die oft mit einer veralteten IT-Infrastruktur zu kämpfen haben [Anmerkung].
Der verbliebene IE6-Traffic am Wochenende wiederum kommt von sehr alten, ungepatchten Windows-Versionen. Hier handelt es sich offensichtlich um »ausgeliehene« Software, bei der die Aktualisierungs-Funktion unterbunden wurde um die Zwangs-(De-)Aktivierung zu umgehen. Bei diesen Rechnern braucht man sich keine Hoffnungen auf Updates zu machen – erst wenn diese auf dem Elektroschrott landen und durch Neuere ersetzt werden, kommen diese Nutzer wohl in den Genuss modernerer Browser. (Unschön ist auch, dass der relative Anstieg der Uralt-Rechner am Wochenende scheinbar mit einem massiven Anstieg an Kommentar- und E-Mail-Spam zusammenfällt. Aufgrund der zahlreichen und massiven Sicherheitslücken solcher Systeme scheint es klar, dass diese zumindest zum Teil in ferngesteuerten Botnetzen hängen, über die dieser Werbemüll verteilt wird, sobald der Rechner am Wochenende angeschaltet wird. Alte Browser machen also nicht nur bei der CSS-Entwicklung Kopfschmerzen, sondern produzieren auch an anderer Stelle erhebliche Kosten.)
Zurückzanken?
Nun könnte man angesichts dieser Zahlen auf die Idee kommen, auf seinen Seiten einen mehr oder weniger freundlichen Upgrade-Hinweis anzubringen oder dem IE6 nur noch unformatierte Seiten auszuliefern oder gleich ganz zu ignorieren. Vorschläge dafür gibt es zuhauf im Netz, bis hin zum angekündigten Webmaster-Aufstand gegen alte Internet Explorer, aber es gibt eben auch genügend Beispiele, dass so etwas schlichtweg nicht funktioniert.
Aus Sicht der Barrierefreiheit kommt das Problem dazu, dass viele Menschen mit Behinderungen auf ganz spezielle Hilfsmittel angewiesen sind. Diese sind unter Umständen hochgradig auf die individuelle Behinderung angepasst sind und funktionieren nur mit ganz bestimmten Browser-/Betriebssystem-Konfigurationen. Und solch ein System tauscht man nicht mal so eben aus wie einen Billig-PC vom Kistenschieber.
Die bessere Alternative: vom Gas gehen und langsam ausrollen lassen
Aussperren geht also nicht, das geben die Zahlen einfach noch nicht her. Also was dann?
Der oftmals zu beobachtende Zwang, dass Webseiten in allen Browsern gleich aussehen sollen heisst letztendlich, dass sie dann eben so aussehen wie im IE6, wenn dieser als kleinster gemeinsamer Nenner nach wie vor Teil der Gleichung ist – das kann es ja wohl nicht sein. Ingo Chao bringt das schön auf den Punkt:
»The current paradigm: A page has to look equal in all browsers, that is, like in IE6.«
Jens Grochtdreis von den Webkrauts meint dazu:
»Wir müssen uns von der irrigen Annahme verabschieden, wir könnten Pixelperfektion in allen Browsern garantieren. Wir müssen uns von der Annahme verabschieden, Pixelperfektion sei ein sinnvoller Wert. Vor allem Kunden und Grafiker müssen in meinen Augen lernen, daß Pixelperfektion nur im Bildbearbeitungsprogramm sinnvoll ist, aber nicht in unterschiedlichen Browsern.«
Fazit: die Versorgung des IE6 mit einem halbwegs funktionierenden Layout ist schon schwierig genug (bei all den Bugs mit dem Box Model, Alpha-Kanal-PNGs, kein min-width und kein max-width, zerstörte Layouts durch kursive Buchstaben, verschwindende oder sich wie von Zauberhand verdoppelnde Abstände, etc. pp. – um nur einige zu nennen). Da kann man als Nutzer eines solchen Browsers nicht erwarten, eine identische Darstellung geliefert zu bekommen wie Nutzer moderner Versionen von Firefox, Safari, Opera und, ja, Internet Explorer 8.
Also kann man es durchaus rechtfertigen, eine Grenze zu ziehen, ab der sich der Aufwand nicht mehr lohnt. Jeremy Keith stellt dazu bei 24 ways eine interessante Beispielrechnung auf, die allerdings (wie er auch selber bemerkt) einen entscheidenden Fehler hat: man weiss leider erst dann, wieviel Aufwand das Debugging im IE6 verursacht, wenn man mit dem Debugging fertig ist. Und das kann sich für kleine und nicht ganz so kleine Darstellungsfehler schonmal gerne von Stunden auf Tage ausdehnen.
Die Lösung ist also, einzusehen dass der IE6 ein leicht anderes Erscheinungsbild bekommt, und zwar an genau den Stellen wo er mit modernen Techniken überfordert ist. Richtig eingesetzt wird dies dem IE6-Nutzer garnicht auffallen, ausser er wechselt zwischen verschiedenen Browsern hin und her (aber dann ist er ja kein echter IE6-User mehr im Sinne dieses Gedankenspiels, sondern wahrscheinlich ein Kollege Web-Entwickler, der nur mal was testen will).
Die eine Möglichkeit, dass der IE6 mit einem Conditional Comment in Quarantäne geschickt wird, hat sich mittlerweile durchgesetzt. Wendet man die Prinzipien der ›graceful degradation‹ jedoch konsequent weiter an, so ergeben sich neue Möglichkeiten. Zur Verdeutlichung ein einfaches praktisches Beispiel:
Auf den Seiten zum diesjährigen Biene-Wettbewerb gibt es ganz unten einen Abbinder, in dem weiterführende Links aufgelistet sind. Da die vertikale Auflistung der 14 Links zu lang geworden wäre hatten wir zunächst die Liste in drei einzelne Listen aufgeteilt, diese dann in verschachtelte div gesteckt und per CSS nebeneinander aufgereiht. Das Resultat war ein fürchterlich aufgeblähter Code, der zwar in allen Browsern in etwa gleich aussah, aber kaum mehr Flexibilität z.B. bei unterschiedlichen Fenster- oder Schriftgrößen bot. Zumal sich sowas im Screenreader merkwürdig anhört, wenn diese Liste von Links nur um der Optik willen als 3 Listen mit n Einträgen vorgelesen wird.
Seit neuestem stehen diese Links wieder gemeinsam in einer Liste:
<div id="related" role="complementary"> <h2>Mehr zum Wettbewerb:</h2> <ul class="linkliste"> <li><a href="/biene-2008/gewinner/">Die Gewinner</a></li> <li><a href="/biene-2008/gewinner/fotos/">Fotos der Ausgezeichneten</a></li> […] </ul></div>
Der eigentliche Trick steht im CSS:
.award #related ul { column-count: 3; column-width: 32%; column-gap: 10px; column-rule: solid #ddd 1px; -webkit-column-count: 3; -webkit-column-width: 32%; -webkit-column-gap: 10px; -webkit-column-rule: solid #ddd 1px; -moz-column-count: 3; -moz-column-width: 32%; -moz-column-gap: 10px; -moz-column-rule: solid #ddd 1px;}
Durch das nun auch schon nicht mehr so ganz taufrische CSS3-Modul Multi-column layout wird die Liste in drei Spalten aufgeteilt (column-count: 3;); wie viele Einträge in die jeweiligen Spalten rutschen wird nun nicht mehr im Markup bestimmt, sondern da wo sowas hingehört: auf der Präsentationsebene. Zusätzlich wird den Spalten noch eine Breite zugewiesen, der Spaltenabstand festgelegt und zur besseren optischen Trennung noch eine dünne Linie dazwischen gelegt. Da CSS3 bekanntlich noch nicht fertig spezifiziert ist, muss man wie üblich noch ein paar Browser-spezifische Regeln nachschieben, aber das tut dem ganzen keinen Abbruch.
Hier sind wir dann beim Punkt graceful degradation für den IE6 angelangt: da dieser älter ist als CSS3 kann er nichts damit anfangen und stellt die Liste einspaltig dar. Was nicht weiter schlimm ist, denn der Inhalt ist nach wie vor nicht nur nutzbar, sondern auch ansprechend formatiert – nur eben nicht mehrspaltig. Dafür kommen modernere Browser in den Genuss einer höheren Flexibilität, die man zum Beispiel bei der Darstellung mit vergrößerter Schrift sehen kann: passt ein Link nicht mehr in eine Spalte rein, dann wandert er einfach komplett in die nächste Spalte. Mit der ursprünglichen Lösung aus separaten Listen in divs wäre dies nicht gegangen.
Sie glauben ja gar nicht wie befreiend das sein kann, wenn man sich von diesem Zwang verabschiedet hat, dass Webseiten in allen Browsern gleich aussehen müssen. Zum Abschluss noch eine Liste von Links, bei denen ebenfalls pro & contra IE6 diskutiert wurde:
Pro IE6:
Irgendwo dazwischen:
Contra IE6:
Anmerkung zur Statistik
Wir sind uns natürlich der Tatsache bewusst, dass auf eine solche Statistik nie 100%-ig Verlaß ist. Moderne Browser handhaben ihren Cache anders als ältere Modelle, was die absoluten Zahlen zu Gunsten der älteren Browser verschiebt. Zudem produziert der IE alleine schon deswegen mehr Anfragen am Server, weil er als einziger per Conditional Comment ein zusätzliches Style Sheet zugewiesen bekommt, in dem darüber hinaus noch eine ganze Reihe Bilder aufgerufen sind, die im ›richtigen‹ Style Sheet direkt eingebettet sind (mehr dazu hier). Dazu kommt noch das alte Problem, dass sich viele Tools (z.B. Linkscanner) oder andere Browser als IE tarnen, indem dessen user agent string benutzt wird.
Wie üblich haben uns auch beim letzten Relaunch viele Rückmeldungen und kritische Anmerkungen (und in seltenen Fällen sogar Lob) per E-Mail oder über die Kontakt- und Kommentarformulare erreicht. Zu einigen Punkten hatten wir ja bereits ausführlich was geschrieben; heute geht es um einen Teil des HTML-Codes dieser Seiten, der schon öfter Anlass zu Diskussionen war: die »Tag Cloud«, auch Schlagwort- oder Stichwortwolke genannt.
Laut Wikipedia ist eine Tag Cloud »eine Methode zur Informationsvisualisierung, bei der eine Liste aus Schlagworten alphabetisch sortiert flächig angezeigt wird, wobei einzelne unterschiedlich gewichtete Wörter größer oder auf andere Weise hervorgehoben dargestellt werden.«
Lustigerweise ist die Tag Cloud in der linken Spalte eines der wenigen Code-Fragmente, die nicht nur den letzten Relaunch, sondern auch einige Relaunches davor unbeschadet überstanden hat – das zu Grunde liegende Konstrukt hat sich also seit Jahren nicht geändert. Aber wie bei jedem Relaunch erreichen uns wohl-gemeinte Tipps, wie man diese Tag Clouds besser umsetzen und semantisch anreichern könnte (womit sich mal wieder die alte Regel bewahrheitet, dass die Menge des Diskussionsbedarfs immer umgekehrt proportional zur Komplexität des Problems ist).
Weiterlesen …
So auch diesmal:
»… die Größe eines Links in der Tag-Cloud habt Ihr ja mit "strong in strong in strong …" realisiert. Ich habe gerade mal mit JAWS etwas herumgespielt, vor allem mit dem Konfigurationsmanager, und da keine Einstellung gefunden, mit der ich mir die Anzahl der strong-Tags vorlesen lassen kann. Daher mein Tipp: Schreibt doch die Nummer der strong-Tags als Zahl in Klammern hinter den jeweiligen Link und schiebt das dann per CSS aus dem Viewport. In der Überschrift ›Themen:‹ schreibt Ihr das halt als ›(Beliebtheit als Zahl in Klammern)‹, ebenfalls versteckt, dahinter. Das ist zwar so knapp, dass man erst nicht weiß, ob der Zahlenwert mit der Beliebtheit steigt oder ob es hier umgekehrt proportional gesehen werden muss, aber das wird spätestens bei der vier für HTML klar.«
(Detlef Girke per E-Mail)
Zum Hintergrund des ganzen: unsere Tag Cloud besteht aus einer Liste von Einträgen, die alphabetisch sortiert als Unordered List (UL) angelegt sind, jeder Eintrag steht in einem separatem List Item (LI). Wir bekamen auch einige Mails mit Vorschlägen, statt der UL doch eine geordnete Liste (OL) zu nehmen – danke für die Vorschläge, aber das Kriterium zur Sortierung der Einträge ist das Alphabet – damit sind die (zusätzlichen) Ordnungszahlen komplett überflüssig und bringen dem Nutzer keine brauchbaren Erkenntnisse.
Eine Sortierung nach Häufigkeit würde ebenfalls keinerlei Vorteile für den Nutzer bringen. Zum einen wäre für den Nutzer die Orientierung entlang des Alphabets dahin; zum anderen würde sich diese Sortierung auch laufend ändern. Ein weiteres Problem bleibt dadurch ebenfalls ungelöst: in den vergangenen Jahren haben wir sehr viel über HTML & CSS gebloggt, entsprechend viele Treffer gäbe es bei einer Sortierung nach diesen Tags. Nun gibt es aber Techniken wie z.B. WAI-ARIA, die relativ neu sind und daher in Summe nicht so häufig im Blog vorkommen – aber genau von diesen Beiträgen möchten wir, dass sich unsere Leser damit beschäftigen und eine alleinige Sortierung nach Häufigkeit käme einer Abwertung gleich und ginge somit am Ziel vorbei. Im Ernstfall würde man damit höchstens den Digg-Effekt erreichen, bei dem alle User auf das Ding mit der höchsten Zahl draufklicken.
Im Urzustand sieht unsere listenförmige Tag Cloud folgerichtig so aus:
<div id="tagcloud"><h4>Themen:</h4> <ul> <li><a href="/blog/tags/ajax/" rel="tag">AJAX</a></li> <li><a href="/blog/tags/atag/" rel="tag">ATAG</a></li> [...] </ul> </div>
Allerdings ist dies noch nicht alles, und genau daran entzündet sich die Kritik: je nach Häufigkeit des Tags enthält der Link noch ein oder mehrere <strong> – je häufiger, desto mehr <strong> sind dort hineingeschachtelt:
<li><a href="/blog/tags/bitv/" rel="tag"><strong><strong>BITV</strong></strong></a></li>
Durch geschicktes Ausnutzen der Vererbungen in CSS wird der enthaltene Linktext immer größer, je öfter strong ineinander verschachtelt ist:
#tagcloud li strong { font-size: 1.1em;}
Nun bezieht sich einige Kritik darauf, dass <strong> unsemantisch sei – leider konnte uns jedoch bisher noch niemand eine echte, passendere Alternative aufzeigen. Kurzfristig hatten wir über die Verwendung von <small> & <big> zur Gewichtung der Einträge nachgedacht, aber dann davon abgesehen. Nicht weil es unpassend wäre (wobei: eventuell wäre es sogar passender und damit ehrlicher gewesen), sondern weil dies wohl einen Sturm der Entrüstung hervorgerufen hätte. Das Problem bleibt also: HTML bietet kein 100%-ig passendes Element zur semantisch korrekten Auszeichnung von Gewichtungen in Tag Clouds an. Also läuft es (wie so oft in HTML) auf eine Annäherung hinaus, die nach den Prinzipien der Einfachheit diejenige sein sollte, die am wenigsten stört (›least obtrusive‹) und dem Nutzer nichts vorgaukelt, das effektiv nicht vorhanden ist bzw. die Handhabung für den Nutzer nicht unnötig verkompliziert. Eben einfach.
Daher hatten wir uns damals nach intensivem Nachdenken für <strong> entschieden, eben genau weil mit <strong> ausgezeichneter Text in sämtlichen uns bekannten Screenreadern nicht anders vorgelesen wird als herkömmlicher Text ohne <strong> (wie übrigens bei <big> & <small> auch nicht, neben einer ganzen Reihe anderer, seit über einem Jahrzehnt spezifizierter Elemente).
Gleich mehrere Mails und IMs beschäftigten sich mit der Frage, ob man die Gewichtung dem Screenreader-Nutzer dann nicht besser durch die Ansage der Zahl der gefundenen Treffer mit diesem Tag mitteilen sollte. Auch mit diesem Vorschlag haben wir ein paar Probleme:
- Wenn die Zahlen einen Nutzwert haben sollen, dann müsste sich der Nutzer beim durchhören der Tag Cloud die Zahlen merken, dann nochmals zurückgehen und dann auf Basis der Zahlen als Entscheidungskriterium (Welcher Zahl? Der höchsten? Der niedrigsten? Dem Mittelwert?) entscheiden, welchem Link er folgt. Was aber nicht das eigentliche Problem des Vorschlags löst, nämlich:
- Warum sollte ein Nutzer einen Link anklicken, nur weil ihm die (hohe oder niedrige) Zahl irgendwie zusagt? Wenn jemand nach Tipps zu CSS sucht, dann ist es für ihn vollkommen unerheblich, ob da nun 2 oder 20 oder 200 Einträge dahinter sind. Weder wir noch der Benutzer können wissen, ob das Gesuchte gefunden wird (und zwar vollkommen unabhängig von der Anzahl; und nein, die Wahrscheinlichkeit das Gesuchte zu finden steigt nur unwesentlich mit der Zahl der verlinkten Blog-Beiträge).
Die wesentliche Information ist auch jetzt schon der verlinkte Text (›BITV‹, ›CSS‹, …), alles darüber hinaus wäre nicht Beiwerk oder zusätzlicher Komfort, sondern akustischer Müll. Wir glauben nicht, dass allzu viele Nutzer zu EfA kommen nur um nachzulesen, wie viel wir über ein bestimmtes Thema berichten – das ist vielleicht später mal für Archäologen interessant, aber nicht hier und jetzt für die Nutzer, die sich über bestimmte Themen informieren wollen.
Daher können wir auch den Nutzwert einiger Tutorials nicht nachvollziehen, die man zu dem Thema im Netz findet. Mark Norman Francis hatte im Dezember 2006 im Adventskalender von 24 ways eine Anleitung veröffentlicht, die nach seiner Auffassung alle Probleme löst und somit absolut barrierefrei zugänglich sei. Im fertigen Code-Beispiel stehen zusätzliche Informationen über die Anzahl zwar im HTML innerhalb des Links, diese werden aber per CSS aus dem Viewport geschoben.
In die gleiche Richtung geht ein neuerer Artikel »Semantische Tag Cloud« im SELFHTML aktuell Weblog, auf den Wolfgang Wiese per IM hinwies: auch hier werden zusätzliche (für grafische Browser wiederum versteckte) Infos wie »eher selten«, »ausgesprochen häufig«, usw. in die Tag Cloud geschrieben – allerdings ausserhalb der Links:
<ul> […] <li><span style="font-size:169%"><a href="linkziel">Arzt-Suchdienst</a></span><span class="ignore"> ausgesprochen häufig</span></li> […]</ul>
Leider zeigen beide Ansätze bei genauerem Hinsehen, dass sie wohl kaum mit echten Screenreader-Nutzern getestet sein können, denn beide Ansätze haben grundsätzliche Probleme:
- Entweder lässt der Screenreader-Nutzer sich das alles vorlesen – dann steigt der Nutzer nach unserer Erfahrung ob der Menge der unnützen Zusatzinfos nach der Hälfte der Tag Cloud aus; oder
- Der Screenreader-Nutzer tabbt durch die Tag Cloud (von Link zu Link) – dann wiederum bleibt ihm die Zusatzinfo verborgen, wenn diese ausserhalb der Links steht. Und nein, die Infos in die Links selbst reinzuschreiben ist wie gesagt auch keine Lösung, weil dann wieder Punkt 1 greift.
Und deswegen ist die Tag Cloud so wie sie ist.
Nachtrag:
(Tipp von Rainer Schlegel via E-Mail)
Content-lastige Angebote wie das unsrige bestehen in der Regel immer aus der Navigation und dem wesentlichen Inhalt der jeweiligen Seite. Egal wo die Seite innerhalb der Struktur der Website angesiedelt ist – der Nutzer will immer nur eins von beidem: entweder weiternavigieren oder den Inhalt lesen. Daher sollte es mittlerweile zum guten Ton gehören, insbesondere dem Tastaturnutzer über sog. Skip-Links die Möglichkeit zum direkten Anspringen der wesentlichen Unterbereiche einer Seite zu geben. Screenreader-Nutzern erspart man so, sich immer wieder die gesamte Navigation anhören zu müssen, wenn man nur zum Artikel will.
Weiterlesen …
Drück mich, ich bin ein Skip-Link
Bereits vor dem aktuellen Relaunch hatten wir hier diese Skip-Links eingesetzt, mit denen der Navigations- und der Inhaltsbereich direkt angesprungen werden kann. Die Umsetzung ist denkbar einfach: unmittelbar nach Logo & Claim der Initiative folgen zwei Links zu Zielen innerhalb der Seite:
<a class="skip" href="#navigation">Zur Navigation</a><a class="skip" href="#inhalt">Zum Inhalt</a>
Diese sind per CSS ausgeblendet, allerdings nicht per display: none; komplett versteckt. Dies würde in den meisten Screenreadern dazu führen, dass die Inhalte dieser Links wirklich weg sind und dementsprechend nicht vorgelesen werden. Stattdessen haben wir die Links um einen Wert aus dem Viewport geschoben der garantiert, dass diese in grafischen Browsern nicht sichtbar sind:
a.skip { position: absolute; left: -1000em; top: -1000em; height: 1px; width: 1px;}
Die Dopplung von left: und top: scheint auf den ersten Blick unnötig, aber ohne die zusätzliche Angabe eines Wertes für top: funkte uns der Mac-Safari dazwischen und verschob beim Durchtabben die gesamte Box mit dem Header um die Höhe des Skip-Links nach oben.
Sobald der Nutzer nach dem Laden der Seite die Tab-Taste drückt, werden nun die Links der Reihe nach wieder in den sichtbaren Bereich geschoben. Dort verbleiben sie, bis der Nutzer einen der Links per Enter auslöst (draufklicken geht natürlich auch) oder weitertabbt:
a.skip:focus,a.skip:active { position: absolute; z-index: 1; top: 4px; left: 4px; height: auto; width: auto; color: #000; background-color: #eee; outline: 1px solid #999;}
Da sich die Links innerhalb eines (relativ) positionierten Elementes befinden, beziehen sich die Positionswerte für das position: absolute; auf das positionierte Eltern-Element – in diesem Fall also auf den Block mit dem #header dieser Seiten, von dessen oberer linker Ecke um 4px versetzt die Links erscheinen sollen.
Tipp: wenn Sie mehr als zwei, höchstens drei Sprungmarken brauchen, damit ihre Seite überhaupt bedienbar ist, dann haben Sie eventuell ein strukturelles Problem. Dies lässt sich nicht durch die Hinterlegung von einem Dutzend weiterer Skip-Links lösen, sondern nur indem Sie das strukturelle Problem selbst beheben.
Der obligatorische IE-Bug …
… darf natürlich auch nicht fehlen: Die Ziele der Links müssen in Elementen liegen, die die Eigenschaft hasLayout=true (in VisualBasic-Diktion also −1) besitzen, sonst wandert der Fokus nicht mit, sondern verbleibt am Ursprung (beim nächsten Tastendruck wäre der Nutzer also wieder im Kopfbereich der Seiten). Wir erreichen dies hier, indem nur Block-Level-Elemente mit einer ID angesprungen werden, die in der Datei iehacks.css ein lockeres zoom: 1; verpasst bekommen.
Bonus-Trick
Nun nützt es dem Tastaturbediener nichts, wenn er nicht sieht, wo er denn hingesprungen ist. Daher setzen wir seit neuestem für viele lokale Sprungmarken innerhalb dieser Seiten den :target-Pseudo-Selektor aus CSS 3 ein, der schon von vielen modernen Browsern unterstützt wird. Sobald eine beliebige ID angesprungen wird, färbt sich deren Hintergrund ein und hebt diese damit auf der Seite hervor:
*:target { color: #fff; background-color: #8fa6b8;}
Eine noch deutlichere Visualisierung der Sprungziele fanden wir auf den Seiten der schwedischen Hauptstadt http://stockholm.se/: dort werden per JavaScript & CSS die anzuspringenden Ziele mit einer gestrichelten Umrandung hervorgehoben – eine sehr gut gemachte Erleichterung für Tastaturnutzer, wie wir finden.
Nachtrag: Dirk Ginader hat dazu prompt was schönes gebastelt: »jQuery skipnavHighlight - Skip-Link-Ziele Anschaulich machen« (skipnav-demo).
P.S.: Mehr zum Thema Tastaturbedienung finden Sie in unserem Artikel »›Oops, wo bin ich?‹ – Ein Herz für Tastaturnutzer« und in der »BITV-Bedingung 13.6 - Gruppierung und Umgehung von Linkgruppen« sowie im Podcast vom 31. August 2006: »Viel hilft viel?«.
Kein Laborbericht, sondern nur eine kurze Statusmeldung: Wir haben in den letzten Tagen eine ganze Reihe Fleißaufgaben und Bugs abgearbeitet, den Code weiter aufgeräumt und ein paar Dinge eingebaut, die noch auf der To-Do-Liste standen. So sind jetzt alle Codelistings auf einen einheitlichen Stand gebracht – schön zu sehen z.B. in der Tabellenserie. Dann haben wir noch ein Lightbox-Skript nachgerüstet, mit dem größere Grafiken und Bilder angezeigt werden können – zu sehen z.B. in der BITV-Serie. Verwendet haben wir das Skript Thickbox 3.1, da sich die Bilder hier im Gegensatz zu vielen anderen Lightbox-Skripten auch per Tastatur wieder schliessen lassen.
Und weil das so viele Änderungen waren gibt es auch eine neue Version unserer Style Sheets zum Download. Wie immer mit sehr viel erklärender Prosa in den /* Kommentaren */.
Neben den in der letzten Folge behandelten CSS-Dateien gibt es selbstverständlich auch bei den verwendeten Grafiken erheblichen Optimierungsbedarf. Auch hier gilt: so viele und so groß wie nötig und so wenige und so klein wie möglich.
Aber flott, ey!
Dabei geht es nicht nur um die reinen Dateigrößen: eine übermäßige Anzahl von Grafikdateien in einer Seite wird den Aufbau schon alleine wegen des Overheads für Anfrage und Versand der Dateien merklich verlangsamen. Daher setzen wir seit dem Relaunch die sog. CSS-Sprite-Technik ein, bei der verschiedene Grafiken je nach Verwendungszweck gruppiert und zu einer Datei kombiniert werden, die dann immer nur in Ausschnitten angezeigt wird.
Ein Beispiel: in der Hauptnavigation unserer Seiten verwenden wir Ordnungszahlen in Form von Grafiken. Jeder dieser fünf Navigationspunkte hat drei Zustände – nach Altväter-Art wären dies 15 GIFs gewesen, jedes auf einen andersfarbigen Hintergrund geglättet. So hätte der Browser 15 Dateien anfordern müssen, der Server hätte diese 15 Dateien verschicken müssen, und alle hätten sich nacheinander durch die Leitung gedrängelt.
Da die Ziffern aber eigentlich halbtransparent sind und sich zwei der drei Zustände nur durch die (durchscheinende) Hintergrundfarbe unterscheiden, kann man sich die Arbeit sparen und die Grafiken gleich als 24 bit-PNGs mit Alphakanal ablegen. Wenn man diese dann zu einer Datei kombiniert, hat man die o.g. Sprites, die per CSS auf die Höhe der Zeilenbox beschnitten und verschoben werden (hier die Grafikdatei: oz.png). Resultat: 14 gesparte Anfragen an den Server und ein paar Zeilen mehr CSS-Code. Das ›mehr‹ an Dateigröße für die höhere Farbtiefe ist im Endeffekt eigentlich eine erhebliche Ersparnis.
Auch diese Technik hat ihre Grenzen: sämtliche Bilder müssen zur Darstellung entkomprimiert werden und hinterlassen unter Umständen einen ganz ordentlichen Fußabdruck im Arbeitsspeicher. Gerade bei mobilen Endgeräten ist Vorsicht geboten, da zu große Grafiken evtl. nicht in den spärlichen Cache des Geräts passen und immer wieder neu angefordert werden müssen.
Ähnlich verhält sich dies bei den Piktogrammen, mit denen Seitenbereiche gekennzeichnet werden – diese sind zwar ebenfalls 24 bit-PNGs mit 8 bit-Alphakanal und damit wesentlich größer als 8 bit-GIFs oder PNGs mit begrenzter Farbpalette, aber auf Grund ihrer Transparenz sind sie universell auf beliebigen farbigen Hintergründen verwendbar (z.B.: navicons.png).
Ganz anders beim EfA-Logo – dies ist zwar auch freigestellt auf transparentem Hintergrund mit einem leichten Schlagschatten zur rechten Seite, als 24bit-PNG würde es aber mit über 20 kb zu Buche schlagen (s. logo-efa-32bit-Photoshop.png) – eindeutig zu viel des Guten. Allerdings sollte das Logo für die Druckversion wiederverwendet werden – und zwar ohne eine neue Datei anzufordern, nur um diese auf weissem Hintergrund darstellen zu können. Hier kommt der Bildeditor Fireworks zur Hilfe, der im Gegensatz zu Photoshop auch 8 bit-PNGs mit Alphatransparenz exportieren kann. Mit einem gefühlten Aufwand von zwei Minuten konnte hier die Dateigröße auf knapp über 6 kb reduziert werden (bei nahezu identischer Qualität, vgl. logo-efa-8bit-Fireworks.png).
Ein weiterer Vorteil der Bearbeitung in Fireworks ist, dass selbst der IE 6 auf einmal die Transparenz im Rahmen seiner Möglichkeiten sauber darstellt, statt wie bei 24 bit-PNGs in einem grauen Kasten. Hier die Darstellung links im Safari, rechts im IE 6:
Die in vielen Anleitungen zu findende Empfehlung, dem IE 6 über den AlphaImageLoader-Filter auf die Sprünge zu helfen hat zwei gravierende Nachteile: zum einen fuktioniert dieser Filter nach unserer Erfahrung nicht bei CSS-Sprites, und zum anderen geht dadurch die Performance der Seite in den Keller (mehr noch im IE 6 als im IE 5.x – ersterer hat die Angewohnheit, dieses Skript bei 20 Bildern auch 20× auszuführen, was einer Zeitstrafe von ca. 1/10 Sekunde pro Bild entspricht).
Zum Schluß werden die Grafiken noch durch einen Optimierer wie Pngcrush (DOS, Unix) oder PNGThing (Mac) geschickt, um überflüssige Metadaten zu entfernen und die Dateigröße noch weiter zu reduzieren. Aber das war noch nicht alles:
Bilder ins CSS schreiben? Geht doch gar nicht!
Doch, geht: ein Teil der Grafiken liegt hier nicht mehr als Grafikdatei auf dem Server, sondern ist per data: URI direkt in das Style Sheet ›eingebettet‹. Dies spart wieder eine Menge Datenverkehr, da die Bilder nicht mehr während der Verarbeitung des Style Sheets vom Server angefordert werden müssen, sondern bereits vorliegen. Im CSS sieht das wie folgt aus – hier ein Beispiel für das grafische Bullet bei List Items (
):
ul li { list-style-image: url(data:image/png;base64,iVBORw0KGgoAAA
ANSUhEUgAAAAYAAAAHCAQAAACBmfRmAAAAKUlEQVQI12OYKDWxY
eJVIGyYKMUAJP5DYQMDUAzGuYrGQVGGbMB%2FJAgAx7o1X3W50i
UAAAAASUVORK5CYII%3D);}
(Tipp: Ian Hickson stellt unter The data: URI kitchen ein Browser-basiertes Tool zu Verfügung, das Grafikdateien entsprechend konvertiert; weitere Beispiele für diese Technik finden Sie in den kommentierten Style Sheets, die wir unter Downloads veröffentlicht haben.)
Einen Nachteil hat die Methode: die Internet Explorer bis einschließlich Version 7 versteht sie nicht (wer hätte das gedacht!). Da wir aber per Conditional Comment ein separates IE-Style Sheet eingebunden haben, um dessen zahllose Bugs zu umschiffen, kommen die Aufrufe nach herkömmlicher Art einfach dort hinein und alle sind zufrieden:
ul li { list-style-image: url("/img/chrome/list-item.png");}
Wenn Sie mehr über den Trendsport Extrem-Optimizing wissen wollen haben wir hier noch ein paar lehrreiche Links aus dem Yahoo! User Interface Blog:
Nachtrag: Mehr zu Grafikformaten ganz aktuell im Atzventzkalender der Webkrautz: »Das richtige Grafikformat für den richtigen Zweck«.
Need for Speed
So ein Relaunch ist auch immer wieder die Gelegenheit, sich über die Performance der Seiten Gedanken zu machen. Die Flaschenhälse sind hier in der Regel nicht die Server und Clients, sondern der Transport zwischen den beiden. Heutige Desktop-Computer und Laptops haben mittlerweile so viel überschüssige Rechenleistung und auch Web-Server sind im Normalfall ausreichend dimensioniert, dass man sich im Gegensatz zu den Anfangstagen des Webs keine Gedanken mehr machen muss, ob ein Client vielleicht mit einem bestimmten Seitengewicht überfordert sein könnte.
Moderne Browser sind zudem mittlerweile so schnell mit der Verarbeitung von HTML & CSS & JavaScript (ok, mit Ausnahme von Firefox 2), dass man diesen ruhig ein wenig Rechenleistung in Form von aufwändigeren Layouts und Client-seitigen Funktionen abverlangen kann.
Was aber nach wie vor gilt ist, dass die Dateien für den Versand möglichst klein und die Anzahl der Pakete möglichst gering gehalten werden sollte. Viel mehr als ein zusätzliches div hier und da im HTML fallen ausschweifende Formatierungen im Quelltext und unnötige Kommentare ins Gewicht. Ähnliches gilt auch für unsere Style Sheets: in der Entwicklungsversion sind die Formatierungsanweiungen auf fünf Dateien verteilt, die zusammengenommen über 90 Kilobyte wiegen – klar dass sowas nicht im Live-Betrieb auf den Server gehört. Die fünf einzelnen Anfragen an den Server würden schon alleine eine messbare Verzögerung ergeben, und die gesamten Kommentare und Formatierungen interessieren den Browser bei der Verarbeitung der Style Sheets nicht im geringsten – sie sind also unnötiger Ballast.
Weiterlesen …
Daher gibt es im Live-Betrieb nur noch drei Style Sheets – eines für die Monitor-Darstellung, ein Print-Style Sheet und eine Datei mit den leider nach wie vor notwendigen Hacks Extrawürsten für Internet Explorer Version 5-7. Bereinigt um Kommentare, Einrückungen etc. wiegt das Screen-CSS auf einmal nur noch 24 Kilobyte, und wenn Server und Client sich auf einen Datenaustausch in gezippter Form verständigen können (die weitaus meisten Browser beherrschen dies), dann ist das CSS am Ende nur noch 6 Kilobyte groß.
Bei einem aktuellen Rechner an einer DSL-Leitung macht das den Unterschied zwischen 2 und 3 Sekunden bis zur fertig dargestellten Seite – immerhin ein Drittel, aber nichts weltbewegendes. Für das knappe Viertel aller Besucher, die wir immer noch per Modem oder ISDN begrüssen dürfen fällt dieser Unterschied aber umso mehr ins Gewicht.
Geblitzt
Handelsübliche Browser (zumindest solche, die man als Webentwickler auf der Platte haben sollte) haben mittlerweile eingebaute oder per Erweiterung nachrüstbare Tools, mit denen man die Performance der eigenen Seiten testen kann (und sollte). Im Safari ist dies der Web Inspector, der sämtliche Dateien die zur Darstellung einer Seite benötigt werden mitsamt ihren Dateigrößen und Ladezeiten in einem Wasserfall-Diagramm darstellt.
Für Firefox-User gibt es etwas vergleichbares in Form von Firebug in Verbindung mit der YSlow-Erweiterung. Ebenfalls hilfreich ist hier das Pagetest-Tool von AOL, das unterschiedliche Geschwindigkeiten von fetten 20 Mbit bis zu einem langsamen 56k-Modem simulieren kann.
Ganz zum Schluss der Entwicklung durchlaufen die Style Sheets dann noch die geniale Firefox-Erweiterung Dust-Me Selectors von James ›Brothercake‹ Edwards, um unbenutzte CSS-Regeln aufzuspüren. Diese haben die Eigenschaft, sich im Laufe der Entwicklung anzusammeln und können in der Regel gefahrlos entsorgt werden. Besonders hilfreich bei großen Angeboten ist die Funktion, die gesamte Website anhand einer sitemap.xml automatisch abzugrasen:
P.S.: Was unsere heutige Folge mit der Barrierefreiheit zu tun hat? Nichts, aber auch das gehört zu einem professionell gemachten Webangebot.
Wie versprochen dokumentieren wir hier in loser Folge, was zu unserem aktuellen Relaunch geführt hat und wie die technischen und gestalterischen Hintergründe sind. Den Anfang machen wir mit der Veröffentlichung einer ausführlich kommentierten Fassung der ›Cascading Style Sheets‹ (Formatvorlagen), die Sie ab sofort auf der Seite Downloads finden.
Ein wesentlicher Unterschied der Download-Version zu der optimierten Live-Version sind die ausführlichen Kommentare im Quelltext. Dort finden Sie auch die Begründungen für Workarounds und weiterführende Links zu verbreiteten und nicht ganz so verbreiteten Browser- und Screenreader-Bugs. Falls Sie weitere Verbesserungsvorschläge haben würden wir uns freuen von Ihnen zu hören.
Übrigens: dass unsere Style Sheets formal nicht validieren ist vollste Absicht! Zum einen verwenden wir schon einiges aus dem noch nicht fertig spezifizierten CSS Level 3 – wenn man den CSS-Validator ausdrücklich drauf hinweist, dann verschwinden diese Fehler wie von Zauberhand. Zum anderen verwenden wir sog. ›vendor-specific extensions‹, um Browsern auf die Sprünge zu helfen, die diese (übrigens im im CSS-Standard genau dafür vorgesehen!) Erweiterungen benötigen, um z.B. neue Selektoren in der Praxis zu testen.
Bitte beachten Sie, dass unsere Style Sheets unter einer Creative Commons-Lizenz stehen. Das heisst: anfassen – ja; mitnehmen und 1:1 woanders verwenden – bitte nicht. Alles weitere dazu finden Sie in der Lizenz. Da unser CSS auf dem YAML-Framework basiert, darf der Hinweis auf dessen eigenständige Lizenzbedingungen und die ausführliche Dokumentation natürlich auch nicht fehlen.
Für Webentwickler bedeutete die Umstellung von Tabellen auf CSS, dass sie alte Gewohnheiten vergessen mussten. Sämtliche Techniken und Kniffe aus den Zeiten von Layout-Tabellen sind scheinbar »verlernt«. Das richtige Umsetzen echter Datentabellen erfordert jedoch eine Rückbesinnung: man muss sich wieder mühsam in die Spezifikationen einlesen und in das Tabellenmodell von HTML hineindenken.
Wie man tabellarische Daten so aufbereitet, dass sie nicht nur hübsch aussehen, sondern auch mit den assistiven Programmen von Menschen mit Behinderung optimal nutzbar sind erfahren Sie in unserer neuen Serie: »Benimmregeln für Datentabellen«
Wie man zugängliche Werbebanner erstellt wird im Web Access Centre Blog des RNIB erklärt: »Accessible banner adverts« für statische Banner und »Accessible Flash banner ad guidelines« für die interaktive Variante. (via)
Jede Menge Accessibility-Tipps gibt es in mundgerechte Häppchen verpackt bei Mike Davies unter accessibilitytips.com.
Wenn dann noch Appetit auf mehr herrscht, dann empfehlen wir das »Accessibility Tutorial« bei webucator.com, einer überarbeiteten Version des Tutorials von Accessibility-Urgestein Jim Thatcher. Die Grundlagen sind zwar auf den amerikanischen Markt und die §508 zugeschnitten, aber die praktische Umsetzung ist ja dieselbe.
Ebenfalls brauchbar:
Damit keiner mehr sagen kann es gäbe keine brauchbaren Anleitungen …
Gesammelte Werke mit CSS:
