Der nachfolgende Artikel von Joe Clark ist von uns übersetzt worden und ist in niederländischer und englischer Fassung bei www.naarvoren.nl nachzulesen. Joe Clark ist Journalist, Autor (Building Accessible Websites - New Riders, 2003) und Unternehmensberater für Barrierefreie Informationstechnik aus Toronto, Kanada. Joe Clark beschäftigt sich schon seit 20 Jahren mit dem Thema Accessibility (und grafischer Gestaltung).

Bevor es richtig losgeht, sollte man vielleicht einfach mal pauschal feststellen, dass es zwei Hauptgründe gibt, warum Menschen sich in die Produktion von Webseiten stürzen. Entweder sie lieben es zu programmieren (Techniker), oder sie lieben die grafische Gestaltung im Internet (Designer).

Interessanterweise ist es heutzutage möglich, sozusagen gleichermaßen Techniker und Designer in Personalunion zu sein. Vorbei sind die Zeiten, als Designer noch begierig auf Menschen mit akademischem Abschluss schielten und umgekehrt. Heute kann jeder, der über Grafik-Design Fähigkeiten verfügt Webstandards nutzen, um ansehnliche Webseiten zu entwerfen. Webseiten, die ausreichend für fast alle, ja sogar hervorragend für die Mehrzahl aller Besucher funktionieren, einschließlich der Besucher mit einer Behinderung. Dieser Artikel wird eine Anzahl von Details untersuchen, die das Zusammenspiel von Barrierefreiheit und Webdesign beeinflussen. Wir werden feststellen, dass es neue Methoden gibt, um sicherzustellen, dass sogar Internetseiten, die Design sehr ernst nehmen, adäquat nutzbar sind für Menschen mit einer Anzahl häufig auftretender Behinderungen. Und dabei werden wir entdecken, warum es wichtig ist, dass manche Besucher Ihrer Internetseiten, das von Ihnen gewählte Design Ihrer Seite vollkommen abschalten können - und dass das noch nicht bedeutet, dass man dann das Design für alle anderen Besucher ebenfalls vergessen kann.

Die gute alte Zeit

Vielleicht erinnern Sie sich noch an die dunkle Vergangenheit der Webentwicklung. Vor Jahren war es in Ordnung, mit irgendeiner HTML-Kombination Internetseiten zu bauen, solange das Ergebnis nur in unserem Lieblings-Browser so dargestellt wurde, wie man es wollte (wir haben immer noch einen Lieblings-Browser, nur sind unsere Argumente dafür heute besser). Um das Ganze auch gut aussehen zu lassen, hat man den Code mit Elementen, wie font und jedermanns Liebling blink, die man heute Präsentations-Elemente nennt, aufgepeppt. Hauptsache es lief, oder?

Im Zeitalter von Webstandards weiß man, wie unsäglich diese Art und Weise des Codens war. Webseiten waren bleischwer, Struktur und Inhalt waren nicht getrennt, HTML funktionierte meist nur in einem Browser, zerfiel jedoch im nächsten dann vollkommen. Dessen ist man sich heute bewusst und man hat sogar einen schönen Sammelbegriff für diese Art von Quell-Code gefunden: HTML-Suppe. Eine Anzahl anderer Fakten über Barrierefreiheit sind allerdings noch nicht so weit durchgedrungen:

1. Die Zugänglichkeit von Internetseiten für Menschen mit einer Behinderung (oder wie es im Original schöner heißt, mit einem Handicap) war früher viel schlechter. Wenn Browser schon die allergrößte Mühe hatten, sich durch den ganzen Code-Müll zu wühlen, um dahinter zu kommen, wie eine Webseite eigentlich richtig dargestellt werden sollte, kann man sich vorstellen, wie viel Mühe es Screen-Reader kostete, denselben Code in Sprache oder Braillezeichen umzusetzen. Man wusste übrigens ohnehin kaum, was ein Screen-Reader war, obwohl diese auf jeden Fall schon seit 1989 auf dem Markt waren (zu der Zeit ist nämlich OutSpoken für den Macintosh erfunden worden).
2. Sobald das gesamte Konzept von barrierefreiem Webdesign etwas weiter bekannt wurde - das wird wahrscheinlich etwa 1999 gewesen sein, als die Web Content Accessibility Guidelines 1.0 (WCAG) veröffentlicht wurden - kam es sozusagen zu einer Überreaktion. Einige Entwickler und eine große Anzahl von Befürwortern von Barrierefreiheit beschlossen, dass sehr grafische Internetseiten nur aufgrund ihrer Grafiken unzugänglich seien. Es war zu der Zeit nicht schwer, Artikel zu finden, die Nur-Text-Seiten als Alternative empfahlen, da diese deutlich besser zugänglich sein sollten, zumindest besser geeignet für blinde Menschen. Joe Clark hat 1995 selbst einen Artikel mit ähnlicher Botschaft veröffentlicht.
3. Während alle Beteiligten damals eiligst versuchten, das Internet für blinde Menschen barrierefrei zu machen, vergaßen viele, dass es auch Menschen mit anderen Behinderungen gibt, die das Internet ebenfalls nutzen, und dass viele dieser Menschen sehr wohl hervorragend sehen können. Diese Menschen honorieren, begrüßen, ja, erwarten sogar gutes barrierefreies Webdesign, genauso, wie andere sehende Menschen es auch tun. Obendrein schmiss man damals die schlecht sehenden Menschen und Menschen mit anderen Einschränkungen einfach in einen Topf mit Blinden.

Über einen Zeitraum von etwa zwei Jahren, etwa zum Zeitpunkt des Jahrtausend-Wechsels, entwickelte sich ein Bewusstsein in Richtung barrierefreies Webdesign: Von einer Zeit ohne Regeln in der Webentwicklung, über die Feststellung, dass es doch einige nützliche Regeln gab (zum Beispiel WCAG), bis hin zum heutigen Tage, wo man allenthalben die irrtümliche Überinterpretation dieser Regeln gerade bei visuell reizvollen Seiten beobachten kann.

Heutzutage

Heute können Webentwickler auf die Zeit um 1999 zurückblicken, so wie Vorstädter, die es in der großen Stadt geschafft haben, vielleicht auf die Zeit zurückschauen, als sie noch die Bauern vom Lande waren. Keiner denkt heute mehr gerne an die Zeit und an die beschränkte Arbeitsweise von damals zurück. Zu viele Font-Tags in unserer Vergangenheit. Zu viele "Optimiert für Netscape Navigator" Banner auf den Seiten.

Aber soll man deshalb heute nicht mehr von damals reden? Jetzt wo alle erwachsener und erfahrener sind als damals? Jetzt wo viele den Sinn von Webstandards begriffen haben.

1. Mittlerweile ist es bekannt, dass man altes HTML nicht einfach in eine Text-Datei stopfen kann, auch wenn das Ergebnis im Lieblings-Browser hinterher zufällig gut aussieht, sondern dass valides HTML existiert, das man auch einsetzen kann. Damals wurde ausgeklügelt, was valides HTML eigentlich ist, obwohl es zu dieser Zeit kaum Hilfestellungen zu diesem Thema gab und obwohl es fast unmöglich ist, Menschen, die sich mit der Materie nicht befassen, zu erklären, was sich hinter dem Begriff valides HTML eigentlich verbirgt. (Die Beste Art und Weise es zu erklären, ist wohl nach wie vor, zu sagen: Valides HTML ist so ähnlich, wie grammatikalisch korrektes HTML .)
2. Heute verwendet man nicht nur valides HTML, sondern auch valides semantisches HTML, worin HTML-Elemente nach ihrer tatsächlichen Bedeutung eingesetzt werden und nicht mehr danach, was die Elemente in einem Browser hinterher anzeigen. Man hat endlich gelernt, Überschriften, Paragrafen, Bilder, Listenelemente und ähnliches zu unterscheiden und in korrekter Markup-Sprache auszudrücken.
3. Aber tief im Inneren schämen sich heute noch viele Webdesigner für die Tatsache, dass sie noch immer einige Dinge aus ihrer dunklen Vergangenheit schön finden. Zum Beispiel Singles von Dead or Alive oder Wham! Oder eben wahnsinnig cool aussehende Websites. Und manch einer macht sich Sorgen, dass andere im Club der standardkonformen HTMLer einen Blick auf neue, gut aussehende Websites, die man so mühevoll ineinander geschraubt hat, werfen und einfach annehmen könnte, dass sich sowieso nur HTML-Schrott unter der Motorhaube befindet. Und niemand will, dass seine besten neuen Freunde auf ihn runterschauen.

Der neue Freund CSS

Man hat mittlerweile noch ein paar andere Dinge gelernt. Wir wissen zum Beispiel heute, dass es nicht unwichtig ist, nach der Qualität der Daunen zu schauen, wenn man nach einem neuen Kopfkissen Ausschau hält. Oder dass es Sinn macht, im Restaurant nicht an der Vorspeise zu sparen, wenn man nicht als einziger am Tisch ohne Essen sitzen möchte. Und man weiß heute auch, dass der Ingenieur namens HTML mit einer sehr angesehenen und hippen Innenausstatterin verheiratet ist: CSS.

Natürlich, der Ingenieur kann Stützbalken so aneinander zimmern, dass Oma nicht auf abscheuliche Weise in einem einstürzenden Gebäude ums Leben kommt, aber wenn man über Gardinen sprechen will, sollte man ihn vielleicht einfach in den Keller schicken, wo er schön mit seiner Modelleisenbahn spielen kann, um ihr, der Innenausstatterin, den Weg für die wirklich wichtigen Dinge freizumachen.

Cascading Stylesheet - schon der Name klingt unglaublich elegant - verweist widerspenstige Browser endlich auf ihren zugedachten Fleck. CSS befiehlt Browsern endlich, HTML-Elemente so zu zeigen, oder besser gesagt, zu präsentieren, wie es der Gestalter ursprünglich wollte.

Wir sprechen jetzt über echte Macht! Jetzt, da man die Knochen und die Körperstruktur des Modells (HTML) herausgearbeitet hat, kann man es in jeden glamourösen, glitzernden und tief ausgeschnittenen Abendfummel (CSS) schmeißen, den man sich nur vorstellen kann. Man kann mit CSS endlich die Struktur, also den Inhalt, von der Präsentation, also dem Design, trennen.

Aber lässt man gehandicapte Menschen damit im Regen stehen? In manchen Fällen ja.

CSS im Dienste der Barrierefreiheit

Das World Wide Web Consortium - unsere Verwandten vom Lande - haben ein wirklich nettes Dokument über CSS und Barrierefreiheit entwickelt, aber eigentlich findet sich in diesem Dokument wenig brauchbares. Es scheint irgenwie wenig mit grafischer Gestaltung und Webdesign zu tun zu haben, wie man es aber eigentlich auch nicht anders von den Verwandten vom Lande, die doch immer etwas weltfremd auf unseren Familienfesten erscheinen, erwarten konnte.

Auf den ersten Blick sieht man nicht, dass CSS viel mit Barrierefreiheit zu tun hat, angesichts der Tatsache, dass alle nur von validem HTML reden. Aber selbst wenn man sich als Webdesigner an Standards hält, ist es möglich, Internetseiten zu produzieren, die für manche Menschen mit Behinderung schwierig, oder sogar unmöglich zu benutzen sind.

Blinde Menschen

Für jemanden, der überhaupt nichts sieht, oder zumindest so schlecht sieht, dass er eigentlich fast nichts sieht, ist die Arbeit eines Webdesigners vollkommen unrelevant. Dann nämlich wird die betreffende Website nur mit Hilfe eines Screen-Readers besucht, einer so genannten Vorlese-Software, die dem Besucher die Texte auf der Seite entweder vorliest, oder zusätzlich auf einer Braillezeile ausgibt. Sichtbare Elemente der Website sind davon, vom Text abgesehen, nicht betroffen.

Natürlich braucht es Designer nicht zu kümmern, wenn blinde Menschen ihre prächtigen grafischen Ergüsse nicht sehen können. Denn diese können ja tatsächlich nichts sehen. Zwar mögen einige Designer denken, dass blinde Menschen wahnsinnig viel verpassen, und einige blinde Menschen werden das vielleicht auch denken, aber als Designer kann man daran halt auch nicht viel ändern.

So, oder so ähnlich, sollte man aber wohl nur reden, wenn man zumindest semantisch valides HTML verwendet. Denn falls man immer noch altmodische HTML-Wüsten produziert, werden blinde Menschen, die einen Screen-Reader einsetzen, auch weiterhin sehr viel Mühe haben, sich ihren Weg durch die Internetseite zu bahnen. Überschriften, Links, Listen und ähnliche Strukturen (ja sogar Tabellen) können, so sie denn intelligent verarbeitet sind, von modernen Screen-Readern durchaus gelesen werden. Wenn man es richtig macht, macht es auch keinen großen Unterschied, dass ein blinder Besucher das Design der Seite gar nicht sehen kann.

Es gibt allerdings eine Anzahl von Ausnahmen, von denen einige ziemlich überraschend sind.

Navigation

Seinen Weg durch eine Website zu finden wird ab dem Moment ziemlich wichtig, wenn man sich die Seite nicht mehr, wie für Sehende üblich, in der Alles-zur-gleichen-Zeit-Methode ansehen kann, sondern linear abtasten muss. Sehr komplexe Seiten-Layouts mit mehreren Navigationsbalken und unzähligen Links sind oftmals vollkommen unnötig und vor allem lästig für Nutzer von Screen-Readern. Höhere Nutzerfreundlichkeit (Usability) führt in diesem Fall auch zu einer verbesserten Zugänglichkeit (Accessibility).

Reihenfolge des Codes

Screen-Reader arbeiten sozusagen als Browser-Aufsatz (fast ausnahmslos Internet Explorer für Windows). Die wichtigsten Screen-Reader sind davon abhängig, wie Browser CSS interpretieren, allerdings haben sie auch noch ihre eigene Interpretation von CSS. Unter bestimmten Umständen - ziemlich hypothetisch, und niemand kann ein klares Beispiel dafür angeben, wo es auch tatsächlich passiert - könnten Float-Elemente in CSS durch Screen-Reader auf eine eigenartige Art und Weise vorgelesen werden, weil die Reihenfolge im HTML-Code für solche Layouts von Bedeutung ist. Eigentlich ist das ein Grund, warum es bessere Screen-Reader geben sollte, daher muss man sich selbst um das Problem kümmern, bis eine neue Generation von Screen-Readern erhältlich ist - zumindest in der Theorie.

Alternativen für Bilder

Wenn man CSS einsetzt, um ein Bild durch einen Text zu ersetzen (statt der altmodischen Methode ), gibt es keine bekannte Methode, die garantiert, dass der Alternativ-Text auch tatsächlich von Screen-Readern vorgelesen wird. (Das hängt damit zusammen, wie Screen-Reader mit visibility: hidden und selbst display: none in CSS umgehen. Ein zukünftiger Reader Media Type (www.w3.org) kann da vielleicht einen Fortschritt bringen.) Für manche Bilder mag es ja nicht weiter schlimm sein, dass sie für Screen-Reader unsichtbar sind und für andere wiederum doch. Es bleibt dabei jedem selbst überlassen, herauszufinden, auf welche Bilder das nun zutrifft.

Verborgener Text

Der Einsatz von Text-Alternativen für Bilder hält aber noch ein weiteres Problem bereit. Wenn man visibility: hidden oder auch display: none verwendet, um einige Texte unsichtbar zu machen, lesen manche Screen-Reader trotzdem den Text vor, oder geben ihn als Braillezeichen wieder. Unsichtbarer Text wird oft eingesetzt, um Webseiten mit werbenden Schlagworten zu versehen, wobei es auch eine Anzahl respektabler Anwendungen, wie Browser-Upgrade Anleitungen oder versteckte Hinweise auf Veränderungen von W3C-Spezifikationen, gibt.

Visuelle Behinderungen

Leider ist es so, dass manche Dinge, die für Designer sehr verlockend sind, das Online-Leben für Menschen mit visueller Einschränkung schwierig machen.

Farbkombinationen

Hier gibt es mehr oder weniger zwei Gruppen, um die man sich Sorgen machen muss: Zum einen, Menschen mit angeborener Farbblindheit, zum anderen Menschen mit bestimmten Formen der Fehlsichtigkeit, die auf eine andere Weise Farben nur schwer erkennen können, als die Gruppe der Farbenblinden.

Menschen die farbenblind sind sehen immer Farben. (Die einzige nennenswerte Ausnahme wird Achromatopsie genannt und betrifft nach Schätzungen ungefähr 0,03% aller Menschen. Diese Menschen sehen - soweit sie das bestimmen können - alles in Graustufen.) Das Problem ist mehr, dass es eine Reihe von Farben gibt, die Farbenblinde Menschen durcheinander bringen. Rot und Grün sind klassische Farbkombinationen, die für Irritationen sorgen, allerdings sorgen auch viele rötliche und grünliche Farbabstufungen für Verwirrung. Diese Formen der Fehlsichtigkeit, die Mühe mit der Unterscheidung von rot/grün verursachen, nennen sich Protanopie und Deuteranopie, die auch in abgeschwächter Form auftreten und Protanomalie und Deuteranomalie heißen.

Die Anzahl der Menschen, die Probleme haben blau und grün auseinander zu halten, ist deutlich geringer und nennt sich Tritanopie. Manche Menschen entwickeln irgendwann im Leben diese Form der Farbblindheit, wogegen Protanopie und Deuteranopie meistens erblich sind. Ungefähr vier bis acht Prozent der Bevölkerung in westlichen Ländern (meistens Männer) haben in der einen oder anderen Form eine Abweichung der Farbsichtigkeit.

Farbblindheit führt zu Symptomen, die sich durch bestimmte Muster bemerkbar machen. Dabei ist es nicht sonderlich schwierig, sich Regeln zu überlegen, die diesen Mustern von vorneherein begegnen. Auch Webdesigner müssen keinen großen Aufwand betreiben, um diese Probleme in den Griff zu bekommen. Man muss eigentlich nur dafür Sorge tragen, dass Farbenkombinationen, die oft zu Problemen führen, nicht in irreführender Weise verwendet werden. Man kann durchaus rot und grün, oder blau und grün auf derselben Seite einsetzen, man darf sie halt nur nicht nebeneinander setzen, wenn man vom Besucher erwartet, dass er die Farben auseinander halten kann. (Und selbst das kann man machen, wenn man noch auf andere Weise für Unterscheidung sorgt - rote und grüne Buttons nebeneinander sind durchaus möglich, wenn der Navigationstext alleine ausreichend Aufschluss über den Unterschied liefert.)

Sehschwäche

Alles wird allerdings ein bisschen komplizierter, wenn es um Sehschwäche geht - Menschen, die noch über einen Teil ihres Sehvermögens verfügen. Was diese Menschen brauchen unterscheidet sich enorm und jede Person ist mit ihrer speziellen Form der Sehschwäche anders. Manche Behinderungen, wie das Vergilben der Iris als Folge des natürlichen Alterungsprozesses, sorgen für eine Veränderung der Farbwahrnehmung.

Sicherlich bedeutet dies ein Alptraum-Szenario für jeden Webdesigner. Selbst, wenn man die Marketing-Schlagworte über HTML und CSS im Schlaf runterbeten kann (Trennung von Inhalt und Design, etc.) Selbst wenn man sehr gut damit leben kann, dass blinde Menschen das eigene Webdesign halt nicht sehen können. Sehbehinderte Menschen wollen aber etwas sehen, und sie nutzen das Design des Designers auf eine Art und Weise, die das ursprüngliche Design zu einer fürchterlichen Parodie seiner selbst macht.

Sehbehinderte Menschen müssen folgende Dinge selbst einstellen können:

1. Schrift in Größe und Laufweite
2. Vorder- und Hintergrundfarbe
3. Reihenfolge (Layouts mit mehreren Spalten sind unpraktisch)
4. Navigation (wenn alle Buchstaben enorm groß sind, ist es schwer herauszufinden, wo man sich gerade befindet)

Das ist nun eine ganz neue Herausforderung für Webdesigner, allerdings gibt es gute Nachrichten: Auch sehbehinderten Menschen kann geholfen werden - und in vielen Fällen kann man als Designer immer noch ziemlich viel Einfluss auf das Ergebnis ausüben.

Stylesheet-Switcher

Beim Entwickeln von Websites kann man eigentlich so viele verschiedene CSS-Versionen einsetzen, wie man will, um alternative Anzeigemöglichkeiten anzubieten - gerade für sehbehinderte Menschen. Man kann durchaus ein oder mehrere alternative Anzeigemöglichkeiten einbinden, um zum Beispiel die Hauptnavigation direkt am Anfang einer Webseite zu platzieren (ein "Sie befinden sich hier" Ariadne-Pfad oder ähnliche Lösungen) und man kann auch entsprechend größere Schriften in hellen Farben auf dunklem Hintergrund verwenden (gedämpftes Weiß auf einem schwarzen Hintergrund funktioniert gut). Jemand, der eine derartige Darstellung bevorzugt oder braucht, kann einfach den entsprechenden Stil auswählen.

Es gibt verschiedene Möglichkeiten das Interface einer Website an einen Stylesheet-Switcher zu übergeben:

Auswahlbutton auf der Seite

In Anbetracht der Tatsache, dass die meisten schlecht sehenden Menschen kaum Gebrauch von Browsern machen, die die Möglichkeit bieten, Stylesheets zu wechseln, wie Mozilla, muss man dafür sorgen, das die Besucher irgendetwas an die Hand bekommen, womit sie Stylesheets automatisch wechseln können, zum Beispiel Schaltflächen oder Links. Hier verstecken sich allerdings noch einige Haken und Ösen:

1. Die meisten Gestalter setzen diese Art von Schaltflächen nur ein, um die Schriftgröße ein klein wenig zu verändern. Selten findet sich eine Version, die das ganze Erscheinungsbild einer Seite verändert.
2. Oft sind die Schaltflächen sehr klein und unauffällig, weil Gestalter diese Elemente auf einer Seite auch nicht zu sehr ins Auge springen lassen wollen.
3. Die Terminologie dieser Schaltflächen ist äußerst uneinheitlich, was auch den Ort auf der Webseite betrifft, wo die Schaltflächen für die Stylesheet-Switcher zu finden sind. Dabei sollte man nicht vergessen, dass die Stylesheet-Switcher für Besucher gedacht sind, die ohnehin schon schlecht sehen. Meistens müssen sie aber wirklich verdammt intensiv suchen, um die Schaltflächen für die Stylesheet-Switcher überhaupt finden zu können. Und das, obwohl sehbehinderte Menschen ja vorher gar nicht wissen, ob sich auf der Seite überhaupt ein Stylesheet-Switcher befindet.

Präferenz-Auswahl

Vielleicht ist es grundsätzlich das Beste, eine eigene Seite anzubieten, auf der Besucher ihre Präferenzen für die Darstellung der jeweiligen Internetseite vorauswählen können, die dann möglicherweise sogar durch Einsatz von Cookies für spätere Besuche gespeichert werden. Eine wirklich ambitionierte Seite sollte dem Besucher die Möglichkeit bieten, aus einer großen Anzahl von verschiedenen Schriftgrößen (oder der Option, direkt eine bestimmte Schriftgröße einzugeben) und diversen Farbkombinationen auszuwählen. Allerdings gäbe es da natürlich auch noch das Problem, dass diese Präferenz-Auswahl-Seite ebenfalls barrierefrei sein muss. Das sollte man wahrscheinlich am besten durch eine Seite mit großer Schrift, hellem Text und dunklem Hintergrund, zumindest im Bereich des Stylesheet-Switchers erreichen. (In ferner Zukunft werden vielleicht neue CC/PP Empfehlungen durch das W3C allgemein eingeführt, sodass diese Präferenzen für jeden Besucher ausgeführt werden können.

Joe Clark hat eine lange Liste von Internetseiten aufgestellt, die Stylesheet-Switcher einsetzen (und die Liste ist noch lange nicht komplett). Man kann sicherlich die eine oder andere Lösung einfach mal ausprobieren und nachverfolgen.

Vorher-Nachher Vergleich

Aber jetzt zur Umsetzung: Wenn man Barrierefreiheit von Webseiten für sehbehinderte Menschen verbessern will, ohne das grundsätzliche Design der Seite für normal sehende Menschen zu zerstören, stellt sich die Frage: Wie sieht eine solche Seite denn eigentlich vor und nach dem Updaten aus?

Vorher:

1. valides HTML und CSS
2. Grafische Gestaltung ist eigentlich egal
3. keine Verwendung von Farben (wie zum Beispiel rot und grün, oder blau und grün) auf missverständliche Weise, die dazu geeignet ist, Besucher zu verwirren
4. ein Layout mit mehreren Spalten
5. am liebsten eine sehr klare Art und Weise, um Stylesheets zu wechseln oder Präferenzen einzustellen.

Nachher:

1. zusätzliche Stylesheets (mit aussagekräftigen Titeln für die Links: die werden nämlich im „Use Style“ Optionsmenü von Mozilla angezeigt.)