Eine kleine Untersuchung zur Barrierefreiheit von Lightboxes
Dieser Beitrag von Oliver Siemoneit zur Zugänglichkeit und Barrierefreiheit sogenannter Lightboxes besteht aus drei Teilen: Teil 1 befasst sich mit den Grundlagen der Zugänglichkeit von Lightboxes und ist ziemlich technisch und theoretisch. Teil 2 ist dagegen eher eine Spielwiese: Hier wird der entwickelte Prototyp einer voll zugänglichen Lightbox ausführlich vorgestellt. Teil 3 schließlich schildert Grundlegendes zur Installation und Verwendung des neuen Accessibility-Plugins für das verbreitete Lightbox-Script ColorBox.
Autor: os
Die Grundlagen: Lightboxes und Barrierefreiheit
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. In ihrer rudimentärsten Form sind Lightboxes eigentlich nicht viel mehr als zwei simple <div> Container, die per JavaScript sporadisch in das DOM eingebracht werden, etwa dann, wenn der Nutzer auf einen Link zu einer Bildergalerie klickt. Mittels CSS wird einer dieser Container so formatiert, dass er das gesamte Browserfenster ausfüllt und die darunter liegende Webseite ausgraut. Der andere Container ist die Lightbox mit dem Inhalt selbst, die mittels des z-order-Attributs über den halbtransparenten, grauen Container gelegt wird. Zusätzlich wird die Lightbox oft horizontal und vertikal auf dem Schirm zentriert, was bei dem Nutzer insgesamt den Eindruck erweckt, vor einer klassischen Desktop-Umgebung mit einem geöffneten Dialogfenster zu sitzen.
So schön dieser Effekt auch ist, aus Sicht der Zugänglichkeit und Barrierefreiheit bringt er jedoch etliche Probleme mit sich. Die Hauptkritikpunkte sind 1) die Benachrichtigung des Nutzers und 2) die Bedienbarkeit per Tastatur. Für den uneingeschränkt sehenden Nutzer dürfte es ein Leichtes sein zu erkennen, was auf dem Bildschirm vor sich geht. Nicht so aber für blinde Nutzer, die auf die Hilfe von Screenreader angewiesen sind: Die Ad-hoc-Einbringung neuer Inhalte in die Seite per JavaScript bleibt dieser Nutzergruppe oft verborgen. Genau dies ist der Grund weshalb W3C WAI WCAG 2.0 Technik SCR37 fordert, dass Dialoge in das DOM nur direkt hinter dem auslösenden Element eingebracht werden sollen, sodass diese Inhalte unmittelbar nächstes Element in der Vorlesereihenfolge der Screenreader sind. Zusätzlich schlägt WCAG 2.0 Technik G91 vor, den Zweck eines Links bzw. die Effekte seiner Aktivierung zu beschreiben indem – wie in Technik C7 beschrieben – Teile des Linktextes per CSS verborgen werden. All diese Maßnahmen helfen sicherzustellen, dass 1) der Screenreader-Nutzer vor der Aktivierung des Links weiß, was geschehen wird und 2) dass die neu eingebrachten Inhalte auch vorgelesen werden. Leider ist es jedoch so, dass die meisten der existierenden Lightbox-Lösungen sich nicht an diese basalen Webstandards halten, sondern die Lightbox immer am Anfang oder am Ende des <body>-Elements in das DOM einbringen. Dies hat zwei Gründe:
- Browser-Kompatibilität: Das Einbringen der Lightbox am Anfang oder Ende des
<body>-Elements ermöglicht es, die Box mitposition:absolutezu positionieren. Die eigentlich benötigteposition:fixed-Positionierung, die von manchen älteren Browsern schlecht unterstützt ist, wird somit umgangen. - Vererbung von CSS-Eigenschaften: Die Lightbox ist nicht Child oder Child-Child von irgend einem anderen Element, weshalb das einheitliche Erscheinungsbild bessert kontrolliert werden kann. Da keine vererbten Eigenschaften und Styles vorhanden sind, ist auch kein extra »CSS Reset« für die Lightbox notwendig.
In naher Zukunft wird die W3C WAI ARIA 1.0-Richtlinie weitere Verbesserungen für Screenreader-Nutzer bringen, weil die Richtlinie genau auf solche Dinge abzielt wie Lightboxes. Obwohl ARIA 1.0 noch kein offizieller W3C-Standard ist, haben die neuesten Screenreader-Versionen bereits Teile davon implementiert. Die Grundidee von ARIA 1.0 ist die Anreicherung von Seitenelementen (wie etwa div-Elemente) mit semantischen Informationen, Informationen also über deren Rolle oder Funktion bzw. Funktionalität. Nach ARIA 1.0 benötigt eine Lightbox z.B. die Rolle eines aria-role="dialog", ein Dialog selber hat immer auch einen Namen (aria-labelledby="title_div") usw. Um es kurz zu machen: All diese neuen Elementeigenschaften ermöglichen es Screenreader-Nutzern, dynamisch in das DOM eingebrachte Elemente zu identifizieren bzw. etwas über deren Zweck, Zustand und deren Beziehung zu anderen Elementen zu erfahren.
Der zweite Hauptkritikpunkt aus Sicht der Barrierefreiheit an Lightboxes ist die Bedienbarkeit per Tastatur. Viele Menschen wissen gar nicht: Man kann auf einer Webseite auch nur mit der Tastatur navigieren, u.a. unter Zuhilfenahme der Tab-Taste. Alle marktgängigen Browser unterstützen dieses Konzept (außer dem Opera-Browser, der ein sehr eigenes Konzept der Tastaturnavigation entwickelt hat). Und natürlich müssen Lightboxes als heutzutage fast normaler Bestandteil von Webseiten auch per Tastatur bedienbar sein. Leider sind es die meisten Lightboxes jedoch nicht oder nur eingeschränkt.
- WCAG 2.0 SCR37 fordert, dass eine Lightbox reguläres Element der normalen Tab-Reihenfolge zu sein hat bzw. dass das Drücken der Tab-Taste den Fokus in die geöffnete Lightbox setzt. Des Weiteren schlägt SCR37 vor, die Box zu schließen, sobald der Fokus verloren geht.
- Wenn die Lightbox sich wie ein modales Dialogfenster verhalten soll, muss nach ARIA 1.0 Authoring Practices 3.3 der Fokus innerhalb der Lightbox gehalten werden, d.h. die Tab-Navigation ist bei geöffneter Lightbox nur innerhalb der Lightbox möglich.
Das Schließen der Lightbox bei Fokus-Verlust bzw. das Halten des Fokus innerhalb der Box (was ein Überschreiben / Reimplementieren der eingebauten Tab-Navigation des Browsers bedeutet) ist jedoch alles andere als eine triviale Angelegenheit und erfordert einige programmiertechnische Anstrengungen. Eine gute Zugänglichkeit und Barrierefreiheit ist leider nicht umsonst zu haben, und jede als »leicht« beworbene Lightbox-Variante wird dadurch an Code um einiges schwerer. Zusätzlich ist es so, dass derartige Implementierungen auch Browser der neueren Generation erfordern, Browser, die document.activeElement und Event-Capturing (und nicht nur Event-Bubbling) unterstützen und keine Probleme mit dem position:fixed-Attribut haben. Gerade das Beispiel der Lightbox zeigt, wie schwierig es (zurzeit?) noch ist, eine Desktop-Umgebung im Browser nachzuempfinden. Denken Sie z.B. bloß an den Sachverhalt, dass bei einem blur-Event das Event-Objekt keinerlei Informationen darüber enthält, was den Blur ausgelöst hat bzw. welches Element als nächstes den Fokus erhalten wird. Obwohl Lightboxes also schon sehr verbreitet sind, befinden sich die Technologien zu ihrer korrekten und soliden Umsetzung wie ein stabiles DOM-Scripting und WAI-ARIA noch im Entstehen. Und auch wenn die Basistechnologien dafür vorhanden sind, gibt es aus Sicht der Usability und Accessibility immer noch grundlegende Einwände:
- Zum einen sind Lightboxes eben nur mit aktiviertem JavaScript zugänglich. Im Fall von ColorBox ist Inline-Content gar nicht zugänglich. Das Klicken auf einen Link zu einer Bildergalerie öffnet nur ein einzelnes Bild in einem nackten Browser-Fenster ohne jegliche Texte und Navigationshilfen. Dies ist nicht die Idee von Progressive Enhancement, die wir von Suchfeldern auf Webseiten kennen. Mittels JavaScript wird diesen Suchfeldern oft eine Auto-Complete-Funktion hinzugefügt. Die Suche auf der Webseite ist aber trotzdem problemlos auch ohne JavaScript möglich.
- Ein anderer Schwachpunkt ist die mangelnde Druckunterstützung für Lightbox-Inhalte: Bei geöffneter Box ist es bisher nicht möglich, komfortabel dessen Inhalte auszudrucken. Dies könnte etwa dann interessant sein, wenn man Formulare anzeigt und der Nutzer sich seine Eingaben »konservieren« möchte.
- Schließlich gibt es noch das Problem, dass manche Nutzer das Konzept einer Lightbox fundamental missverstehen: Sie klicken auf den Back-Button des Browsers, um die Box zu schließen. Dies schließt jedoch nicht die Lightbox im technischen Sinne, sondern lädt leider die zuletzt besuchte Seite.
Fazit: Wann und wo eine Lightbox auf einer Webseite eingesetzt werden kann, muss also sehr genau überlegt werden. V.a. ist genau zu überlegen, wie man durch einen gekonnten Einsatz von JavaScript und anderen Techniken der Idee des »Progressive Enhancement« besser gerecht werden kann als bisher.
In dem gleich noch näher darzustellenden Accessibility-Plugin ist jetzt auch eine experimentelle Druckunterstützung eingebaut. Das Problem mit der Druckunterstützung ist, dass sie eigentlich nur dann zuverlässig funktioniert, wenn die Lightbox nicht hinter dem auslösenden Element eingebracht wird, wie von WCAG 2.0 SCR37 aber gefordert. Dies ist ein klarer Nachteil. Weitere Tests müssen zeigen, ob es wirklich notwendig ist, die Lightbox immer nach dem auslösenden Element einzubringen oder ob es nicht ausreicht, beim Öffnen der Box per JavaScript den Fokus in die Box zu setzen. Sollte das Setzen des Fokus nicht ausreichen, wäre dieser Nachteil nicht aufzulösen: Die Verbesserung eines Aspekts der Zugänglichkeit (etwa für Screenreader-Nutzer) würde gleichzeitig einen anderen Aspekt der Zugänglichkeit (Drucken der Lightbox-Inhalte) verschlechtern.
Der Prototyp: Ein Accessibility-Plugin für ColorBox
Eine Warnung an all diejenigen, die den ersten Teil nicht gelesen haben: Das Plugin ist nur ein Prototyp, ein Proof-of-Concept. Es benötigt einen Browser der neuesten Generation. Das Plugin wurde bisher erfolgreich mit Firefox 3.6, Internet Explorer 8, Safari 5 und Opera 11 getestet.
Eine Lightbox nach WAI WCAG 2.0 Standard
WAI WCAG 2.0 Lightbox jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]
Diese Lightbox setzt die basalen, in WCAG 2.0 formulierten Standards für ein Dialogfenster um. Die Lightbox wird in das DOM direkt hinter dem auslösenden Element/Link eingebracht. Die Box wird sofort geschlossen, sobald der Fokus verloren geht.
Eine Lightbox als modales Dialogfenster nach WAI ARIA 1.0
Modale WAI ARIA 1.0 Lightbox jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]
Die Lightbox implementiert alle wichtigen ARIA 1.0 Eigenschaften. Darüber hinaus hat die Lightbox einen eigenen Keyboard-Handler, der den Fokus innerhalb der Box hält. Geht der Fokus (aus welchen Gründen auch immer) verloren, wird er sofort wieder in die Lightbox zurückgesetzt. Auf der Seite eingebettete Accesskey gehen jedoch weiterhin. Probieren Sie es doch einfach mal aus: Mit Accesskey=1 springen Sie an das obere Ende dieser Seite, mit Accesskey=2 an das untere Ende und Accesskey=3 bringt Sie zur Website von www.accessibility.at. Und falls Sie nicht wissen, wie Sie Accesskey in Ihrem Browser aufrufen können, gibt es in der englischsprachigen Wikipedia einen schönen Überblicksartikel zu Accesskeys in den unterschiedlichen Browsern.
Eine Lightbox als ein »hartes« modales Dialogfenster
Harte modale Lightbox jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]
Hartes modales Dialogfenster heißt, dass Accesskey bei geöffneter Box vorübergehend deaktiviert sind (selbst gestandene JavaScript-UI-Frameworks wie Dojo Toolkit oder YUI Dialogs scheitern an diesem Kriterium). Das Klicken auf den grauen Hintergrund schließt das Fenster nicht mehr. Das Tabben ist auf die Lightbox beschränkt ohne den Zugang zu den normalen Browser-Toolbars bzw. der Adressleiste einzuschränken.
Eine zugängliche Bildergalerie
Zugängliche Bildergalerie jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]
ARIA 1.0-Eigenschaften stellen ein semantisches Grundgerüst zur Verfügung. Das Foto ist durch seinen Titel und die aktuelle Position in der Bildergalerie »beschrieben« (aria-describedby). Der Vor- bzw. Zurück-Button »kontrollieren« (aria-controls) den Inhalt des Fotos. Zusätzlich wird für Screenreader-Nutzer per Ajax eine ausführliche Bildbeschreibung nachgeladen und im Titel-div versteckt. Schalten Sie in Ihrem Browser einfach die Style Sheets ab und Sie werden sehen, was gemeint ist. Jedes Foto verfügt über eine ausführliche Beschreibung der Bildinhalte, sodass blinde Nutzer ebenfalls eine Idee bekommen, was auf dem Bild zu sehen ist und die Bildergalerie genießen können.
![Zugängliche Bildergalerie jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]](content/ohoopee1.jpg){kind=link}
Automatische Erkennung alternativer Bildversionen für Menschen mit Farbsehschwäche
Automatische Erkennung alternativer Bildversionen jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]
Die obige Galerie enthält Bilder, die allesamt für Menschen mit einem Farbseh-Defizit eine echte Herausforderung darstellen. Das Accessibility-Plugin erkennt automatisch, wenn alternative Bildversionen auf dem Server zur Verfügung stehen und bietet einen Link dazu an. Die in den Alternativ-Versionen verwendete Bild-Korrektur für Farbfehlsichtige ist als kleines Kommandozeilen-Tool im Download-Paket enthalten. Das Tool implementiert einen ähnlichen Algorithmus wie Vischeck, basiert aber auf Arbeiten von Onur Fidaner. Bei Rot-Grün-Schwäche reicht es meist schon aus, eine Graustufen-Version des Bilder zur Verfügung zu stellen, wobei es wichtig ist, einen verbesserten Graustufen-Umwandlungs-Algorithmus zu verwenden wie etwa den von Martin Faust. Dieses Tool ist ebenfalls im Download-Archiv enthalten.
![Automatische Erkennung alternativer Bildversionen jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]](content/ishihara.png){kind=link}
Download, Installation und Bedienung des Accessibility-Plugins
Download des Skripts von accessibility.at: cboxa11y.zip (1.56 MB).
Das Accessibility-Plugin für ColorBox ist unter der MIT-Lizenz veröffentlicht.
Das Accessibility-Plugin ist für ColorBox V.1.3.15 geschrieben und benötigt jQuery 1.4.4. Achtung: Die Originalversion von ColorBox ist mit dem Accessibility-Plugin nicht lauffähig! Das Plugin ist auf die gepatchte jquery.colorbox.js-Datei und die gepatchte colorbox.css-Datei, wie im Download-Paket enthalten, angewiesen.
Bitte beachten Sie: Manche Features können sie nicht ohne einen lauffähigen http-Server testen. Der Extra-Text für Screenreader-Nutzer wird ebenso wenig funktionieren wie die automatische Erkennung alternativer Bildversionen.
Bitte beachten Sie: Es handelt sich bei dem Plugin um einen Prototypen, der einen Browser der neueren Generation erfordert (wie etwa Internet Explorer 8, Firefox 3.6, Safari 5 oder Opera 11).
Installation
Nehmen Sie die vorliegende Seite und die obigen Beispiele einfach als eine Vorlage, wie Sie ColorBox und das Plugin aufrufen können. Im Grund genommen ist es ganz einfach: Sie müssen in dem onComplete-Handler von ColorBox das Plugin einfach mit $.colorbox.a11ySetup(); initialisieren, etwa wie folgt:
$(".example3").colorbox({
inline:true,
width:"50%",
overlayClose:false,
onComplete: function() { $.colorbox.a11ySetup({
trapFocus:true,
forceInput:true,
focusFirstElement:true});}
});
Wie bitte? a11y?? a11y ist nur eine Abkürzung für ›accessibility‹ (so wie i18n eine für ›internationalization‹ ist).
Die Funktion $.colorbox.a11ySetup() akzeptiert folgende Parameter:
| Key | Default | Beschreibung |
|---|---|---|
focusFirstElement | false | Fokussiert bei einem Wert von 'true' das erste Element ansonsten das letzte (sollte der Schließen-Button sein). |
trapFocus | true | True: Das Tabben ist nur innerhalb der Lightbox möglich. |
forceInput | false | True: Accesskeys sind vorübergehend deaktiviert. |
dialogLabel | 'Lightbox' | ARIA-Label / Name der Lightbox. |
imageLabel | 'lightbox content' | Alt-Attribut des Bildes. |
imageOriginal | 'original version' | Text für den Button mit dem Link zur Originalversion. |
imageC2g | 'grayscale version' | Text für den Button mit dem Link zur Graustufen-Version. |
imagePro | 'protanopia version' | Text für den Button mit dem Link zur Bildversion für Protanope. |
imageDeu | 'deuteranopia version' | Text für den Button mit dem Link zur Bildversion für Deuteranope. |
imageTri | 'tritanopia version' | Text für den Button mit dem Link zur Bildversion für Tritanope. |
suffixLongDescURI | '' | i18n-Feature: Suffix Dateinamen Langbeschreibung Bild. |
Aus Sicht der Barrierefreiheit sind ferner diese ColorBox-Parameter von besonderem Interesse:
| Key | Default | Beschreibung |
|---|---|---|
returnFocus | true | Gibt den Fokus nach dem Schließen der Box an das aufrufende Element zurück (bitte nicht ändern!). |
overlayClose | true | False: Das Klicken auf den Hintergrund schließt die Box nicht mehr (harte modale Dialogbox). |
escKey | true | True: Ermöglicht das Schließen der Box mit Esc. |
arrowKey | true | True: Ermöglicht das Navigieren mit den Cursortasten innerhalb einer Galerie. |
previous | 'previous' | Text für den Zurück-Button. Sollte geändert werden, wenn die Standardsprache nicht Englisch ist. |
next | 'next' | Text für den Vor-Button. |
current | 'image {current} of {total}' | Text für die Positionsanzeige innerhalb einer Galerie. Sollte geändert werden, wenn die Standardsprache nicht Englisch ist. |
close | 'close' | Text für den Schließen-Button. |
onComplete | false | Von hier aus muss das Accessibility-Plugin aufgerufen werden. |
Bedienung
Bitte beachten Sie: Das Accessibility-Plugin funktioniert nicht mit automatisch weiterblätternden Bildergalerien. Dieses Feature ist für Screenreader-Nutzer relativ sinnlos. Screenreader-Nutzer benötigen Zeit, sich in der Box zu orientieren und sich den Beschreibungstext vorlesen zu lassen. Ein automatisches Weiterblättern wäre kontraproduktiv.
Bitte beachten Sie: Das Accessibility-Plugin funktioniert nicht mit iframes. Zurzeit gibt es einfach noch zu viele Probleme mit den unterschiedlichen Browsern.
Wichtiger Hinweis bezüglich dynamischer Änderungen von Lightbox-Inhalten bei modalen Boxen: Werden bei geöffneter Box fokusierbare Elemente hinzugefügt (sichtbar gemacht) oder gelöscht (versteckt), muss das Accesssibility-Plugin über die Änderungen mit der Funktion $.colorbox.a11yUpdateFocusableElements() informiert werden. Wenn Sie also z.B. mit jquery.toggle() einen div-Container ein- bzw. ausblenden, müssen Sie in der Callback-Funktion von toggle die Update-Funktion des Plugins aufrufen (d.h. zu dem Zeitpunkt also, in dem alle Animationen beendet sind und alle Elemente korrekt dargestellt werden):
$('#playercontrols').toggle('slow', function(){ $.colorbox.a11yUpdateFocusableElements(); });
Wichtiger Hinweis zu Accesskeys und modalen Dialogen: Accesskeys zu anderen Seiten sind problemlos. Accesskeys innerhalb einer Seite, etwa zu Ankern oder anderen JavaScript-Widgets, benötigen etwas Vorbereitung: Es ist Ihre Aufgabe, die Lightbox »von außen« zu schließen und die Fokus-Rückgabe von ColorBox an das aufrufende Element zu verhindern. Die Anker auf dieser Seite funktionieren nur, weil sie einen speziellen onclick-Handler haben, der die Rückgabe des Fokus mittels einer Helferfunktion des Accessibility-Plugins unterdrückt und anschließend "true" zurück gibt, sodass der Link auch wirklich ausgeführt wird:
<a href="#bottom" accesskey="2" onclick="$.colorbox.a11yReturnFocus(false); $.colorbox.close(); return true;">Accesskey=2: Zum Seitenende springen</a>
Bei einem JavaScript-Widget, das über einen Accesskey aufgerufen werden kann, würde man dagegen folgendes machen:
<a href="noscript.html" accesskey="3" onclick="$.colorbox.a11yReturnFocus(false); mywidget(); return false;">Accesskey=3: "mywidget" aufrufen</a>.
Leider funktioniert die obige Lösung nicht im Internet Explorer und mit Lightboxes, die die Settings trapFocus:false haben. Das liegt daran, dass der Internet Explorer beim Aktivieren eines Accesskeys den Ziellink nur fokussiert aber nicht ausführt. Um den Link auszuführen, ist zusätzlich das Drücken der Enter-Taste notwendig. Im vorliegenden Fall heißt das aber: Durch das Fokussieren des Accesskey-Links wird die Lightbox bereits geschlossen, was automatisch die Focus-Return-Funktionalität von ColorBox auslöst, die wiederum den Fokus vom Accesskey-Link weg auf das Element setzt, von dem aus die Lightbox gestartet wurde. Das anschließende drücken der Enter-Taste startet dann die Lightbox neu und führt nicht den Accesskey-Link aus. Dieses Verhalten ist einer der Gründe, weshalb empfohlen ist, Lightboxes grundsätzlich mit der Option trapFocus:true auszustatten.
Wichtiger Hinweis zu den versteckten Langbeschreibungen von Bildern: Das Accessibility-Plugin berechnet den Name bzw. URI der Beschreibungsdatei aus dem Namen bzw. URI der Bilddatei. Die entsprechende Beschreibungsdatei für das Bild "http://myserver.com/images/image1.png" ist z.B. "http://myserver.com/images/image1.html". Bilddatei und Beschreibungsdatei müssen also immer im gleichen Ordner liegen. Die Beschreibung von "image1.png" ist "image1.html". Zum Zwecke der Internationalisierung (i18n) kann mit dem Parameter suffixLongDescURI zusätzlich noch eine Nachsilbe für den Dateinamen angeben werden. Wenn Sie z.B. "DE" als Suffix angeben, wird der Dateiname der Beschreibungsdatei als "image1DE.html" berechnet. Dies ermöglicht es, zu ein und derselben Bildressource unterschiedliche Bildbeschreibungen vorrätig zu halten.
Wichtiger Hinweis zur automatischen Erkennung alternativer Bildversionen: Das Accessibility-Plugin leitet den Namen / URI der alternativen Bildversionen aus dem Namen / URI der Bilddatei ab. Das Suffix für die Graustufen-Version lautet "_C2g", für die Protanopen-Version "_Pro", für die Deuteranopen-Version "_Deu", für die Tritanopen-Version "_Tri". Das Bild "image1.png" hat also die alternativen Versionen "image1_C2g.png", "image1_Pro.png", "image1_Deu.png" und "image1_Tri.png". Und all diese Dateien müssen sich im gleichen Ordner befinden wie die Originalversion des Bildes.
So, das war's eigentlich! Viel Spaß damit und bitte bedenken Sie beim Einsatz von Lightboxes immer: Obwohl sich die Zugänglichkeit mit dem vorliegenden Plugin verbessert haben dürfte, sollte Ihnen klar sein, dass 1) der Inhalt der Lightboxes nur mit aktiviertem JavaScript zugänglich ist und dass 2) die Druck-Unterstützung von Lightbox-Inhalten schlecht ist. Für wichtige Formulare, die sich der Nutzer etwa ausdrucken möchte oder aber für Anfahrtsbeschreibungen, die nicht als PDF eingebettet wurden, ist eine Lightbox also nicht die beste Wahl.
Update: Für die Lightbox gibt es jetzt auch eine Druckunterstützung:
Druckunterstützung Einzelelement jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]
Druckunterstützung Gruppe von Elementen jetzt testen [Link überblendet Fenster mit einem modalen Dialogfeld]
Die Druckunterstützung ist lauffähig mit Safari 5, Firefox 3.6, Opera 11, geht jedoch nicht mit IE 8 (aber mit IE 9). Bitte beachten Sie: Dieses Feature fügt die Lightbox am Anfang des body-Elements ein und nicht, wie von WCAG 2.0 Technik SCR37 gefordert, direkt nach dem auslösenden Element. Das Drucken der Lightbox ist jedoch unmöglich, wenn sie Child oder Child-Child irgendeines anderen Elements ist. Wir haben hier einen klaren Nachteil: Die Verbesserung eines Aspektes der Zugänglichkeit (Lightbox nur hinter dem Trigger-Element) verschlechtert einen anderen Aspekt der Zugänglichkeit (Drucken des Lightbox-Inhaltes). Es sind weitere Test notwendig, um festzustellen, ob die Lightbox wirklich nur nach dem Trigger-Element eingebracht werden darf oder ob es nicht bereits ausreicht (wie implementiert), beim Öffnen der Box den Fokus automatisch in die Box zu setzten. Rückmeldungen hierzu bzw. Testergebnisse sind sehr willkommen!