macOS’ kaputte Tab-Steuerung & etwas Tabulator-Geschichte

Ich habe vor Kurzem meinen Dauerbrenner-Artikel aktualisiert, nämlich wie man in macOS eine Bluetooth-Maus nur mit Tastatur verbinden kann. Dabei habe ich mich gefragt warum das Standard-Verhalten der Tabulator-Taste in macOS, die das Problem erst verursacht, eigentlich so seltsam ist.

Apples seltsames Tabulator-Verhalten

Bevor es losgeht, was meine ich konkret mit »seltsamem Tabulator-Verhalten«? macOS hat das Problem, dass Tabulator nicht immer alle notwendigen Felder durschaltet, um Einstellungen nur mit Tastatur vornehmen zu können. Das war schon vor Ventura und den neuen Systemeinstellungen so. Im folgenden Screenshot war es z.B. nicht möglich mittels Tabulator zum begehrten »Bluetooth aktivieren«-Button zu gelangen (mit welchem Trick es doch klappt, lest ihr im entsprechenden Artikel):

Nur mit Tastatur eine Sackgasse: Die Bluetooth-Einstellungen.

Seit Ventura mit den redesignten Systemeinstellungen hat sich das Problem noch verschlimmert.

Die Tabulator-Taste schaltet nämlich seitdem nur mehr Felder in der neuen Seitenleiste links durch (also z.B. Suchfeld, WLAN, Bluetooth etc.):

Tab schaltet nur die Einträge in der Seitenleiste links durch.

Die jeweiligen Einstellungen werden zwar immer korrekt im Detailbereich rechts angezeigt, nur kommt man nur mit Tastatur nicht in diesen Bereich hinein, um auch tatsächlich Einstellungen zu ändern. Es gibt Lösungen und Workarounds dafür (siehe entsprechender »Maus verbinden«-Artikel), hier soll es aber darum gehen, woher die Tabulator-Steuerung überhaupt kommt und zumindest den Versuch einer Erklärung, warum diese in macOS so seltsam implementiert ist.

(Und falls jemand fragt: In Windows schaltet Tabulator in der Systemsteuerung alle Bereiche des Fensters durch. 😉)

Woher kommt die Tabulator-Steuerung?

Um ehrlich zu sein war ich mir bzgl. der Ursprünge der Tabulator-Steuerung in GUIs nicht ganz sicher. Der Webdeveloper in mir vermutete natürlich ein Accessibility-Feature, um z.B. auch mit Sehbeeinträchtigung in einem Interface bzw. Formular die Eingabefelder auswählen zu können.

Nach etwas Recherche stieß ich auf der englischsprachigen Wikipedia-Seite zum Tab-Key auf folgende Info:

In many graphical applications, especially on Windows, the Tab key will move the focus to every control or widget such as buttons so that the user interface can be used without a mouse at all (this was part of the IBM Common User Access design).

Aha – es hatte also tatsächlich etwas mit »Access« tun! Vielleicht nicht mit Accessibility, wie wir es heute verstehen, aber als Standard, wie man mit interaktiven Elementen interagieren kann wenn man keine Maus hat. Beschrieben wurde das Tab-Verhalten also erstmals im IBM-Standard IBM Common User Access (1987). Spannend sind darin unter anderem folgende beiden Punkte:

• All operations can be done with either the mouse or the keyboard;
• Navigation within fields in dialog boxes is by cursor key; navigation between fields is by pressing the Tab key; […]

Ihr merkt es schon: Der letzte Punkt ist etwas ungenau, weil er den Scope nicht definiert. Welche Felder in welchem Kontext schaltet Tabulator nun durch? Alle in einer Gruppe, alle in einem Fenster, überhaupt alle in der GUI? In Kombination mit dem ersten Punkt sollte es aber zumindest irgendwie möglich sein. Und irgendwie möglich ist es bei Apple ja auch (dazu später mehr).

Doch der Reihe nach: Im selben Wikipedia-Beitrag wird auf Apples Human-Interface-Guidelines verwiesen. Da wird es interessant, allerdings weniger, weil wir dem Grund für Apples seltsame Implementierung näher kommen, sondern weil sich hier die Spur schlicht verliert: Zum Suchbegriff »Tabulator« spuckt die Suche auf der HIG-Seite zwar keine Ergebnisse aus, wohl aber zum Begriff »Keyboards«.

Apples HIG zum Thema Tastatursteuerung

Hier liest man dann, passenderweise unter der Überschrift »Best Practices« (und den Guidelines vom IBM Common User Access nicht unähnlich), Folgendes:

Support keyboard-only interaction where possible. As the name suggests, full keyboard-access mode lets people navigate and activate windows, menus, controls, and system features using only the keyboard.

Interessant ist einerseits, dass dieser »full keyboard-access mode« in macOS von Haus aus deaktiviert ist. Bis Monterey konnte man diesen in den Systemeinstellungen unter Tastatur → Kurzbefehle aktivieren:

Via der Kurzbefehle-Optionen der Tastatur-Einstellungen lässt die Tabulator-Funktionalität erweitern.

Seit Ventura (2022) wird die Tastatursteuerung allerdings anders aktiviert, siehe Apples aktualisierte Anleitung.

Tab-Verhalten in macOS: Undefiniert bis fehlerhaft

Es geht aber noch weiter, denn weiter unten in den HIG unter »Specifications« listet Apple folgende reservierte Aktionen für die Tabulator-Taste auf:

In macOS reservierte Aktionen für Tabulator.

Interessant ist, dass Apple die Standard-Aktion für die Primärtaste (also nur Tab) gar nicht auflistet. Wenn man die Beschreibung von Shift + Tab ableitet, wäre es in dem Fall wohl schlicht »Navigate through controls«.

Auch hier ist einerseits nicht klar, welche Controls das nun umfasst (aktuelles Fenster, aktueller Bereich eines Fensters, alle Fenster einer App etc.).

Und: Es ist teilweise falsch.

Beim konkreten Beispiel der »neuen« Systemeinstellungen schaffe ich es z.B. regelmäßig, diese zwar über Strg + Leertaste und der Suche nach »Bluetooth« rein mit Tastatur zu öffnen. Tabulator bewirkt dann aber gar nichts. Ich kann dieses Verhalten noch nicht reproduzieren, es passiert mir aber sehr oft.

Selbst, wenn es funktioniert, scheitert man zunächst am eingangs erwähnten Grundproblem, dass man nur mit Tabulator allein keine Bluetooth-Einstellungen vornehmen kann. Apples eigene HIGs würden aber nahelegen, dass man mit Control + Tab den Fokus zur nächsten Einstellungsgruppe bewegen kann. Das klappt aber in den Systemeinstellungen nicht. Notwendig ist dafür die Tastenkombination (Fn +) Strg + F7, was laut Apple Folgendes bewirkt:

Art und Weise ändern, wie die Tabulatortaste den Fokus bewegt – entweder Navigation aller Steuerelemente im Bildschirm oder nur von Textfeldern und Listen.

Und selbst die Beschreibung stimmt strenggenommen nicht: Denn Tabulator bewegt den Fokus nicht durch alle Steuerelemente im Bildschirm, sondern nur im aktiven Fenster. 🙈

Fazit & eure Meinung

Warum Apple die Tab-Steuerung innerhalb eines Fensters standardmäßig auf einen Bereich limitiert, anstatt auf das ganze Fenster ist nach wie vor nicht klar. Nachteile ergäben sich daraus meiner Meinung nach nicht – aber vielleicht kann mich ja jemand in den Kommentaren aufklären (oder auch gerne andere Tipps dalassen)!