Ein Sprunglink, der den Fokus nicht mitnimmt, sieht im Quelltext
korrekt aus und ist in der Benutzung wertlos. Der Test betätigt ihn
deshalb wirklich und misst, wo der nächste Tab landet.
Beim Nachmessen auf der Live-Seite fiel auf: Der Fokus liegt sofort
nach dem Sprung korrekt auf <main>, wandert rund 300 ms später aber
auf <body>. Drei Hypothesen einzeln geprüft und alle widerlegt --
sanftes Scrollen (aus: unverändert), Animationen (aus: unverändert),
Fensterfokus im Testbrowser (document.hasFocus() bleibt true). Ein
Abfangen sämtlicher focus()- und blur()-Aufrufe ergab keinen einzigen
Aufruf aus dem Seitencode. Es ist browserinternes Verhalten und
folgenlos: die Sprungmarke für die Tab-Reihenfolge bleibt gesetzt,
nachgewiesen auf allen fünf Seiten.
Zählung korrigiert: Die erste Fassung suchte nur Links und Knöpfe und
meldete auf Formularseiten "Nr. 0 von 67, -1 Punkte gespart", weil das
Ziel dort ein Eingabefeld ist. Jetzt dieselbe Liste wie beim Zählen,
und unsichtbare Elemente fliegen raus.
25 von 25 bestanden.
Co-Authored-By: Claude Opus 5 <[email protected]>
Der Tastatur-Test (pruef-tastatur.mjs, neu) zeigte auf allen fünf
geprüften Seiten dasselbe Bild: jedes Bedienelement erreichbar, Fokus
durchgehend sichtbar, keine Tastaturfalle -- aber kein Sprunglink.
Ohne ihn muss sich jemand, der die Tastatur benutzt, auf JEDER Seite
erneut durch das komplette Menü tabben (31 bis 52 Punkte), bevor der
eigentliche Inhalt beginnt. WCAG 2.4.1 verlangt genau diesen Ausweg.
An einer Stelle gelöst statt in 35 Dateien: renderHeader() in main.js
setzt das Sprungziel und stellt den Link davor.
Das tabindex="-1" am <main> ist der Teil, der meistens fehlt: ohne ihn
verschiebt der Sprung in Chrome und Safari nur die Bildlaufleiste, der
Tastaturfokus bleibt in der Navigation -- der nächste Tab landet wieder
im Menü und der Sprung war wirkungslos.
Cache-Buster auf 20260827a (244 Stellen), sonst bekäme niemand die
geänderte main.js und main.css ausgeliefert.
Co-Authored-By: Claude Opus 5 <[email protected]>