WAI Guidelines - und in der Praxis?
0 
Dennis
0 0
WAI Guidelines - und in der Praxis?
Hallo zusammen,
ich habe mir eben mal die W3C Web Content Accessibility Guidelines (sowie weitere Dokumente zu dem Thema) angeschaut.
Einige Sachen sind ja wirklich sinnvoll (unbestritten), andere Empfehlungen habe ich noch nie (selten) bei html-Dokumenten angewandt gesehen (codiere HTML seit 10 Jahren), wie z.B.:
* axis- und scope-Attribute für Tabellen
* colgroup bei Tabellen (sehr sehr selten)
* logische Beschreibung mit samp, abbr und acronym
* for-Attribut für Label zu Controls
* acccesskey-Attribut (sehr sehr selten)
* OPTGROUP bei select-elementen
* Fieldset und legend für Formulargruppierung
(Vielleicht liegt es ja daran dass ich so schlecht codiere und immer die falschen Seiten besuche...)
Teilweise erscheinen mir einige Sachen auch zu abgehoben von der Wirklichkeit.
Ich mache mir z.B. momentan mehr Sorgen darum, wie ich ein Formular für Menschen mit Behinderung (v.a. motorischen Schwächen) ordentlich hinkriege. Gerade bei Formularelementen gibt einem CSS (so wie es crossplattform möglich ist) imho noch sehr wenige Möglichkeiten an die Hand, ein Formular benutzerfreundlich zu gestalten. (Einsatz von for-Attribut und acccesskey-Attribut wären hier durchaus sinnvoll!)
Wie sind Eure Erfahrungen damit? Hat jemand Tipps aus der Praxis zu barrierefreien Formularen?
Gruß,
LeKuchen
-
Hi LeKuchen,
* logische Beschreibung mit samp, abbr und acronym
Das habe ich allerdings bereits oft gesehen.
* for-Attribut für Label zu Controls
Das sollte man IHMO schon in jedem Formular für die Bechriftung von Radiobuttons oder Checkboxen nehmen, da sich dann in den meisten Browsern auch auf den Text klicken lässt - mit der gleichen Wirkung wie auf das Element.
* Fieldset und legend für Formulargruppierung
Die Nutzung hiervon mag Sinn machen, wenn z.B. mehrere Einstellmöglichkeiten zu einer Sache bestehen, manchmal nutze ich es auch.
Wie sind Eure Erfahrungen damit? Hat jemand Tipps aus der Praxis zu barrierefreien Formularen?
Bzgl. der Formulare s.o.
MfG, Dennis.
--
Mein SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) rl:( n4:# ss:) de:] js:| ch:{ sh:( mo:} zu:|
Antworten per E-Mail gibts hier nicht! -
hi,
ich habe mir eben mal die W3C Web Content Accessibility Guidelines (sowie weitere Dokumente zu dem Thema) angeschaut.
Einige Sachen sind ja wirklich sinnvoll (unbestritten), andere Empfehlungen habe ich noch nie (selten) bei html-Dokumenten angewandt gesehen (codiere HTML seit 10 Jahren), wie z.B.:
* axis- und scope-Attribute für Tabellen
* colgroup bei Tabellen (sehr sehr selten)nach zehn jahren "HTML codierung" hast du es dir ja inzwischen sicher abgewöhnt, tabellen zum layouten zu missbrauchen ;-) - und dann reduziert sich ihr einsatz ggf. schon auf sehr seltene fälle.
* logische Beschreibung mit samp, abbr und acronym
wird vielfach genutzt.
beispielsweise unter den bloggern gilt die verwendung von acronym bzw. abbr in verbindung mit einer erklärung im title sogar regelrecht als schick ...* for-Attribut für Label zu Controls
sollte eine selbstverständlichkeit sein; insbesondere (aber nicht nur) bei checkboxen und radiobuttons, damit man diese auch durch klicken auf den text ankreuzen kann.
* acccesskey-Attribut (sehr sehr selten)
ist auch eher umstritten, weil man dabei zu oft den tastaturcodes der verschiedenen browser in die quere kommt; siehe auch http://www.einfach-fuer-alle.de/artikel/formulare/tag4/
* OPTGROUP bei select-elementen
derzeit noch weitgehend witzlos, da von den browsern nicht wie vorgesehen unterstützt.
* Fieldset und legend für Formulargruppierung
können wesentlich zur guten gliederung umfangreicherer formulare beitragen; insb. auch wenn die optik nicht so dargestellt werden kann, wie vom ersteller per CSS _empfohlen_.
Ich mache mir z.B. momentan mehr Sorgen darum, wie ich ein Formular für Menschen mit Behinderung (v.a. motorischen Schwächen) ordentlich hinkriege. Gerade bei Formularelementen gibt einem CSS (so wie es crossplattform möglich ist) imho noch sehr wenige Möglichkeiten an die Hand, ein Formular benutzerfreundlich zu gestalten. (Einsatz von for-Attribut und acccesskey-Attribut wären hier durchaus sinnvoll!)
zu dem thema würde ich auch auf den rest von dem, was einfach-fuer-alle.de zum thema formulargestaltung hat, mal einen intensiveren blick empfehlen.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hallo wahsaga,
nach zehn jahren "HTML codierung" hast du es dir ja inzwischen sicher abgewöhnt, tabellen zum layouten zu missbrauchen ;-)
Jep, habe ich mir im Laufe der Jahre abgewöhnt...;o) Wenn man ordentlich mit (X)HTML und CSS codiert, ist die Umstellung auf barrierefreies Coding scheinbar nicht mehr so weit.
zu dem thema würde ich auch auf den rest von dem, was einfach-fuer-alle.de
Ich werde mal einen Blick reinwerfen - Danke!
Gruß,
LeKuchen
-
-
Hi,
ich schließe mich Deiner Meinung an.
Meine Erfahrung:
- Wenn man alles per Hand selbst codet, dann kann man sich an die Empfehlungen meist ohne große Probleme halten, weil volle Kontrolle.
- Nutzt man dagegen ein CMS, sieht die Sache schon anders aus. Wirklich barrierefreie Seiten sind in der Praxis dann oft kaum möglich, entweder weil das CMS und deren Plugins dies nicht unterstützen oder weil eine Anpassung auf diese jew. Standards das Budget des Kunden sprengen... Pflegt der Kunde die Inhalte einer umfangreichen Webseite per CMS selbst, dann hat man wenig oder keinen Einfluß mehr auf eine Umsetzung gemäß Empfehlungen... Da hilft in der Praxsis dann nur noch eine aufwändige Umkonfiguration/Anpassung des CMS mit starker Einschränkung der Nutzerrechte/Möglichkeiten des internen WYSIWYG-Editors ;)
MfG
Danny