danke für die Erklärung. Ohne online-Demo wäre deine Lösung für mich weniger überzeugend gewesen.

Das stimmt. Meine private Webseite betrachte allerdings ich auch nicht als Referenzimplementation aller meiner Entwicklungen. Meine Homepage erhält dann ein YAML-Update, wenn ich Zeit dafür finde. Ich hoffe inständig, dass diese Einstellung bei meinen Lesern keinen negativen Einfluss auf die Qualität des hier vorgestellten Skriptes hat.

Wie Du im Beitrag lesen kannst, ist die hier vorgestellte Lösung seit einiger Zeit bereits in YAML und allen mitgelieferten Beispielen integriert. Wieso schaust Du also nicht einfach mal auf der YAML-Homepage vorbei und überzeugst Dich anhand der zahlreichen Layoutbeispiele von deren Funktion?

Gruß
Dirk

auf dieser Seite hier scheinst du die beschriebenen Lösung nicht einzusetzen? Zumindest zeigen meine aktuellen WebKit Browser unter Win das falsche Verhalten.

deine Lösung basiert auf fest im Markup verankerten Inline-Events (“onclick”). Sowas würde ich heutzutage niemandem mehr empfehlen.

Der Vorteil der hier vorstellten Lösung ist, dass der Anwender keinen zusätzlichen Markup schreiben muss und zudem nicht nur Webkit-Browser sondern auch der IE8 unterstützt wird. Der Vorschlag von @molily macht die Lösung noch einfacher und robuster.

an der JavaScript Lösung für die WebKit basierten Browser habe ich mich vor einiger Zeit auch versucht.
HIer meine Lösung

[...]  Sollen Skiplinks auch im Safari und Chrome wie vorgesehen funktionieren, lässt sich der Einsatz von Javascript nicht vermeiden. Dirk Jesse stellt aus meiner Sicht die bisher flexibelste Lösung zur Diskussion [...]

Nachtrag Ich habe Deinen Code getestet: Im IE8/Win7 scheint es Probleme zu geben, der Focus wird zwar im IE7-Modus, aber nicht mehr im Standardmodus gesetzt. Mein Ansatz funktioniert auch im IE7 und im Standardmodus des IE8. Im IE7-Modus reagieren beide Lösungen gleich.

Lass uns mal skypen oder telefonieren.

Dirk

Dumme Frage: Kann man das JavaScript nicht noch weiter vereinfachen? Ist z.B. die Browserabfrage überhaupt nötig? Hätte es Nachteile, wenn man einfach allen Browsern diesen Fix spendieren würde?

Gute Frage: Firefox braucht diesen Fix zumindest nicht. Ältere IE’s auch nur, wenn hasLayout nicht da ist (was zumindest bei YAML überwiegend gesichert ist). Ich wollte lediglich unnötige Codeausführungen vermeiden.

Und Nachteile? Vermutlich nicht, so wie Deine Änderungen aussehen :-). Zwar könnte man mit der Browserabfrage die Ausführung im FF stoppen, das Laden kann man aber eh nicht unterbinden. In jedem Fall Danke für die Codeüberarbeitungen, die übernehme ich gern.

Anstatt eines umständlichen Selektor-Ansatzes würde ich eher Event-Delegation verwenden. Also zentral bei document.body auf click-Events hören und bei Klicks auf Skiplinks den Fix anwenden.

Außerdem funktionieren getAttribute(‘class’) und setAttribute(‘onclick’, ‘..’) m.W. nur im IE8 und nur im standardkonformen Modus. Für alle müsste es .className bzw. .onclick = function () {..} heißen. Mit dieser Closure spart man sich auch den doppelten getElementById-Aufruf und man spart sich, dass zur Laufzeit nochmal Code geparst wird (das ist quasi ein eval()).

Die Webkit-Engine unter Windows muss erst richtig MSAA lernen.

Oder gleich UI Automation. Wäre mal interessant zu erfahren, ob da nicht doch wieder wie so oft irgendwas in der alten Schnittstelle hängenbleibt (soll bei MSAA ja des öfteren vorkommen).

In der Regel ist es doch so, dass nach H1 und Skiplink zunächst die Navigation kommt, dann der Inhalt, dann die Randbemerkungen (oder was auch immer in dem Container rechts steht), dann der Footer. Der Inhalt folgt also i.d.R. im Quelltext nach der Navigation. ...

Es gibt keine Vorschrift oder Regel nach welcher die Reihenfolge von Inhalten im Quelltext festgelegt ist. Die einzelnen Elemente können sonstwo im Quelltext stehen - für die Anordnung am Bildschirm ist CSS zuständig.

... der Skiplink ist ja nur deswegen nötig, weil aufgrund von Schwächen im CSS der Navigationscontainer vor dem Inhalt stehen muss. Wäre das nicht nötig, könnte man sich den Skiplink sparen.

Nochmal Nein: Es gibt keine solche CSS-Schwäche. Selbstverständlich kann man per CSS auch eine Navigation vom Ende des Quelltextes auf der Webseite nach oben holen. Zudem definieren sich Skiplinks nicht exklusiv darüber, Navigationselemente zu überspringen.

Und nein, ich denke nach wie vor, dass ein einzige Skiplink sinnvoller ist. In der Regel ist es doch so, dass nach H1 und Skiplink zunächst die Navigation kommt, dann der Inhalt, dann die Randbemerkungen (oder was auch immer in dem Container rechts steht), dann der Footer. Der Inhalt folgt also i.d.R. im Quelltext nach der Navigation. zur Navigation muss man also nicht per Skiplink springen, sondern kann ganz normal voranschreiten.

Übrigens, wenn die Seite eingeleitet wird von H1, H2, H3 u.s.w., also von Titel und Untertiteln, dann folgt der Skiplink logischerweise nach den Untertiteln. Abr es bleibt das erste fokussierbare Element.

Und noch ein Gedanke am Rand. der Skiplink ist ja nur deswegen nötig, weil aufgrund von Schwächen im CSS der Navigationscontainer vor dem Inhalt stehen muss. Wäre das nicht nötig, könnte man sich den Skiplink sparen. Vielleicht gibt es für XHTML eine solche Möglichkeit. Man könnte den Quelltext so abfassen, wie es für eine audible Version notwendig wäre, und könnte das vor der visuellen Darstellung zunächst durch XSL umsortieren lassen, dann per CSS visuell aufbereiten. Dann könnte man sich den Skiplink sparen. Geht aber natürlich nur mit XHTML.

Es ist durchaus üblich, mehr als nur einen einzigen Skiplink zu setzen, im Beitrag wurden auch ensprechende Beispiele genannt. Insofern ist die Mehrzahl auch richtig gewählt.

Was die Position betrifft, schreibe ich bewusst “das erste focussierbare Element”. Ich bin mir nicht sicher, was Du mit “Titel” meinst? Das <title> Element steht im <head> der Seite und sollte bereits grundlegende Informationen zur Seite enthalten. Die Skiplinks hingegen stehen im <body> und damit grundsätzlich dahinter. Oder was meinst Du?

1. Meinre Ansicht nach gibt es (auf einer Seite) nicht die Skiplinks, sondern den Skiplink (Singular). Ansonsten wird der Sinn des Skiplinks ausgehebelt. Der Sinn ist ja, ellenlange Navigationslisten schnell überspringen zu können, um direkt zum Inhalt zu gelangen. Wenn nun der Skiplink auch wieder eine ellenlange Liste von Skiplinks ist, muss man dann nicht einen Skiplink Skiplink einbauen?

2. Der erste fokussierbare Element heisst nicht, das erste Element überhaupt. Ich habe eine Weile hin und her überlegt, und bin zu dem Schluss gekommen, dass der Skiplink am Besten direkt nach dem Seitentitel plaziert wird. Man könnte das auch umgekehrt machen, aber ich finde, der Titel ist wesentlicher Bestandteil des Inhalts. Daher halte ich eine Positionierung nach dem Titel für sinnvoller.