Wiki-Eintrag zur Barrierefreiheit
marctrix
- barrierefreiheit
- selfhtml-wiki
Hej alle,
habe mal den Wiki-Eintrag zur Barrierefreiheit verausführlicht. Werde auch in Zukunft, wenn mir was auffällt und ich Zeit habe gerne zu diversen Themen schreiben.
Ich hoffe es gefäll. Wenn nicht, freue ich mich auf Verbesserungsvorschläge und konstruktive Diskussionenn hier und werde die Ergebnisse, zu denen Konsens erzielt wurde, natürlich einarbeiten.
Marc
Aloha ;)
Vielen Dank für diesen qualitativ hochwertigen Beitrag!
Ich hoffe es gefäll. Wenn nicht, freue ich mich auf Verbesserungsvorschläge und konstruktive Diskussionenn hier und werde die Ergebnisse, zu denen Konsens erzielt wurde, natürlich einarbeiten.
Mir sind beim Lesen folgende (sprachlich-formulatoriererische) Kleinigkeiten aufgefallen:
Inhaltlich ist das Ganze meines Erachtens nach sehr gut gelungen.
Grüße,
RIDER
Hallo
Mir sind beim Lesen folgende (sprachlich-formulatoriererische) Kleinigkeiten aufgefallen:
- … Besser vielleicht: "Formularfelder sollten ein label-Element mit einem for-Attributwert aufweisen, der identisch zum id-Attributwert des Formularfelds ist."
MMn noch besser: … id-Attributwert des zugehörigen Formularfelds …
- darunter: "Bei Verwendung von Tastatur-Shortcuts sollte man [...] die unterschiedlichen Implementationen [...]" - heißt es nicht "Implementierung(en)"?
Ich habe zwar schon beide Versionen gehört und gelesen, die „Implementierungen“ erscheinen mir aber mindestens gängiger.
Tschö, Auge
Hej Auge,
Mir sind beim Lesen folgende (sprachlich-formulatoriererische) Kleinigkeiten aufgefallen:
- … Besser vielleicht: "Formularfelder sollten ein label-Element mit einem for-Attributwert aufweisen, der identisch zum id-Attributwert des Formularfelds ist."
MMn noch besser: … id-Attributwert des zugehörigen Formularfelds …
Habe es wie folgt formuliert:
Die Beschriftungen von Formularfelder sollten mit den Formularfeldern mittels label-Element logisch verknüpft werden
Alles weitere dann bei der Beschreibung des laben-Elementes im Wiki. Dabei ist mir aufgefallen, dass das alt-Attribut auch mitgegeben wird, wenn die Input-Elemente im label liegen - ist das nicht überflüssig?
- darunter: "Bei Verwendung von Tastatur-Shortcuts sollte man [...] die unterschiedlichen Implementationen [...]" - heißt es nicht "Implementierung(en)"?
Ich habe zwar schon beide Versionen gehört und gelesen, die „Implementierungen“ erscheinen mir aber mindestens gängiger.
Da Tastatur-Shortcuts ohnehin mindestens umstritten sind, würde ich den ganzen Abschnitt gerne streichen.
Ansonsten war ich noch mal dran, habe zu den Gesetzen etwas zur EU ergänzt und auch sonst weitere überholte Dinge umformuliert, entfernt und durch neuere und aktuellere Infos ergänzt...
Marc
Aloha ;)
Alles weitere dann bei der Beschreibung des laben-Elementes im Wiki. Dabei ist mir aufgefallen, dass das alt-Attribut auch mitgegeben wird, wenn die Input-Elemente im label liegen - ist das nicht überflüssig?
Du meinst for statt alt, oder? Und ja, das Beispiel macht keinen rechten Sinn. Wenn-dann sollte es die unterschiedlichen Möglichkeiten veranschaulichen; so wie es jetzt ist ist es tatsächlich überflüssig und verfehlt den eigentlichen Sinn des for-Attributs (denn wenn man schon das input ins label macht könnte man sich for genauso sparen)...
Ich werde mich dessen mal annehmen... Mal schauen was dabei rauskommt.
Grüße,
RIDER
Hej Camping_RIDER,
Alles weitere dann bei der Beschreibung des laben-Elementes im Wiki. Dabei ist mir aufgefallen, dass das alt-Attribut auch mitgegeben wird, wenn die Input-Elemente im label liegen - ist das nicht überflüssig?
Du meinst for statt alt, oder?
Jo.
Und ja, das Beispiel macht keinen rechten Sinn. Wenn-dann sollte es die unterschiedlichen Möglichkeiten veranschaulichen; so wie es jetzt ist ist es tatsächlich überflüssig und verfehlt den eigentlichen Sinn des for-Attributs (denn wenn man schon das input ins label macht könnte man sich for genauso sparen)...
Normalerweise weiß ich das, aber wenn mein Wissen im Gegensatz zum SelfHTML-Wiki steht, werde ich unsicher... :-}
Man kann ja nicht alles im Kopf haben!
Ich werde mich dessen mal annehmen... Mal schauen was dabei rauskommt.
Cool!
Marc
Aloha ;)
Ich werde mich dessen mal annehmen... Mal schauen was dabei rauskommt.
Cool!
Hoffentlich zur allgemeinen Zufriedenheit und vor allem auch zur Zufriedenheit von @Matthias Scharwies...
Grüße,
RIDER
Hallo Camping_RIDER,
Hoffentlich zur allgemeinen Zufriedenheit und vor allem auch zur Zufriedenheit von @Matthias
Sind denn die beschriebenen Probleme perdu?
Bis demnächst
Matthias
Hej Matthias,
Hoffentlich zur allgemeinen Zufriedenheit und vor allem auch zur Zufriedenheit von @Matthias
Sind denn die beschriebenen Probleme perdu?
Da bin ich mir nicht sicher, aber angesichts der Tatsache, dass ein Blinden-Arbeitsplatz sehr teuer ist und die Kosten dafür von der Krankenkasse nur alle paar Jahre übernommen wird, halten sich alte Screenreader-Browser-Kombinationen ungewöhnlich lange. Die Aussage aus dem Artikel von 2013 könnte also noch aktuell sein...
Andererseits ist unter Blinden das vergleichsweise günstige iPhone sehr beliebt. Da sollte das kein Problem sein.
Hat jemand Lust das zu testen?
Marc
Hallo marctrix,
Da bin ich mir nicht sicher, aber angesichts der Tatsache, dass ein Blinden-Arbeitsplatz sehr teuer ist und die Kosten dafür von der Krankenkasse nur alle paar Jahre übernommen wird, halten sich alte Screenreader-Browser-Kombinationen ungewöhnlich lange. Die Aussage aus dem Artikel von 2013 könnte also noch aktuell sein...
Zumal ein zusätzliches (vielleicht nicht notwendiges) for-Attribut ja den Quelltext nun wirklich nicht aufbläht.
Bis demnächst
Matthias
Aloha ;)
Da bin ich mir nicht sicher, aber angesichts der Tatsache, dass ein Blinden-Arbeitsplatz sehr teuer ist und die Kosten dafür von der Krankenkasse nur alle paar Jahre übernommen wird, halten sich alte Screenreader-Browser-Kombinationen ungewöhnlich lange. Die Aussage aus dem Artikel von 2013 könnte also noch aktuell sein...
Zumal ein zusätzliches (vielleicht nicht notwendiges) for-Attribut ja den Quelltext nun wirklich nicht aufbläht.
Es schadet nicht, dazu zu raten, das for-Attribut immer zu setzen (selbst wenn es vielleicht durch Schachtelung nicht direkt notwendig ist). Ob die beschriebenen Probleme erledigt sind kann ich nicht beurteilen - ich habe ja absichtlich alle drei möglichen Wege im Beispiel belassen.
Mir ging es vor allem darum, dass auch andere mögliche Wege gezeigt werden; immerhin ist es ja unser vordergründiger Auftrag, zu zeigen, was der Spec nach möglich ist. Deshalb fand ich es doof, dass das Beispiel nur eine von drei möglichen Arten, label sinnvoll zu verwenden, zeigt. Wenn die eine davon gegenüber den Anderen Vorteile hat (z.B. legacy-Screenreader-Support o.ä.), sollte das (mit Begründung) in einem Empfehlungs-Kasten erwähnt werden. Nur die (aktuell (!) - oder auch nicht aktuell) empfehlenswerteste Möglichkeit im Beispiel zu zeigen und auf die Anderen nur im Nebensatz zu verweisen fand ich irgendwie doof.
Vor allem die alleinige Verwendung des for-Elements ohne Verschachtelung (Beispiel Teil 3) hat mir definitiv im Beispiel gefehlt, weil die in der Praxis (zumindest in dem, was mir so über den Weg läuft) doch häufig vorkommt oder sinnvoll angewandt werden kann.
Grüße,
RIDER
Hej Camping_RIDER,
Aloha ;)
Ich werde mich dessen mal annehmen... Mal schauen was dabei rauskommt.
Cool!
Hoffentlich zur allgemeinen Zufriedenheit und vor allem auch zur Zufriedenheit von @Matthias Scharwies...
Schön!
Zwei Kleinigkeiten:
1.) ...damit Screenreader die in label vorhandenen Informationen weitergeben können.
Ich störe mich ein wenig, daran dass (auch in anderen Artikeln) die Screenreader so herausgestellt werden. Barrierefreiheit besteht ja nicht in erster Linie darin Webseiten Blinden zugänglich zu machen. Die Unterstützung von Blinden ist dabei noch am einfachsten, weil abgesehen von diesen Zuordnungen wie hier beschrieben nur auf zwei Dinge geachtet werden muss: sinnvolle Reihenfolge des Quelltextes und für jedes nicht-Text-Element eine textliche Entsprechung bereit zu stellen. Außerdem (um es mal so hart zu sagen) sind Blinde eine zahlenmäßig viel kleinere Gruppe als zum Beispiel Fehlsichtige.
Daher macht es Sinn, sich auch mit Fehlsichtigen auseinanderzusetzen. Für die ist es zum Beispiel sehr hilfreich, wenn Beschriftungen OPTISCH einem Input zuordenbar sind, das heißt links über dem Input-Feld stehen.
Wenn man die so beliebte zweispaltige Darstellung nimmt, ist der Zusammenhang zwischen Beschriftung und Feld oft nur noch schwer oder gar nicht erkennbar, wenn man auf extreme Zoomraten bei der Bildschirmlupe angewiesen ist oder einen Tunnelblick hat.
Man sieht dann nur noch einen kleinen Ausschnitt, also oft entweder den mit der Beschriftung oder den mit den Eingabe-Feldern.
Ein positiv-Beispiel ist das Kontakt-Formular auf MuD-Tierschutz
Hier sieht man auch noch bei extremen Vergrößerungen, welche Beschriftung zu welchem Eingabefeld gehört - label sind natürlich zusätzlich vergeben, fieldset und legend auch! ;-)
bei Checkboxen und Radio-Buttons die anklickbare Fläche vergößert wird, da auch auf das Label geklickt werden kann.
Marc
Aloha ;)
- darunter: "Bei Verwendung von Tastatur-Shortcuts sollte man [...] die unterschiedlichen Implementationen [...]" - heißt es nicht "Implementierung(en)"?
Ich habe zwar schon beide Versionen gehört und gelesen, die „Implementierungen“ erscheinen mir aber mindestens gängiger.
Da Tastatur-Shortcuts ohnehin mindestens umstritten sind, würde ich den ganzen Abschnitt gerne streichen.
Hm, besser als Streichen fände ich, die Erwähnung zu belassen aber noch deutlicher von der Verwendung abzuraten - einfach, damit wir nochmal ausdrücklich gesagt haben, dass Tastatur-Shortcuts barrierefreiheitsmäßig (und auch ansonsten) doof sind - sonst ist die Schlussfolgerung bei Manchen vielleicht "steht nix da also wird es schon okay sein".
Grüße,
RIDER
Hej Camping_RIDER,
- darunter: "Bei Verwendung von Tastatur-Shortcuts sollte man [...] die unterschiedlichen Implementationen [...]" - heißt es nicht "Implementierung(en)"?
Ich habe zwar schon beide Versionen gehört und gelesen, die „Implementierungen“ erscheinen mir aber mindestens gängiger.
Da Tastatur-Shortcuts ohnehin mindestens umstritten sind, würde ich den ganzen Abschnitt gerne streichen.
Hm, besser als Streichen fände ich, die Erwähnung zu belassen aber noch deutlicher von der Verwendung abzuraten - einfach, damit wir nochmal ausdrücklich gesagt haben, dass Tastatur-Shortcuts barrierefreiheitsmäßig (und auch ansonsten) doof sind - sonst ist die Schlussfolgerung bei Manchen vielleicht "steht nix da also wird es schon okay sein".
Habe es mal so gemacht, allerdings gewinnt der Abschnitt dadurch eine Länge (und damit eine Gewichtung), die diesen Aspekt in meinen Augen überbetont. Mir fällt aber auch nicht viel anderes dazu ein.
Man kann natürlich alles ausführlicher machen, aber das gibt es ja schon sehr ausführlich und sehr gut auf einfach-fuer-alle, barrierefreies-webdesign usw...
Marc
Hej Camping_RIDER,
Vielen Dank für diesen qualitativ hochwertigen Beitrag!
Inhaltlich ist das Ganze meines Erachtens nach sehr gut gelungen.
Danke für die Blumen, aber das meiste ist nicht von mir ;-)
Offenbar hat mein Beitrag dem Text aber nicht geschadet - schon mal gut zu hören!
Marc