JavaScript
Freitag12. Februar 2010

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

Anforderungen

Zunächst wären noch einmal die Anforderungen an Skiplinks zu definieren. Die WCAG 2.0 gibt unter G1 Testkriterien vor:

  1. Stelle sicher, dass Skiplinks die ersten focussierbaren Elemente der Webseite darstellen.
  2. Stelle sicher, dass die Linkbeschreibung eine verständliche Beschreibung des Sprungzieles enthält.
  3. Stelle sicher, dass der Skiplink entweder immer oder zumindest dann sichtbar ist, wenn der Tastaturfocus auf ihm liegt.
  4. Stelle sicher, dass beim Aktivieren eines Skiplinks der visuelle Focus im Viewport des Browsers auf das Ziel gesetzt wird.
  5. Stelle sicher, dass nach dem Aktivieren des Skiplinks der Tastaturfocus auf das Zielelement gesetzt wurde.

Die WCAG ist unnachgiebig, was diese Kritierien betrifft: Alle 5 Testkriterien müssen erfüllt werden.

Den gesamten Beitrag lesen


Mittwoch28. Oktober 2009

Die neue Version 3.2 des (X)HTML/CSS Frameworks YAML steht ab sofort im Downloadbereich der Projektseite zum herunterladen bereits. Erst vor wenigen Tagen, am 15. Oktober 2009 konnte das Projekt seinen nun schon vierten Geburtstag feiern und ich freue mich außerordentlich, dass auch nach einer so langen Zeit die Luft für Verbesserungen und Weiterentwicklungen noch nicht aufgebraucht ist. Die vorliegende Version 3.2 bringt einige wichtige Änderungen mit sich, die ich im Folgenden kurz vorstellen und begründen werde.

Schlankerer Framework-Core

Die wichtigste Änderung gleich zu Beginn: YAML besteht nunmehr nur noch aus zwei Kernbausteinen. Die base.css ist das Herzstück des Frameworks und stellt dem Nutzer ein schonendes Browser-Reset, oft benötige CSS-Klassen für die Layouterstellung (Float Clearing, Skiplinks, ect.), die “Subtemplates” als flexible Grid-Bausteine, ein universelles Fallback auf ein dreispaltiges Basislayout und wichtige Vorgaben für eine fehlerfreie Druckausgabe bereit. Über den zweiten Baustein, die iehacks.css werden die älteren Versionen des Internet Explorers 5.x bis 7.0 mit Bugfixes versorgt, die so formuliert sind, dass sie ohne Eingreifen des Anwenders den überwiegenden Teil der CSS-Bugs dieser Browser korrigieren. Der ehemaliige dritte Baustein, die print_base.css ist in der base.css aufgegangen.

Struktogramm YAML 3.2

Eine Umstrukturierung der medienspezifischen Definitionen innerhalb der base.css ermöglichte weiterhin einige Vereinfachungen der Codebasis, sodass trotz der Erweiterung der Grid-Komponente der gesamte Framework-Core insgesamt fast 600 Byte (ca. 10%) kleiner geworden ist. Mit den Wegfall der print_base.css kann zudem ein HTTP-Request eingespart werden (zumindest, wenn man die finalen Stylesheets nicht zusammenfasst) und in modernen Browsern wie dem Internet Explorer 8, Firefox, Opera, der Safari benötigt der YAML-Core nur noch 2,34 kB (slim_base.css). Ausschließlich die veralteten Versionen des Internet Explorers 5.x – IE 7.0 müssen den vollständige Core mit 5,04 kB laden.

byte-size of several CSS framework cores

Neue Features & Altlastenentsorgung

Wie mit fast jeder YAML-Version wird auch mit YAML 3.2 der Funktionsumfang des Frameworks leicht erweitert. Die Subtemplates (die Grid-Komponente von YAML) erhält vier weitere Unterteilungen (20%, 40%, 60% und 80%). Selbstverständlich besteht auch hier die Möglichkeit, gleiche Containerhöhen über die Klasse .equalize zu erzwingen. Daneben steht mit einem weiteren Add-on, dem SyncHeight-Plugin für jQuery, eine JavaScript-Alternative für das Erzwingen gleichhoher Container zur Verfügung.

Der Formularbaukasten ist ebenfalls flexibler geworden. So ist die Klasse .yform nicht mehr an das form-Element gebunden, was den Einsatz in Content Management Systemen wie z.B. ExpressionEngine vereinfacht, bei denen der form-Tag automatisch vom CMS generiert wird. Die zusätzliche Darstellungsklasse .full hilft bei Platzproblemen (schmale Formulare) und erzeugt Input-, Select-Felder und Textareas mit voller Breite des umgebenden Elternelementes. Ein neues Layoutbeispiel demonstriert, wie einfach und komfortabel sich mehrspaltige Formulare mit YAML erstellen lassen.

Neben diesen neuen Möglichkeiten, wurden mit diesem Release auch einige Altlasten beseitigt. So wurden die IE-Fixes für die ehemaligen ID’s #page_margins und #page aus der iehacks.css entfernt. Beide ID’s werden seit YAML 3.1 (Januar 2009) in mehrfach verwendbare Klassen umgewidmet. Einen echten Feature-Drop betrifft der Verzicht auf die Möglichkeit, Spaltenhintergründe mit Hilfe der Border-Definition von #col3 zu erzeugen. Zwar ist diese Technik denkbar einfach in der Umsetzung, sie beschwört aber in Verbindung mit den Windows-Kontrastmodi ein Zugänglichkeitsproblem herauf, da in diesen Modi Vordergrund- und Rahmenfarben auf den gleichen Farbwert gesetzt werden, infolgedessen Inhalte mit dahinterliegenden farbigen Rahmen (den simulierten Spaltenhintergründen) z.T. nicht mehr lesbar sind. Erschwerend kam hinzu, dass diese Technik im Internet Explorer ein Anpassung des z-index von #col3 bedurfte, was in seltenen Fällen das Selektieren von Inhalten mit der Maus im Browser blockierte.

Ein oft diskutierter Punkt unter vielen Framework-Anwendern war bisher der Workaround zur Vermeidung seitlich springender, zentierter Layouts im Firefox und Safari durch Erzwingen eines vertikalen Scrollbalkens. Mit der Veröffentlichung der neuen Browsergenerationen Internet Explorer 8, Firefox 3.5, Safari 4 und Opera 10 wurde die bisherige Lösung unbrauchbar und deshalb aus dem Core entfernt. An ihre Stelle tritt eine CSS3-basierte Lösung (overflow-y: scroll), welche nunmehr in den Nutzerstylesheets (basemod.css) verankert ist und somit von jedem Anwender bei Nicht-Gefallen einfach deaktiviert/entfernt werden kann.

Ebenfalls ersatzlos gestrichen wurde das Debug-Stylesheet (debug.css), welches mit der Version 3.0 Einzug in das Framework gehalten hatte. Zu sehr litt die Übersicht bei der Vielzahl der gleichzeitig eingeblendeten Informationen. Die fehlende Konfigurierbarkeit und die umständlichen Handhabung waren ebenfalls nicht vorteilhaft. Mit dem bereits im Febuar 2009 veröffentlichten Codeanalyse-Tool YAML Debug steht YAML-Entwicklern eine deutlich bessere und vielseitigere Alternative zur Verfügung, die mit einem einzigen Klick jedes Layout analysiert.

Handwerkszeug für die Barrierefreiheit

Kein Framework, auch nicht YAML, ist ein Garant für barrierefreie Webseiten. Dennoch zeigt sich mehr und mehr, wie sinnvoll und richtig es ist, Webentwicklern das grundlegende Handwerkszeug innerhalb des 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 Focus auf die angesprungene ID zu setzen.

Ein weiterer Schritt ist die konsequente Einbeziehung von WAI-ARIA. Sämtliche bei YAML mitgelieferte Beispiellayouts wurden mit ARIA-Landmarkroles versehen. Zwar handelt es sich hierbei nicht wirklich um ein Feature des Frameworks (die korrekte Auszeichnung sollte der Webentwicklers vornehmen), dennoch halte ich auch diesen Schritt für wichtig, um als Framework-Entwickler trotz der noch fehlenden Validierungsmöglichkeiten im W3C-Validator die positiven Effekte des kommenden Standards hervorzuheben. Schon heute können alle modernen Browser (einschließlich des IE8) 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 Add-on ein fester Bestandteil des Frameworks. Das dahinter stehende Konzept habe ich zusammen mit Dirk Ginader bereits vor zwei Jahren entwickelt, die Umsetzung im Rahmen dieses Plugins ist mittlerweile ausgereift und umfangreich getestet. Auch dieser Baustein ist weniger als Feature des Frameworks zu sehen. Stattdessen bemühe ich mich darum, zusammen mit YAML sinnvolle Best-Practice-Lösungen zu vermitteln und die Verbreitung dieser Techniken zu fördern.

Zusammenfassung

Neben diesen großen Neuerungen/Verbesserungen stehen zahlreiche kleinere Korrekturen hier und da, über die das Changelog im Detail Ausfunft gibt. Wie mit jedem Release wurde auch die Projektvorlage “Simple Project” auf den aktuellen Stand gebracht.Der YAML Builder beherrscht momentan WAI-ARIA noch nicht und auch die neue Skiplink-Variante ist dort noch nicht implementiert, die Codeausgabe ist aber selbstverständlich kompatibel zu YAML 3.2.

Der Release-Zyklus war diesmal deutlich länger, zudem zwischen v3.1 und v3.2 keine sogenannten Maintenance-Releases eingeschoben wurden. Der Hauptgrund hierfür lag in der eng gestaffelten Veröffentlichung der aktuellen Browsergeneration, angefangen mit dem Internet Explorer 8 im Frühjahr 2009. Gerade bei diesem war es wichtig, die zuverlässige Funktion der Kernfunktionen des Frameworks ohne jegliche Hacks zu überprüfen. Nach nunmehr einem halben Jahr lässt sich dieser Fakt bestätigen. Einzig bei der Darstellung von Formularen benötigt der Internet Explorer 8 noch wenige individuelle Hilfestellung, die notwendigen Anpassungen kennt der Formularbaukasten jedoch.

Daneben stellt das 3.2-Release für mich eine weitere Schärfung des Profils von YAML hinsichtlich des modularen Aufbaus auf Basis eines sehr schlanken Kerns und der Focussierung auf flexible, barrierefreie Webseiten dar. Und die Entwicklung geht weiter ...


Sonntag27. September 2009

Der YAML Builder ist spätestens seit Version 1.0 eines der komfortabelsten Werkzeuge bei der Arbeit mit dem YAML-Framework. Nachdem ich in der Vergangenheit immer wieder nach einer Offline-Version gefragt wurde, habe ich mich heute hingesetzt und eine erste Implementation in Adobe AIR gebastelt.

Im Grunde ist der Umstieg auf Adobe AIR nicht weiter schwer und so bringt die AIR Applikation gleich mehrere Vorteile mit sich. Zum einen ist kein Flash-Plugin mehr erforderlich denn AIR bringt eine native Unterstützung zur Befütterung des Clipboards mit. Zum zweiten – und das dürfte der interessantere Punkt sein – hat man in einer Adobe AIR Applikation Zugriff auf das lokale Filesystem. Und drittens benötigen AIR Applikationen keinen Browser und auch keine Internetanbindung mehr, womit sich auch die Anwenderfreundlichkeit weiter erhöhen dürfte.

Der Screenshot des experimentellen YAML Builders unter AIR zeigt deshalb bereits ein neues Feature, den vollständigen Exports des YAML-Projekts in ein lokales Nutzerverzeichnis. Die copy & paste Orgien könnten damit der Vergangenheit angehören. Der vom Builder generierte Code kann mit einem Klick lokal gesichert werden als indiviudell konfiguriertes “Simple Project”. Parallel steht die Clipboard-Ausgabe einzelner Files weiterhin zur Verfügung.

Das ist zunächt einmal ein Testbalon – zu einer stabilen Version ist noch ein Stückchen hin. Im nächsten Schritt werde ich mir anschauen müssen, wie unter AIR die Versionsverwaltung und automatische Updates funktionieren, sonst macht eine solche Applikation auf Dauer keinen Sinn. Das ist der Vorteil eines Online-Dienstes, hier hat man immer volle Versionskontrolle.

Natürlich schreibe ich diesen Blogbeitrag nicht grundlos. Ich möchte Feedback zu dieser Idee an sich und weitere Tipps für kleine Änderungen, welche bei dieser Gelegenheit gegebenenfalls am Builder vorgenommen werden könnten/sollten. Falls jemand der Mitlesenden bereits Erfahrungen mit Adobe AIR gesammelt hat wäre ich ebenfalls dankbar, wenn ich gelegentlich die eine oder andere Frage loswerden könnte, die sich sicherlich noch auftun wird.


Freitag25. September 2009

Gestern, am 24.9. hatte ich die Ehre, zusammen mit David Maciejewski auf dem “Best of Accessibility” Symposium über Möglichkeiten zur Optimierung der Ladezeiten von Webseiten zu sprechen. David war so freundlich und hat die Folien bereits bei Slideshares hochgeladen, sodass ich sie hier zur Verfügung stellen kann.


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 3 Seiten

 <  1 2 3 >