Strebt man bei der BIK eine Zertifizierung an, gibt es unterschiedliche Problemstellen, die wir uns nacheinander ansehen werden.
Eine davon ist sicherlich sIFR, eine Flash-Techik, die den Einsatz von Kundenschriften erlaubt, gleichzeitig jedoch auch bei nicht-aktiviertem Flash die Überschrift als Klartext ausgibt. Mit den Problemen bei benutzerdefinierten Einstellungen, Farb-, Hintergrund- und Schriftartänderung haben wir uns bereits im ersten Teil beschäftigt.
Eine Stellungnahme zu dieser Technik gibt es bei der BIK in der Überarbeitung des BITV-Testverfahrens aus dem Jahre 2005 unter dem Sammelbegriff „Flash“:
„sIFR wird oft als barrierefrei bezeichnet. Tatsächlich ist sIFR jedoch genau wie die anderen bekannten Bild-Ersetzungsmethoden keine zugängliche Technik.“
Quelle: BIK: Flash
Im zweiten Teil beschäftigen wir uns nun mit den weiteren Punkten, die die BIK gegen sIRF anführt. Wir wählen für die Testreihe eine der offiziellen Beispielseiten, die die aktuelle sIFR-Version nutzen: die Saratoga Springs Public Library. Um benutzerdefinierte Einstellungen schnell und einfach zu erreichen, nutzen wir die Erweiterungen Accessibar und Accessibility Toolbar für den Browser Firefox. Die Ergebnisse der Testreihe sind (*):
Skalierbarkeit der Texte
„Die bessere Zugänglichkeit von sIFR im Vergleich zu FIR wird vor allem mit der Skalierbarkeit der Flash-Texte begründet. Allerdings funktioniert das Skalieren nur eingeschränkt: Wenn der Benutzer im Browser die Schriftgröße anpasst, wird die Flash-Schrift wird nicht wie normale Schrift gleich mit skaliert, sondern erst nach einem erneuten Laden der Webseite.“
Quelle: BIK: Flash
Das stimmt immer noch: Obwohl Flash an sich skalierbar ist, muss für die Skalierung die Seite neu geladen werden. Wird die Schrift vom Benutzer vergrößert, ohne die Seite neu zu laden, bleibt die sIFR Überschrift davon unberührt.
Ungewohnte Handhabung
„Vieles funktioniert ungewohnt – zum Beispiel das Markieren von Text, um ihn in eine andere Anwendung zu kopieren.“
Quelle: BIK: Flash
Gerade die Möglichkeit, dass man sIFR Überschriften auch markieren und kopieren kann, unterscheidet es von anderen Überschriftenverfahren. Grundsätzlich ist das auch eine gelungene Sache, aber der BIK ist durchaus zuzustimmen, dass hier einige Dinge unhandlich sind: Da ist zum einen die inverse Darstellung beim Markieren des Textes – weiße Schrift auf schwarzem Grund, egal welche benutzerdefinierte Hintergrundfarbe man eingestellt hat. Interessant ist, dass auf Beispielseite für die aktuelle sIFR Version nicht alle Elemente in inverser Darstellung markiert werden, eine Variante markiert den Text gänzlich weiss auf weiss.
Wenn man mehrere sIFR Elemente schnell hintereinander markiert, kann es passieren, dass der Fokus auf mehreren Elementen hängen bleibt. Beim Markieren mit der Maus ist es etwas unelegant, dass die Markierung sich beim Kopieren gerne wieder etwas verschiebt und nicht mehr alle Buchstaben erfasst. Schliesslich bietet der Browser im Menü noch die Möglichkeit das ganze sIFR Element auszuwählen. Hierbei hat man dann das merkwürdige Ergebnis eines Zeilenumbruchs im kopierten Text. Bei mehreren sIFR Elementen auf einer Seite erzeugt der Browser bei mehreren Markierungsversuchen irgendwann nur noch Renderfehler und hebt die Markierungen nur noch unzureichend auf.
Per Tastaturnavigation ist es zwar nicht möglich das sIFR Element anzusteuern, aber mit Hilfe von Caret Browsing werden sie miterfasst. In diesem Modus wird mittels Drückens der Taste F7 ein Cursor auf der Seite gesetzt und man kann mit der Tastatur auf der Seite markieren. Das sIFR Element wird dabei nicht markiert – auch nicht invertiert, aber der Inhalt wird mit kopiert.
Lange Ladezeit
„sIFR ist langsam: Überschriften werden oft später eingeblendet als der restliche Text und verlieren damit einen wesentlichen Teil ihres eigentlichen Zwecks (schneller Überblick).“
Quelle: BIK: Flash
Darüber gibt es wenig zu sagen und zu testen. sIFR Elemente werden wohl immer erst am Ende angezeigt, weil sie zum einen nicht wenig Größe mitbringen und zum anderen jedes Mal neu erzeugt werden. Das ergibt dann einen Plopp-Effekt auf der Webseite. Wenn sIFR für Überschriftenhierarchien verwendet wird, tritt das Problem besonders intensiv auf: der Fliesstext ist komplett zu sehen, aber die Überschriften fehlen noch. Dieser Effekt scheint besonders auf Seiten aufzutreten, wo die Flashdatei nicht zwischengespeichert wird. Ist sie jedoch einmal zwischengespeichert, sind die Elemente relativ zeitgleich mit dem restlichen Inhalt zu sehen. Freilich bleibt ein kleiner Versatz immer noch bestehen.
Verlinktes sIFR
Gänzlich verzichten sollte man auf die Nutzung von sIFR für Verlinkungen. Damit begibt man sich nicht nur im Hinblick auf Barrierefreiheit auf extrem dünnes Eis. Hierbei werden die bereits kritisierten Punkte noch verschärft: Bei unseren Versuchen, sIFR verlinkt einzusetzen – etwa auch für ganze Navigationen -, beginnt der Browser irgendwann die Navigation oder die Verlinkung zu deaktivieren – es ist kein Link mehr erkennbar. 🙂 Aber die Entwickler von sIFR empfehlen selbst diesen Einsatz nicht.
Fazit
Wieder muss man in allen Punkten der BIK zustimmen: Weder lassen sich sIFR Elemente hinreichend und nutzernah skalieren, noch ist die Handhabung wie etwa das Markieren wirklich ausgereift einsetzbar und schließlich verhindert die lange Ladezeit, eine zeitnahe Struktur einer Webseite zu erfassen.
Damit muss der BIK zugestimmt werden: sIFR ist nicht barrierefrei.
(*) Im ersten Schritt teste ich auf dem Macintosh, ich werde aber danach auch immer die Ergebnisse auf dem Windows-System sammeln. Es wird die Ergebnisse nicht in einem Schwung geben, sondern immer nach und nach. 🙂
eine traurige Aussage. Aber was ist das Fazit? Andere Replacement-Methoden oder eben doch auf Nicht-Systemschriften verzichten? Was ja nicht immer geht.
Dafür hab ich das ausführliche Testen gemacht, um eine Entscheidung für zukünftige Projekte fällen zu können. Unf für barrierefreie Projekte heisst das, eine deutliche Absage an sIFR setzen zu müssen. Leider haben wir das vorab nicht ausführlich genug testen können. Aber das wird mir eine Lehre sein.
Andere derartige Ersetzungsmethoden kommen noch weniger in Frage. sIFR ist da schon am besten gelagert. Ja – auf CI-Schriften verzichten.
Freilich muss man beobachten, welche weiteren Wege gefunden werden in dieser Hinsicht. Da sind ja immer wieder Ideen und Ansätze virulent.
Anmerkung zu „auf CI-Schriften verzichten“:
Was heißt CI? Viele Firmen setzen gern auf CI- (besser CD-)Schriften und vergessen dabei völlig die Mediengegebenheiten. Wenn es (zur Zeit) nicht sinnvoll möglich ist, individuelle Schriften *als reinen Text* im Web zu benutzen, muss man eben *mediengerecht* darauf verzichten. Vielleicht bringt die Zukunft Verbesserungen. Bis dahin muss jeder für sich entscheiden, ob er alle potentiellen Besucher umfassend erreichen und bedienen will oder nicht.
Hallo Rainer,
das ist so leicht ins Web gesagt, auf CD-Schriften zu verzichten. 🙂 Klar – ich stimme Dir zu, aber meine Agenturerfahrung spricht leider eine ganz andere Sprache. Da kostest es eher viel Mühe, Kunden darauf hinzuweisen, dass ihre Schriften nicht in der Form umgesetzt werden können. Das betrifft ohnehin „nur“ Projekte mit barrierefreiem Schwerpunkt.
Bei anderen Projekten hat man keine Argumentationsgrundlage. Da setzen wir entweder SIFR ein oder via PHP generierte Schriftgrafik.
Ich finde auch, und da stimme ich Dir zu, dass es wichtig wäre, wenn man z.b. die Ansätze, Schriften ganz normal einzubinden, endlich wieder vorantreiben würde. Im Grunde ist des der falsche Ansatz, über Ersetzungsmethoden zu gehen.