CSS 2.1 ::Artikel
Die FIR-Technik: Tatsachen und Beurteilung
Das Original dieses Textes wurde zuerst am 20. Oktober 2003 unter dem Titel Facts and Opinion About Fahrner Image Replacement im Online-Magazin A List Apart veröffentlicht. Der Autor ist Joe Clark. Die Übersetzung erfolgte mit Genehmigung von A List Apart und dem Autor.
Translated with the permission of A List Apart Magazine and the author.
Einleitung
Weiterentwicklungen der FIR-Technik und vergleichbarer Methoden kommen heute schneller als seinerzeit der Fall der Berliner Mauer. In diesem Artikel werden Ergebnisse einiger längst überfälliger Untersuchungen vorgestellt, die das Verhalten der FIR-Technik in Vorleseprogrammen (Screen-Reader) beschreiben.
Die FIR-Technik ist eine standardsgemäße Technik, bei der mit Hilfe von Stylesheets und gewöhnlichem HTML ein sichtbares Bild dargestellt wird, das normalerweise aus Textzeichen besteht. Der Designer spezifiziert durch CSS, dass dieses Bild in den meisten Fällen auf dem Bildschirm ausgegeben wird. Sollte das Bild einmal nicht erscheinen, wird statt dessen das unterliegende HTML ausgegeben. Diese Technik wurde nach Todd Fahrner benannt, dem Vernehmen nach ursprünglich von C. Z. Robertson entwickelt und bekannt gemacht durch Douglas Bowman (dessen Website alle Einzelheiten der Codierung enthält) und Jeffrey Zeldmans Buch 'Designing with Web Standards'.
FIR ermöglicht es, durch Verwendung von einfachem Markup, wie <span>
innerhalb von <h1>
, gut aussehende Titelzeilen und andere Designelemente zu entwerfen. Der HTML-Text wird durch die Deklaration display: none
verborgen (streng genommen wäre auch visibility: hidden
möglich), das Bild des Textes wird als Hintergrundbild dargestellt.
Die Vorteile dieser Technik sind ein gefälliges grafisches Design und ein HTML, das etwas eleganter ist als <h1><img alt=""></h1
>. Diese Schachtelung ist sozusagen Ihre einzige Alternative, wenn Sie das Bild eines Textes als Titelzeile verwenden wollen. In Bezug auf Webzugänglichkeit ist FIR oberflächlich gesehen die bessere Technik, weil sie keine Grafiken innerhalb von Überschriften schachtelt.
Screen-Readers (Vorleseprogramme)
Wie bereits in einem älteren ALA-Artikel erläutert wurde, sind Screen-Reader Programme, die die Inhalte von Webseiten laut vorlesen, ebenso wie alles andere, was auf Ihrem Bildschirm erscheint. Dadurch wird der Computer für Menschen zugänglich, die blind oder stark sehbehindert sind. Diese Programme werden gelegentlich auch von Menschen mit angeborener Lesestörung (Dyslexia) verwendet. Sie sind eine Form von anpassender Technologie (Software oder Hardware), durch die ein Computer für einen behinderten Menschen zugänglich wird.
Dies sind die heute meistbenutzten Screen-Reader [Anmerkung d. Ü.: Aus Gründen des Copyright bleiben die Links so wie im Originalartikel vom Oktober 2003.]:
- IBM Home Page Reader (Dieses Programm ist größtenteils auf Webseiten, web-basierte E-Mail und Multimedia- Programme beschränkt.)
- Jaws (Freedom Scientific)
- Window-Eyes (GW Micro)
- OutSpoken (ALVA Access Group; wurde für Windows und Macintosh hergestellt, die Mac - Version wurde aber eingestellt)
- Emacspeak (Freeware für Linux; T.V. Raman)
- SpeakThis (Fonix)
Auswertung von Stylesheets
Die Fahrner-Image-Replacement-Technik verwendet zwei CSS-Techniken, von denen nur eine mit visuellem Styling zu tun hat. Dennoch stammen beide nicht aus dem Bereich des auditiven, sondern des visuellen CSS.
Unser Problem ist hier die Deklaration display: none
. Die Spezifikation schreibt folgendes zum Wert none
:
"Dieser Wert bewirkt, dass ein Element innerhalb der Ausgabestruktur keine Box bildet, d. h. das Element hat keine Auswirkung auf das Layout. Nachkommen dieses Elements bilden ebenfalls keine Boxes. Dieses Verhalten kann nicht geändert werden, auch dann nicht, wenn die Eigenschaft display
für die Nachkommen - Elemente auf einen anderen Wert gesetzt wird."
und:
"Bitte beachten Sie, dass der Wert none
nicht eine unsichtbare Box erzeugt, sondern überhaupt keine Box."
Daher bedeutet display: none
tatsächlich nichts anderes als 'Erscheinung: keine' oder 'Elimination: total'. Ein Element mit der Deklaration display: none
tilgt sich selbst.
Es gibt noch eine andere Option, die wir anwenden können: die Deklaration visibility: hidden
. In der Spezifikation steht dazu:
"Die generierte Box ist unsichtbar, d. h. völlig transparent, hat aber noch einen Einfluss auf das Layout. Nachkommen dieses Elements sind wieder sichtbar, wenn sie mit visibility: visible
deklariert werden."
Der sichtbare Unterschied liegt dann zwischen einer nicht-existenten Box und einer leeren Box.
Wie sollen Vorleseprogramme diese beiden Fälle behandeln?
Benutzertest der Screen-Reader
Ich weiß nicht, wie ich diese Frage beantworten soll, aber dank einiger Anwendertests weiß ich jetzt, wie Vorleseprogramme mit diesen Fällen umgehen.
Dazu habe ich mich an ein paar meiner Bekannten und an einige Mailing-Listen (WAI Interest Group, UVIP-Web-Test) gewandt. Ich bat sie, zu versuchen, einen mit FIR codierten Text mit jedem Vorleseprogramm zu lesen, das sie finden konnten.
Der Testfall war die eher simple Startseite des (heute eingestellten) Satiremagazins Ten Tears Ago in Spy. Diese Seite wurde von mir erstellt und erst kürzlich von Matt Mullenweg mit Hilfe von CSS-Layout und FIR neu gestaltet. Zwei Grafiken dieser Seite wurden mit FIR codiert, ich selbst hatte vorher einfache img
-Elemente verwendet.
Ergebnisse
Dann erstellte ich zwei Testseiten:
- Unter Verwendung von
display: none
. - Unter Verwendung von
visibility: hidden
.
Ich fand Anwender dreier verschiedener Versionen von Jaws, dazu Windows-Eyes, Home Page Reader und Hal. Auch für die nicht mehr weiterentwickelte Macintosh-Variante von OutSpoken erhielt ich Ergebnisse.
Die Ergebnisse sind besorgniserregend:
Produkt | display: none |
visibility: hidden |
---|---|---|
Hal version 5.20 | Liest nicht | Liest |
IBM Home Page Reader 3.02 | Liest nicht | Liest nicht |
Jaws (4.02, 4.50, 5.0 beta) | Liest | Liest |
OutSpoken 9 | Liest nicht | Liest nicht |
Window-Eyes 4.2 | Liest nicht | Liest nicht |
Analyse
Es erscheint klar, dass jedes Element, das mit display: none
deklariert ist, nicht dargestellt, vorgelesen oder anders ausgegeben werden sollte. Das gilt für alle Ausgabegeräte und für jeden Modus, in dem sie arbeiten. Ausgehend von dieser Definition, verhalten sich Hal, IBM Home Page Reader, OutSpoken und Window-Eyes richtig, während Jaws sich falsch verhält.
Für Elemente, die mit visibility: hidden
deklariert sind, kann man davon ausgehen, dass nicht vorgelesen werden sollte, sei es durch visuelle oder andere Geräte. Der einzige Unterschied zwischen den beiden Deklarationen liegt in den Auswirkungen auf das Bildschirm-Layout (visibility: hidden
beansprucht Platz auf dem Bildschirm, display: none
nicht). Ein Browser muss sich daran halten, ein Vorleseprogramm kann sie theoretisch ignorieren.
Eine Ausnahme könnte dann gegeben sein, wenn eine mit visibility: hidden
deklarierte Box die vorgelesene Reihenfolge oder einen anderen wichtigen Faktor beeinflusst, der beim sequentiellen Vorlesen erkennbar wäre. Das könnte z. B. eine gewisse Änderung in der Stimmausgabe sein. Einige Anwendungen der FIR-Technik könnten vielleicht hiervon betroffen sein. Es wäre gut, wenn es Testseiten gäbe, um diese Theorie auszutesten.
Es sieht jedenfalls so aus, dass es mit Ausnahme einiger seltener Fälle kein Vorleseprogramm gibt, in dem die FIR-Technik funktioniert. Die Tatsache, dass Jaws, das meistverbreitete Programm, und das kleinere Produkt Hal diese Technik im Grunde genommen verstehen, ist nur ein Missgeschick. Wir sollten uns in der Zukunft nicht darauf verlassen.
CSS verbessern
Ein Merkmal der Produkte Jaws, Window-Eyes und Home Page Reader, das nur wenigen bekannt ist, ist ihre Fähigkeit, die gesprochene Ausgabe mit einer Ausgabe auf dem Bildschirm und/oder einem Braillegerät zu synchronisieren.
- In einer Beilage zu Window-Eyes wird es "Surfen mit sehenden Freunden" genannt.
- Der IBM Home Page Reader ist mit einem laufenden Cursor synchronisiert, um das Lesen zu vereinfachen.
- Jaws und Window-Eyes können beide eine Braille-Ausgabe produzieren, entweder anstelle oder zusätzlich zur gesprochenen Ausgabe.
Die weit verbreiteten Vorleseprogramme arbeiten also in mehreren Modi gleichzeitig. Damit stehen sie klar im Widerspruch zu den gültigen Definitionen der Medientypen in der aktuellen CSS-Spezifikation. Die dort definierten Medientypen screen
, aural
und braille
passen nicht zu einer multimodalen Arbeitsweise. Möglicherweise ist hier ein neuer Medientyp angebracht, nach dem sich die heute gebräuchlichen Screen-Reader richten könnten. Ein Medientyp, der der eine klare Anleitung gibt, wie ein System, das anzeigt, spricht und Braille produziert, die heute in der Praxis verwendeten Stylesheets verwenden sollte.
Das W3C sollte nicht den Fehler wiederholen, den es bereits mit dem Element embed
gemacht hat: ein weithin benutztes und unterstütztes Element wurde nie durch Aufnahme in den (X)HTML-Standard 'legalisiert'. Das multimodale Verhalten der heutigen Vorleseprogramme sollte durch die CSS-Spezifikation ausdrücklich legalisiert werden, auch wenn dafür die Spezifikation ergänzt werden muss.
Dazu brauchte nicht die Spezifikation umgeschrieben zu werden. CSS 2.1 sagt heute bereits:
"Medientypen schließen sich in dem Sinne gegenseitig aus, dass ein Benutzerprogramm bei der Ausgabe eines Dokuments nur einen Medientypen unterstützen kann. Dennoch kann ein Programm verschiedene Arbeitsweisen haben, die unterschiedliche Medientypen unterstützen."
Es dürfte nicht allzu schwer sein, diese Definitionen so zu erweitern, dass multimodale Ausgaben möglich werden.
Mit einem Medientyp, der sich auf die Arbeitsweise der heute weithin genutzten Vorleseprogramme bezieht, hätten wir auch eine breitere Basis für unser Verlangen, dass die Hersteller von Vorleseprogrammen sich an die CSS-Spezifikationen halten. Diesen Punkt komplett zu behandeln, würde jedoch einen besonderen Artikel erfordern.
Keine zugängliche Technik
Leider kann man die FIR-Technik, soweit sie für Text verwendet wird, nicht als zugängliche Technik bezeichnen. Die Nutzer von Vorleseprogrammen können Text, der so codiert ist, entweder bereits jetzt nicht lesen oder sie werden es in Zukunft nicht können, wenn Stylesheets durch die Software korrekt interpretiert werden. Andere Menschen mit Behinderungen werden wahrscheinlich niemals durch die Verwendung von FIR beeinträchtigt sein, denn viele Behinderte haben normale Sehkraft und freuen sich auch über attraktive Websites. Wir können aber die Benutzer von Vorleseprogrammen nicht von unserer Vorstellung der Zugänglichkeit ausschließen.
Deshalb sollten standardsbewusste Designer die FIR-Technik nur für Grafiken verwenden, die man als 'nichtsemantisch' bezeichnen kann, die also keine Bedeutung haben. Beispiele dafür könnten Hintergrundmuster sein oder ein Firmenlogo, das in der Nähe in reinem Text wiederholt wird. Nutzen Sie dazu Ihren gesunden Menschenverstand.
Hilfe für Entwickler
Wir haben es hier mit einer standardsgemäßen Technik zu tun, die von den fähigsten Designern entwickelt wurde, die aber im Bereich der Webzugänglichkeit dennoch am sprichwörtlichen Eisberg zerschellt und untergeht. Dies hat zumindest den Vorteil, dass es einige Mängel deutlich macht, die behoben werden müssen. Insbesondere sind dies:
- Webentwickler brauchen Zugang zu preiswerten, funktional uneingeschränkten Vollversionen der Screen-Reader für unabhängige Testläufe.
- Wir sollten nicht andere Menschen bitten müssen (so wie ich es hier getan habe), ihre Zeit zu opfern, um unsere Webseiten für uns zu testen.
- Designer müssen selbst herausfinden können, ob ihre standardsgemäßen Entwürfe in der Praxis so gut funktionieren, wie sie auf dem Papier aussehen.
- Die Anzahl der Permutationen ist schwindelerregend, selbst wenn man nur die FIR-Technik testet. Die von Bob Easton vorgeschlagene Testsuite arbeitet mit sieben verschiedenen Möglichkeiten. Jede davon müsste mindestens in den drei meistverbreiteten Vorleseprogrammen getestet werden.
- Für formale Studien sollte eine größere Anzahl von Menschen gefunden werden, die Screen-Reader benutzen und dann für Untersuchungen im Felde zur Verfügung stehen können. Die Mailing-Liste der UVIP-Web-Test ist ein guter Anfang, aber selbst die große Nielsen-Norman-Gruppe hatte Probleme, genügend Behinderte für Usability-Tests zusammen zu bringen. Es gibt Zehntausende Anwender von Vorleseprogrammen (Jaws allein hat 80 000 Benutzer), aber selbst damit ist die Zusammenstellung jeglicher Art von Test unverhältnismäßig schwierig.
- Das Problem kann aber von beiden Seiten gelöst werden: die Hersteller der Screen-Reader und Browser müssen ihre Produkte an den fortschrittlichsten standardsgemäßen Websites testen. Wenn man die richtigen Sites liest und die richtigen Weblogs besucht, sind solche Websites nicht allzu schwer zu finden. Viele von ihnen demonstrieren die Technik selbst und reichen zum Nachweis der Standardstreue völlig aus.
- Zur Zeit gibt es eine Online-Petition, mit der Freedom Scientific dazu bewegt werden soll, eine verbilligte Entwicklerversion von Jaws heraus zu bringen. Nicht ganz fair ist, dass andere Hersteller nicht das Ziel solcher Petitionen sind, andererseits ist Jaws das meistverbreitete Produkt, sodass solch eine gezielte Petition durchaus Sinn macht. [Die Petition ist seitdem wieder offline. - Herausg.]
- Es wird nachvollziehbar argumentiert, dass 30- bis 40-minütige Demoversionen der Screen-Reader dem Designer nicht die Möglichkeit geben, das flüssige Bedienen der Software zu erlernen. Zum Zeitpunkt der Veröffentlichung dieses Artikels war die Betaversion von Jaws für Windows 5.0 gratis erhältlich. [Die Betaversion ist nicht mehr verfügbar und die endgültige Version ist nicht mehr umsonst. - Übers.]
- Wenn Webentwickler auf ihrem eigenen PCs rechtmäßige, lizenzierte und erschwingliche Versionen der Vorleseprogramme installiert hätten, könnten sie die Benutzung dieser Programme im Einzelnen erlernen und ihre experimentellen Websites und Produktionen selbst testen.
- Gleichzeitig müssen sich die Produzenten der Screen-Reader auch in den Prozess einfügen. Es ist dringend geboten, dass sie sich mehr als bisher an der CSS-Arbeitsgruppe (CSS Working Group) beteiligen. Im Gegenzug muss die CSS WG weit bessere medienspezifische Richtlinien erarbeiten, die sich auf den praktischen Gebrauch von Vorleseprogrammen und anpassender Technologie stützen. Standardstreue Designer streben danach, dass alles gut funktioniert, die Produzenten der Screen-Reader und das W3C müssen mehr daran arbeiten.
Dank und Anerkennung
- Brandon Bowersox
- Douglas Bowman
- Rich Caloggero
- Tomas Caspers
- Antonio Cavedoni
- Tantek Çelik
- Tom Croucher
- Bob Easton
- Todd Fahrner
- Chris Hofstader
- Michael L. Johnson
- Andrew Kirkpatrick
- Eric Meyer
- Will Pearson
- Seth Rothberg
- Dave Shea
- Aaron Smith
- Jim Thatcher
- Léonie Watson
TOP
Hinweis:
Das Original dieses Textes wurde zuerst am 20. Oktober 2003 unter dem Titel Facts and Opinion About Fahrner Image Replacement im Online-Magazin A List Apart veröffentlicht. Der Autor ist Joe Clark. Die Übersetzung erfolgte mit Genehmigung von A List Apart und dem Autor.
Translated with the permission of A List Apart Magazine and the author.