Screenreader und display:none

[Dieter Raber]

Hallo,

Ich bastele gerade eine Formavalidation und habe eine Frage dazu. In meinem Szenario sieht ein Formelement mit allem drum und dran etwa so aus:

<label>
  <strong>Passende Fehlermeldung</strong>
  Labeltext
  <formelement />
</label>

Das ist alles noch etwas unausgegoren, aber im Prinzip soll es so funktionieren, dass das <strong>-Element erstmal auf display:none stehen soll und das Formelement unter Umstaenden die Fehlermeldung sichtbar macht.

Technisch ist das ja sowohl client- als auch serverseitig kein Problem, sondern es geht mir darum, was ein Screenreader davon halten wuerde. Wuerde er den Fehler auch bei display:none vorlesen oder nur dann, wenn er auch angezeigt wird.

Gibt es sonstige Einwaende, die mir bisher vielleicht entgangen sind? Ausserdem wuerden mich auch andere Ideen interessieren, wie man die Fehlermeldung geschickt unterbringen kann. Ich wuerde am liebsten ohne irgendwelche Konfigurationsbereiche auskommen.

Gruß,

Dieter

[Orlando]

<label>
  <strong>Passende Fehlermeldung</strong>
  Labeltext
  <formelement />
</label>

Das ist alles noch etwas unausgegoren, aber im Prinzip soll es so funktionieren, dass das <strong>-Element erstmal auf display:none stehen soll und das Formelement unter Umstaenden die Fehlermeldung sichtbar macht.

Kennst du den potentiellen Fehler bereits bei der Auslieferung? Die Fehlermeldung lediglich vorab zu verstecken empfinde ich als wenig elegant. Da du ohnehin per JavaScript die display-Eigenschaft änderst wäre das nachträgliche Einfügen der Meldung sinnvoller. Auf der sicheren Seite bist du nur mit serverseitiger Technik und dort hast du dann ohnehin freie Hand.

[…] es geht mir darum, was ein Screenreader davon halten wuerde. Wuerde er den Fehler auch bei display:none vorlesen oder nur dann, wenn er auch angezeigt wird.

display:none wird von vielen Screenreadern nicht vorgelesen.

http://www.access-matters.com/screen-reader-test-results/
http://css-discuss.incutio.com/?page=ScreenreaderVisibility
http://www.webaccessibility.info/lab/displaytest.html

Besser geeignet ist position:absolute; left:weit-weg;

Ausserdem wuerden mich auch andere Ideen interessieren, wie man die Fehlermeldung geschickt unterbringen kann.

Mittig. ;-)

Roland

[Dieter Raber]

Hi Roland,

Kennst du den potentiellen Fehler bereits bei der Auslieferung?

Eigentlich schon, letzendich geht es ja immer um solche Sachen wie Felder sie nicht leer sie duerfen, Emailsyntax, Passwoerter, die matchen muessen etc.

Die Fehlermeldung lediglich vorab zu verstecken empfinde ich als wenig elegant.

Ich bin auch nicht gerade vor Begeisterung ueber soviel Eleganz in Traenen ausgebrochen. Die Alternative sind halt Konfigurationsbereiche, das gefaellt mir auch nicht sonderlich. Wenn ich die Elemente on-the-fly generiere, muss ich wieder ein JS-Object basteln und irgendwas fuer die Serverseite, so haette man alles in einem Aufwasch. Im Moment benutze ich ini-Dateien, die einerseits das Javascript und andererseits die PHP-Meldungen generieren. Eleganter finde ich das auch nicht unbedingt.

Auf der sicheren Seite bist du nur mit serverseitiger Technik und dort hast du dann ohnehin freie Hand.

Serverseitig ist auch nicht so das Problem, es geht mir mehr um JS.

display:none wird von vielen Screenreadern nicht vorgelesen.

http://www.access-matters.com/screen-reader-test-results/
http://css-discuss.incutio.com/?page=ScreenreaderVisibility
http://www.webaccessibility.info/lab/displaytest.html

Danke fuer die Links, schau ich gleich mal rein.

Besser geeignet ist position:absolute; left:weit-weg;

Da dachte ich auch schon daran, aber auch hier weiss ich nicht, was Screenreader damit anstellen.

Ausserdem wuerden mich auch andere Ideen interessieren, wie man die Fehlermeldung geschickt unterbringen kann.

Mittig. ;-)

.error {
  font: bold 16px 'Comic Sans';
  color: yellow;
  background: blue;
  text-decoration:blink;
  text-align:center;
}
Oder macht man das besser mit <font> :-) ?

Gruß,

Dieter

[Steel]

Hallo!

Kennst du den potentiellen Fehler bereits bei der Auslieferung?
Eigentlich schon, letzendich geht es ja immer um solche Sachen wie Felder sie nicht leer sie duerfen, Emailsyntax, Passwoerter, die matchen muessen etc.

Moeep! :) Wie moechtest Du denn solche Sachen ueberpruefen? Doch mit Javascrip, wie ich dich verstehe? Nun. Das ist keine gute Idee eineServerseitige Pruefung ist quasi Pflicht. Es hat sich schon so mancher gewundert warum seine Formulare Dinge verschcken, die doch mit JS geprueft werden...

Also kannst Du die Felder auch Serverseitig in das Dokument einbauen.

Da Du aber ja sowieso JS benutzen willst, kannst Du natuelrich noch einen draufsetzen, belaesst es bei deinem Plan aber baust ne kleine AJAX geschichte ein, die dir die Felder serverseitig testet. (wobei du aber wieder das Problem hast, dass ohne JS nix funktioniert und du sowieso eine zusaetzliche und von JS unabhaengige Serverseitige Variane brauchst.

[Dieter Raber]

Hallo Steel,

Moeep! :) Wie moechtest Du denn solche Sachen ueberpruefen? Doch mit Javascrip, wie ich dich verstehe? Nun. Das ist keine gute Idee

Ich weiss, ich habe dazu vor ein paar Jahren den mittlerweile etwas veralteten Fachartikel fuer Selfhtml geschrieben. ;-)

Also kannst Du die Felder auch Serverseitig in das Dokument einbauen.

Das geht ja auch aus meinem Posting hervor

Da Du aber ja sowieso JS benutzen willst, kannst Du natuelrich noch einen draufsetzen, belaesst es bei deinem Plan aber baust ne kleine AJAX geschichte ein, die dir die Felder serverseitig testet. (wobei du aber wieder das Problem hast, dass ohne JS nix funktioniert und du sowieso eine zusaetzliche und von JS unabhaengige Serverseitige Variane brauchst.

Meine Frage war, wie Screenreader ueber display:none denken.

Gruß,

Dieter

[Steel]

Meine Frage war, wie Screenreader ueber display:none denken.

Ich glaub, Du hast Recht! ... Da! eine Ablenkung! *fade*

[wahsaga]

hi,

Kennst du den potentiellen Fehler bereits bei der Auslieferung?
Eigentlich schon, letzendich geht es ja immer um solche Sachen wie Felder sie nicht leer sie duerfen, Emailsyntax, Passwoerter, die matchen muessen etc.

Das kann man nicht nur "Fehlermeldung" nennen, sondern auch simplen Hinweis.

Die Fehlermeldung lediglich vorab zu verstecken empfinde ich als wenig elegant.
Ich bin auch nicht gerade vor Begeisterung ueber soviel Eleganz in Traenen ausgebrochen.

<label>
  <strong>Achtung, dieses Feld darf nicht leer gelassen werden</strong>
  Labeltext
  <formelement />
</label>

Das ist Hinweis, und Fehlermeldung zugleich.
Ob es überhaupt vor dem sehenden Nutzer versteckt werden muss?

Es könnte zunächst "normal" gestaltet werden.
Im Fehlerfall darf es dann gern dynamisch auf "rot, fett, blinkend" umformatiert werden.

Dass der Screenreader die Meldung gleich von Anfang an mit vorliest, ist m.E. auch nicht unbedingt von Nachteil.

Man könnte es vielleicht auch zunächst nur in einem Span unterbringen (normaler Hinweis) - und dann im Fehlerfalle Span per Javascript durch Strong austauschen, um ihm mehr Bedeutung zu geben und gezielter darauf hinzuweisen, dass es noch nicht "erfüllt" ist.

gruß,
wahsaga

[Dieter Raber]

Hallo wahsaga,

Das ist Hinweis, und Fehlermeldung zugleich.
Ob es überhaupt vor dem sehenden Nutzer versteckt werden muss?

Ich hatte beim Schreiben sowas im Kopf wie 'Die Emailadresse sieht irgendwie komisch aus' (ohne jetzt eine Diskussion ueber Sinn und Unsinn von Emailvalidierungen lostreten zu wollen). Das waere jedenfalls eher eine Fehlermeldung, die erst dann eintritt, wenn der value von 'Email' bekannt ist. Wenn es eher um Hinweise ginge, koennte ich die ja im title unterbringen und meinetwegen bei Bedarf im <strong> etwas prominenter machen.

Im Fehlerfall darf es dann gern dynamisch auf "rot, fett, blinkend" umformatiert werden.

Deinen Geschmack moechte ich haben ;-)

Dass der Screenreader die Meldung gleich von Anfang an mit vorliest, ist m.E. auch nicht unbedingt von Nachteil.

Wenn es sich um eine Fehlermeldung handelt, schon, bei Hinweisen hingegen waere das natuerlich wuenschenswert.

Gruß,

Dieter

[wahsaga]

hi,

Ich hatte beim Schreiben sowas im Kopf wie 'Die Emailadresse sieht irgendwie komisch aus' (ohne jetzt eine Diskussion ueber Sinn und Unsinn von Emailvalidierungen lostreten zu wollen). Das waere jedenfalls eher eine Fehlermeldung, die erst dann eintritt, wenn der value von 'Email' bekannt ist.

"Eine E-Mail-Adresse sollte das Format 'Name at Domain Punkt TLD' haben" wäre wieder als beides zu gebrauchen.

Aber gut, wenn du darauf hinweisen willst, dass vor dem "at" was fehlt, oder dahinter kein Punkt auftaucht o.ä., dann sind das schon speziellere Fehlermeldungen, da kannst du so wohl nicht vorgehen. Die "auf Verdacht" alle schon im Dokument unterzubringen, halte ich aber für ungünstig; und das unabhängig von der Frage, ob ein Screenreader jetzt trotz display:none vorliest oder nicht - ein Textbrowser zeigt's auf jeden Fall an, und liefert damit seinem Nutzer einen Inhalt, der erst mal ziemlicher Quark wäre.

Im Fehlerfall darf es dann gern dynamisch auf "rot, fett, blinkend" umformatiert werden.
Deinen Geschmack moechte ich haben ;-)

Stil ist unbezahlbar :-)

gruß,
wahsaga

[rob]

Hi!

Wuerde er den Fehler auch bei display:none vorlesen oder nur dann, wenn er auch angezeigt wird.

Ich habe nie getestet, wie sich ein Screenreader in diesem Fall verhält.
Es gibt verschiedene Ansätze solcher Programme.
Zum einen gibt es richtige Screenreader, die praktisch echte Browser sind.
Die Dinger verstehen dann auch HTML und CSS.
Zum anderen gibt es Text2Speech-Tools, die vorlesen, was auf dem Screen ist.
Solche Programme kann man zwar auch in den Browser integrieren und sich Websites vorlesen lassen, aber die Dinger können weder HTML noch CSS.

Ein Text2Speech-Tool, das nur liest, was auf dem Screen zu sehen ist, bleibt bei deinem display:none; dementsprechend natürlich stumm.
Wie sich ein Screenreader-Browser hier allerdings verhält, weiß ich nicht genau.
Wenn du nicht möchtest, daß ein Text von einem richtigen Screenreader vorgelesen wird, dann solltest du speak:none; setzen.

Wenn du nur ein einziges Stylesheet verwendest, kannst du deinem Element neben der display-Eigenschaft auch noch die speak-Eigenschaft zuweisen.
Wenn du verschiedene Stylesheets für verschiedene Mediatypes einsetzt, solltest du wissen, daß der richtige Mediatype in CSS 2 "aural" heißt, in CSS 2.1 allerdings als "mißbilligt" eingestuft wurde und in CSS 3 dann "speech" heißen wird.

Weitere CSS-Eigenschaften für die Sprachausgabe findest du in SelfHTML.

Naja und zu deinem Konzept selbst und dem Problem mit Textbrowsern hat wahsaga dir eigentlich schon alles geschrieben, was dazu zu sagen wäre.

Schöner Gruß,
rob