HTML5.1 <label>

[marctrix]

Hej Gunnar,

@@mermshaus

Ich habe die Aussagen von Marco Zehe und Léonie Watson, die sollten es wissen (weil beide blind). Ich sehe keinen Grund, daran zu zweifeln.

In der Wikipedia würden sie jetzt sagen: [Citation needed] :)

Wir sind hier nicht in der Wikipedia. Hier gilt mein Wort. ;-)

Ernst beiseite, unzählige Artikel der beiden sind im Web verfügbar.

Darüber hinaus sind label ein absolutes Basic. Darauf zu verzichten und Screenreader dazu zu bringen, das trotzdem vorzulesen, ist als würde man von Browsern verlangen weißen Text auf weißem Grund anzuzeigen, weil doch klar ist, dass der sonst nicht zu sehen ist.

Aber vielleicht soll er ja nicht zu sehen sein. Vielleicht steckt ein Text ja absichtlich in einem p statt in einem label - es gibt wohl für Software keine Möglichkeit solche Entscheidungen zu treffen.

Was wenn zu den inputund p auch noch span oder andere Elemente hinzukommen? Was soll ein Screenreader damit machen?

Vor allem im Kontext der von mir zitierten Aussage, dass Screenreader bei Fehlen eines label-Elements oder vergleichbarer Semantik bei Texteingaben nach Text davor suchen und diesen als Bezeichnung wählen würden (siehe mein vorheriger Post in diesem Strang).

Falls Screenreader das nicht machen oder nicht auf eine Weise machen, die „benutzbar“ ist, dann sollte man definitiv darüber nachdenken, die Entwickler dieser Reader über diese Möglichkeit zu informieren.

Man kann sich durchaus auch solche Texte ausgeben lassen. Es ist aber mühsam und es macht vieles kaputt. Man muss dafür, wenn ich mich nicht irre, den Formularmodus des Screenreaders verlassen.

Sicher kann/sollte AT (assistive technology) versuchen, auch aus schlechtem Markup das beste für den Nutzer rauszuholen.

Das tun sie schon - hier gibt es aber Grenzen. Wenn sich ein Entwickler an keinen Standard hält (und label sind hier der Standard - auch wenn es ohne valide ist - hier kommt der Validator an seine Grenzen), was soll ein Screenreader dann annehmen, was er mit seinem wirren, konzeptlosen unnachvollziehbaren Gestammel gemeint haben könnte?

Wie Gunnar schon sagte: die Beschriftung mittels irgendwelchen, nicht dafür geeigneten Elementen ist nicht eindeutig zuzuordnen: nicht einmal für Menschen an einem konkreten Formular. Wie soll das dann eine Software allgemeingültig für alle Formulare lösen? Geht nicht!

Es kann ja durchaus sein, dass einer auf die lustige Idee kommt, die Beschriftung der Formularfelder hinter die Felder zu setzen. Durch Rahmen, Hintergründe, Pfeile, Linien können die Verbindungen für Sehende nachvollziehbar werden (obwohl das gegen den Grundsatz "Don#t make me think!" verstößt).

Aber Software und nicht Sehende stoßen an ihre Grenzen. Und Sehende auch, wenn in einer mobilen Darstellung alles untereinander steht und dann auch ihnen nicht mehr klar ist, auf welches Feld sich welche Beschriftung bezieht...

Das kann aber kein Grund für Entwickler sein, überhaupt erst schlechtes Markup zu coden.

Schlecht bedeutet in diesem Fall: ohne logischen Bezug. Daher: nicht automatisch (oder wie es in der WCAG heißt: durch Software) erkennbar.

“How do I convince stakeholders?”
“Don’t! Just go ahead and do it anyway!” 
—Léonie Watson

Einself!

Wozu überhaupt die korrekte Anwendung von HTML verteidigen?

Ich frage mal andersrum: warum soll man statt des Elementes, das ausdrücklich als Beschriftung für Formularfelder gedacht ist, irgendein anderes nehmen? Und wie entscheidet man dann, welches das sein soll? Würfeln?

Und wie soll ein Screenreader diesen Irrsinn wieder entwirren?

Marc