Screenreader und versteckte Inhalte

[Gordon]

Hallo.
Ich beziehe mich auf folgenden Artikel:
http://www.123-barrierefrei.de/barrierefreiheit/wassehenscreenreader

In diesem Artikel wird gezeigt, daß Screenreader versteckte Inhalte, die mit display:none versteckt werden, diese Inhalte auch tatsächlich nicht zeigen. Eine Alternative für eine versteckte Sprungnavigation wird auch genannt und leuchtet auch ein. Man benutzt einfach ein transparentes Gif, das verlinkt wird und dessen Alternativ-Texte die relevanten Texte transportiert. Jetzt kann es allerdings bei pixelgenauem Arbeiten dazu kommen, daß selbst ein pixelgroßes Gif visuell stören.

Wir haben uns jetzt für eine Variante entschieden, die dieses Gif nicht als störend darstellt. Wir haben die Höhe und die Breite auf Null gesetzt. Kein Checker hat gemeckert und in den Textbrowsern wird der Alternativ-Text angezeigt. Also eigentlich alles in Ordnung. Aber trotzdem hat man so ein ungutes Gefühl, quasi ein "Geister-Gif" erstellt zu haben. Hat damit schon mal jemand Erfahrungen gesammelt? Kommt man deshalb in die HTML-Hölle?

Aber noch eine viel schwerwiegendere Frage ist, was man denn nun mit anderen versteckten Inhalten einer Page machen soll. So ist doch der bekannte Trenner zwischen Verlinkungen <span class="unsichtbar">&mbsp;|&nbsp;</span> doch auch nicht mehr fuinktionstüchtig in einem Screenreader, oder? Muß man diese Trenner zwischen Verlinkungen nun auch mit einem Blank-Gif oder Geistergif (height=0 width=0) ersetzen?

Oder was ist mit Textergänzungen, zum Beispiel bei einem "Artikel lesen"-Link? Da haben wir bisher einfach einen unsichtbaren Text angehängt, wie Zum Beispiel: Artikel lesen<span class="unsichtbar">: Screenreader haben Probleme.>/span>.

Und man stößt bestimmt noch auf sehr viel andere Gebiete, die versteckte Inhalte brauchen. Muß man sich nun völlig davon trennen? Wird in keinem Quellcode mehr ein Style zu finden sein, der mit display:none angelegt wurde? Sind dann nur noch blank-Gifs unterwegs? Mich würde Eure Meinung mal interessieren.

Vielen Dank

Gordon

[e-mail]

[Cyx32]

Hallo,

Und man stößt bestimmt noch auf sehr viel andere Gebiete, die versteckte Inhalte brauchen. Muß man sich nun völlig davon trennen? Wird in keinem Quellcode mehr ein Style zu finden sein, der mit display:none angelegt wurde? Sind dann nur noch blank-Gifs unterwegs? Mich würde Eure Meinung mal interessieren.

display:none kann als CSS-Weiche, also CSS ja/nein, eingesetzt werden, und ist wohl nötig, dazu valides CSS.
Und natürlich bei einigen Seiten erforderlich um die netten "Ich hasse Netscape 4" DIVs zu kaschieren.

Schließlich scheint wohl ein media="screenreader" bzw. ein anwendbares media="aural" zu fehlen,
aber leider kann ich anhand des Artikels nicht ganz nachvollziehen wie letztlich das Problem
entstehen soll, statt dessen der nette einprägsame Elefantenvergleich, wie das "jetzt schlauer"
sein soll... Würde display:none in einem media="screen"-CSS den betr. Screenreader auch erreichen?

Grüsse

Cyx23

[Jeena Paradies]

Hallo,

Und natürlich bei einigen Seiten erforderlich um die netten "Ich hasse Netscape 4" DIVs zu kaschieren.

hm, warum sollte man den NS 4.x hassen?

Würde display:none in einem media="screen"-CSS den betr. Screenreader auch erreichen?

So weit ich weiß ja. Natürlich gibt es im Internet einige Beiträge darüber wie zum Beispiel diesen: http://css-discuss.incutio.com/?page=ScreenreaderVisibility wo unten auch dargestellt wird wie man das ganze umgehen kann.

Grüße
Jeena Paradies

[Cyx23]

Hallo,

danke für den Link, die Tabelle ist ja ernüchternd. Offenbar bedarf es wirklich anderer Strategien, dazu zeigt sich wieder wie unzulänglich letztendlich CSS derzeit ist, zumindest wenn es auch nicht gelingt mittels media=aural o.ä. ein display:none wieder aufzuheben.
Die Elemente rauszuschieben ist ja ein alter Hut, DHTML usw., und hat auch Nachteile bei einigen Browsern, z.B. dem beliebten "warum sollte man den NS 4.x hassen".
Das Verhalten zukünftiger bzw. unbekannter, ungetesteter Browser ist auch unklar, ein fragwürdiger Hack.

Unklar ist mir in diesem Zusammenhang auch die verbreitete Empfehlung den Inhalt vor die Navigation zu setzen, soll ich wirklich davon ausgehen dass bei Darstellungsfehlern (wie bei display:none offenbar möglich) der Sehbinderte lieber erst den ganzen Inhalt anhört bis er zur Navigation gelangt?
Und sollten wir nicht bei solchen Unklarheiten die Navigation gleich sauber in einen eigenen Frame auslagern;-?

Grüsse

Cyx23

[Jeena Paradies]

Hallo,

danke für den Link, die Tabelle ist ja ernüchternd. Offenbar bedarf es wirklich anderer Strategien, dazu zeigt sich wieder wie unzulänglich letztendlich CSS derzeit ist

Wussten wir das nicht schon lange?

Die Elemente rauszuschieben ist ja ein alter Hut, DHTML usw., und hat auch Nachteile bei einigen Browsern, z.B. dem beliebten "warum sollte man den NS 4.x hassen".

Kannst du das mit dem NS 4.x hassen mal erklären? Ich glaube ich bin zu kurz dabei um das zu verstehen.

Das Verhalten zukünftiger bzw. unbekannter, ungetesteter Browser ist auch unklar, ein fragwürdiger Hack.

Das ist aber ein Problem aller Hacks, nicht nur dieses hier.

Unklar ist mir in diesem Zusammenhang auch die verbreitete Empfehlung den Inhalt vor die Navigation zu setzen

Wer empfielt das? Ich zumindest habe immer davon abgeraten, weil ich davon ausgehe dass sich der »Blinde« Besucher erst einmal über die Struktur der Seite orientieren will. Wer weiß wie lange den Content ist. (vor allem wenn man dann aus Unkenntniss display: none; einsetzt) Ich denke so etwas würde nicht aufkommen, wenn sich mehr Webdesigner mal so einen Screenreader installieren würden, den Monitor ausschalten würden und sich ihre eigenen Seiten mal anhören würden. Dann noch ein bischen in jemanden versetzen, der die Seite nicht kennt und schon weiß man wie es solch jemandem auf deiner Seite geht.

Und sollten wir nicht bei solchen Unklarheiten die Navigation gleich sauber in einen eigenen Frame auslagern;-?

Ganz so abwegig ist der Ansatz gar nicht, er würde eigentlich viel näher an die <nl> oder <link> Navigationen rankommen als so manche JavaScript Navigation.

Grüße
Jeena Paradies

[Cyx23]

Hallo,

danke für den Link, die Tabelle ist ja ernüchternd. Offenbar bedarf es wirklich anderer Strategien, dazu zeigt sich wieder wie unzulänglich letztendlich CSS derzeit ist
Wussten wir das nicht schon lange?

ja, aber dass offenbar grundlegende Konflikte gerade zu einem der wichtigsten Ziele von CSS bestehen mögen wäre in der krassen Form neu, Validität und Konformität verkommen vielleicht endgültig zu einem modernen Schildbügerstreich.
Wenn man dann noch das immer wieder hinausgeschobene Erscheinungsdatum eines IE 7 hinzunimmt ist ein Strukturwechsel hin zu CSS und W3C Validität momentan eigentlich absurd, das Argument Zukunftstauglichkeit als Vorteil entfällt damit erstmal, die Altlasten (Clients) werden unter CSS auch teurer als erwartet.

Kannst du das mit dem NS 4.x hassen mal erklären? Ich glaube ich bin zu kurz dabei um das zu verstehen.

Netscape 4 ist ja bekanntlich wegen seiner heiklen CSS-Unterstützung für viel Frust gut gewesen, und unter dem Vorwand ein "modernes Internet" zu fördern haben einige wenige "durchgeknallte" Webdesigner nicht etwa nur Netscape 4 vom CSS ausgeschlossen, sondern Nag-Screens eingebaut man solle den Browser wechseln.
Damit haben sich natürlich einige Firmen auch handfeste Einsparungen an Wartungskosten erhofft, teilweise dürfte das bis auf den Imageverlust und Frust beim Kunden und den Wartungsaufwand für die Nag-Screens, Hotlinekosten usw. auch dem Webdesigner mehr Zeit für Checks mit dem weniger genutzen Opera gelassen haben.
Entsprechende Liebeserklärungen an Netscape 4 finden sich sicherlich auch hier im Forumsarchiv.
Zugleich hatte meinen Beobachtungen zufolge Heise etwas mit CSS experimentiert und dann aber den Auftritt konsequent auf ein stabiles abwärtskompatibles Tabellenlayout umgestellt.

Interessant auch ein Text des W3C http://www.w3c.de/sieben.html, der sich nicht etwa für eine radikale breite Umsetzung neuer Normen ausspricht, sondern Abwärtskompatibilität als Ziel wichtig nimmt.
Paradox wäre es Abwärtskompatibilität durch Zwang zu neuen Browsern zu erreichen, wenn dann aber noch das Verhalten aller Screenreader so auschaut dass diese offenbar gar nicht oder nicht per media=aural erreichbar sind bedeutet es auch ein Scheitern der Arbeit des W3C.

Das Verhalten zukünftiger bzw. unbekannter, ungetesteter Browser ist auch unklar, ein fragwürdiger Hack.
Das ist aber ein Problem aller Hacks, nicht nur dieses hier.

Hier wäre ein Scheitern auch erstmal nicht so schlimm wenn doch etwas angezeigt würde.
Wenn aber unklar ist ob ein Browser das Layout zerlegt, was bei Eingriffen in Positionierungen und den vorstellbaren Wechselbeziehungen denkbar ist, wird es kritisch.
Wenn dann der Hack in Zusammenhang mit ordentlicher Codierung und Barrierefreiheit auftaucht wird es noch peinlicher.
Und einigen anderen "Hacks" würde ich bzgl. "zukünftiger bzw. unbekannter, ungetesteter Browser" durchaus Unbedenklichkeit bescheinigen.

Wer empfielt das?

Viele. Die Frage wäre vielleicht mit welcher da Berechtigung empfohlen wird.
Argumentation: wer will denn ellenlange Links vorgelesen bekommen bis er zum Inhalt kommt.

Ganz so abwegig ist der Ansatz gar nicht, er würde eigentlich viel näher an die <nl> oder <link> Navigationen rankommen als so manche JavaScript Navigation.

Ist mit Sicherheit ein Plus an klarer Struktur und dürfte für einige Personen auch barierefreier sein, ob das für alle Personen uner allen Browsern zumutbar ist kann ich schlecht abschätzen.

Grüsse

Cyx23

[Ingo Turski]

Hi,

dazu zeigt sich wieder wie unzulänglich letztendlich CSS derzeit ist, zumindest wenn es auch nicht gelingt mittels media=aural o.ä. ein display:none wieder aufzuheben.

eher die Umsetzung durch die Screenreader (bzw. die Browser, auf denen sie aufsetzen). Diese müßten die display-Eigenschaft per Definition ignorieren, selbst wenn sie für media="all" eingebnden wäre.

Unklar ist mir in diesem Zusammenhang auch die verbreitete Empfehlung den Inhalt vor die Navigation zu setzen, soll ich wirklich davon ausgehen dass bei Darstellungsfehlern (wie bei display:none offenbar möglich) der Sehbinderte lieber erst den ganzen Inhalt anhört bis er zur Navigation gelangt?

Diese Empfehlung geht ohnehin an der Praxis vorbei, denn sie erfordert i.d.R. eine absolute Positionierung für die Navigation - was nicht immer problemlos in Hinblick auf Barrierefreiheit ist.

freundliche Grüße
Ingo

[Cyx23]

Hallo,

eher die Umsetzung durch die Screenreader (bzw. die Browser, auf denen sie aufsetzen). Diese müßten die display-Eigenschaft per Definition ignorieren, selbst wenn sie für media="all" eingebnden wäre.

interessant. In dem einen Artikel war etwas schwammig das DOM des IE erwähnt; wenn die Screenreader mittels JavaScript arbeiten könnte eigentlich auch da eine Lösung erfolgen.

Unklar ist mir in diesem Zusammenhang auch die verbreitete Empfehlung den Inhalt vor die Navigation zu setzen, soll ich wirklich davon ausgehen dass bei Darstellungsfehlern (wie bei display:none offenbar möglich) der Sehbinderte lieber erst den ganzen Inhalt anhört bis er zur Navigation gelangt?
Diese Empfehlung geht ohnehin an der Praxis vorbei, denn sie erfordert i.d.R. eine absolute Positionierung für die Navigation - was nicht immer problemlos in Hinblick auf Barrierefreiheit ist.

Sicher, oder teilweise position:fixed, und das Auslagern der Navigation in einen iframe wäre auch noch ein zusätzlicher Aspekt, sofern "transitional" möglich ist. Bleibt natürlich noch float. Nachvollziehbares, u.U. kontrollierbares Risiko ist ein zu kleiner Bildschirm- lassen sich denn noch andere Probleme konkret benennen oder siehst du nur grundsätzlich das Risiko von Überlappungen usw. etwa bei Wechsel der Schriftgrösse usw.?

Grüsse

Cyx23

[Ingo Turski]

Hi,

Bleibt natürlich noch float. Nachvollziehbares, u.U. kontrollierbares Risiko ist ein zu kleiner Bildschirm- lassen sich denn noch andere Probleme konkret benennen oder siehst du nur grundsätzlich das Risiko von Überlappungen usw. etwa bei Wechsel der Schriftgrösse usw.?

Bei Nutzung von Positionierung muß es nicht zwangsläufig zu Überlagerungen kommen. Es kommt darauf an, _wo_ die Navigation positioniert wird. Links oben bei zum Inhalt passender relativer Breitenangabe sollte unproblematisch sein. Der Nachteil ggü. float ist natürlich, daß die Nutzung des Anzeigebereiches unter der Navigation ausgeschlossen bzw. problematisch ist.

freundliche Grüße
Ingo

[willie.de]

hallö ins forum,

[...] Kommt man deshalb in die HTML-Hölle?

ich befürchte: ja!

ich finde es ja bemerkenswert und wirklich gut, dass das thema 'barrierefreihiet' so an relevanz gewinnt - aber dafür von den positionen abrücken zu müssen, in die ich über jahre (und nicht zuletzt in diesem forum) geprügelt wurde, das kann ich mir nur schwer vorstellen...

da bin ich (zuerst einmal) völlig borniert und berufe mich auf eine exakte lesart der WAI-Richtlinie 11 http://www.w3c.de/Trans/WAI/webinhalt.html#gl-use-w3c: "Verwenden Sie W3C-Technologien und -Richtlinien." - und das schließt IMHO grafiken als platzhalter vollständig aus...

ich weiß, das ist blöd. gibt es nicht andere techniken?

grüße aus Leipzig
willie

ps: wie funktioniert eigentlich das verlinken mit text statt uri?

[willie.de]

hallö nochmal,

[...] und das schließt IMHO grafiken als platzhalter vollständig aus...

ich fühle mich gestärkt: http://www.w3.org/TR/WCAG10-CSS-TECHS/#spacer: "If content developers _cannot_ use style sheets and _must_ use invisible or transparent images [...]" das heißt doch für mich, auf der 'richtigen seite' zu sein ;-)
kann es sein, dass die leute von http://www.123-barrierefrei.de/barrierefreiheit/wassehenscreenreader/ da (ausschließlich) von direkt formatiertem CSS reden?! ein 'display:none'(!) im verwendeten stylesheet http://www.123-barrierefrei.de/barrierefreiheit/wassehenscreenreader/css/style.css dürfte diese annahme zu unterstützen...

ps: wie funktioniert eigentlich das verlinken mit text statt uri?

hallo? danke!

grüße aus Leipzig
willie

[Gordon]

Hallo Willie,

vielen Dank für Dein Engagement. Der Dank geht natürlich auch an die anderen Antworter auf meine Frage. Ich glaube, Du hast mich eventuell etwas mißverstanden. Ich möchte dieses Blank-Gif nicht als Layoutgrafik verwenden, um ein pixelgenaues Layout zu gestalten, sondern es soll eine Funktion erhalten. W3C weist darauf hin, daß man auf Layoutgrafiken verzichten soll. Das haben wir auch. Aber ich gehe mal davon aus, daß es nicht völlig verboten sein darf, Bilder mit Verlinkungen zu benutzen : ). Aber daß man ein image mit height=0 und width=0 quält und daß man deshalb in die HTML-Hölle kommen kann, denke ich leider auch. Schon irgendwie doof. Aber danke nochmal für die Infos.

Deine Frage "wie funktioniert eigentlich das verlinken mit text statt uri?" habe ich in diesem Zusammenhang nicht ganz nachvollziehen können.

GG

[Jeena Paradies]

Hallo,

Aber daß man ein image mit height=0 und width=0 quält und daß man deshalb in die HTML-Hölle kommen kann, denke ich leider auch. Schon irgendwie doof. Aber danke nochmal für die Infos.

Hast du dir mal den Artikel durchgelesen, den ich verlinkt habe? Dort wird es ungefär so gemacht:

<!-- HTML -->
<ul id="skip">
 <li><a href="#content">skip to content"></a></li>
 <li><a href="#subnavi">skip to subnavigation</a></li>
 <li><a href="#search">skip to searchform</a></li>
</ul>
<!-- Ende HTML -->

/* CSS */
#skip {
 position: absolute;
 left: -9999px;
 top: -9999px;
}
/* Ende CSS */

Somit wird die Ganze Liste aus dem Sichtbaren Bereich geschoben. Wenn jemand kein CSS hat sieht er das alles, bzw. bekommt es vorgelesen. Dadurch braucht der Browser auch nicht noch eine extra Anfrage wegen eines transparenten GIFs zu machen, das sowieso niemand sieht.

Deine Frage "wie funktioniert eigentlich das verlinken mit text statt uri?" habe ich in diesem Zusammenhang nicht ganz nachvollziehen können.

Wie du das meinst musst du noch mal erklären, ich verstehe überhaupt nicht wie du das meinst. Wenn du an Sprungmarken denkst dann geht das so:

<div id="content">
 <!-- hier der ganze Inhalt rein -->
</div>

Und wenn man dann auf den Link <a href="#content">skip to content"></a> klickt dann springt der Browser genau zu diesem div mit der id "content". Das funktioniert eigentlich in so ziemlich allen aktuellen Browsern, außer dem NS 4.x, den wohl - meiner Erfahrung nach - aber niemand für einen Screenreader verwenden wird. Wenn ich mich irre bitte ich um Berichtigung.

Grüße
Jeena Paradies

[Tobias Müller]

Hallo allerseits,

<!-- HTML -->
<ul id="skip">
<li><a href="#content">skip to content"></a></li>
<li><a href="#subnavi">skip to subnavigation</a></li>
<li><a href="#search">skip to searchform</a></li>
</ul>
<!-- Ende HTML -->

/* CSS */
#skip {
position: absolute;
left: -9999px;
top: -9999px;
}
/* Ende CSS */

Ich blende den Text einer grafischen CSS-Navigation beispielsweise immer so aus:

HTML:
<ul id="navi">
  <li><a href="link1.html"><span class="nichtzeigen">Link1<span></a></li>
  <li><a href="link2.html"><span class="nichtzeigen">Link2<span></a></li>
</ul>

CSS:
.nichtzeigen {
  display:block;
  margin-left:-10000em;
}

Idealerweise sollte das umgebende Element dann noch ein overflow:hidden erhalten.

MfG, Mülli

[Jeena Paradies]

Hallo,

CSS:
.nichtzeigen {
  display:block;
  margin-left:-10000em;
}

Das Problem dabei ist aber dass du im sichtbaren Bereich einen leeren Balken in höhe der Navigation hast.

Grüße
Jeena Paradies

[Tobias Müller]

Hallo Jeena,

Das Problem dabei ist aber dass du im sichtbaren Bereich einen leeren Balken in höhe der Navigation hast.

Deshalb ja das overflow:hidden für das umgebende Element. Damit hatte ich bislang noch keine Probleme.

MfG, Mülli

[Cyx23]

Hallo,

[...] Damit hatte ich bislang noch keine Probleme.

mir ist unklar welche Screenreader als Test nötig und aussagefähig  sind. Um ganz sicher zu gehen müsste offenbar erstmal eine verläßliche Umgebung definiert werden.

Ich habe gerade testweise eine Software "webform" bzw. http://www.webformator.com angeschaut, ein IE-Aufsatz (Zitat:"Webdesigner können mit dem WebFormator überprüfen, ob ihre Internetseiten auch für sehgeschädigte Surfer lesbar sind; vorausgesetzt ..."). Da wird offenbar display:none einwandfrei angezeigt, ausser wenn in den Voreinstellungen der Default verändert und "nur wirklich sichtbare Objekte zeigen" aktiviert wird.

Wer das Teil also als Screenreader nutzt (Zitat:"Produktinfo - Der WebFormator erleichtert blinden und sehbehinderten Internetsurfern das Surfen im Internet.") und die Voreinstellungen lässt bekommt Links auch bei display:none angezeigt.

Grüsse

Cyx23

[molily]

Hallo,

mir ist unklar welche Screenreader als Test nötig und aussagefähig  sind.

Dann teste doch mal mit JAWS, Window-Eyes und IBM Home Page Reader. Das dürften, neben Virgo in Deutschland, die wichtigsten sein. Aber die Ergebnisse siehst du ja auch auf http://css-discuss.incutio.com/?page=ScreenreaderVisibility.

Und ja, Webformator ist ebenfalls verbreitet, zumindest im deutschsprachigen Raum. Er stellt aber wie du siehst eine Ausnahme dar.

Mathias

[Cyx23]

Hallo,

Dann teste doch mal mit JAWS, Window-Eyes und IBM Home Page Reader. Das dürften, neben Virgo in Deutschland, die wichtigsten sein. Aber die Ergebnisse siehst du ja auch auf http://css-discuss.incutio.com/?page=ScreenreaderVisibility.

danke, die Screenreader werde ich mir noch genauer anschauen.

Und ja, Webformator ist ebenfalls verbreitet, zumindest im deutschsprachigen Raum. Er stellt aber wie du siehst eine Ausnahme dar.

Es sind in der einfachen Version mit Bildschirmausgabe nur 2 MB Programm nötig. Die anderen Pakete liegen schon bei 40 MB und greifen vmtl. auch tiefer in den jeweiligen PC ein. Webformator hätte als einfache Kontrolle durchaus Vorteile wenn das Ergebnis verläßlich genug ist.

Mit dem wohl nötigen Verzicht auf display:none ergeben sich jedenfalls erstmal einige Nachteile.
So ist eine Positioinierung bei Netscape 4 oft nicht möglich bzw. funktioniert nicht oder hat unerwünschte Effekte.
Wenn ein Sprung zur Navigation möglich sein soll wie bei diesem Beispiel "Barrierefreies Webdesign", ist der Link "Zur Navigation" ja noch einfach beherrschbar, aber kann auch bereits den Aufbau stören oder vielleicht den Resizebug forcieren.
Falls dann noch ein Sprungziel und ein Link zum Inhalt in eine Navigations-Liste eingebaut werden ist für Netscape 4 die Positionierung u.U. nicht möglich.
Ähnlich die Auswirkungen wenn beim Verzicht auf CSS eine immer gleiche Navigation, also z.B. inklusive Sub-Menus, angeboten werden soll (also im "Normalfall" per CSS teilweise ausgeblendet wird).
Eigentlich gehe ich erstmal davon aus dass eine solche Konsistenz einer immer gleichen Navigation Vorteile bei der Orientierung bietet selbst wenn mehr Links aufgezählt werden als bei der Bildschirmdarstellung, kann aber schlecht abschätzen wie sich ein Sehbehinderter eine umfangreichere Navigation merkt und vorstellt, und ab welchen Volumen zusätzliche Gliederungen hilfreich werden.
Immerhin dürften die grössten Probleme mit position:absolute durch ein eigenes CSS nur für Netscape 4 zu lösen sein, zumindest solange kein auf Netscape 4 aufbauender Screenreader zu befürchten ist.

Grüsse

Cyx23

[willie.de]

hallö zu verspäteter stunde,

ich war ein paar tage lang in der deutschen Hauptstadt des Friedens und von der außenwelt abgeschnitten...

[...] Ich glaube, Du hast mich eventuell etwas mißverstanden. Ich möchte dieses Blank-Gif nicht als Layoutgrafik verwenden, um ein pixelgenaues Layout zu gestalten, sondern es soll eine Funktion erhalten.

ich hab dich wahrscheinlich schon richtig verstanden. du suchst einen weg, barrierefreiheit deiner seiten zu erreichen und suchst nach einem weg, entsprechende elemente für screenreader usw. für 'normale anzeigeprogramme' zu verstecken. das finde ich gut (und versuche ich auch).

W3C weist darauf hin, daß man auf Layoutgrafiken verzichten soll.

darauf bezieht sich meine quasi-kritik. ich les das eben strict; 'quasi' steht da, weil sie sich nicht gegen dich sondern die vorgeschlagene technik richtet.

Das haben wir auch. Aber ich gehe mal davon aus, daß es nicht völlig verboten sein darf, Bilder mit Verlinkungen zu benutzen : ).

das ja nun nicht. aber bilder einzufügen, damit das layout (in dem fall für besondere ausgabegeräte/-programme) so wird, wie es werden soll ;-)

Aber daß man ein image mit height=0 und width=0 quält und daß man deshalb in die HTML-Hölle kommen kann, denke ich leider auch. Schon irgendwie doof. Aber danke nochmal für die Infos.

grundsätzlich beziehe ich mich hier auf eine eher puristische html- und css-philosophie. (ein scherz am rande: 'filosofie' - sollte so pure *NDR* aussehen?) und deshalb ist mir so unwohl beim gedanken eines für wahrscheinlich nicht-blinde blinden (mithin sinnlosen, überflüssigen) bildes...

Deine Frage "wie funktioniert eigentlich das verlinken mit text statt uri?" habe ich in diesem Zusammenhang nicht ganz nachvollziehen können.

das war wohl zu sehr nebenbei gefragt. ich bezog mich damit auf das verlinken hier im forum. ein beispiel: ich kenne nur diese art link: http://jeenaparadies.net/weblog/2004/november/net-umzug/. Jeena Paradies ist da trickreicher und versieht (zb. in seiner antwort auf diesen beitrag https://forum.selfhtml.org/?t=95163&m=577102) den link mit dem Text 'Ich ziehe ins .net(Z) um'.

grüße aus Leipzig
willie

[Jeena Paradies]

Hallo,

Jeena Paradies ist da trickreicher und versieht (zb. in seiner antwort auf diesen beitrag https://forum.selfhtml.org/?t=95163&m=577102) den link mit dem Text 'Ich ziehe ins .net(Z) um'.

Das ist eigentlich ganz einfach guck mal in der textarea wenn du auf diesen Beitrag antworten willst:

Meine kuhle Homepage

Grüße
Jeena Paradies

[willie.de]

hallö,

Das ist eigentlich ganz einfach guck mal in der textarea wenn du auf diesen Beitrag antworten willst:

Meine kuhle Homepage

danke für den tipp! hab ich in den (neuen?) FAQ nicht finden können.

schade, dass externe bilder bei mir nicht angezeigt werden ;-) aber sehr schön!

grüße aus Leipzig
willie

[Jeena Paradies]

Hallo,

danke für den tipp! hab ich in den (neuen?) FAQ nicht finden können.

Ist aber schon gemeldet: http://bugs.selfhtml.org/bug.php?op=show&bugid=412&pos=0

schade, dass externe bilder bei mir nicht angezeigt werden ;-) aber sehr schön!

Um so besser, dann hast du ja (hoffentlich) das alt Attribut gesehen, auf welches ich eigentlich damit hinaus wollte ;-)

Grüße
Jeena Paradies

[willie.de]

hallö nochmal,

Um so besser, dann hast du ja (hoffentlich) das alt Attribut gesehen, auf welches ich eigentlich damit hinaus wollte ;-)

leider nicht. ist eine eigenschaft von mozilla, bei der ich mir sehr unsicher bezüglich der frage "bug or feature?" bin - offensichtlich nicht unbekannt und wird (vielleicht, hoffentlich?) geändert.
http://forum.de.selfhtml.org/archiv/2004/7/t85397/#m502597

grüße aus Leipzig
willie

[Cyx23]

Hallo Willie,

leider nicht. ist eine eigenschaft von mozilla, bei der ich mir sehr unsicher bezüglich der frage "bug or feature?" bin - offensichtlich nicht unbekannt und wird (vielleicht, hoffentlich?) geändert.

der Ablauf um d. Alt-Text zu zeigen wäre 1. Bild laden und 2. kein Bild verfügbar. Also vom logischen Ablauf und vmtl. auch von der Programmierung her erstmal sehr unterschiedlich zum "originating server only" Vorgang.

Grüsse

Cyx23

[willie.de]

hallö,

der Ablauf um d. Alt-Text zu zeigen wäre 1. Bild laden und 2. kein Bild verfügbar. Also vom logischen Ablauf und vmtl. auch von der Programmierung her erstmal sehr unterschiedlich zum "originating server only" Vorgang.

nunja, den realen vorgang kann ich ganz gut selbst nachvollziehen. das problem liegt für mich in der definition einer 'alternativen' bildbeschreibung: alternativ wozu? zum fehlenden bild.

dass dieses verhalten als (notwendiger) bugfix beschrieben wird, weist darauf hin, dass ich mit dieser problemsicht nicht sehr einsam bin.

danke für unterstützung und
grüße aus Leipzig
willie

[willie.de]

hallö nochmal,

schade, dass externe bilder bei mir nicht angezeigt werden ;-) aber sehr schön!
Um so besser, dann hast du ja (hoffentlich) das alt Attribut gesehen, auf welches ich eigentlich damit hinaus wollte ;-)

im FF1.0 wird immerhin ein tooltip angezeigt (kein text in der seite). das verlangt aber eine gewisse blindsichtigkeit bei der führung des cursors. (entschuldige den kalauer ;)

grüße aus Leipzig
willie

[Marc]

Moin moin

Navigation nur für Blinde (d. h. ausgegeben nur auf Braille-Zeile und Audio-Geräten:

CSS (bestimmt, dass so gekennzeichneter Text nicht auf Projektoren, Bildschirmen usw. ausgegeben wird, braille und aural sind nicht erwähnt, d. h. hier greift die Anweisung display:none  nicht! Audio-Ausgabe-Geräte und Braille-Zeile geben den Inhalt also aus):
--------------------------------

/*  Klasse zur Kennzeichnung von Elementen, die nur von Audio-Geraeten und der Braille-Zeile  */
/*  wiedergegeben werden sollen ............................................................  */

@media screen,projection,print,tty,tv
  {
   .sr-hint {display:none;}   /* Hinweis nur fuer Screenreader und Audio */
  }

-------------------------------

HTML:

-------------------------------
<div class="sr-hint">
<!-- Hier steht, was nur Screenreader und Audio-Geraete wiedergeben sollen -->
</div>
-------------------------------

So lässte sich viel mehr Text unterbringen als mittels alt-Text. Z. B. ganze Menüs!

Gruß,
Marc.

[Ingo Turski]

Hi,

CSS (bestimmt, dass so gekennzeichneter Text nicht auf Projektoren, Bildschirmen usw. ausgegeben wird, braille und aural sind nicht erwähnt, d. h. hier greift die Anweisung display:none  nicht!

Du solltest Dich besser informieren oder zumindest den Thread ganz und aufmerksamer lesen, bevor Du so einen Unsinn schreibst. Natürlich ist das so definiert und den hier beteiligten Postern dürfte das längst bekannt sein. Aber darum geht es bei diesem Problem doch gar nicht. Lies weiter und auch Du wirst entdecken, daß zwischen der Theorie bzw. den Specs und der Wirklichkeit, sprich Umsetzung durch die Screenreader, eine Diskrepanz besteht - weshalb auch dieser Thread eröffnet wurde und worum sich die Diskussion im wesentlichen dreht.

freundliche Grüße
Ingo

[Marc]

Moin moin

inzwischen weiß ich, dass diese Methode nciht funktioniert und zwar aus zwei Gründen:

1.) die meisten Blinden lassen sich die Bildschirmausgabe des Internet-Explorers vorlesen. Mit meiner CSS-Anweisung habe ich vor dem Internet-Explorer die Ausgabe aber verborgen... - also liest der Screenreader auch cnihts vor

2.) Mit der Unterstützung von CSS durch Screenreader scheint es noch nicht so weit zu sein...

Gruß,
Marc.

[Cyx23]

Hallo,

wie von mir befürchtet scheinen unter gewissen Umständen Darstellungsfehler durch ein Verschieben (als Ersatz für display:none wegen einiger Screenreader) möglich. Ich hatte allerdings etwas ungewöhnliche Werte von left:-999em; und width:777em; gewählt, insofern vielleicht praxisfremd.
Wenn nun bei Mozilla die Schriftgrösse auf über 100% gesetzt wird ist auf der betr. Seite (Elemente u.a. in einer Liste) bei meinem Test reproduzierbar erst ein Anzeigfehler und letztlich ein Hängen oder eigentlich Absturz bei Mozilla wie auch bei FireFox festzustellen (interner Rechenfehler oder zuwenig "Fläche"?).

Mein vorläufiges Fazit ist aber trotz meiner großen Werte erstmal auf den Schiebe-Hack zu verzichten, es ist sowieso peinlich neben der Murkserei einer verünftigen Skalierung beim IE und W3C-Konformität solche Hacks ausgerechnet zur Barrierefreiheit anzuwenden.

Grüsse

Cyx23

[Kristof Lipfert]

Hallo Forum,

Mein vorläufiges Fazit ist aber trotz meiner großen Werte erstmal auf den Schiebe-Hack zu verzichten

eine vorläufige Lösung habe ich jetzt in Barrierefrei Webdesign für Alle unter display:none beschrieben.
Das geschilderte Problem war bei der Seite Barrierefreies Webdesign - Web Design for All mit den genannten em-Werten für .keincss zu beobachten.

Beste Grüße,
Kristof Lipfert

[Detlef G.]

Hallo Kristof

eine vorläufige Lösung habe ich jetzt in Barrierefrei Webdesign für Alle unter display:none beschrieben.

Imho ist so eine allgemeingültige Lösung sehr oft gar nicht erforderlich.

Bei vielen Layouts ist es nicht wirklich nötig, die entsprechenden Links
vollständig unsichtbar zu machen. Oft ist es möglich, diese mit
entsprechender Formatierung als Layoutelemente (z.B. Trennlinien) zu
verwenden, statt dafür Border zu verwenden oder gar exra Elemente einzufügen.

Auf Wiederlesen
Detlef

[Cyx23]

Hallo Detlef,

Bei vielen Layouts ist es nicht wirklich nötig, die entsprechenden Links
vollständig unsichtbar zu machen. Oft ist es möglich, diese mit
entsprechender Formatierung als Layoutelemente (z.B. Trennlinien) zu
verwenden, statt dafür Border zu verwenden oder gar exra Elemente einzufügen.

auf visuell dargestellte Strukturierungen zu verzichten wäre ja zumal in einem visuellen Medium auch keine Lösung, aber entsprechende Zwischentitel und Sprungmarken für Screenreader bei media=screen nicht zu verstecken dürfte auch kein Allheilmitel sein.

"eine allgemeingültige Lösung" ist hier um so mehr gefordert weil die Masstäbe wie W3C-Konformität auf so vielen Ebenen versagen. Zuerst wird  die Zugänglichkeit und Stabilität auch mit dem Argument der Barrierefreiheit umfassend verschlechtert, dann geht es soweit dass die Konzeptrettung durch CSS-Hacks auch noch auf Screenreader angewendet werden muss. Das Experiment CSS, Ansätze wie Tableless Layout sind eigentlich gescheitert, nur wäre es derzeit fraglich auf erreichte Vorteile und mögliche zukünftige Entwicklungen zu verzichten, ein Zurück gibt es eben auch nicht.

Wenn "eine allgemeingültige Lösung" nicht möglich ist, die Schieberei aus dem Viewport jedenfalls scheint keine Lösung zu sein, wird eine harmlosere Lösung nötig wie im vorherigen Posting vorgestellt, oder es muß eben doch display:none in barrierefreien Seiten stehen, eine auch nicht zu verachtende Alternative, schliesslich ist valides CSS und sematisch richtiges HTML die Voraussetzung, und das darf auch den Herstellern und Nutzern von Screenreadern zugemutet werden, erst recht wenn berücksichtigt wird wieweit die allgemeine Zugänglichkeit bereits verschlechtert worden ist, da muss nicht noch eins drauf gesetzt werden.

Grüsse

Cyx23

[Detlef G.]

Hallo Cyx23

auf visuell dargestellte Strukturierungen zu verzichten wäre ja zumal in einem visuellen Medium auch keine Lösung,

Wo habe ich geschrieben, dass auf diese verzichtet werden soll?
Oder habe ich mich so unverständlich ausgedrückt?

aber entsprechende Zwischentitel und Sprungmarken für Screenreader bei media=screen nicht zu verstecken dürfte auch kein Allheilmitel sein.

Die Sprungmarken verstecken?
Du meinst sicher die Verweise auf diese.

Was ich sagen wollte:
Meiner Meinung nach ist es nicht immer nötig, die entsprechenden Verweise
vollständig verschwinden zu lassen, es reicht oft, diese im Layout zu
verstecken.
Bei vielen Layouts ist es durchaus möglich, diese Links so zu formatieren,
dass sie nicht mehr als Textlinks in Erscheinung treten, sondern ein
vorhandenes Layout- oder Design element ersetzen.

So kann z.B. eine gewünschte Trennline dieser Link sein, bei dem die Maße
und Farben entsprechend eingestellt sind, statt diese mittels Border zu
realisieren.

Wenn "eine allgemeingültige Lösung" nicht möglich ist, die Schieberei aus dem Viewport jedenfalls scheint keine Lösung zu sein, wird eine harmlosere Lösung nötig wie im vorherigen Posting vorgestellt,

Natürlich, nur sollte auch diese Lösung nicht gedankenlos angewandt werden.

Ich wollte lediglich zum Ausdruck bringen, dass es oft mit ein bisschen
Überlegung nicht nötig ist, die Links wirklich von der Seite verschwinden zu
lassen, es oft auch reicht lediglich ihr Aussehen zu verändern (eventuell
auch drastisch).

Auf Wiederlesen
Detlef

[molily]

Hallo,

eine vorläufige Lösung habe ich jetzt in Barrierefrei Webdesign für Alle unter display:none beschrieben.

Ich habe die gesamte Entwicklung nicht mehr im Kopf, aber die Experten diskutieren seit mehreren Jahren über einer angemessenen Ersatz. Das von dir beschriebene overflow:none und height:0 kam auch irgendwo im Zusammenhang mit Image Replacement zur Sprache. Meiner Erinnerung nach machte diese Methode Schwierigkeiten in gewissen Browsern, da müsste ich allerdings recherchieren.
visibility:hidden ist auf jeden Fall kontraproduktiv, das hat nahezu denselben Effekt auf Screenreader wie display:none. Man hätte wohl nichts gewonnen mit dieser Methode.

Deine Aussagen sind einmal wieder herzlich unkonkret (es gab unter vollkommen konstruierten, »praxisfremden« Umständen einen nicht näher beschriebenen Anzeigefehler), sodass ich sie weder verifizieren noch falsizifieren kann. Daraus lassen sich auf jeden Fall keine Schlüsse ziehen, daher ist mir kein vernünftiger Grund ersichtlich, wieso die overflow-Methode günstiger wäre. Die position:absolute-Methode scheint sich in vielen Tests bewährt zu haben. Meine Erfahrungen damit sind sowohl in Browsern als auch in Screenreadern gut.

Mathias

[Cyx23]

Hallo Mathias,

Ich habe die gesamte Entwicklung nicht mehr im Kopf, aber die Experten diskutieren seit mehreren Jahren über einer angemessenen Ersatz.

offenbar hält sich der Bedarf in Grenzen, sonst wäre vielleicht doch auch bei anderen Screenreadern eine Softwareanpassung erfolgt oder, wie beim genannten Software-Beispiel ja vorhanden, eine Option "unsichtbare Elemente anzeigen".

Das von dir beschriebene overflow:none und height:0 kam auch irgendwo im Zusammenhang mit Image Replacement zur Sprache. Meiner Erinnerung nach machte diese Methode Schwierigkeiten in gewissen Browsern, da müsste ich allerdings recherchieren.

Vmtl. meinst du Dinge wie "Fahrner Image ...", da hatte ich sowieso potentielle Probleme u.a. mit Suchmaschinen vermutet und deswegen die Diskussionen nicht im Detail weiterverfolgt, wäre jetzt in dem Zusammenhang natürlich interessant.

visibility:hidden ist auf jeden Fall kontraproduktiv, das hat nahezu denselben Effekt auf Screenreader wie display:none. Man hätte wohl nichts gewonnen mit dieser Methode.

Danke für den Hinweis, ich werde ggf. erstmal eine Weiche davorsetzen müssen wie Opera 6 CSS Weiche, ohne dass ich das als besonders elegant propagieren möchte, oder mir für Opera 6 etwas anderes überlegen; Opera 6 ist wohl noch mit 0,3% anzutreffen.

Deine Aussagen sind einmal wieder herzlich unkonkret (es gab unter vollkommen konstruierten, »praxisfremden« Umständen einen nicht näher beschriebenen Anzeigefehler), sodass ich sie weder verifizieren noch falsizifieren kann.

Es wird auch durch dein unzutreffendes "einmal wieder" nicht richtiger, es waren konkret eigentlich alle nötigen Angaben, URI und die nötige Änderung im CSS, verfügbar.
Andererseits ist es natürlich eine blöde Situation wenn jemand testet, keinen Fehler findet und nicht weiß ob alles richtig war, da habe ich aber erstmal keine andere Lösung gefunden.
Und dass ich auf möglicherweise »praxisfremde« Umstände hinweise halte ich für fair, zumal wenn ähnliche Fehler nicht bekannt geworden sind, auch wenn mir diese Umstände ausreichen um darauf umgehend zu reagieren.
Genauso kann ich auch Dinge wie Messfehler oder irgendwelche Seiteneffekte nicht ausschliessen, es sind genug Fehlerquellen vorstellbar.
Hier ist jetzt nochmal eine abgespeckte Beispieldatei, die nicht mehr abstürzt, aber den Bildschirmfehler anzeigt: Fehler beim display:none Ersatz durch position:absolute. Im Bereich der Navigation wird der Bildschirm nicht aktualisiert wenn die Schriftgrösse z.B. 120% beträgt.

Daraus lassen sich auf jeden Fall keine Schlüsse ziehen, daher ist mir kein vernünftiger Grund ersichtlich, wieso die overflow-Methode günstiger wäre. Die position:absolute-Methode scheint sich in vielen Tests bewährt zu haben. Meine Erfahrungen damit sind sowohl in Browsern als auch in Screenreadern gut.

Nachdem ich reproduzierbar Abstürze ausgerechnet dann hatte wenn die Schriftgrösse erhöht wird sind beim Mozilla irgendwelche Grenzen vorhanden.
Solch eine Grenze würde beim Scrollen langer Dateien (ggf.dazu eine Anhängigkeit von CSS-Eigenschaften) weniger auffallen, etwa wenn der Mozilla durch das Scrollen den Bildschirminhalt auch wieder aufbauen würde.
Da wenn ich es recht erinnere auf der Seite der NRW-Polizei auch mittles grosser em-Werte geschoben wird halte ich eine Warnung für angebracht, und die Situation ist u.U. kein Einzelfall oder so praxisfremd.
Auch wenn ein bestimmtes OS, Grafikkarte usw. nötig sein sollten hilfts nicht, anders wäre es wenn anhand der darzustellenden Fläche klar eine Pixelgrenze o.ä. des Mozilla berechnet werden kann, unabhängig von Grafikkarte usw..

Grüsse

Cyx23

[molily]

Hallo,

offenbar hält sich der Bedarf in Grenzen, sonst wäre vielleicht doch auch bei anderen Screenreadern eine Softwareanpassung erfolgt oder, wie beim genannten Software-Beispiel ja vorhanden, eine Option "unsichtbare Elemente anzeigen".

Ich glaube, zumindest das JAWS-Entwicklungsteam steht durchaus in regem Austausch mit der Accessibility-Szene. Die vertreten meines Wissens die Meinung, dass ein Screenreader seinem Namen nach eben nur das vorlesen soll, was auf dem Bildschirm erscheint. Dementsprechend hat sich von JAWS 4.5 zu 5.0 nicht viel geändert (bzw. erst von 4.0 zu 4.5 entstand das Problem in seiner Tragweite http://www.webaccessibility.info/lab/displaytest.html).

Und dass ich auf möglicherweise »praxisfremde« Umstände hinweise halte ich für fair, zumal wenn ähnliche Fehler nicht bekannt geworden sind, auch wenn mir diese Umstände ausreichen um darauf umgehend zu reagieren.

Die Wertekombination -999px/990x ist eben keine willkürliche Wahl, sondern ein Erfahrungswert, weil gewisse Browser andere Werte nicht schluckten. Irgendwo hatte ich eine Diskussion gelesen, bei der es um die Findung eines solchen optimalen Wertepaars ging. Es wundert mich daher nicht, dass andere Werte, insbesondere krasse Phantasiezahlen, andere Resultate erzielen.

Hier ist jetzt nochmal eine abgespeckte Beispieldatei, die nicht mehr abstürzt, aber den Bildschirmfehler anzeigt: Fehler beim display:none Ersatz durch position:absolute. Im Bereich der Navigation wird der Bildschirm nicht aktualisiert wenn die Schriftgrösse z.B. 120% beträgt.

Unter Firefox für Linux habe ich das Problem nicht nachvollziehen können. Unter Firefox 1.0 auf Windows 98SE tritt der Fehler tatsächlich auch bei mir auf. Aber anscheinend nur bei diesen Extremwerten, nicht z.B. bei -999px/990px. Und wohl auch nur in Verbindung mit position:fixed. Weil ich diese Bedingungen für ziemlich speziell halte, würde ich nicht sagen, dass die Methode an sich dadurch diskreditiert wird.
Andere Windows-Versionen habe ich hier nicht zur Verfügung, wären aber sicher interessant, vielleicht ist es ein Windows-98-Problem..

Nachdem ich reproduzierbar Abstürze ausgerechnet dann hatte wenn die Schriftgrösse erhöht wird sind beim Mozilla irgendwelche Grenzen vorhanden.

Hier wird Firefox nur zum Teil ewig lahm, da ich Windows 98 aber auf einem Pentium 133 laufen habe, auf dem Firefox sowieso eklig lahm ist bei allen möglichen Operationen, muss das nichts heißen.

Da wenn ich es recht erinnere auf der Seite der NRW-Polizei auch mittles grosser em-Werte geschoben wird halte ich eine Warnung für angebracht, und die Situation ist u.U. kein Einzelfall oder so praxisfremd.

Ja, wie gesagt, -999px/990px scheint sich erprobt zu haben, ich sehe keine Notwendigkeit, hier mit astronomischen em-Werten zu arbeiten. Bei der NRW-Polizei sehe ich -2000px ohne width (http://www.polizei.nrw.de/im/styles/basis.css). Irgendein Browser hatte bei 1000px eine Grenze, wenn ich mich richtig erinnere. Ohne width zu arbeiten ist wohl auch nicht sehr klug.

Mathias

[Jeena Paradies]

-999px/990px

Was bedeutet das eigentlich? top: -999px; und was ist das 990px?

Grüße
Jeena Paradies

[molily]

Hallo,

-999px/990px
Was bedeutet das eigentlich? top: -999px; und was ist das 990px?

left:-999px und width:990px wie auf der genannten Seite http://css-discuss.incutio.com/?page=ScreenreaderVisibility.

Mathias

[Cyx23]

Hallo,

Ich glaube, zumindest das JAWS-Entwicklungsteam steht durchaus in regem Austausch mit der Accessibility-Szene. Die vertreten meines Wissens die Meinung, dass ein Screenreader seinem Namen nach eben nur das vorlesen soll, was auf dem Bildschirm erscheint.

einen ähnlichen Standpunkt hatte ich auch erst erwogen, dann aber überlegt dass eine "Abbildung" des Bildschirms sowieso unmöglich ist, auch nicht sinnvoll ist ausser der Anwender möchte möglichst ungefiltert dran sein (was ich natürlich auch sehr gut nachvollziehen kann).
Zudem sind ja alle Methoden wie auch position ersetzbar oder gleich zu bewerten, position-Hacks wären dann bald aus den CSS zu entfernen weil auch nicht wirksam, oder aber, eigentlich noch heikler, bei Tolerierung von position entsteht eine letztlich unakzeptable Quasi-Norm vorbei an W3C usw. statt einer nötigen Lösung wie per media=screenreader oder =aural, gerade beim Thema Barrierefreiheit eigentlich ein Unding, und auch rechtlich eine sehr heikle Situation.

Die Wertekombination -999px/990x ist eben keine willkürliche Wahl, sondern ein Erfahrungswert, weil gewisse Browser andere Werte nicht schluckten. Irgendwo hatte ich eine Diskussion gelesen, bei der es um die Findung eines solchen optimalen Wertepaars ging. Es wundert mich daher nicht, dass andere Werte, insbesondere krasse Phantasiezahlen, andere Resultate erzielen.

Zunächst hatten mir meine "üblichen" Werte schon nicht gereicht, dann hatte ich ein (wohl auch etwas prominentes) Beispiel mit -1000em gefunden.
Es sind eben doch keine krassen Phantasiezahlen, auch wenn es mit px nicht passiert wäre.

Unter Firefox für Linux habe ich das Problem nicht nachvollziehen können. Unter Firefox 1.0 auf Windows 98SE tritt der Fehler tatsächlich auch bei mir auf. Aber anscheinend nur bei diesen Extremwerten, nicht z.B. bei -999px/990px. Und wohl auch nur in Verbindung mit position:fixed. Weil ich diese Bedingungen für ziemlich speziell halte, würde ich nicht sagen, dass die Methode an sich dadurch diskreditiert wird.

Es bedarf wohl "em" und fixed, von daher würde ich die Warnung "em" hier gar nicht zu verwenden für sinnvoll und nötig halten, und empfehlen bei fixed genauer zu testen, und sich vielleicht noch des offenbar vorhandenen Restrisikos und der sowieso falschen Vorgehensweise bewußt zu sein. (zudem kann ich das mal als Mozilla-Bug melden)

Und "diskreditiert"? Das Verfahren als solches sowieso, und die Methode selbst könnte auch ihre "Unschuld" verloren haben, aber das wird m.E. erst in einem politischen Kontext relevant, und betrifft dann zunächst die Verwendung von CSS, die Rolle des W3C und die Screenreaderhersteller, und fällt dann wieder auf die hier betroffene Webdesign-Szene und letztlich alle an Konformität oder an Codeerstellung überhaupt Interessierte zurück.
Wie eingangs schon angedeutet, Austausch mit der Accessibility-Szene usw. ist in der Form womöglich falsch, vielleicht sollten bei solchen Themen eben doch mal ganz kleinkariert Erbsen gezählt werden wie anderswo auch um zu einem verläßlichen und verbindlichem Ergebnis zu kommen, sonst hätten Ansprüche wie Validität und Code-Konformität doch gleich bei "best @800/explorer" bleiben können und es wär gut.

Grüsse

Cyx23