Nach dem Oeffnen der Schublade lag ein blauer Rahmen um "Dashboard", nach dem
Schliessen um den Hamburger — bis man woanders hinklickte. Der Ring hat einen
praktischen Grund, aber nur fuer die Tastatur: Er zeigt, wo man gerade steht.
Nach einem Mausklick weiss man das ohnehin.
Ursache war unser eigener Fokus-Sprung, nicht die CSS-Regel. Die benutzt
laengst :focus-visible. Setzt aber ein Skript den Fokus — Fokusfalle beim
Oeffnen, Rueckgabe an den Ausloeser beim Schliessen —, wertet Chrome das wie
Tastaturbedienung und zeigt den Ring trotzdem.
Drei Aenderungen:
- Beim Oeffnen bekommt der Dialograhmen den Fokus statt des ersten Links. Das
ist ohnehin das uebliche Vorgehen fuer einen Dialog; die Sprachausgabe liest
den Dialog an, der erste Tabulatorschritt landet auf dem ersten Link.
- Elemente mit tabindex="-1" bekommen keinen Ring mehr. Sie sind aus der
Tabulatorreihenfolge heraus und werden nur per Skript fokussiert — ein Ring
um den ganzen Schubladenrahmen waere dort Laerm.
- AppShell schreibt die zuletzt benutzte Eingabeart als data-eingabe an das
Wurzelelement. Solange sie "zeiger" ist, entfaellt der Ring an Knoepfen und
Links. Eingabefelder sind ausgenommen, dort gehoert er zum Zustand "hier
wird gerade geschrieben". Der erste Tastendruck schaltet ihn ueberall zurueck.
Dabei ist eine Luecke in der Fokusfalle aufgefallen und behoben: Mit dem Fokus
auf dem Rahmen lief Umschalt+Tab aus dem Dialog heraus, weil die Falle nur den
ersten Link als Umkehrpunkt kannte. Der Rahmen steht im Dokument vor seinen
Kindern und gehoert dazu — sonst waere die Zusage von aria-modal gebrochen.
Nachgemessen statt begutachtet, alle Faelle:
Maus offen → Rahmen, kein Ring
Maus zu → Hamburger, kein Ring
Tastatur offen → Rahmen, kein Ring
Tastatur erstes → "Dashboard", RING
Tastatur rueckwaerts → "Komponenten", RING (Falle haelt)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
dejanandClaude Opus 5
7bbbd00ed2