UI tastaturproblem

[beatovich]

hallo

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

<label aria-label="switch aktive Tab with Arrow-Keys"> erachte ich für Screenreader ungünstig (repetitiv)` visuell wäre ein Icon angebracht, das :onfocus erscheint.

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.

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?

[Matthias Apsel]

Hallo beatovich,

Sammelt Klopapier!!! In der Zeitungsbranche herrscht Papiermangel!!!

Deine Tastatur ist kaputtttt.

(und auch inhaltlich ist die Signatur nicht wirklich der Bringer. Nicht jede Zeitung dümpelt auf Bildnineau.)

Bis demnächst
Matthias

[beatovich]

hallo

Danke für den Hinweis

[marctrix]

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.

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…?

<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

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äher der Stelle vornehmen können, wo man sie nutzt.

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.

Marc

[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.

[marctrix]

Hej beatovich,

um nicht zu viel Erwartung zu schüren: mit Anwendungen habe ich nicht so viel Erfahrung und dein hier vorgestelltes Projekt scheint recht umfangreich. Daher ist es schwierig etwas konkretes dazu zu sagen. Ein bisschen was allgemeines statt dessen (da Dur dir viel mehr Gedanken gemacht hast über Dein Projekt, wird dir eventuell das meiste davon auch schon durch den Kopf gegangen sein).

Ich halte das Projekt für so komplex, dass du eine gute Nutzererfahrung nicht allein auf Annahmen gestützt hinbekommen wirst. Deine Ideen halte ich für gut, z.B. die Tab-Karusselle.

Um Anwendertests wirst du aber vermutlich nicht herumkommen.

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.

Aber es ist für Tastatur-Nutzer das gewohnte Verhalten…

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.

Das gewohnte Browserverhalten solltest du auch so weit wie irgend möglich beibehalten und ergänzen wo immer es Sinn macht.

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.

Häh? 😂

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.

Du hast hier sinnvolle zentrale Einstellungen genannt. Was das Ausblenden von Hilfetexte betrifft sehe ich das Problem, dass Nutzer glauben diese nicht mehr zu benötigen. Und nach dem nächsten Urlaub wissen Sie nicht mehr, die die Seite zu bedienen ist. Da hilft es, wenn die Möglichkeit zur Anzeige von Hilfetexten dort zu finden ist, wo die Hilfe benötigt wird.

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.

Ja, es gibt zahlreiche Möglichkeiten. Womit die Nutzer letztendlich am besten klar kommen, wirst du nur durch Tests herausfinden.

Wie die funktionieren (muss nicht viel Aufwand sein) weißt du vermutlich?

In seinem Buch „Don't make me think“ beschreibt Steve Krug auch das. Da gibt es auch Empfehlungen für das weitere Vorgehen — aber damit sage ich dir vermutlich nichts neues…

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.

Dann renne ich ja offene Türen ein.

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

Kannst dich aber auf gewohntes Verhalten stützen. Ein schwacher Trost, ich weiß…

Marc