accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

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:

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.