Die Verwendung simulierter Dialogfenster oder »Lightboxes« – wie man im Englischen kurz und treffend zu sagen pflegt – ist aus dem Internet und der Web2.0-Welt eigentlich kaum noch wegzudenken, zu weit verbreitet scheint ihre Verwendung – zur Freude und zum dem Ärgernis der Nutzer.
Oliver Siemoneit zeigt in seinem Beitrag die gängigen Probleme aus Sicht der Nutzer und stellt den Prototypen einer zugänglichen Lightbox vor:
»Eine kleine Untersuchung zur Barrierefreiheit von Lightboxes«
Ergänzend zum vorstehenden Artikel hier noch ein paar zusätzliche Gedanken, Anforderungen und weiterführende Links zum Thema ›Barrierefreie Lightboxes‹.
Weiterlesen …
Kontext & Anforderungen
Manchmal muss man Benutzern ein reduziertes Interface präsentieren, das den Fokus auf die wesentlichen Informationen oder auf Formularfelder setzt und die Interface-Elemente versteckt, die für die gerade zu erledigende Aufgabe unnötig sind. Wenn dies in Form eines Overlays (auch ›Lightbox‹ genannt) implementiert wird, erscheint der Inhalt als Pop-Up-Fenster oder als simulierter Dialog. Die Lightbox überlagert den Inhalt der Webseite, der Hintergrund wird typischerweise ausgegraut.
Eine Lightbox kann modal sein, d.h. der Benutzer kann nur mit der Lightbox und deren Inhalt interagieren. Oder sie kann nicht-modal sein, d.h. der Benutzer kann in diesem Fall sowohl mit der Lightbox und ihrem Inhalt, als auch mit anderen Elementen der ursprünglichen Seite interagieren.
Hürden & Schwierigkeiten
In Sachen Barrierefreiheit bringt die Benutzung von Lightboxes einige Probleme für verschiedene Gruppen von Menschen mit Behinderungen mit sich. Mögliche Schwierigkeiten sind unter anderem:
- Die Möglichkeit, die Lightbox ohne die Hilfe einer Maus oder anderer Zeigewerkzeuge über eine Tastatur-Schnittstelle zu öffnen und zu schließen.
- Die Benachrichtigung des Benutzers über die Generierung einer Lightbox bzw. das Einfügen des benötigten Codes in die Seite (dies schließt Benutzer von Vergrößerungssoftware ein, die möglicherweise das plötzliche Erscheinen einer Lightbox nicht bemerken, da dies außerhalb ihres Sichtfeldes passiert ist).
- Der Zugriff per Tastatur auf die Lightbox selber (und auf deren Position im DOM-Tree in Relation zu dem auslösenden Element) und auf die Tab-Reihenfolge (und damit die Lesereihenfolge) zu jeglichen Formular-Elementen, Steuerelementen, Links usw., die in der Lightbox enthalten sind.
- Die visuellen Grenzen der Lightbox für Benutzer mit eingeschränktem Sehvermögen oder blinde Benutzer verständlich zu machen und die Notwendigkeit, den Zugriff des Benutzers auf Inhalte innerhalb einer modalen Lightbox zu beschränken.
- Die meisten Lightbox-Scripte setzen einen relativ großen Bildschirm voraus und scheitern bei mobilen Geräten (oder verkleinern nicht auf elegante Art und Weise).
- Die meisten Lightbox-Skripte unterstützen das Drucken nicht.
Barrierefreie Lösungen
Eine Lightbox und ihr Inhalt kann durch die Benutzung einer Reihe von Techniken barrierefrei gemacht werden, wenn man Best Practices der Barrierefreiheit (wie zum Beispiel die Techniques der WCAG 2.0) einsetzt:
- Beim Öffnen der Lightbox sollte der Tastatur-Fokus auf die Lightbox gesetzt werden (idealerweise auf das erste fokussierbare Element, bei dem es sich um einen Link, ein Formular-Label oder ähnliches handeln könnte).
- Beim Schließen der Lightbox muss der Tastatur-Fokus wieder zu der exakt gleichen Stelle zurückkehren, bei der er war, als die Lightbox geöffnet wurde (normalerweise das anfänglich benutzte Element zum Öffnen des modalen Dialogs). Die ursprüngliche Tab-Reihenfolge sollte wiederhergestellt werden und der Benutzer sollte nicht länger in der Lage sein, sich per Tab zu Inhalten innerhalb des modalen Dialogs zu bewegen (d.h. die Lightbox sollte nicht einfach nur aus dem Viewport bewegt werden, sondern sollte ganz aus dem Dokumenten-Baum entfernt werden);
- Das Lightbox-Script sollte die Bedienung per Tastatur vollständig unterstützen (z.B. Esc. zum Schließen der Lightbox, Pfeiltasten zum Blättern in einer Diaschau, Home- & End-Schaltflächen wie auf einer normalen Webseite). Es sollte ein deutlich sichtbarer Fokus-Indikator vorhanden sein und Tastaturbefehle sollten in der Lightbox dokumentiert sein (z.B. »Zum Schließen drücken Sie Esc«).
- Das Lightbox-Script sollte einen vollständigen Browser-Verlauf bieten und die Änderung des
title unterstützen (z.B. über jQuery Address).
- Der Inhalt innerhalb der Lightbox muss voll skalierbar sein (z.B. mit unterschiedlichen Textgrößen).
- Das Design der Lightbox sollte robust genug sein, damit es komplett wahrnehmbar ist, wenn benutzer-definierte Farben (z.B. ein Windows Kontrast-Schema) benutzt wird.
- In modalen Dialogen sollte der Benutzer nicht zu irgendwelchen Elementen außerhalb der Lightbox navigieren können. Stattdessen muss der Tastatur-Fokus innerhalb der Lightbox verbleiben, bis der Benutzer diese absichtlich schließt, entweder indem er Esc drückt oder auf einen Schließen-Link oder eine Schließen-Schaltfläche klickt. Vor allem wenn Formulare in einer Lightbox präsentiert werden, sollte das Tabben über die Lightbox hinaus diese nicht schließen, um einen Datenverlust zu verhindern. Dies kann allerdings in anderen Fällen, wie zum Beispiel bei einer Galerie, genau das erwartete Verhalten sein.
- Die Benutzung von ARIA-Rollen & -Eigenschaften (wie zum Beispiel
aria-role="dialog"oder role="button" für das »Schließen«-Symbol), ARIA-Live-Regions und zusätzlichen ARIA-Attributen, die Beziehungen beschreiben, wie zum Beispiel aria-owns.
Anwendbare Standards & verwandte Techniken
Literatur zum Thema
Beispiele ›aus der freien Wildbahn‹
Code-Beispiele & Downloads
Das W3C hat am 16. September einen zweiten sogenannten Last Call Working Draft des kommenden WAI-ARIA-Standards und verwandter Dokumente veröffentlicht:
In dieser Phase der Entwicklung sollen letzte Kommentare aus der Community eingeholt werden, bevor die Texte als fertige Spezifikation veröffentlicht werden. Damit soll sichergestellt werden dass nichts übersehen wurde, was eine Implementierung des Standards in Browser und Hilfsmittel verhindert, oder die Umsetzbarkeit durch Web-Entwickler erschwert. Die Frist zur Abgabe von Kommentaren läuft bis zum 29. Oktober 2010, das Prozedere ist unter w3.org/WAI/PF/comments/instructions erklärt; weitere Informationen dazu im Call for Review.
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.
Das HTML & CSS-Framework YAML, auf dem auch diese Seiten hier aufgebaut sind, ist seit heute in der fertigen Version 3.2 am Start. Erst vor wenigen Tagen konnte das Projekt seinen vierten Geburtstag feiern und auch nach einer so langen Zeit ist die Luft für Verbesserungen und Weiterentwicklungen noch nicht aufgebraucht. Die vorliegende Version 3.2 bringt einige wichtige Änderungen mit sich: neben dem schlankeren Framework-Kern, der Vereinfachung der Code-Basis, der Erweiterung der Gestaltungsraster (sog. Grids) und den Performance-Gewinnen gibt es eine ganze Reihe von Verbesserungen im Bereich der Accessibility, die uns natürlich besonders interessieren.
Barrierefreiheit eingebaut
Kein Framework, auch nicht YAML, ist ein Garant für barrierefreie Webseiten (obwohl eine ganze Reihe von YAML-basierten Sites bereits mit einer BIENE ausgezeichnet wurden). Dennoch zeigt sich mehr und mehr, wie sinnvoll und richtig es ist, Webentwicklern das grundlegende Handwerkszeug innerhalb von Frameworks zur Verfügung zu stellen. In YAML 3.2 wird eine neue Darstellungsmöglichkeit für Skiplinks unterstützt, die ein Überlagern des Layouts für die eingeblendeten Skiplinks ermöglicht und dadurch die sonst üblichen Probleme bei deren Integration beseitigt. Zudem wird für Webkit-basierte Browser ein JavaScript-Fix mitgeliefert, um auch Apple’s Safari und Google Chrome dazu zu bewegen, den Fokus auf die angesprungene ID zu setzen.
Weiterlesen …
Ein weiterer Schritt ist die konsequente Einbeziehung von WAI-ARIA: sämtliche bei YAML mitgelieferte Beispiel-Layouts sind nun mit sog. ARIA-Landmark-Roles versehen. Zwar handelt es sich hierbei nicht wirklich um ein Feature des Frameworks (die korrekte Auszeichnung sollte nach wie vor der Webentwickler vornehmen), dennoch ist dieser Schritt wichtig, um trotz der noch fehlenden Validierungsmöglichkeiten im W3C-Validator die positiven Effekte des kommenden Standards hervorzuheben, denn schon heute können alle modernen Browser (einschließlich des IE 8) mit WAI-ARIA umgehen und ermöglichen somit einen deutlichen Zugewinn an Barrierefreiheit auf Webseiten jeder Komplexitätsstufe.
Das ›Accessible Tabs‹-Plugin von Dirk Ginader wird mit YAML 3.2 als Erweiterung ein fester Bestandteil des Frameworks. Die Umsetzung im Rahmen dieses Plugins ist mittlerweile ausgereift, umfangreich getestet und funktioniert auch hervorragend mit aktuellen Hilfsmitteln wie Screenreadern.
Entsorgung von Altlasten
Manchmal liegt eine Verbesserung auch im Verzicht auf ein Feature: so bot das Framework bisher die Möglichkeit, Spaltenhintergründe mit Hilfe der CSS-border-Definition von bestimmten Spalten zu erzeugen. Zwar ist diese Technik denkbar einfach in der Umsetzung, sie beschwört aber in Verbindung mit den für viele Sehbehinderte typischen Einstellungen von Benutzer-definierten Farben (z.B. den Windows-Kontrastmodi) ein Zugänglichkeitsproblem herauf, da dort Vordergrund- und Rahmenfarben auf den gleichen Farbwert gesetzt werden. Inhalte mit dahinterliegenden farbigen Rahmen (den simulierten Spaltenhintergründen) waren infolgedessen zum Teil nicht mehr lesbar. Erschwerend kam hinzu, dass diese Technik im Internet Explorer ein CSS-Anpassung benötigte, die in seltenen Fällen das Auswählen von Inhalten mit der Maus im Browser blockierte. Daher ist diese Variante nun, auch aufgrund unserer Überzeugungsarbeit, nicht mehr im Framework enthalten.
Neben diesen großen Neuerungen stehen zahlreiche kleinere Korrekturen, über die das Changelog im Detail Ausfunft gibt. Download des Gesamtpakets, Lizenzbedingungen; YAML Dokumentation: Deutsch (PDF), English (PDF)
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.
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:
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:
… und die Reaktionen der Betroffenen:
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:
In der kleinen Laborbericht-Serie zu unserem vergangenen Relaunch hatten wir öfters eine Abkürzung benutzt, die das Potenzial hat, das nächste große Ding zu werden: WAI-ARIA (›Accessible Rich Internet Applications‹). Damit werden Ergänzungen zu HTML beschrieben, die vorhandene Lücken in den Spezifikationen stopfen sollen. So lässt sich zum Beispiel in Web-basierten Applikationen ein Schieberegler auszeichnen – ein Element, dass es in HTML (noch) nicht gibt. Dieser wird dann z.B. in einem Screenreader auch als solcher angesagt und nicht als eine Ansammlung sinnfreier div.
Der Entwurf hat mittlerweile den Status eines Last Call Working Draft erreicht; die übliche Kommentierungs-Phase läuft bis zum 24. März. Es ist also mit einer baldigen Fertigstellung zu rechnen, zumal die Browser- und Hilfsmittel-Hersteller bereits fleißig implementieren.
Deswegen ein paar gesammelte Links als Ergänzung zu unserer Serie, falls Sie tiefer in die Materie einsteigen wollen:
Weiterlesen …
Lesenswertes:
Ohne die Unterstützung durch Browser und Hilfsmittel geht es natürlich nicht:
Einen noch zum Schluss: wie man am besten mit Screenreadern testet (oder noch besser: echten Screenreader-Nutzer testen lässt) erklärt Henni Swan von Opera: »Setting up a screen reader test enviroment«.
Im Chaosradio Express №107 unterhalten sich Tim Pritlove, Jan Eric Hellbusch und Tomas Caspers fast zwei Stunden lang über Grundsätzliches und Aktuelles aus dem Bereich Barrierefreiheit im Web – Was man bedenken sollte, wenn man Websites plant und gestaltet (Kommentare, Mitmachseite, Direkter Download der Mediendatei, ca. 80 MB).
Unter anderem geht es um folgende Themen: The Web Standards Project; Auswirkung der Farbwahl in Webseiten für Farbfehlsichtige; Bedeutung der Struktur und semantischem Markup für blinde Nutzer; Vorteile von barrierefreiem Design für nicht-behinderte Nutzer; Screenreader-Programme und vergleichbare Funktionalitäten in Betriebssystemen; Aspekte der Gebärdensprache; Aufbau, Anwendung und Testbarkeit der Web Content Accessibility Guidelines der W3C und WAI-ARIA; Gesetzliche Vorgaben und Verpflichtung zur Barrierefreiheit für Behörden und öffentliche Körperschaften und Accessibility für Podcasts.
In den letzten Tagen haben wir wieder mal ein wenig an den Seiten geschraubt. Seit neuestem gibt es jetzt (wieder) eine Live-Suche, die in Echtzeit passende Treffer zu den Eingaben in das Suchformular zurückliefert. Das Andocken an die im Backend verwendete Suchtechnik geschieht über ein paar Erweiterungen der von uns auch für andere Dinge verwendeten jQuery-Bibliothek; die Bedienung entspricht dem üblichen Verhalten von Combo-Boxen – also eintippen und ab (zurzeit) 2 Zeichen kommt eine Liste mit Vorschlägen vom Server zurück. Durch diese Liste kann man mit den Pfeiltasten navigieren, mit Enter wählt man einen Vorschlag aus, der dann in die Combo-Box übernommen wird. Dann kann man diesen Vorschlag entweder noch ergänzen oder per Tab zum Button, um die Suchanfrage loszuschicken (Maus geht natürlich auch).
Weiterlesen …
Echte Combo-Boxen gibt es in HTML leider nicht (bzw. noch nicht, HTML5 verspricht auch hier Besserung für den Fehler, dass man in der HTML4-Spezifikation Combo-Boxen schlichtweg vergessen hat). Daher geschieht die Eingabe über ein herkömmliches INPUT-Element, die Trefferliste wiederum ist eine ganz normale Liste vom Typ UL. Verknüpft sind die beiden allerdings über das ARIA-Attribut owns, mit dem die INPUT-Box einem geeigneten Hilfsmittel sagen kann, dass die id="trefferliste" zu ihr gehört (aria-owns="trefferliste").
Eine gute Erklärung dafür gibt es in den Wai-Aria Grundlagen bei protofunc():
Aria schreibt ähnlich wie HTML vor, dass einige Elemente immer Kindelement einer bestimmten Rolle sein müssen. Dies gilt beispielsweise für die Rolle option, welches ein Kind von select oder einer ähnlichen Rolle sein muss. In manchen Fällen ist dies technisch nicht möglich (Ein input-Element kann keine Kinder haben.) oder widerspricht dem Aufbau der UI-Komponente. In diesen Fällen kann das owns-Attribut verwendet werden, welches anzeigt, dass ein Element das Eltern-Element eines anderen ist.
Untenrum
So sieht das ganze dann im HTML aus – erstmal die Suchbox …
- <form id="searchform" action="/suche/" method="get" role="search" aria-owns="trefferliste">
- <fieldset>
- […]
- <label for="livesearch">Suchbegriffe:</label>
- <input name="q" id="livesearch" type="text" size="50">
- <button type="submit" id="submit" name="submit" value="Finden">Finden</button>
- </fieldset>
- </form>
… und dann die vom Skript in die Seiten eingebaute Trefferliste:
- <ul class="ac_results" id="trefferliste" aria-live="assertive">
- <li class="ac_over"><span class="ac_match">foo</span></li>
- <li><span class="ac_match">foo</span>bar</li>
- [...]
- </ul>
In der Trefferliste findet sich ein weiteres ARIA-Attribut (aria-live="assertive"), mit dem User Agents und insbesondere Hilfsmittel wie Screenreader darauf hingewiesen werden, dass hier eine wesentliche Änderung innerhalb der Seite stattgefunden hat mit der Bitte, den Nutzer doch bei nächster Gelegenheit darauf hinzuweisen.
Natürlich validiert das alles nicht, aber warum das so ist und warum das nicht nur in unserem eigenen, sondern auch im Interesse der Nutzer ist, hatten wir ja bereits im Laborbericht № 3 ausführlich erläutert. Unterstützt wird diese Technik zurzeit vom Screenreader JAWS ab Versionsnummer 10 mit aktuellen Versionen von Firefox und Internet Explorer 8.
Obenrum
An der Oberfläche haben wir uns ebenfalls wieder ein bisschen weiter aus dem Fenster gelehnt: auch hier kommen einige Standards zum Einsatz, die noch gar keine Standards sind, sondern noch in der Entwicklung befindliche W3C-Entwürfe. Unter anderem sind dies fortgeschrittene Selektoren, die eine Menge HTML-Code einsparen, um z.B. jede zweite Reihe in der Trefferliste mit einer anderen Hintergrundfarbe darzustellen. Früher hätte man dafür jede zweite LI einer Liste mit einer speziellen Klasse versehen (mit dem entsprechenden Programmieraufwand, um diese Logik im Backend bereitzustellen); heute reicht dafür (ohne Eingriffe in das HTML):
- .ac_results li:nth-child(odd) {
- background-color: #f6f9fe;
- }
Das Ergebnis ist (zumindest in modernen Browsern) eine gestreifte Liste wie im nebenstehenden Screenshot zu sehen. Einen gewissen Nachteil hat die Methode natürlich auch: ältere Browser verstehen sie nicht, daher haben wir uns im Sinne des »progressive enhancement« dafür entschieden, eine zusätzliche subtile Linie zur Differenzierung um die Listeneinträge zu legen.
Ebenfalls auf der linken Seite des Screenshots zu sehen ist ein weicher Schlagschatten hinter der gesamten Box der Trefferliste – auch hier wieder pures CSS ohne Eingriffe ins HTML und irgendwelche fragwürdigen leeren Elemente und Hintergrudbilder, wie sie in vielen Webdesign-Tutorials zu finden sind. Erreicht wird dies durch box-shadow, einem Selektor aus dem kommenden CSS Level 3.
Wundern Sie sich nicht über die komischen -webkit- oder -moz-Präfixe in den Regeln – diese sind in der CSS-Spezifikation dafür vorgesehen, Dinge in der Praxis und damit auf ihre Tauglichkeit testen zu können, bevor sie endgültig verabschiedet werden. -webkit ist die Anweisung für den Safari-Browser von Apple bzw. dessen Rendering Engine namens Webkit, -moz wiederum steht für Mozilla und andere Browser mit der Gecko-Engine:
- .ac_results {
- [...]
- box-shadow: 2px 2px 6px #333;
- -webkit-box-shadow: 2px 2px 6px #333;
- -khtml-box-shadow: 2px 2px 6px #333;
- -moz-box-shadow: 2px 2px 6px #333;
- }
Dass dies ebenfalls nur von den neuesten Browsern unterstützt wird, haben wir bewußt in Kauf genommen; die Begründung dafür finden Sie hier.
Und sonst?
Unsere Style Sheets werden seit neuestem gezippt ausgeliefert und sind nur noch ca. 10kb ›groß‹, was die Geschwindigkeit dieser Seiten nochmals deutlich verbessern sollte (zur Performance-Optimierung hatten wir ja schonmal an anderer Stelle was geschrieben). Ansonsten haben wir noch ein bisschen weiter aufgeräumt und endlich mal die Blogroll auf den neuesten Stand gebracht sowie die 2009er-Events-Seite befüllt. Wir bitten um freundliche Beachtung.
Web-Standards, HTML und so…
Kommen wir zum technischen Gerüst dieser Seiten. Wie bereits erwähnt basieren das HTML&CSS auf dem YAML-Framework in der neuesten Version. Da auch die letzte Version auf diesem Gerüst basierte, war die Umstellung mit ein paar ausgefeilten Suchmustern im Editor relativ leicht zu bewältigen und so manche Zeile Code hat es aus der alten Fassung auch bis herüber geschafft – ein nicht zu unterschätzender Vorteil, den barrierefreie Seiten durch ihre eingebaute Logik haben.
Über die Style Sheets als solche hatten wir ja bereits in der ersten Folge dieser kleinen Serie geschrieben; dort finden Sie auch den Link zum Download einer ausführlich kommentierten Fassung.
Bedeutungslehre
Unsere Seiten sind nach wie vor mit sinnvoll strukturiertem und semantischem Markup aufgebaut. Dies betrifft insbesondere die Textauszeichnungen und die Struktur der Inhalte. Da HTML aber nie alle Eventualitäten abdecken wird, kommt es zwangsläufig zu Interpretationen der Bedeutung von Elementen, die von anderen Interpretationen abweichen kann. Insofern kann man über das eine oder andere Element sicher diskutieren (z.B. in unserer ›Tag-Cloud‹ – hierzu wird es noch einen eigenen Laborbericht geben), aber in der Regel werden beide Positionen Recht behalten.
Ein Element hat die Umstellung nicht überlebt: ACRONYM wurde global durch ABBR ersetzt. Da selbst Linguisten sich nicht einigen können, welche Abkürzung denn auch ein Akronym sei, und da das ACRONYM-Element in HTML5 aller Voraussicht nach nicht mehr spezifiziert sein wird, fiel uns dieser Abschied nicht sonderlich schwer.
Weiterlesen …
Valid, Valid über alles?
Fast alle Seiten validierten zum Zeitpunkt ihrer Erstellung nach HTML 4.01 strict (für Fachleute: unter Berücksichtigung der Regeln zur Wohlgeformtheit gemäß »XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition): A Reformulation of HTML 4 in XML 1.0.« mit Ausnahme der in Appendix C.1, C.2 und C.3 gelisteten XML-spezifischen Anforderungen). Wenn Sie dennoch Fehler im Markup dieser Seiten finden, wären wir natürlich für einen kurzen Hinweis dankbar.
Mit zwei Ausnahmen:
- Einige Seiten weisen »Fehler« in der Validierung auf, da wir z.B. im Gegensatz zum W3C der Auffassung sind, dass das
start-Attribut von OL echter Inhalt ist und somit ins HTML gehört und nicht ins CSS.
- Seit dem aktuellen Relaunch setzen wir zur Kennzeichnung von Seitenbereichen und für erweiterte Funktionen Teile des kommenden WAI-ARIA-Standards ein. Aktuelle Hilfsmittel wie der Screenreader JAWS unterstützen diese Technik bereits in Verbindung mit modernen Browsern. Sie ermöglicht eine einfache Identifikation von Bestandteilen einer Seite wie z.B. der Navigation, der Suche, dem wesentlichen Inhalt einer Seite und ergänzenden Informationen zum jeweiligen Artikel.
Das hierfür benötigte role-Attribut ist jedoch noch nicht Bestandteil irgendeiner HTML- oder XHMTL-Spezifikation des W3C – verbreitete Validatoren geben hier also zurzeit noch einen Fehler aus. Da uns die Zugänglichkeit für den Nutzer wichtiger ist als ein grünes Fähnchen eines Prüfprogramms, haben wir nicht lange überlegt, ob wir diese Technik einsetzen sollen oder nicht.
Im Einzelnen setzen wir folgende Rollenzuweisungen ein, um Bereiche der Seiten zu kennzeichnen und abzugrenzen:
role="article"- Der wesentliche Inhalt einer Seite, also wie der Name schon sagt ein Artikel, ein Blogpost etc.
role="banner"- Die Kopfzeile der Seite mit dem Namen, Logo und Claim der Initiative
role="complementary"- Von Inhalt abhängige Bereiche, die diesen ergänzen, aber auch für sich allein stehen könnten (z.B. eine Vorlesefunktion)
role="contentinfo"- Ergänzende Informationen zum Inhalt wie z.B. Fußnoten, weiterführende Links etc.
role="main"- Der wesentliche Inhaltsbereich
role="navigation"- Der oder die Navigationsbereich(e)
role="note"- Ergänzende Bemerkungen zum Inhalt
role="search"- Die Suchfunktion
Eine tiefergehende Einführung in dieses Konzept finden Sie in einem Artikel von Gez Lemon bei der Opera Developer Community: »Introduction to WAI ARIA«
Fehlervermeidungsstrategien
Zusätzlich setzen wir Attribute aus WAI-ARIA ein um Screenreader-Nutzern die Handhabung von Formularen zu erleichtern. Besonders hilfreich sind hier:
aria-required="true"- Kennzeichnet ein Pflichtfeld in einem Formular, dass vom Nutzer ausgefüllt werden muss; mehr dazu bei Marco Zehe: »Easy ARIA Tip #1: Using aria-required«
role="alert"- Kennzeichnet eine Fehlermeldung; mehr dazu bei Marco Zehe: »Easy ARIA tip #3: aria-invalid and role ›alert‹«
aria-live="assertive"- Über diese sog. ›Live Regions‹ lässt sich steuern, mit welcher Dringlichkeit der Nutzer auf eine Fehlermeldung hingewiesen wird. Im konkreten Fall wird der Nutzer nicht unmittelbar bei der Arbeit unterbrochen (das wäre
aria-live="rude"), sondern erst bei der nächsten Gelegenheit informiert.
Wie sich dies in der Praxis im Screenreader anhört hat Martin Kliehm auf dem Wiener A-Tag vorgeführt. Die Videos dazu finden sich in seinem flickr-Account, die dazugehörige Präsentation gibt's bei Slideshare.
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:
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.
Seit ungefähr zwei Jahren entwickelt die Web Accessibility Initiative des W3C an der WAI-ARIA-Reihe, von der nun ein neuer Entwurf vorgelegt wurde. ARIA steht für »Accessible Rich Internet Applications« und soll als Interims-Lösung dafür sorgen, dass Web-basierte Applikationen für die Hilfsmittel behinderter Nutzer zugänglicher werden.
- WAI-ARIA Primer ist ein neues Dokument, in dem die Hintergründe und Lösungsansätze der Spezifikation erklärt werden;
- Accessible Rich Internet Applications (WAI-ARIA) Version 1.0, der aktuelle W3C Working Draft vom 4 Februar 2008, in dem die bisher getrennten Entwürfe für ›Roles‹ und ›States and Properties‹ kombiniert werden;
- WAI-ARIA Best Practices beschreibt, wie Entwickler heute schon zugängliche Web-Anwendungen schreiben können.
Die Arbeitsgruppe bittet um Kommentare bis zum 3. März 2008, spezifische Fragen finden sich in den o.g. Dokumenten jeweils im Abschnitt »Status of This Document«.
Den besten Einstieg in das gesamte Thema bekommt man beim W3C: »WAI-ARIA Overview« oder in diesem Artikel von Martin Kliehm: »Accessible Web 2.0 Applications with WAI-ARIA« bzw. in der deutschen Übersetzung: »Barrierefreie Web 2.0 Anwendungen mit WAI ARIA«. Woran es zurzeit noch (insbesondere von Seiten der Hilfsmittel her) hapert beschreibt ein Artikel von Steve Faulkner: »AJAX and Screen Readers - Content Access Issues«.
Die Protocols and Formats-Arbeitsgruppe des W3C hat aktualisierte Entwürfe von WAI-ARIA Roadmap, WAI-ARIA Roles und WAI-ARIA States and Properties veröffentlicht.
Die WAI-ARIA-Reihe soll die Barrierefreiheit von dynamischen Web-Inhalten (also das, was gemeinhin unter AJAX läuft) für Menschen mit Behinderungen sicherstellen. WAI-ARIA beinhaltet Techniken, um interaktive Regionen, Kontrollelemente und Events in Web-basierten Applikationen so abzubilden, dass sie von den Accessibility-APIs (MSAA, ATK etc.) der Betriebssysteme entsprechend verarbeitet werden können und damit in Hilfsmitteln zugänglich sind.
WAI-ARIA beschreibt darüber hinaus neue Techniken, um gängige Strukturen wie Menüs, primäre und sekundäre Inhalte, Banner und andere typische Webinhalte auszuzeichnen. Die Implementierung von WAI-ARIA in Markup-Sprachen wie HTML 4, HTML 5 und XHTML ist zurzeit in vollem Gange, weitere Infos im »Accessible Rich Internet Applications (WAI-ARIA) Suite Overview«.
Sonst noch von Interesse:
Die technische Basis vieler Computer-Hilfsmittel für Menschen mit Behinderung stammt aus Zeiten, als der Kanzler noch Kohl hiess. Da verwundert es nicht, dass diese oftmals ihre lieben Nöte mit moderneren Techniken der Webentwicklung haben. Ein paar Beispiele: viele Screenreader »raten« anhand des gerenderten Bildschirmbildes, was dahinter im Quelltext passiert (daher rühren dann die Probleme mit dynamischen Inhalten); gängige Lupenprogramme skalieren Bildschirmpixel und versuchen diese zu glätten, statt Vektor-Informationen zu benutzen (was bei starken Vergrößerungsfaktoren zu unleserlichem Text führt) usw. Die Umsetzung der »User Agent Accessibility Guidelines« (UAAG) in den verbreiteten Browsern lässt ebenfalls zu wünschen übrig, sodaß die Hilfsmittel leider nach wie vor darauf angewiesen sind, durch Erraten aus Murks-Code das Beste herauszuholen (was oftmals dazu führt, dass sauberer Code falsch verstanden wird).
In Zeiten Web-basierter Applikationen wird es jedoch für Hilfsmittel immer wichtiger, auf die Accessibility-Schnittstellen der jeweiligen Betriebssysteme zu setzen, über die sie mit Informationen zu Strukturen und Inhalten, Rollen und Zuständen von Bedienelementen etc. versorgt werden. Nur so kann aus Sicht der Anbieter und Nutzer ein konsistentes Verhalten einer Anwendung auch in den verbreiteten Computer-Hilfsmitteln gewährleistet werden.
Wo diese Schnittstellen unterdokumentiert oder lückenhaft sind (wie im Falle MSAA) könnte ein neues API namens IAccessible2 helfen, das von IBM entwickelt wurde und über die Free Standards Group allen interessierten Hilfsmittel-Herstellern zur Verfügung gestellt wird. Der Code fungiert quasi als Zwischenebene und ermöglicht es damit auch, die Anwendungen einfacher auf andere Plattformen zu portiern. Bereitgestellt werden Funktionen, die bisher für Hilfsmittel nicht zugänglich waren, oder die für Programmierer nur über unschöne Hacks zu erreichen waren (was dann z.B. zu den berüchtigten Abstürzen bei Kollisionen der Grafikkarten-Treiber führt und verhindert, dass man bestimmte Hilfsmittel gemeinsam auf einem Rechner betreibt).
Aus Webentwickler-Sicht besonders interessant ist, dass hiermit auch die WAI-ARIA Roadmap in Hilfsmittel und Browser implementiert werden kann, ohne dafür die gesamte Anwendung umzuschreiben. Da namhafte Hersteller wie Freedom Scientific, GW Micro, IBM, das Mozilla Project, Oracle, SAP und Sun bereits ihre Unterstützung zugesagt haben kann man in Zukunft damit rechnen, dass Webapplikationen auch mit heute noch problematischen Hilfsmitteln genutzt werden können.
Weitere Berichterstattung zum Thema bei Golem: »IAccessible2 für mehr Barrierefreiheit« sowie bei der Linux Foundation: »The Free Standards Group to Standardize New Accessibility Interfaces«.
Wenn Sie schon immer mal wissen wollten, was dieses DOM-Dings ist, und wie moderne Skripte geschrieben werden sollten – der JavaScript-Veteran Douglas Crockford hat eine sehens- und hörenswerte (englischsprachige) Präsentation zum Thema »Theory of the DOM« abgeliefert: Teil 1 (31 Minuten), Teil 2 (21 Minuten) und Teil 3 (26 Minuten) (Flash-Video, via)
Ebenfalls lesenswert:
