accessBlog

Testen mit Hilfsmitteln

In den vergangenen Jahren gab es einiges an Bewegung im Markt für Computer-Hilfsmittel für Menschen mit Behinderung. Besonders liess sich das bei den Screenreadern beobachten: wo bisher ein oder zwei führende Produkte den Markt dominierten, gibt es nun wesentlich mehr Auswahl, die auch professionellen Ansprüchen genügt. Noch vor einigen Jahren konnte man mit Sicherheit davon ausgehen, dass der Screenreader JAWS 75% oder mehr des Marktes besetzte (mit, je nach Land, einem Zweitplatzierten wie zum Beispiel Cobra / Virgo / Blindows in Deutschland, SuperNova / HAL in Großbritannien oder Window-Eyes in den USA). Nun stehen den Nutzern wesentlich mehr Optionen zur Verfügung.

Das Erscheinen von kostengünstigen oder sogar freien Open-Source-Anwendungen wie NVDA oder SAToGo und Screenreadern, die gleich mit dem Betriebssystem installiert werden (wie VoiceOver unter Mac OS X & iOS oder Orca für Gnome) bedeutet für die Nutzer, dass nun mehr Menschen Zugang zu den Medien haben, die ihnen vorher aufgrund der hohen Kosten kommerzieller Hilfsmittel versperrt waren. Es bedeutet aber auch für Entwickler von Webangeboten, dass mit einer größeren Anzahl von Browser-/Hilfsmittel-Kombinationen getestet werden muss als nur mit dem sprichwörtlichen JAWS-Nutzer mit Internet Explorer und Windows XP.

Weiterlesen …

Das Problem bei der Erstellung einer Test-Matrix und der Priorisierung von Tests (und Reparaturen!) ist, dass Hilfsmittel-Hersteller traditionell nicht über Marktanteile und die Anzahl der ausgelieferten Produkte reden. Wir müssen uns hier also auf Beobachtungen, grobe Schätzungen, Hörensagen und Anekdoten verlassen.

Umfragen wie der WebAIM Screen Reader Survey von Ende 2010 unterstützen die Annahme einer Verschiebung im Markt. Die Befragung ergab, dass der Anteil von JAWS auf 59% gefallen ist (von über 75% vor zwei Jahren), VoiceOver und NVDA kletterten auf jeweils 10%. Ebenfalls interessant ist die Erkenntnis, dass 80% der Nutzer ihr Hilfsmittel innerhalb eines Jahres auf eine neuere Version aktualisiert hatten und dass 98,4% aller Nutzer JavaScript aktiviert haben.

Internet Explorer dominiert weiterhin mit 63,5%, allerdings waren dies noch vor einigen Jahren nahezu 100%. Nach wie vor ist der Marktanteil unter Menschen mit Behinderung jedoch signifikant höher als in der allgemeinen Nutzerschaft. Firefox wird mittlerweile zu 23,5% zusammen mit Hilfsmitteln benutzt, Safari kommt auf 9,6%.

Hilfsmittel am Arbeitsplatz

Man kann mit Sicherheit davon ausgehen, dass die teureren kommerziellen Produkte vorzugsweise am Arbeitsplatz genutzt werden, was folgende Testszenarien ergibt:

JAWS v.12 – www.freedomscientific.com

• Internet Explorer (beste Unterstützung, obwohl moderne Techniken wie WAI-ARIA wesentlich von der Implementierung in anderen Browsern wie Firefox abweichen. Zudem können dynamische Änderungen des Inhaltes je nach Art der Umsetzung immer noch zu Problemen in der Nutzbarkeit mit Hilfsmitteln führen)
• Firefox (nahezu auf Augenhöhe mit IE, mit teils besserer Unterstützungen für AJAX und ARIA)
• Google Chrome (befriedigende Unterstützung mit aktuellen Versionen wie Chrome 12)
• Opera (keine Unterstützung)

SuperNova (früher Hal) v.12 – www.yourdolphin.com

• IE (Unterstützung vergleichbar mit JAWS, allerdings versteht SuperNova noch keinen WAI-ARIA-Markup)
• Firefox (solide Unterstützung, ebenfalls kein WAI-ARIA)
• Chrome (Unterstützung unbekannt)

Window-Eyes v.7.5 – www.gwmicro.com

• Marktanteile & Verbreitung unbekannt

ZoomText v.9.1 – www.aisquared.com

• IE (vollständige Unterstützung)
• Firefox (vollständige Unterstützung)
• Chrome (wird laut Hersteller Ai Squared nicht unterstützt)

Dragon v.11.5 – www.nuance.com

• IE (vollständige Unterstützung)
• Firefox (vollständige Unterstützung)
• Chrome (wird laut Google nicht unterstützt)

Hilfsmittel im privaten Bereich

Die Tatsache dass eine Kombination aus Screenreader & Braillezeile gerne mit 5.000 € zu Buche schlägt lässt die Vermutung zu, dass Nutzer im privaten Bereich eher zu kostengünstigen oder freien Lösungen greifen. Daraus ergeben sich die folgenden Testszenarien:

Apple VoiceOver (Bestandteil von Mac OS X für Desktop- und iOS für Mobilgeräte) – www.apple.com

• Safari (gute Unterstützung, innovativ in einigen Bereichen, in anderen mit deutlichen Lücken)
• Chrome (teilweise Unterstützung, besonders bei Formularen »buggy«, wird allerdings häufig aktualisiert)
• Firefox (leider keine Unterstützung)

NVDA (Windows) – www.nvda-project.org

• Firefox (vollständige Unterstützung)
• Google Chrome (befriedigende Unterstützung mit aktuellen Versionen wie Chrome 12)
• Internet Explorer? (hervorragende Unterstützung der UI Automation API unter Windows 7, obwohl man argumentieren könnte, dass Nutzer, die einen OpenSource-Screenreader benutzen eher nicht den IE verwenden und stattdessen auf einen OpenSource-Browser setzen)

Orca (Linux/Gnome) live.gnome.org/Orca

• Firefox (vollständige Unterstützung unter Linux)

Serotek System Access To Go (SAToGo) www.serotek.com

• Web-basiert, Marktanteil & Nutzung unbekannt

Die Ebene der Browser

Schaut man sich nun die Browser-Statistiken von Diensten wie StatCounter an, so sieht man den selben Trend in der allgemeinen Nutzerschaft wie bei den Nutzern von Hilfsmitteln: die Anteile von IE fallen, alternative Browser wie Firefox, Chrome & Safari steigen. Sogar relativ aktuelle Versionen von IE verlieren Anteile (IE8 zurzeit runter auf 28% von 38% im Januar 2011). Wenn wir die verschiedenen Browser- bzw. Rendering-Engine-Kombinationen zusammenfassen, bekommen wir 47% für alle IE zusammengenommen, Firefox ist relativ stabil bei 22% und Safari bei 9% (Werte gerundet). Den stärksten Anstieg verzeichnet Google Chrome, der sich von 7% im Januar 2010 auf 21% im Juni 2011 hochgearbeitet hat.

Die Statistik hier bei ›Einfach für Alle‹ ergibt folgendes Bild:

Hilfsmittel-Schluckauf

Man kann aus den Testergebnissen mit einer bestimmten Browser-/Hilfsmittel-Kombination leider nicht ableiten, dass der getestete Code genauso funktioniert, wenn man ihn mit dem gleichen Hilfsmittel und einem anderen Browser oder mit dem gleichen Browser, aber unterschiedlichem Hilfsmittel benutzt. Ein Beispiel soll das illustrieren:

Nach der HTML-Spezifikation kann man einem Formular-Element mehrere Label per <label for="#ID"> zuweisen – ein Feature das zum Beispiel bei Fehlermeldungen oder erläuternden Texten in einem komplexen Formular durchaus sinnvoll sein kann. Das Verhalten solcher mehrfachen Labels ist in den gängigen Desktop-Browsern wie erwartet: alle Labels sind klickbar und steuern bzw. fokussieren die zugeordneten Formularelemente. Allerdings geben sämtliche uns bekannten Screenreader immer nur ein Label aus: je nachdem welche Browser-/Hilfsmittel-Kombination benutzt wird ist dies entweder das erste oder das letzte Label, da es weitgehend abhängig von Browser ist, welche Information an das Hilfsmittel durchgereicht wird. Dies kann zum Verlust von Informationen oder mangelnder Funktionalität führen, wenn ein Formular nicht in allen relevanten Kombinationen durchgetestet wurde.

Unterschiede bestehen sogar innerhalb einer Familie von Rendering Engines, wie ein anderes Beispiel belegt: Sowohl Apple Safari als auch Google Chrome basieren beide auf der Webkit-Rendering-Engine. Ein einfacher Test mit dem neuen Outline-Algorithmus von HTML5 zeigt, dass Überschriften-Ebenen unterschiedlich interpretiert werden (in diesem Fall macht Chrome es richtig; Safari macht es falsch und zeigt die inneren, verschachtelten H1 in der gleichen Größe wie die äußeren H1).

Auch der umgekehrte Fall ist möglich: Google hat dem Vernehmen nach einige Accessibility-Features aus Webkit wieder ausgebaut, die in Safari reibungslos funktionierten.

Schlussfolgerung

Alleine die Anzahl der Nutzer alternativer Kombinationen sollte bereits umfassendere Tests als nur mit einem Browser rechtfertigen. Nimmt man dann noch die Tatsache hinzu, dass die Ausgabe von Browser zu Browser erheblich abweicht (selbst wenn man identische Screenreader benutzt), dann bekommt man sehr schnell eine relativ umfassende Matrix von Testdurchläufen. Ein minimaler Satz sollte also die folgenden Kombinationen beinhalten:

JAWS (aktuelle Version & aktuelle Version minus 1)

• IE/Win 7/8/9 (v.10 ist kurz vor fertig) – diese Kombination sollte ca. ⅔ aller use cases im Bereich blinder Nutzer abdecken
• Firefox,l,l/Win (aktuelle Version & aktuelle Version minus 1)
• Chrome/Win (jeweils die aktuelle Version, ältere Versionen unnötig wegen automatischen Updates)

ZoomText (aktuelle Version & aktuelle Version minus 1)

• IE/Win 7/8/9
• Firefox/Win (aktuelle Version & aktuelle Version minus 1)

Dragon (aktuelle Version & aktuelle Version minus 1)

• IE/Win
• Firefox/Win (aktuelle Version & aktuelle Version minus 1)

NVDA (jeweils die aktuelle Version)

• Firefox (aktuelle Version & aktuelle Version minus 1)
• Chrome (aktuelle Version, ältere Versionen unnötig wegen automatischen Updates)

VoiceOver (jeweils die aktuelle Version)

• Safari (aktuelle Version unter Mac OS X & iOS)

Warum ›Einfach für Alle‹ nicht valide ist

Immer wieder erreichen uns Anfragen, warum der Webauftritt von ›Einfach für Alle‹ nicht gegen HTML 4 und CSS 2 validiert. Die Antwort ist einfach: Barrierefreiheit ist uns wichtiger als valider Code. EfA setzt auf neue Techniken aus der WAI-ARIA-Spezifikation des W3C, um die Zugänglichkeit unseres Angebots zu verbessern.

Der letzte Arbeitsentwurf der WAI-ARIA stammt vom 15. Dezember 2009. Ähnlich wie bei HTML5 gelten einige der Spezifikation schon als stabil und werden von aktuellen Browsern und Hilfsprogrammen unterstützt.

WAI-ARIA erlaubt unter anderem das Definieren von Orientierungspunkten einer Website: Wichtige Elemente wie die Navigation oder der Inhaltsbereich können eindeutig benannt und angesteuert werden. Bei Formularen erlaubt WAI-ARIA das eindeutige Kennzeichnen von Pflichtfeldern. Die endgültige Version der WAI-ARIA sieht auch das Steuern von Schiebereglern und die Verwendung komplexer AJAX-Anwendungen vor.

Diese Eigenschaften werden auch von aktuellen Browsern wie dem Firefox 3, dem Screenreader Jaws 10 und einigen anderen Browsern und Hilfsprogrammen unterstützt. Auch das am 1. Februar 2010 gestartete neue Portal der Aktion Mensch verwendet bereits WAI-ARIA.

Die derzeit aktuellen Versionen von HTML – HTML 4.01 und XHTML 1.0 – kennen die WAI-ARIA noch nicht, deshalb lassen sich unsere aktuellen Websites nicht validieren.

Opera auf Uni-Tournee

Der norwegische Browser-Hersteller Opera war schon immer für Innovationen bekannt, die irgendwann ihren Weg in die anderen Browser fanden. Damit das weiter so bleibt, will Opera die nächste Generation von Führungskräften in der IT-Industrie erreichen und hält dazu Seminare an Hochschulen auf der ganzen Welt. Dabei geht es um die Geschichte und die Zukunft des Webs, die Browser-Industrie, offene Web-Standards, Web-Anwendungen und die Rolle der Webs und der mobilen Nutzung insbesondere in den Entwicklungsländern.

Studenten können so neue Perspektiven auf Technologie-Trends gewinnen, in Podiumsdiskussionen direkte Fragen an Operas Software-Entwickler und Produktmanager stellen und sich mit Führungskräften der IT-Branche vernetzen. Nach über 80 Seminaren in 10 Ländern gibt die Opera University Tour nun ihr Gastspiel in Deutschland.

Weiterlesen …

Termine

Neues in der Werkzeugkiste

Opera

Opera 10 ist ab sofort ohne ›beta‹ und ›release candidate‹ dahinter als fertige Version erhältlich (Download, alternativ per FTP, Packungsbeilage). In der neuen Version ist die WAI-ARIA-Unterstützung ausgebaut worden; viele Neuerungen gab es auch im Bereich CSS – allerdings nur bis zur Version 2.1 (inklusive der HSL- und RGB-Farbräume mit Alpha-Transparenz und Web-Fonts mit @font-face); weitergehende Dinge aus CSS 3 wie das CSS-Column-Modul oder multiple Hintergrund- und Rand-Bilder sind offenbar noch nicht implementiert. Was sonst noch alles neu ist erklärt Chris Mills in der Opera Developer Community: »The Opera 10 experience«, oder im YouTube-Video »Opera 10 Reviewer's Guide«.

JAWS

Eine Nummer weiter ist ab sofort auch der Screenreader JAWS, von dem eine öffentliche Beta der Version 11 bereitsteht (Download, Packungsbeilage). Auch hier hat sich einiges im Bereich der Zugänglichkeit von Web-Applikationen getan – so werden in der neuesten Version ARIA Drag & Drop sowie ARIA Live Regions unterstützt.

Der ganz normale Wahnsinn

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 …

UAAG aktualisiert

Die Web Accessibility Initiative des W3C hat einen aktualisierten Entwurf der User Agent Accessibility Guidelines (UAAG) 2.0 veröffentlicht. Die UAAG definieren, wie Browser, Media Player und andere sog. ›User Agents‹ die barrierefreie Nutzung von Webinhalten durch Menschen mit Behinderungen ermöglichen sollen. Die Arbeitsgruppe bittet Interessierte darum, den Entwurf zu lesen und bei Bedarf bis zum 9. September 2009 zu kommentieren. Weitere Infos dazu im Call for Review, mehr Details zur Richtlinie bei UAAG Overview.

Wochenendbeilage:
Neues vom W3C und was mit CSS 3

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:

• CSS Fonts Module, W3C Working Draft vom 18. Juni 2009;
• CSS 3D Transforms Module, W3C Working Draft vom 20. März 2009;
• CSS 2D Transforms Module, W3C Working Draft vom 20. März 2009;
• CSS Transitions Module, W3C Working Draft vom 20. März 2009;
• CSS Animations Module, W3C Working Draft vom 20. März 2009.

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

• »Vier CSS3-Tricks für sauberes HTML« von den Webkrauts
• »RGBa Browser Support« bei CSS-Tricks.com
• »ZURB – Super Awesome Buttons with CSS3 and RGBA« von Mark Otto
• »Schönes neues CSS: box-shadow« bei Peter Kröner
• »Fun with WebKit css gradients« im Martini Lab Blog (ein passendes Tool zum Erstellen von Linear Gradients gibt es von John Allsopp)
• »The Power of HTML 5 and CSS 3« bei Perishable Press

Wenn das noch nicht reicht: hier ist eine der zurzeit ach so beliebten Top-irgendwas-Listen: »CSS3 Exciting Functions and Features: 30+ Useful Tutorials«

Unschöne Wahrheiten

Beim Browser-Hersteller Opera läuft seit längerem eine Studie namens MAMA (Metadata Analysis and Mining Application). Untersucht werden versteckte Qualitäten von Webseiten wie deren Aufbau und die Verwendung (oder Nicht-Verwendung) von HTML-Tags und -Attributen – gemeinhin Dinge, die man kaum mit einer herkömmlichen Suchmaschine herausfinden wird. Interessant ist sowas vor allem für Browser-Hersteller wie eben Opera, aber auch für die Weiterentwicklung von HTML (zum Beispiel zur Version 5).

Untersucht wurden mittlerweile 4,2 Mio. URLs, die Ergebnisse werden nach und nach veröffentlicht (mehr zur Methodik und eine Zusammenfassung der wichtigsten Punkte). Heute fanden wir im Opera Developer Network einen Artikel von Henni Swan über einige gerade aus Sicht der Barrierefreiheit interessante Teilaspekte – die Verwendung von Überschriften-Strukturen, Bildern und Datentabellen: »Opera MAMA - a sneak peek at headings, images and summary«. Hier ein paar der wichtigsten Ergebnisse:

Weiterlesen …

Es gibt kein Bier auf h3 …

• 58,5% der untersuchten Webseiten benutzen keinerlei Überschriften-Elemente,
• 7,9% haben hingegen gleich mehrere <h1>,
• 16,1% fangen ihre Überschriften-Struktur nicht mit der Ebene <h1> an, sondern mit <h2>, <h3>, etc.,
• 11,3% der Seiten überspringen Überschriften-Ebenen, und bei
• 7,1% der Seiten sind die Überschriften-Ebenen in keiner logischen Reihenfolge.

Über die Punkte 2-5 kann man geteilter Meinung sein (und wie bei Opera vermerkt gibt es mittlerweile sogar eine Seite www.h1debate.com, wo man sich per Twitter an dieser Endlos-Debatte beteilgen kann). Was aber ganz sicher gar nicht geht ist Überschriften ganz wegzulassen, da diese gerade für Screenreader-Nutzer eine wichtige, wenn nicht die wichtigste Orientierungshilfe sind.

Es gibt nichts zu sehen, gehen Sie bitte weiter …

Ganz bitter auch das Bild bei Bildern, Grafiken und deren Alternativ-Texten:

• 75,1% der untersuchten Seiten benutzen zumindest alt-Attribute für Bilder. Was aber im Umkehrschluss leider bedeutet, dass
• 24,9% gar keine alt-Attribute verwenden. Abgesehen davon, dass hier oftmals relevante Informationen und Funktionen für Screenreader-Nutzer verborgen bleiben heisst das auch, dass bei diesen Seiten in gängigen Screenreadern unter Umständen der Pfad der Bilddatei vorgelesen wird – der Benutzer darf dann anhand des Dateinamens selbst herausfinden, was ihm da wohl verborgen bleibt.

Auch bei Datentabellen sieht es nicht besser aus:

• 2,4% der Seiten benutzen überhaupt das summary-Attribut, allerdings bei
• 1,7% der Seiten fehlerhaft, nämlich in der Form von summary="layout table"

Weitere Werte, die gefunden wurden waren "layout", "layout table", "header", "navigation", "content", "banner", "main", "main table", "breadcrumb", "category" etc. Das deckt sich weitestgehend mit unseren Erfahrungen – uns sind auch schon Websites mit hunderten summary="Zusammenfassung" (wörtlich!) untergekommen. Wenn schon immer noch Layout-Tabellen eingesetzt werden, dann wenigstens so richtig falsch!

Es gibt noch viel zu tun …

Die kleine Browserbastelecke

Mal wieder was Vermischtes über die Programme ohne die Sie das hier nicht lesen könnten; ordentlich nach Hersteller und Popularität sortiert (in Klammern die kumulierten Anteile für das laufende Quartal hier bei EfA):

Firefox (59,1%)

• »How to use NVDA and Firefox to test your web pages for accessibility«
• »Firefox 3.5 for developers«
• »CSS implementation status reports (and a first one from Mozilla)«
• »Use Firefox, Save the Planet«

Internet Explorer (25,4%)

• »Prepare for Automatic Update distribution of IE8«
• »Fixing Reliability Issues in IE8«
• »IE8 Users Downgrade To Explorer 7«
• »Browser-Update.org - Benutzer über Browserupdates informieren«
• »Making the IE Voodoo Doll«
• »6 html and javascript codes to crash IE6«
• »10 Cool Things We’ll Be Able To Do Once IE6 Is Dead«
• »putting ie6 out to pasture«
• »It's time to end the misery of IE6«

Safari (7,6%)

• »Safari 4 - how its Top Sites view can mess up your stats«
• MobileSafari in iPhone 3.0 mit schnellerem JavaScript

Opera (3,3%)

• »Opera 10’s Y2K Bug: Browser Detection Goes Bad«
• »Changes in Keyboard Shortcuts between Opera 9.23 and 9.50 Alpha 1«

Chrome (0,6%)

• »Google Chrome 2 - Neue Beta bringt mehr Stabilität«
• »On rendering engines and graphic libraries«
• »Early Stats: Google Chrome Hurts Firefox, not IE«

Schnell, schneller, am allerschnellsten …

Aus der Kategorie ›Nutzloses Wissen‹:

• Auf Microsofts msn.com surft man am schnellsten mit Google Chrome,
• google.com hingegen geht am schnellsten mit dem Internet Explorer,
• und auf microsoft.com nimmt man am besten den Firefox.

Gefunden bei cnet: »Browser war centers on once-obscure JavaScript«.

Die kleine Browserbastelecke

Wie sich vielleicht schon herumgesprochen hat, ist gestern die finale Version des Internet Explorer 8 zum Download veröffentlicht worden. Haben wir natürlich gleich gemacht, alleine schon um unsere eigenen Seiten komplett durchzutesten – bisher ohne Befund.

Angenehm überrascht hat uns (neben der gesteigerten Geschwindigkeit und den verbesserten Entwickler-Werkzeugen) die vollständige Unterstützung von CSS 2.1 (mit Ausnahme von Appendix A »Aural style sheets«, aber die unterstützt ja auch sonst niemand). Bevor ungeduldige Webdesigner nun einwerfen »Bäh, der kann ja immer noch keine runden Ecken« – runde Ecken werden erst in CSS 3 spezifiziert werden, und das ist im Gegensatz zu CSS 2.1 noch lange nicht beim Status einer ›Candidate Recommendation‹ angelangt. Also freuen wir uns erstmal über das Erreichte.

Weiterlesen …

Standards

Und das ist eine ganze Menge. Die bereits erwähnte Unterstützung des aktuellen CSS-Standards brauchen wir nicht im Detail aufzudröseln, dafür gibt es im Netz ganz wunderbare Vergleichstabellen:

• CSS Browser Support (including IE8 & Safari 4 Beta)
• When can I use...
• CSS3 im IE 8 - Was kann er und worauf muss man achten?
• Compatibility Master Table
• CSS 2.1 Conformance Test Suite

Weitere Infos zum Browser, zur Unterstützung von Web-Standards und zu deren Weiterentwicklung gibt es in einem Interview mit Chris Wilson, Platform Architect for IE bei Microsoft im SitePoint Podcast #11.

Accessibility

Für uns natürlich besonders interessant der Bereich der Zugänglichkeit des Browsers und der dargestellten Inhalte. Auch da gab es enorme Fortschritte – Jonas Hellwig nennt einige davon:

»In Punkto Barrierefreiheit macht der IE8 ebenfalls große Fortschritte! Die neue Funktion ›Caret Browsing‹ ermöglicht dem User eine vereinfachte Bedienung der Website mittels Tastatur. Hierbei soll ähnlich komfortabel navigiert werden wie innerhalb einer Textverarbeitungssoftware.

Die zweite neue Funktion nennt sich ›Adaptive Zoom‹. Hier muss eine Website nicht immer wieder von neuem gezoomt werden, sondern es kann ein individueller Wert in den Einstellungen vergeben werden. Die gesamte Ansicht innerhalb des IE8 wird dann immer in der gewünschten Zoomstufe dargestellt.«

Ebenso neu dabei ist die Unterstützung von WAI-ARIA. Diese zusätzlichen Rollen, Zustände und Eigenschaften können bereits von geeigneten Hilfsmitteln für die effektive Nutzung von Web-basierten Applikationen ausgewertet werden. Einen aktuellen Test der Unterstützung, nicht nur im IE 8, hat Steve Faulkner erstellt: ARIA roles exposed via MSAA by browsers on Windows - Safari 4, Opera 10, IE 8, Firefox 3 & Chrome 1.

Die komplette Übersicht der Neuerungen im Bereich ›Accessibility‹ gibt es im IEBlog: New Accessibility Features in IE8.

Schwarze Listen

Weniger schön ist der Schalter zur vermeintlichen Verbesserung älterer Web-Inhalte, die auf die fehlerhafte Darstellung in älteren IE-Versionen hin entwickelt wurden, bei Microsoft Compatibility View Blacklist genannt. Auch hierzu hat sich schon halb Klein-Bloggersdorf in epischer Breite ausgelassen; hier zunächst die Position von Microsoft:

• Introducing Compatibility View
• Just The Facts: Recap of Compatibility View
• Compatibility View Improvements to come in IE8

… und die Reaktionen der Betroffenen:

• Microsoft breaks IE8 interoperability promise
• Microsoft betrayed the web community (or not? — Update)
• IE8 Blacklist: forcing standards rendering opt-in
• The IE8 Blacklist minefield

Fazit: Alles in Allem ein guter Browser. Ob nun die Zeit gekommen ist, den IE6 komplett zu ignorieren oder ob man seine Website kompatibel für alle Browser macht, muss jeder für sich entscheiden.

Nachtrag 22.03.2009:

• IE8 Kompatibilitätsmodus: Meta-Tag EmulateIE7 und Listen - der Überblick
• IE8 (final release) bugs

Browser in Zeiten wie diesen …

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:

1. <div id="related" role="complementary">
2. <h2>Mehr zum Wettbewerb:</h2>
3. <ul class="linkliste">
4. <li><a href="/biene-2008/gewinner/">Die Gewinner</a></li>
5. <li><a href="/biene-2008/gewinner/fotos/">Fotos der Ausgezeichneten</a></li>
6. […]
7. </ul>
8. </div>

Der eigentliche Trick steht im CSS:

1. .award #related ul {
2. column-count: 3;
3. column-width: 32%;
4. column-gap: 10px;
5. column-rule: solid #ddd 1px;
6. -webkit-column-count: 3;
7. -webkit-column-width: 32%;
8. -webkit-column-gap: 10px;
9. -webkit-column-rule: solid #ddd 1px;
10. -moz-column-count: 3;
11. -moz-column-width: 32%;
12. -moz-column-gap: 10px;
13. -moz-column-rule: solid #ddd 1px;
14. }

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:

• nitzsche.info/Blog/Abschied vom Internet Explorer 6?
• IE-User durch Nichtunterstützung zum Wechsel bewegen funktioniert nicht - Peter Kröner
• The Death of Internet Explorer 6: Still Prematurely Called | Devlounge
• "Stop being a dick, support IE6" as seen on MarylandMedia

Irgendwo dazwischen:

• F-LOG-GE » Den Teufelskreis brechen
• net.work.xing - Ingo Chao » Degradation Without Grace
• textformer Weblog - Abschied vom IE6, dezente Variante
• Adieu IE6. Schleppende Ablösung. | Webzeugkoffer Webdesign
• 24 ways: The IE6 Equation
• Brendan Cullen • Is it Finally Time to Ditch IE 6?
• No more pixel perfectionism in IE 6 | 456 Berea Street
• Hold on and stand still - das Leben mit dem IE6 - High Resolution Spotlights

Contra IE6:

• Abschied vom IE6 | Pisto
• Stop developing for Internet Explorer 6 - Robert’s talk
• Feed IE 6 with a basic stylesheet - Simon Clayson
• heise online - Webmaster-Aufstand gegen alte Internet Explorer
• That Norwegian Guy » Norwegian IE6 spring cleaning
• It’s Our Fault IE6 Still Lingers | ara pehlivanian
• Satire: Abwrackprämie für Internet Explorer 6 | hyperkontext
• IE Death March
• DearIE6 - So Long

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.

EfA-Laborbericht № 5

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.

Ä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 ():

169. ul li {
170. list-style-image: url(data:image/png;base64,iVBORw0KGgoAAA ANSUhEUgAAAAYAAAAHCAQAAACBmfRmAAAAKUlEQVQI12OYKDWxY eJVIGyYKMUAJP5DYQMDUAzGuYrGQVGGbMB%2FJAgAx7o1X3W50i UAAAAASUVORK5CYII%3D);
171. }

(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:

573. ul li {
574. list-style-image: url("/img/chrome/list-item.png");
575. }

Wenn Sie mehr über den Trendsport Extrem-Optimizing wissen wollen haben wir hier noch ein paar lehrreiche Links aus dem Yahoo! User Interface Blog:

• developer.yahoo.com: »Best Practices for Speeding Up Your Web Site«
• Steve Souders: »High Performance Web Sites: 14 Rules for Faster Pages«
• Tenni Theurer: »Performance Research, Part 2: Browser Cache Usage - Exposed!«
• Stoyan Stefanov: »Image Optimization, Part 3: Four Steps to File Size Reduction«
• Dirk Ginader: »Sehr sehr schnelle Seiten - Website Performance Best Practice - Teil 1« und »Teil 2«

Nachtrag: Mehr zu Grafikformaten ganz aktuell im Atzventzkalender der Webkrautz: »Das richtige Grafikformat für den richtigen Zweck«.

EfA-Laborbericht № 2

Zu einem Relaunch gehört selbstverständlich, dass man sich mit der Ausstattung seiner Nutzer befasst und analysiert, mit welchen Browsern, Betriebssystemen und Monitorgrößen die Leute hier vorbeikommen. Ein Warnhinweis vorweg: bei der angenommen Zielgruppe von EfA handelt es sich überwiegend um Fachleute im engeren Sinne – hier kann man also eine höhere IT-Kompetenz als im Durchschnitt der Bevölkerung annehmen. Die folgenden Zahlen sind demnach für genau einen Server repräsentativ: diesen hier.

Verkehrsnachrichten

Bei den Browsern zeigt sich seit Jahren ein deutliches Bild hin zu modernen Browsern, die aktuelle Web-Standards sauber verarbeiten können. So hat der Firefox in diesem Jahr erstmalig die 50%-Hürde übersprungen und liegt aktuell bei 53,05% für die Versionen 1.x bis 3.x. Dieser Zuwachs ging größtenteils zu Lasten des Internet Explorer, der von Januar bis November auf 33,58% kommt (alle Versionen von 5 bis 8 zusammengenommen). Für historisch Interessierte hier zum Vergleich noch die Statistiken vom Januar diesen Jahres und vom November 2005.

Wenn man die Unterversionen einzeln betrachtet, so ergeben sich einige interessante Erkenntnisse: der IE6/XP hatte im laufenden Jahr die höchsten Verluste, sorgt aber unter der Woche immer noch für bis zu 5% der Zugriffe. Am Wochenende sinkt diese Quote dann allerdings auf 1-1,5% – was nur den Schluss zulässt, dass dieser Browser in Firmennetzen noch wesentlich häufiger Verwendung findet als in Privathaushalten. Bitte, liebe Sysadmins, fasst euch ein Herz.

Die geringe Verbreitung des IE6 unter unseren Lesern hat beim aktuellen Relaunch zu der Entscheidung geführt, diesen Browser nur noch eingeschränkt zu unterstützen. Das heisst selbstverständlich, dass alle Besucher mit dem IE6 die gleichen Seiten mit den gleichen Inhalten und Funktionen geliefert bekommen; es kann nur hier und da passieren, dass es nicht ganz so hübsch aussieht. Wie diese Auswirkung im Detail aussieht werden wir in einer kommenden Folge etwas genauer erklären.

Weiterlesen …

Auch bei den Betriebssystemen gibt es einen klaren Sieger: hier liegt Windows XP mit 63,83% klar vorne, gefolgt vom Nachfolger Vista, das aber mit 12,74% nicht so richtig von der Stelle kommt. Den dritten Platz belegt MacOS X mit erstmalig knapp über zehn Prozent (genau 10,19%), Linux mit 5,57%; der Rest verteilt sich auf den Rest. Windows98 mit 0,26% und Windows95 mit 0,01% spielen hingegen keine Rolle mehr.

Größe zählt

Bei den Bildschirmauflösungen ergibt sich das zu erwartende bunte Bild: ein knappes Drittel der Besucher (32,26%) sind mit 1280×1024 unterwegs, 21,97% mit 1024×768. Auf den Plätzen findet sich dann alles mögliche bis hin zu gigantischen 2560×1600, aber bis einschließlich Platz 11 alles über 1.000 Pixel Breite. Erst auf Rang 12 findet sich die geringe Auflösung 800×600 mit nur noch 1,02% – diese haben beim aktuellen Relaunch auch als absolutes Minimum in allen Tests angenommen (n.b.: bei der BIENE wird seit 2006 mit 1024×768 getestet, was durch die 5%-Regel der BITV abgesichert ist).

Geschwindigkeitsüberschreitung

Mittlerweile finden über 70% aller Zugriffe auf diese Seiten über breitbandige Verbindungen statt. DSL liegt in dieser Gruppe mit 54,39% aller absoluten Zugriffe vorne, der Rest geschieht über Kabel oder sonstige breitbandige Anbindungen (z.B. aus Firmennetzen). Dialup per Analog-Modem und ISDN liegen nur noch bei knapp über 26%.

Herkunftsbezeichnung

Einigermaßen erstaunt waren wir, als wir spaßeshalber mal die Zugriffe nach Bundesländern sortiert haben: in der Spitzengruppe gibt es keine Überraschungen – hier liegen die bevölkerungsreichen Flächenländer NRW (26,06%), Bayern (13,39%), Baden-Württemberg (11,83%) und Hessen (11,72%) klar vorne. Auf Platz 5 folgt aber bereits die Stadt Berlin, die mit ≈3,4 Mio. Einwohnern (≈2,8% der Gesamtbevölkerung) auf 8,86% aller Zugriffe kommt, während z.B. Rheinland-Pfalz mit ≈4 Mio. Einwohnern lediglich den neunten Platz mit 3,33% aller Zugriffe belegt.

Zusätzlich zu dem Stadt→Land-Gefälle zeigt sich auch ein deutliches West→Ost-Gefälle. Zum Vergleich: die Einwohnerzahl von Mecklenburg-Vorpommern entspricht in etwa der Stadt Hamburg (≈1,69 zu ≈1,75 Mio., Quelle: Destatis 2007); aus Hamburg kommt aber 5,35% des Traffics auf diesem Server, aus MeckPomm lediglich 0,72%!

Dies deckt sich in weiten Teilen mit den Erkenntnissen aus dem (N)Onliner-Atlas – hier nützt die ganze Diskussion um Barrierefreiheit im Internet nichts, wenn die betreffenden Personen erst gar nicht im Netz sind.

Platzhirsch

Bei den Suchmaschinen gab es hingegen keine Überraschung: Google liegt mit 95,67% wie schon in den Vorjahren uneinholbar vor der verbliebenen Konkurrenz. Auf dem zweiten Platz folgt die Suche von T-Online (die aber auch von Google angetrieben wird) mit 1,32%; sämtliche anderen Suchmaschinen (inkl. Yahoo) bleiben unter der 1%-Marke.

Nachtrag: Mehr zur Unterstützung älterer Browser bei 24 ways: »The IE6 Equation«.

Neues in der Werkzeugkiste

Beim britischen RNIB gibt es eine neue Erweiterung für den Internet Explorer, die Menschen mit Behinderungen das Surfen erleichtern soll: RNIB Surf Right Toolbar - beta version. Die Toolbar wurde zusammen mit dem Web Accessibility Tools Consortium entwickelt und ermöglicht es, JavaScript, Style Sheets, Flash oder Bilder abzuschalten, Schrift zu skalieren und verschiedene Benutzer-definierte Style Sheets auf Webseiten anzuwenden. (gefunden via)

(Bevor jemand fragt: ja, es ist immer besser sowas clientseitig zu haben, als dass jede einzelne Website entsprechende Knöpfchen anbietet.)

Browserwochen bei EfA

So, da isser nun endlich, der neue Firefox 3. Am Download-Tag selbst (wir berichteten) waren die Server der Mozilla Foundation zwar etwas wackelig, aber am Ende haben es wohl doch mehrere Millionen Menschen geschafft, den Browser herunterzuladen (mit Litauen an erster Stelle). Selbst die Konkurrenz war hocherfreut und hat die schon traditionelle Torte spendiert, und auch die erste kritische Sicherheitslücke hat nur fünf Stunden auf sich warten lassen.

Mittlerweile sind wohl auch die ersten Schockerlebnisse überwunden und für Web-Entwickler so essentielle Erweiterungen wie Firebug in der Version Version 1.2.0b3 verrichten anstandslos ihren gewohnten Dienst. Gemischte Gefühle hingegen hinterlässt der Firefox 3 bei Dirk ›YAML‹ Jesse, nicht nur wegen deplatzierter Gänsefüßchen und anderer CSS-Bugs, sondern auch wegen des merkwürdigen Zoomverhaltens.

Ebenfalls neu ist das Farbmanagement, allerdings muss dies an Stellen angeschaltet werden, wo sich der normale Durchschnittsnutzer selten hintraut. Wie's geht erklärt Manuela Hoffmann. Weniger schön ist der optischen Schriftweitenausgleich (im Volksmund auch Keming genannt), den Firefox 3 erstmalig einführt, und der hin und wieder so richtig in die Hose geht, wie man bei Ralf Herrmann sehen kann: »Kerning and OpenType features in Firefox 3«.

Wenn man als Mac-User die ausgesprochen gewöhnungsbedürftigen »Karl-Dall-Gedächtnis-Buttons« schnellstens wieder los werden will, so empfiehlt sich der Besuch bei takebacktheweb.org. Leider helfen die Themes aber auch nicht bei dem, was Firefox 3 sonst noch alles mit Formularen und anderen Interface-Elementen veranstaltet (was übrigens im ebenfalls neu erschienenen Opera 9.5 auch nicht besser ist).

Was sich hingegen alles im Bereich der Nutzerfreundlichkeit und der Accessibility getan hat kann man im Barrierekompass lesen; gerade für Nutzer mit Behinderungen interessant ist das, was man im Interview »Was kann der neue Browser ›Firefox 3‹?« nachlesen kann, das Martin Ladstätter mit Marco Zehe geführt hat.

Nachtrag:

• »Ein Blick in die Zukunft: Firefox 3.1, Firefox 4.0 und Safari 4«
• »Interview: David Baron on Firefox 3 and W3C Standards«
• »Accessibility testcases up in Litmus! Go and check them out!«
• »JAWS 8.0 beibringen, die Firefox-Konfiguration auch für Firefox 3.0 zu laden«

Browsernachrichten ohne Ende

Firefox

Nachdem unplanmäßig noch ein dritter Release Candidate eingeschoben wurde steht nun Dienstag, der 17. Juni als endgültiges Datum für Firefox 3 fest (wir berichteten). Ebenfalls lesenswert: Mit Firefox per Du - Version 3.0 und Firefox 3: Fonts and text.

Opera

Ganz fertig und schon ohne β hingegen ist die neueste Version 9.5 von Opera. Wie die meisten Browser (mit der Ausnahme des üblichen Verdächtigen) kann Opera auch schon einiges aus HTML 5 – Canvas & Web Forms – und aus CSS 3 – text-shadow, media queries, nth-child, background sizing – am besten zu sehen auf den Testseiten von css3.info/; weitere Details dazu auch bei dev.opera.com und im Changelog. Besonders gut: die Unterstützung des aktuellen Standes von WAI-ARIA und eine neue Version des Entwickler-Tools Dragonfly.

Internet Explorer

Wann der IE 8 hingegen fertig sein wird weiss niemand, wahrscheinlich auch nicht Microsoft. Klar ist aber, dass es im August eine IE 8 Beta 2 geben wird. Wie auch schon beim IE 7 gibt es auch diesmal umfassende Informationen, was auf Webentwickler alles zukommt:

• Getting Your Site Ready for Internet Explorer 8
• What's Coming in Internet Explorer 8 for IT Professionals?
• Improved Productivity Through Internet Explorer 8 Developer Tools
• Introducing IE=EmulateIE7

Safari

Abgerundet wird das ganze von Safari, von dessen kommender Version 4 es über die Seiten der Apple Developer Connection-Website eine erste Vorschau gibt: Apple Gives Developers Safari 4 Preview.

Die kleine Browserbastelecke, Teil IV

Und der Vollständigkeit halber darf der Safari natürlich auch nicht fehlen:

• Dave Hyatt:
  »Full Page Zoom«
  »CSS Canvas Drawing«
  »CSS Masks«
  »CSS Reflections«
  »Introducing CSS Gradients«
• Antti Koivisto:
  »Optimizing Page Loading in the Web Browser«
• Ken Fisher:
  »Safari 3.1 on Windows: a true competitor arrives (seriously)«
• John Gruber:
  »Firefox 3 vs. Safari 3«

Übrigens: beim Gnome-Browser Epiphany wird unter der Haube der Motor ausgetauscht – ab sofort läuft der mit der gleichen WebKit-Engine wie Safari statt wie bisher mit der aus Firefox bekannten Gecko-Engine. Näheres dazu bei »The Future of Epiphany«.

Die kleine Browserbastelecke, Teil III

Immer schön paritätisch und unparteiisch, deswegen hier die neuesten Nachrichten zum Internet Explorer, von dessen 8er-Version eine erste Beta für XP und für Vista erschienen ist:

• Eric Meyer: »Drugs, Bugs, and IE8«
• Jared Smith: »IE8, Standards Compliance, and ARIA«
• David Dorward: »Internet Explorer 8 Doctype and HTTP Header Switching«
• Matthew David Crowley: »WebBrowser Control Rendering Modes in IE8«
• Travis Leithead : »HTML and DOM Standards Compliance in IE8 Beta 1«
• Saloni Mira Rai: »Internet Explorer 8 and Adaptive Zoom«
• msdn: »CSS Compatibility and Internet Explorer«

Die kleine Browserbastelecke, Teil II

Nachtrag zur gestrigen Meldung: getfirebug.com tut's jetzt wieder und die für Firefox 3 benötigte Version 1.2 Beta funktioniert auch einwandfrei.

Was leider nichts an den generellen Problemen von und mit Firefox ändert:

• Mark Pilgrim: »When the fall is all that’s left« (Es ergeht Lesebefehl!)
• Scott Gilbertson: »Extend Firefox Contest Highlights the Catch-22 of Browser Add-ons«
• Michael Calore: »Mozilla's Asa Dotzler on Firefox, Fighting Bloat and the Problem with Democracy«
• Scott Gilbertson: »What Happened to the Microformats Support in Firefox 3«

Ok, es gibt auch positive Nachrichten, die wir niemandem vorenthalten wollen:

• Marco Zehe: »Putting final touches on Firefox 3 accessibility«
• John Resig: »Color Profiles in Firefox 3«