Mir ist noch nie untergekommen (und das habe ich gerade mit allen mir zur Verfügung stehenden Browsern getestet), dass ein Browser (ohne eine explizite Anweisung im Markup) den ersten Radiobutton einer Liste vorausgewählt hat.

Das Problem ist ein anderes: Klickt der Nutzer versehentlich einen Punkt an, gelangt er nie wieder in den Status "keine Auswahl", die aber im Interface (ohne Vorselektierung) erstmal "gefühlt" möglich ist. Was dann die Validierung sagt, steht dann auf einem anderen Blatt.

Kleine Anmerkung zu Selectboxens:
Die angesprochenen mehrzeiligen Auswahllisten sind nicht zwingend Mehrfachoptionen, obgleich diese üblicherweise so dargestellt werden. Auch Einfachauswahlen erlauben mehrzeilige Anzeigestile.

Ansonsten: Netter Text. Nichts wirklich neues, aber eine schöne Zusammenstellung!

Wichtig ist auch, bereits besuchte und gerade aktive Links von unbesuchten Links visuell zu unterscheiden

würde ich das ganze auf die Content Links reduzieren. In der Navigation wirkt das meist eher unruhig als hilfreich.

Dann lag ich mit meiner Vermutung richtig Danke dir für die Erklärung. Bei uns in der Agentur wäre der Scrollbalken in dem Fallbeispiel YAML z.B. nicht gerne gesehen und da ist es sehr hilfreich ihn ausknipsen zu können.

lg
Jared

Gerade mit Dirk Jesse habe ich im Vorfeld über den Artikel gesprochen, und er nannte mir einige überzeugende Beispiele für Anwendungsfälle, bei denen es tatsächlich besser ist, einen deaktivierten Scrollbalken einzublenden. Ebensoviele gibt es aber für die gegenteilige Vorgehensweise.

Bei YAML ist es also weder falsch, noch richtig – Dirk hat sich einfach für eine Variante entschieden, die ja vom YAML-Benutzer problemlos geändert werden kann.

Aber eine Sache ist mir aufgefallen:

Scrollbalken sollten nur dann angezeigt werden, wenn Scrollen tatsächlich notwendig ist.

Ich kann mich dran erinnern das YAML bei einem bestimmten Zustand (ich glaube, wenn die Höhe des Viewports auf 100% eingestellt wird) immer einen Scrollbalken anzeigte. Ganz sicher bin ich mir nicht.

Dies wäre laut dem Artikel ja dann nicht korrekt?!

Und so wird dann bei Webautoren aus einem "sollte man eigentlich so machen" (was "muss es aber nicht" implizieren sollte) mal ganz schnell ein "muss immer und überall so sein".

HTML 4 ist so dermaßen unterspezifiziert, dass es schon fast an ein Wunder grenzt, dass es überhaupt Implementierungen davon gibt.

Ist für keines der INPUT-Elemente einer Gruppe mit Radio-Button das Attribut CHECKED gesetzt, dann muss das Benutzerprogramm den ersten Radio-Button der Gruppe zu Beginn auswählen.

Diese Spezifikation (HTML 2.0) ist aus dem Jahr 1995 und noch ziemlich naiv, was den Umgang mit Formularfeldern angeht. Aktuell bestimmen Radiobuttons Zustimmung zu Newsletter-Anmeldungen, Akzeptanz von Lizenzvereinbarungen, etc. – hier ist keinerlei Vorauswahl möglich, der Benutzer muss nach geltendem Recht eine eigene, aktive Entscheidung treffen.

Weil sich die Vorgehensweise der Benutzerprogramme voneinander unterscheidet, sollten Autoren sicherstellen, dass in jeder Gruppe mit Radiobuttons einer zu Beginn eingeschaltet ist.

Derzeit gibt es, auch laut der von Dir zitierten HTML 4.01-Spezifikation, keinen Zwang, in einer Liste von Radiobuttons eine Option vorauszuwählen, auch das W3C bedient sich hier der abgeschwächten Form „Autoren sollten sicherstellen“. Mir ist noch nie untergekommen (und das habe ich gerade mit allen mir zur Verfügung stehenden Browsern getestet), dass ein Browser (ohne eine explizite Anweisung im Markup) den ersten Radiobutton einer Liste vorausgewählt hat.

Außerdem sollte man bei Radiobuttons eine Vorbelegung erwägen

Man sollte das IMHO nicht nur erwägen, sondern immer tun. Ansonsten droht undefiniertes Verhalten, eventuell wird der erste Radiobutton (vom Webseitenautor ungewollt) als ausgewählt ausgewertet. Siehe HTML-Spec Kapitel 17.2.1.

Sollen Nutzer nicht durch eine Vorbelegung zu einer bestimmten Auswahloption geleitet werden (wichtig bei Fragebögen), kann ein zusätzlicher Radiobutton „keine Antwort“ vorgesehen werden, der vorausgewählt wird und mit CSS versteckt wird. Siehe Posting im SELFHTML-Forum.