Autor:
Joe Clark
Alistapart Ausgabe:
160
Die Entwicklung der Fahrner Image Replacement Technik
und Ihrer Entsprechungen verläuft schneller als der Fall der Berliner
Mauer. Dieser Artikel liefert einige sehr notwendige
empirische Daten darüber, wie FIR tatsächlich mit Vorleseprogrammen funktioniert.
Benannt nach Todd Fahrner, anscheinend von C.Z. Robertson erfunden und bekannt gemacht durch Douglas Bowman (siehe seine Site für
die vollständige
Beschreibung des Quelltexts) und Jeffrey Zeldman's Designing with Webstandards,
ist FIR eine Standardkonforme Technik, die Stylesheets und gewöhnliches
HTML einsetzt, um ein sichtbares Bild darzustellen, meistens aus Text bestehend.
Durch CSS legt der Designer fest, daß das Bild in der Regel angezeigt wird,
sollte es aus irgendeinem Grund nicht angezeigt werden, hat der zugrunde
liegende strukturelle HTML Auszeichnungstext seinen Platz einzunehmen.
Mit FIR wird es möglich, Titelzeilen und andere Designelemente
ansprechend zu beschriften, ohne komplizierteres HTML als <span> innerhalb
von <h1>. Der reine HTML Text ist durch die Stylesheet Deklaration display:none verborgen
(im Prinzip zumindestens, wäre visibility:hidden ebenfalls möglich). Die
Textgrafik wird als CSS Hintergrundbild dargestellt.
Die Vorteile liegen hier meistens in einer ansprechenden
grafischen Gestaltung und einem Quelltext, der etwas eleganter ist, als <h1><img
alt="">, dies wäre so ziemlich die einzige Alternative, wenn Sie z.B. eine Grafik als
Überschrift einsetzen möchten. Da es keine Grafik mit einer Überschrift
verschachtelt, ist FIR zumindestens oberflächlich zugänglicher.
Screenreader
Wie in einem früheren Artikel
für A List Apart bereits erklärt, sind
Screenreader Programme,
die Webseiten und meistens auch alles andere auf ihrem Computer vorlesen.
Sie machen einen Computer für blinde oder ernstlich
sehbehinderte Menschen, auch von Menschen mit Lernbehinderungen wie Dyslexie
werden sie gelegentlich benutzt. Sie stellen eine Form adaptiver Technologie
dar - Soft- oder Hardware, entwickelt, um einen Computer für Behinderte
zugänglicher zu machen.
Die führenden Screenreader sind:
Stylesheet Interpretierung
Beim Fahrner Image Replacement werden
typischerweise zwei CSS Techniken eingesetzt, allerdings bezieht sich
nur eine auf visuelle Gestaltung. Dies gilt, auch wenn sich
beide von visuellen, nicht auditiven, CSS Medientypen herleiten.
Unser Schreckgespenst hier ist display:none. Die W3C Spezifikation
legt fest:
Dieser Wert sorgt dafür, daß ein Element
keine Kastenbildung in der Formatstruktur bewirkt (.d.h., das Element
hat keinen Einfluß auf
das Layout). Auch Kindelemente
bewirken keine Kastenbildung; dieser Umstand kann auch nicht durch das
Setzen der "display" Eigenschaft
für die Kindelemente aufgehoben werden.
N.B: display:none (keine Darstellung) schafft nicht etwa einen unsichtbaren
Kasten, es wir überhaupt kein Kasten gebildet.
Deswegen bedeutet display:none wirklich manifestierung:keine oder eliminierung:total. Ein Objekt mit der Zuweisung display:none löscht sich selbst aus.
Eine weitere Option ist ebenfalls möglich: visibility:hidden,
die Spezifikation erläutert: "der
erzeugte Kasten ist unsichtbar (vollkommen transparent) aber er beinflußt
dennoch das Layout".
Die visuelle Unterscheidung ist also die zwischen Nichtexistenz
und einem leerem, eine Begrenzung bildenden Kasten. Wie sollen Screenreader dies
handhaben?
Screenreader im
Anwendungstest
Ich kann die Frage nicht beantworten, aber Dank einiger Tests durch
mehrere Anwender kann ich jetzt schildern, wie Screenreader die
Aufgabe derzeit meistern.
Ich bat mehrere Bekannte über einige Mailing Listen
(WAI Interest Group, UVIP-Web-Test)
zu versuchen, mit jedem nur erreichbaren Screenreader FIR-kodierten Text zu lesen.
Der Testfall war die eher schlichte Intro-Seite für Ten Years Ago
in Spy, mein Lobgesang auf das mittlerweile eingestellte Satiremagazin,
welches
Matt Mullenweg kürzlich mit CSS und Fahrner Image Replacement umgeschrieben
hat. Zwei Grafiken auf dieser Seite wurden über FIR dargestellt. Ich
hatte vorher gewöhnliche img Elemente eingesetzt.
Resultate
Ich habe zwei Testseiten geschrieben:
- mit
display:none
- mit
visibility:hidden
Ich konnte Anwender finden für: Drei Versionen von Jaws,Windows
Eyes, Homepae Reader und einem weiteren Produkt, Hal. Resultate
konnte ich
ebenfalls
bekommen für das nicht mehr weiterentwickelte Outspoken für Macintosh.
Die Ergebnisse sind beunruhigend.
| Produkt |
display: none |
visibility: hidden |
| Hal version 5.20 |
wird nicht vorgelesen |
wird vorgelesen |
| IBM Home Page Reader 3.02 |
wird nicht vorgelesen |
wird nicht vorgelesen |
| Jaws (4.02, 4.50, 5.0 beta) |
wird vorgelesen |
wird vorgelesen |
| OutSpoken 9 |
wird nicht vorgelesen |
wird nicht vorgelesen |
| Window-Eyes 4.2 |
wird nicht vorgelesen |
wird nicht vorgelesen |
Analyse
Es scheint offensichtlich, daß kein mit der CSS Eigenschaft display:none ausgezeichnetes Element durch irgendein Hilfsmittel in irgendeiner
Modalität dargestellt, vorgelesen
oder überhaupt irgendwie manifestiert werden sollte. HAL, IBM,
Home Page Reader sowie Outspoken verhalten sich dieser Interpretation
konform,
Jaws
tut das nicht.
Es scheint außerdem so, daß kein mit der CSS Eigenschaft visibility:hidden ausgezeichnetes Element durch irgendein Hilfsmittel, ob visuell
oder nicht (d.h. ein Browser
mit grafischer Anzeige oder ein Screenreader)
gelesen werden sollte. Der einzige Unterschied zwischen den
beiden Stylesheet Deklarationen ist die Auswirkung auf das
gerenderte Layout, welches ein Browser befolgen müßte, ein Screenreader aber
aber theoretisch ignorieren könnte. (Erinnern Sie sich an
den Unterschied zwischen display:none, welches kein Raum
beansprucht
und visibility:hidden,
bei welchem
dies der Fall ist)
Eine Ausnahme könnte es darstellen, wenn ein CSS-Container,
der mit der Eigenschaft visibility:hidden versehen ist,
die Lesereihenfolge
oder
einen anderen Umstand
verändert, welcher in sequentieller, auditiver Wiedergabe
wahrnehmbar wäre; in diesem Fall könnte ein Screenreader seine
Sprachausgabe in irgendeiner Weise ändern. Vielleicht fallen
einige Anwendungen von FIR in diese Kategorie. Wir bräuchten
einige Testseiten, um diese Theorie zu prüfen.
Jedenfalls scheint es, daß, bis auf wenige Ausnahmen, kein Screenreader mit Fahrner
Image Replacement zurecht
kommen sollte. Auf den Umstand, daß das marktbeherrschende
dieser Programme, Jaws, und das weniger verbreitete Produkt
HAL, tatsächlich
FIR verstehen,
sollten wir uns auf Dauer nicht verlassen.
CSS Verbessern
Eine wenig bekannte Option von Jaws, Window Eyes und Home
Page Reader besteht in der Fähigkeit zur Synchronisation
zwischen
der Sprachausgabe
und entweder
der Bildschirmanzeige (den Bildschirm scrollend
und/oder Abschnitte hervorhebend, während sie gelesen werden)
oder Braille oder beiden.
Die verbreiteten Screenreader sind also multimodale Hilfsmittel. Sie stehen
eindeutig im Widerspruch zu den aktuellen CSS Medien-Typ Definitionen,
denn ihr Verhalten ist multimodal, wofür die existierenden Medien-Typen
screen, aural, und braille nicht wirklich geeignet sind. Es ist vielleicht
Zeit für einen neuen Medien-Typ, der für die Screenreader, die heute
benutzt werden, verpflichtend wäre - einer der klar vorgeben würde, wie
ein System, daß Braille anzeigt, vorliest und ausgibt, tatsächliche CSS
Definitionen handhabt.
Ich schlage an dieser Stelle vor, daß das World Wide Web Konsortium davon Abstand
nimmt, seinen Fehler mit embed, einem weit verbreitetem und immer noch
unterstütztem Element, welches nie in die (X)HTML Spezifikationen aufgenommen
wurde, zu wiederholen. Das multimodale Verhalten aktueller Screenreader
sollte explizit in die CSS Spezifikationen aufgenommen werden, auch wenn
daß ihre Erweiterung bedeutet.
Dies ginge auch ohne die existierende Definition umzustürzen, die ja schon besagt:
"Medien-Typen schließen sich gegenseitig aus in dem Sinn, daß ein
user agent beim rendern eines Dokuments nur einen Medien-Typ unterstützen
kann.
User agents können jedoch verschiedene Modi haben, welche unterschiedliche
Medien-Typen unterstützen". Es wird wohl nicht so schwer sein, diese
Definitionen so zu erweitern, daß multimodale Ausgabe ermöglicht
wird.
Mit einem Medien-Typ, der Bezug nimmt zum tatsächlichen Verhalten
gebräuchlicher Screenreader, hätten wir eine bessere Ausgangsbasis für
die Forderung an die Hersteller von Sceenreadern, CSS Spezifikationen
einzuhalten. Eine ausführliche Diskusssion darüber würde, das ist wohl
klar, einen separaten Artikel erfordern.
Keine zugängliche Technik
Leider kann FIR nicht als behindertenfreundliche Web-Technik angesehen
werden wenn sie für Text verwendet wird . Benutzer von Screenreadern
können entweder bereits jetzt so aufbereiteten Text nicht lesen oder
sie werden es in Zukunft nicht können, wenn die Programme aktualisierte
sein werden, um CSS korrekt zu interpretieren. Andere Behinderte werden
möglicherweise nie dadurch Nachteile erleiden und viele werden dadurch
ebenso wie Nichtbehinderte profitieren, da viele Behinderte im Netz
normalsichtig sind und attraktive Websites gerne sehen. Aber wir können
Screenreader nicht von unserem Konzept der Behindertenfreundlichkeit
ausnehmen.
Deswegen sollten Standardkonform arbeitende Designer FIR nur für
Bilder einsetzen, die man "nichtsemantisch" nennen könnte, d.h.
nicht bedeutsam. Hintergrundkacheln sind ein Beispiel, ebenso ein
Firmenlogo, welches irgendwo nahebei in reiner Textform wiedergegeben
wird
(möglicherweise als Überschrift). Setzen
Sie ihren gesunden Menschenverstand ein.
Hilfe für Entwickler
Dieser Fall einer standardkonformen Technik, vorangebracht durch
sehr talentierte Entwickler, welche trotzdem auf einen Eisberg trifft und
sinkt, wen es um Behindertenfreundlichkeit geht, hat wenigstens den
Vorteil, daß einige zu beseitigende Defizite zur Sprache kommen. Insbesondere:
- Entwickler brauchen Zugang zu preiswerten, funktional
unbeschränkten Vollversionen für das unabhängige Testen.
- Wir sollten nicht Leute bitten müßen, ihre Freizeit
zu opfern indem sie unsere Webseiten testen, so wie ich es
hier getan habe.
- Entwickler müßen in die Lage versetzt werden, selbstständig
herauszufinden, ob ihre standardkonformen Techniken, die
auf dem Papier gut aussehen,
sich in der Praxis bewähren.
- Die Anzahl der auch nur zum Testen von
FIR notwendigen Permutationen ist erschreckend - die von Bob Easton vorgeschlagene
Testserie hat sieben
Variationen,
die mindestens in den drei wichtigsten Screenreadern getestet
werden müßten.
- Was formalisierte Untersuchungen anbetrifft, sollte eine größere
Zahl von Screenreader-Benutzern gefunden werden um Feldstudien
durchzuführen.
Die UVIP-Web-Test Mailingliste
ist ein guter Anfang. Aber sogar die mächtige Nielson Norman Group hatte Schwierigkeiten, genügend Behinderte
für Usability-Tests zu finden (PDF). Sogar mit zehntausenden Screenreader
-Benutzern (Jaws allein hat 80 000 Benutzer), ist das Einrichten
von Tests unverhältnismäßig schwierig.
- Hier gibt es allerdings keine Einbahnstrasse: Hersteller von Screenreadern
und Browsern müßen ihre Produkte auf den höchstentwickelten, standardkonformen
Sites testen, welche nicht schwierig zu finden sind, wenn sie die
richtigen Sites und Weblogs lesen, viele davon demonstrieren selbst
diese Techniken
und sind ein ausreichendes Testfeld.
- Eine Petition macht z.Z.
die Runde um Freedom Scientific dazu zu bewegen, eine Entwicklerversion
von Jaws herauszubringen. Ähnliche
Petitionen an andere Hersteller scheint es nicht zu geben, was
eigentlich nicht fair ist, aber Jaws ist das meistverbreitete Produkt,
es ist
also politisch sinnvoll, sich darauf zu konzentrieren. {Anm. des
Hrgbrs: Die
Petition ist mittlerweile offline.}
- Es wurde, durchaus nachvollziehbar,
argumentiert, daß eine 30-40 minütige Demoversion nicht lang
genug läuft, damit ein Entwickler
mit der Software vertraut wird. Z.Z. allerdings, war Jaws für Windows
5.0 als öffentliches Beta umsonst erhältlich.
- Mit lizensierten, erschwinglichen und legalen Versionen
auf ihren eigenen Computern, können Entwickler die notwendige
Zeit aufbringen, um die Schwierigkeiten der Screenreader-Benutzung
zu meistern, so daß
sie ihre experimentellen und die Produktionswebsites testen können.
- In
der Zwischenzeit, müßen die Hersteller von Screenreadern sich
selbst auch um das Programm kümmern. Sie brauchen dringend mehr
Teilnahme
an der CSS Arbeitsgruppe, andererseits müßen die Mitglieder der
CSS
Arbeitsgruppe sehr viel bessere medienspezifische Richtlinien
liefern, basierend auf
tatsächlichem Gebrauch von Screenreadern und adaptiver Technologie.
Standardkonforme Entwickler versuchen, alles ordentlich funktionieren
zu lassen, Die Hersteller
von Screenreadern und das W3C müßen sich mehr anstrengen.
Danksagung
- 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
| Glossar: |
| Fahrner Image Replacement | wörtlich: Fahrner Bild-Ersetzung |
| Zugänglichkeit | Accessibility(eng.): hier in Bezug auf Blinde, Sehbehinderte und deren Darstellungs- und Leseprogramme |
| screenreader | Vorleseprogramme |
| user agent | hier: jedes Programm, daß HTML interpretiert |
| rendern | Quelltext einlesen und grafisch darstellen |
Der Journalist, Autor und Accessability
Consultant Joe
Clark aus Toronto schrieb
das Buch Building Accessible Websites, nimmt aber an, das A list Apart Leser das mittlerweile wissen.
Originaladresse:
www.alistapart.com/articles/fir/
Alistapart Diskussionsforum (englisch):
www.alistapart.com/discuss/fir/
Translated with the permission of A List Apart Magazine and the author[s].
