!DOCTYPE html -- was ist zu beachten?

[Marc]

Hallo @@Gunnar,

document.createElement('header');

document.createElement('footer');
document.createElement('section');
document.createElement('aside');

> >   
> > Ziemlicher Aufwand...  
>   
> Ach was. Einmal geschrieben, C&Ped.  
>   
> Allerdings gehört das noch als conditional compilation auskommentiert, damit Nicht-IEs den für sie unnützen Code nicht ausführen.  
  
Einziger Haken: Leute, die ohne JavaScript unterwegs sind.  
  

> > Aber was passiert dann mit Texten über dem Formular (Tipps zum Ausfüllen  
>   
> Wenn ein Formular Tips zum Ausfüllen nötig hat, sollte man ernsthaft überlegen, ob es richtig designt ist (Anordnung der Felder, Beschriftung der Labels, …). Der Nutzer will auf dieser Seite Eingaben tätigen, nicht ellenlange Texte lesen.  
  
Na ja, klar kann man bei Google einfach lostippen und absenden - richtig gut sind Suchen aber meist erst, wenn man vernünftig einschränken kann - und das hat kaum jemand so ganz intuitiv gelöst - ein paar Tipps und Hinweise sind fast immr sinnvoll, meist sogar nötig.  
  

> > Hinweise auf Pflichtfelder  
>   
> Diese lassen sich gut \_in\_ den Eingabefeldern unterbringen. Hier käme @placeholder ins Spiel:  
> ~~~html

<label for="name">Name</label>  

> <input id="name" name="name" placeholder="Pflichtfeld"/>

Finde ich auch problematisch - mir geht es öfters so, dass ich da (voreilig?) rein klicke und dann erst bemerke, dass ich gar nicht gelesen habe, was da stand - aber der placeholder (derzeit meist mit JavaScript realisiert) ist weg, Dann muss ich erst in ein anderes Feld klicken und hoffen, dass der Hinweis wieder erscheint.

Du siehst Hinweise sind nicht immer ein Zeichen für schlechte Nutzerführung - manchmal geht es einfach nicht ohne. Vor allem wenn Web-Neulinge ein Formular bedienen sollen.

Weißt Du intuitiv, wie Du in einem unbekannten Formular richtig trunkierst?

Weißt Du was das für Nutzer von Screenreadern bedeutet, die man per se in den Formular-Modus schickt.

Wenn ein Screenreader ein Problemmit @autofocus hat, muss dieses im Screenreader behoben werden. Die Lösung kann nicht sein, den Sehenden (der großen Mehrheit) diese äußerst nützliche Funktionalität vorzuenthalten.

Nicht mit autofocus an sich, sondern mit der Tatsache, dass der sinnvolle und gewollte "Formularmodus" einfach anders funktioniert, als der "Vorlesemodus".

Und es wäre schlecht, wenn das nicht so wäre. Gerade hier wird es auch noch eine Weile dauern, bis jeder der häufig weniger begürterten Menschen mit starken Seh-Schwierigkeiten die sehr teure neuste Version der Software
kaufen können...

Ein voll ausgestatter Blinden-Arbeitsplatz kostet schnell 10.000 EUR und mehr. Es wird niemanden wundern, dass die Kassen das nciht alle drei Jahre übernehmen.

Also selbst wenn das Problem vom Hersteller gelöst ist, steht die Lösung noch lange nicht jedem Nutzer zur Verfügung. Du weißt selber, wie selten selbst kostenlose Software mitunter aktualisiert wird (wie z. B. der IE...)

Die Idee ist ja an sich nett und Deine Vorschzläge machen durchaus Sinn. Aber noch würde ich dieses spezielle Attribut nicht verwenden.

Klar gibt es zumeist sehende Menschen, aber ich bin ein großer Freund des Solidaritäts-Prinzips und nicht behinderte Menschen haben von den großen Fortschritten und der zunehmenden Verbreitung barriefreier Seiten sehr profitiert. Die meisten "Features" zugänglicher Webseiten sind vor alle Nutzer ein Vorteil. Viele Seiten im Web sind heute viel besser nutzbar, als vor zehn Jahren. Da kann man auch mal von einem Sehenden Zugeständnisse erwarten - zumal wenn die sich darin erschöpfen, einmal "unnötig" zu klicken.

Meine 2 Cent...

Viele Grüße,
Marc.