Zugänglichkeit
Donnerstag18. Juni 2009

Fast auf den Tag genau vor einem Jahr habe ich bei Dr. Web und im Smashing Magazine einen längeren Essay über “Flexible Layouts als die Herausforderung der Zukunft” veröffentlicht.

Schon damals – lange bevor mit dem IE8 und dem Safari 4 die letzten beiden Browsergrößen auf den Seitenzoom-Zug aufsprungen – war ich der Meinung, dass die von Opera 9 und Firefox 3 eingeführte Technik nicht das Allheilmittel für die zahlreichen Limitierungen pixelbasierter Layouts, bzw. der Sargnagel für flexible Layouts sein wird und hatte dies in den beiden Artikeln mit der immer weiter aufklaffenden Schere von Bildschirmauflösungen und der verstärkten Nutzung von Smartphones und Netbooks begründet. Seinerzeit entbrannte eine heiße Diskussion, danach war aber eigentlich die Luft raus und kaum jemand widmete sich mehr diesem Thema.

Umso erstaunter war ich heute über drei aktuelle, englischsprachige Beiträge (Danke Angar, für den Hinweis), die sich erneut dem Thema widmen und weitere gute Argumente für elastische und fluide (oder allg. flexible) Layouts liefern.

Der Beitrag auf 456bereastreet.com bringt ein sehr interessantes Argument: die Mehrsprachigkeit. Allein aufgrund der Sprache, in der Inhalte ausgegeben werden, verändert sich die Textmenge, bzw. deren Platzbedarf. Flexible Layouts können sich hier deutlich besser anpassen als fixe Konstrukte. Der Beitrag von Zoe Mickley Gillenwater geht noch deutlich tiefer ins Detail und bringt sechs weitere, gut durchdachte Argumente pro elastischem bzw. flexiblen Layout. Besonders interessant dabei ist der Punkt “Preserve design proportions”. Genau dies wird aktuell sehr gern als Grund angeführt, warum elastische Layouts in Zeiten eines funktionierenden Seitenzooms praktisch keine Relevanz mehr hätten (noch dazu, da sie sehr aufwändig in der Erstellung seien). Das überzeugende Argument pro elastischem Layout ist wieder einmal der User mit seiner Möglichkeit, die Standardschriftgröße seines Browsers/Betriebssystems beliebig nach oben oder unten anzupassen. Ein fixes Layout - Seitenzoom hin oder her - kann sich derartigen Gegebenheiten nicht anpassen, die Laufweiten der Texte ändern sich zwangsläufig und die schönste Typografie kann den Bach runter gehen.

Ich möchte hier nicht alle Punkte wiederholen. Die Beiträge sind hervorragend geschrieben, also lest selbst. Der sehr schön formulierten Zusammenfassung von Zoe Mickley Gillenwater schließe ich mich hiermit aus ganzem Herzen an.

Again, I have to stress that zooming is a great function for browsers to include. Also, fixed-width layouts are not evil—they are ideal in certain situations. But liquid and elastic layouts have a lot of benefits that fixed-width layouts in combination with browser zoom can’t necessarily match. ... Don’t use browser zooming as a reason to stop—or never start—making flexible layouts.

“Why browser zoom shouldn’t kill flexible layouts”, Zoe Mickley Gillenwater


Samstag07. März 2009

Im letzten Sommer habe ich in meinem Essay zu flexiblen Layouts (deutsch / englisch) ja für einigen Diskussionsstoff gesorgt. Im Rahmen dieses Beitrags hatte ich mir die Display-Statistiken von w3schools.com herangezogen, um darauf hinzuweisen, dass eine “Optimierung” von Webseiten auf eine feste Breite von 1024 Pixel Breite nicht wirklich Sinn macht, denn die absoluten Auflösungen und die damit verbundene Vielfalt steigen immer weiter an. Auf Basis der Statistik hatte ich damals eine Prognose für die Verteilung im Januar 2009 vorgestellt und diese gilt es nun, da die aktuellen Zahlen verfügbar sind, zu überprüfen.

Das Diagramm zeigt drei Graphen für Auflösungen von 800x600, 1024x768 Pixeln und alle darüberliegenden Auflösungen (Higher) als Volllinien. Die gestrichelten Linien entsprechen meiner Prognose für die Entwicklung bis Januar 2009 vom Juni letzten Jahres.

Wie man sieht, liege ich ganz schön daneben – im positiven Sinne. Denn der Anteil der höheren Auflösungen hat exponentiell zugelegt, während ich damals vorsichtig herangegangen war und damals nur eine lineare Zunahme angenommen habe. Dementsprechend ist auch der Anteil für die 1024x768 Auflösung kräftiger gefallen als vermutet. Während ich eine Abnahme auf ca. 42% geschätzt hatte, weist die Statistik aktuell nur noch 36% aus.

Das Gesamtbild verdeutlicht, wie vielfältig und nicht vorhersagbar die Randbedingungen sind, mit der Webseiten im Browser betrachtet werden. Zumal noch hinzukommt, dass der Browser selten im Vollbildmodus betrieben wird, sodass die noch ein weiterer Unsicherheitsfaktor (die Größe des Viewports) hinzu kommt. Ich selbst arbeite mittlerweile sowohl dienstlich als auch privat nur noch in Auflösungen von 1680x1080 oder darüber, der Brower lasse ich ausschließlich in einem Fenster laufen, ziehe jedoch das Fenster meist sehr weit auf, um beim Surfen nicht von anderen Applikationan abgelenkt zu werden. Die Viewportbreite meines Browserfensters liegt daher gewohnheitsmäßig (je nach dem, an welchem Rechner ich gerade sitze) zwischen 1400 und 1600 Pixeln. Das war auch der Grund, weshalb ich das Layout dieser Seite flexibel gestaltet und für große Auflösungen entwickelt habe.

In diesem Zusammenhang auch spannend, die aktuelle Display-Statisik von YAML.de, eine Seite mit recht ordentlichem internationalen Besucherverkehr. Wie man sieht, ist der Anteil der 1024er Auflösung mit 12% bereits deutlich niedriger. Den größten Einzelposten kann die 1280er Auflösung für sich beanspruchen mit 43%. Zusammen mit der 1024er sind das knapp über die Hälfte aller User. Das zeigt zum einen, dass der allgemeine Focus für die Breite einer Webseite sich in diesem Bereich bewegen sollte (alles andere hätte auch verwundert). Aber man sieht auch wie kräftig 1440, 1680 und die HD-Auflösung mit 1920 Pixeln Breite mittlerweile vertreten sind. Und für diese drei Auflösungen prognostiziere ich für Januar 2010 einen weiteren deutlichen Anstieg, während die kleineren Auflösungen, einschließlich der 1280er Breite stark federn lassen werden.

Egal, für welche Breite man letztlich sein Layout auslegt. In jedem Fall sollte die Zentrierung einer linksbündigen Anordnung vorgezogen werden. Denn bei einer fixen Breite von 760px bedeutet das schon bei der 1280er Auflösung, dass 40 Prozent der Viewportbreite ungenutzt bleiben. Steigt die Auflösung beim User - oder werden Inhalte innerhalb des Layout nicht über die volle Breite darsgestellt (typisch für Mehrspaltenlayouts), verschiebt sich das Verhältnis im Regelfall noch weiter in die Richtung, dass der ungenutzte Raum dominiert.
 


Montag02. März 2009

Bereits vor reichlich 3 Wochen hat Dirk Ginader in seinem Weblog ein jQuery-Plugin zur Erstellung barrierefreier Tabboxen veröffentlicht und in einem umfangreichen deutsch- wie englischsprachigen Releasebeitrag auch einen tiefen Einblick in die Hintergründe seiner Lösung gegeben. Offenbar lesen noch viel zu wenig Leute Dirks Blog, denn bei den üblichen Verdächtigen (zumindest denen, die ich über meinen Feedreader überwache) blieb es weitgehend still.

Vor ca. 1,5 Jahren, im Sommer 2007 sprach ich Dirk Ginader per Skype auf ein kleines Problem an. Damals machte ich gerade meine ersten Schritte mit jQuery und wollte für das Redesign von YAML.de ein Tabscript verwenden, um mehrfach hintereinander aufgelistete Quelltextabschnitte aufgeräumter präsentieren zu können. Zu diesem Zweck sah ich mir verschiedene Tab-Lösungen (mit und ohne jQuery) an, die jedoch alle am gleichen Problem krankten.

Die Tabs funktionieren generell nur in Verbindung mit JavaScript. Dennoch erwarteten sämtliche existierenden Scripte von mir, den für die Tabreiter notwendigen Markup (UL-Liste) fest im Layout zu integrieren. Ich hielt das für unsinnig, denn zum Wesen von unaufdringlichem bzw. zugänglichem JavaScript gehört, dass Bedienelemente, die nur in Verbindung mit der JavaScript-Applikation benötigt werden, auch per JavaScript erzeugt werden sollten.

Daraus entstand folgende Idee: Man definiert einen Bereich der Webseite, welcher die Tabinhalte beinhaltet und definiert ein HTML-Element, welches als Trenner zwischen den Tabinhalten fungiert und den Namen des Tabreiters beinhaltet. Im einfachsten Fall wäre das Bereich aus gleichrangigen Überschriften und Absatztexten. Per JavaScript könnten aus den Überschriften die Tabreiter generiert werden. Die dazwischen befindlichen Absatztexte (oder was auch immer sich zwischen den Trennelementen befindet) würden als Inhalte der Tabs interpretiert und entsprechend gestaltet. Das Schöne daran: Ist JavaScript deaktiviert, so stört kein unsinniger Listenmarkup und die Tabinhalte präsentieren sich im normalen Textfluss der Webseite.

Mit dieser Idee trat ich also im Sommer 2007 an Dirk heran und es dauerte nur wenige Tage bis die erste Version des Plugins Gestalt annahm, die im Übrigen bis heute auf YAML.de in der Dokumentation der Subtemplates ihren Dienst tut. Schon lange hatten wir vor, dieses Plugin zu verfeinern und zusammen mit YAML zu veröffentlichen. Dass es dennoch bis ins Jahr 2009 gedauert hat - naja, sei es drum. Ein großer Teil der Verzögerung floss nämlich eben in die Verfeinerung des Plugins, über die Dirk in seinem Blog auch ausführlich berichtet. So ist es gerade bei den so gern auf modernen Webseiten verwendeten Tabs alles andere als trivial, diese wirklich barrierfrei zu gestalten. Nun hat Dirk bei Yahoo in London den besonderen Vorteil, mit Artur Ortega einen blinden Kollegen neben sich sitzen zu haben, und beide gemeinsam konnten die sich langsam entwickelnde Lösung nicht nur theoretisch durchdenken, sondern auch unmittelbar im Praxistest auf Herz und Nieren testen. Vielen Dank Euch beiden, wirklich eine reife Leistung.

Momentan stehe ich mit Dirk in Kontakt, um noch weitere Verbesserungen an seinem Plugin vorzunehmen. So soll das Script in der nächsten Version unabhängig von animierten Übergängen eine vollständige Druckausgabe aller Tabinhalte unkompliziert ermöglichen und eine optionale Synchronisierung der Containerhöhen der Tabinhalte möglich sein. Eine Anreicherung mit ARIA ist ebenfalls denkbar.

Übrigens: Auf die gleiche Art und Weise ließen sich auch zugänglichere Accordion-Boxen erstellen. Die Probleme dürften sich gleichen, ebenso wie der aufgezeigte Lösungsweg.


Seite 2 von 2 Seiten

 <  1 2