UI tastaturproblem

[beatovich]

hallo

Hej beatovich,

Aktuelles Verhalten eines Editors

1. Mit Taste [Tab] verlässt man das Funktionsmenu und wechselt zu einem Button "neuen UI-Tab erstellen".
2. Mit Taste [Tab] betritt man eine Liste von Labeln zu UI-Tabs. (Liste kann beliebig lang werden)

Sollte sie aber nicht. Sonst wissen viele Menschen am Ende nicht mehr, worum es in der Liste ging. Aber gut, das hat dann derjenige in der Hand, der die Liste erstellt.

Ich als Mausbenutzer vergesse auch oft, dass für die Bedienung von Radio-Gruppen / Checkboxen andere tasten zuständig sind. Das ist also ein generelles UI Problem.

Für die Tastaturbedienung ist es wichtig, mehrere Navigationstasten anzubieten. TAB allein ist da zu wenig.

Derzeit behelfe ich mir in der Regel so.

• Bei Betreten der Seite: Lasse die Tab-Taste in der Navigation rotieren, bis ein Button aktiviert wird.
• Lasse den Tab im aktivierten Widget rotieren, bis ein Minimize/Close - Funktion ausgelöst wird, die den Fokus wieder in die primäre Navigation schiebt.

Ich arbeite also mit TAB-Kreisen.

Nun kann ein Widget auch weitere komplexe Navigationen (zB Menu) aufweisen. Anstatt neue TAB-Kreise zu definieren, ist es dort sinnvoller mit Pfeiltasten zu navigieren, während die TAB-Taste eher diesen Kontext verlässt und zum nächsten Fokuselement springt. (derzeit noch nicht so realisiert)

Bei den UI-Tabs handelt es sich um Gruppen die mithilfe von Radiobuttons realisiert sind. Das ansprechen über die Pfeiltasten ist hier schon mal das primäre Browserverhalten.

3. Mit Tasten -> und <- wechselt man den aktiven Tab (keine Leertastenaktivierung notwendig).
4. Mit Taste Enter betrete ich das aktivierte Textarea-Feld

Also zu jedem Tab gehört ein textarea und sonst nichts. Was in das Textarea gehört ergibt sich aus…?

Ein Tab, besteht technisch aus input radio, label und textarea, wobei die nichtaktiven textareas hidden sind. Die aktivierung des Tabs geschieht onfocus.

<label aria-label="switch aktive Tab with Arrow-Keys"> erachte ich für Screenreader ungünstig (repetitiv)`

Es ist auch üblich, das die Pfeiltasten genutzt werden können. Mit dem Tabulator sollte es aber auch möglich sein, zum nächsten Tab/Karteikartenreiter zu gelangen

Hier haben wir im w3c Design für Forumalre bereits, dass die Bedienung von radio/chackboxen von deiner Erwartung abweichen.

visuell wäre ein Icon angebracht, das :onfocus erscheint.

Kann ein Icon sein, klar. Andere Hervorhebungen sind auch möglich und üblich.

Wenn ein User ein Interface versteht, dann benötigt er keine Hilfe mehr. Ich könnte also die repetitiven labels verwenden, vorausgesetzt, dass der User diese auch (anderswo) dann deaktivieren kann.

Man sollte Einstellungen in der Nähe der Stelle vornehmen können, wo man sie nutzt.

Es wird auf jeden Fall globale Einstellungen geben. Dazu gehören:

• GUI-Sprache
• root font-size
• Farbkontrast
• Anzeige von Navigationshilfen
• :focus highlighting

Eine andere Lösung: das aria-label wird dynamisch bei Betreten des ersten aktiven labels erzeugt, danach entfernt. Der Hinweis kann dann länger sein, und auch erwähnen, wie man den Kontext (mit Taste Tab, verlässt)

Aber vielleicht wisst ihr eine bessere Lösung?

Klingt schon mal nicht schlecht. Du kannst die Erklärung aber auch an beliebiger Stelle anlegen (möglichst vorher) und dann mit aria-describedby darauf verweisen.

Das ist ein sehr guter Hinweis. Diese Verhalten brauche ich nämlich immer wieder.

Mir ist aber noch was anderes eingefallen. Wenn ich der Tabgruppe noch ein erstes focusierbares Element vorschalte, dann kann ich das Navigationsverhalten dort beschreiben und bei den einzelnen Labeln unterlassen.

Hinweis:

Ich arbeite an einem browserbasierten Desktopsystem, in welchem Apps leicht angemeldet werden können. das os bietet hier viele Funktionen an wie Fenster, Menus, Tabs. Dass diese Funktionen gut getestet sind, hat deshalb oberste Priorität.

Im Gegensatz zu anderen Desktopsystemen muss ich mit grossen Beschränkung für Tastaturbedienung umgehen.