Nach einer langen krankheitsbedingten Pause von etwa vier Jahren habe ich vergangene Woche das erste Mal wieder Visual Studio Code installiert. Ich möchte mein altes Hobby der Programmierung wieder etwas aufleben lassen und eine moderne Programmiersprache lernen. Und als ich VS Code das erste Mal startete, fand ich einige erfreuliche und überraschende Dinge.
In diesem Artikel
Ein kleiner Rückblick
Gegen Ende der 2010er Jahre versuchte ich, Visual Studio Code das erste Mal für meine Arbeit bei Mozilla einzusetzen. Gerade für den Code-Mischmasch, aus dem das Projekt besteht, hoffte ich so auf eine mehr oder weniger einheitliche Oberfläche für alle Tätigkeiten. Wie auch viele andere Projekte war VS Code zunächst jedoch wenig zugänglich. Dank einer sehr aktiven Gemeinde von Screenreader-Nutzenden und einigen sehr fähigen Köpfen bei Microsoft änderte sich dies jedoch von Version zu Version.
Ich begann, mich selbst im Projekt zu engagieren, da VS Code ja quelloffen entwickelt wird. Ich steuerte Feedback zu bestehenden Problemen bei und machte Vorschläge, wie diese zu beheben sein könnten. Auch sagte ich meine Meinung zu vorgeschlagenen Verbesserungen, indem ich mir den von anderen eingereichten Code anschaute. Zusätzlich gab ich Tipps zur Implementierung z. B. für die Zugänglichkeit per Tastatur zu Symbolleisten, dem Springen zwischen den Hauptbereichen der Benutzeroberfläche usw.
Dank dieses Feedbacks und dem von anderen blinden Nutzenden wurde VS Code in vielen Bereichen bald richtig benutzbar. Es gab allerdings auch noch viele Bereiche, die so visuell waren und für die es keine guten Nutzungsmuster gab, dass einige Bereiche nach wie vor für unseren Personenkreis verschlossen blieben. Dazu gehörte z. B. vieles, was mit Debugger von Code zu tun hat.
Leider wurde ich Anfang 2021 endgültig so krank, mit meiner dritten Burn-out-Episode, dass ich sämtliches Engagement einstellen musste. Es war einfach keine Energie mehr da. Diejenigen, die mir schon länger folgen, wissen, dass diese Erkrankung dann Ende 2022 auch zur Erwerbsminderungsrente führte.
Ein neuer Anlauf 2025
Überspringen wir also die letzten Jahre und kommen zur vergangenen Woche, also Mitte Februar. Nach einigem Herumfragen und selbst Ausprobieren landete ich für das Bearbeiten von Code auf dem Mac wieder bei Visual Studio Code. Da inzwischen keiner der Rechner von 2021 mehr in meinem Haushalt existiert, installierte ich dieses demzufolge frisch auf meinem aktuellen Mac. Ich installierte die veröffentlichte Version, also keine Beta- oder Insider-Version.
Beim Start bekam ich wie erwartet die Willkommensseite angezeigt. Und hier zeigte sich die erste Änderung, die mir bislang nicht geläufig war.
Zugängliche Ansicht von Informationen
Bei vielen Anzeigen bekam ich den Hinweis, dass ich doch Wahltaste+F2 drücken könne, um diesen Bereich in einer zugänglichen Ansicht (englisch „Accessible View“) anzeigen zu lassen. Dies ist eine reine Textansicht in einem nur lesbaren mehrzeiligen Textfeld. Dieses kann ich sowohl mit den Pfeiltasten zeilen-, wort- und zeichenweise durchgehen, als auch den Text wunderbar auf der Braillezeile erfassen. Diese Ansicht steht für alle möglichen Bereiche zur Verfügung. Im Editor kann man sich z. B. nach Aufruf der Hover-Informationen diese in einer solchen Ansicht anzeigen lassen. Um die genauen Parameter und den Aufbau eines Funktionsaufrufs zu erfassen, ist das Gold wert. Im Terminal wird so die Ausgabe nach Befehlen uneingeschränkt lesbar, und Informationen können sogar kopiert werden. Im Debugger gibt es Informationen zu den Zuständen des Codes und andere relevante Einzelheiten. Überall dort, wo diese zugängliche Ansicht verfügbar ist, wird man per Screenreader-Ansage auf die Verfügbarkeit hingewiesen. Und wenn ich mir die offenen Issues bei VS Code so durchblättere, soll dieses System weiter ausgebaut werden.
Kontextbezogene Hilfe zur Zugänglichkeit
Die Willkommensseite widmet dem Thema Zugänglichkeit einen ganzen Bereich. Viele Konzepte zur Benutzung durch Screenreader werden hier kurz, aber anschaulich, erklärt. Auch wird erklärt, wie man sich in verschiedenen Bereichen eine sogenannte kontextabhängige Hilfe aufrufen kann. Auf dem Mac ist dies die Tastenkombination Wahltaste+F1. Im Editor werden so z. B. Dinge wie das Benutzen der Autovervollständigung oder der Hover-Informationen erklärt. Die zugehörigen Tastenkombinationen werden gleich mit gesprochen. Aus dieser Ansicht heraus hat man auch die Möglichkeit, bis jetzt nicht mit Tastaturkürzeln versehene Befehle mit ebensolchen auszustatten. Stellt man also fest, dass man eine Funktion regelmäßig benötigt, diese aber keiner Tastenkombination zugewiesen ist, ist dies hier schnell erledigt.
Die kontextbezogene Hilfe gibt es auch für die Debug-Konsole, das Terminal und weitere Bereiche. Das Vorhandensein einer solchen Hilfe wird auch hier vom Screenreader angekündigt.
Denjenigen, die den Screenreader JAWS verwenden, dürfte dieses Konzept bekannt vorkommen. JAWS hat seit Version 1, die vor 30 Jahren erschienen ist, eine Kontexthilfe für alle möglichen standardisierten Steuerelemente in Windows, die erklärt, wie man mit Buttons, Kontrollfeldern, Listenfeldern o. Ä. umgeht. Auch in verschiedenen Apps gibt es für besondere Fenster eine solche Hilfestellung. Diese erreicht man immer mit JAWS-Taste+F1. Drückt man dieses zweimal hintereinander, wird diese Hilfe auch in dem sog. virtuellen Betrachter angezeigt, und man kann die Informationen auch auf der Braillezeile lesen.
Dass sich Microsoft hier etwas Ähnliches hat einfallen lassen, ist bei einer so komplexen Oberfläche, wie sie VS Code bietet, eine große Hilfe. Ich habe in der kurzen Zeit, in der ich VS Code wieder benutze, schon viele Kniffe dadurch kennengelernt und meine Arbeit signifikant beschleunigen können. Auch dieser Bereich wird kontinuierlich ausgebaut, wie ein Blick in die offenen Issues zeigt.
Klänge bei vielen Ereignissen
Ein Konzept, das damals, als ich krank wurde, gerade in der Diskussion war, ist inzwischen sehr konsequent eingebaut und erweitert worden. Es handelt sich dabei um das Anzeigen bestimmter Ereignisse in der Oberfläche durch konfigurierbare, kleine Sounddateien. So wird der Fortschritt eines Vorgangs durch einen Sound angezeigt. Wenn in einem Terminal ein Erfolg oder Fehler auftritt, werden zwei unterschiedliche Sounds abgespielt, die sich ähneln. Wird eine Chat-Anfrage von Copilot beantwortet oder befindet sich ein Fehler oder ein Unterbrechungspunkt auf einer Zeile, erklingen wieder andere Sounds. Gerade letzteres ist eine super hilfreiche Sache, um beim Debugger zu helfen. Sehende sehen sofort am linken Rand des Editors eine entsprechende Markierung. Gehe ich nun mit den Pfeiltasten durch eine Datei und befindet sich auf einer Zeile ein Breakpoint, höre ich dies beim Vorlesen der Zeile durch einen Sound und weiß ebenfalls sofort Bescheid.
Welche Ereignisse es gibt und welcher Sound welchem Ereignis zugeordnet ist, kann man sich leicht anhören. Man gibt dazu den Befehl für die Command Palette und sucht nach dem Befehl „Help: List Signal Sounds“. Mit den Pfeiltasten kann man jetzt alle Sounds durchgehen, einen neuen zuweisen, bestimmte Sounds deaktivieren oder aktivieren usw. Mit dem ähnlich lautenden Befehl „Help: List Signal Announcements“ kann man hingegen steuern, welche Ereignisse außerdem per hoher Priorität als Text an den Screenreader gesandt werden. So kann man fein einstellen, wofür man Sounds, Ansagen oder beides haben möchte.
Jetzt könnten einige argumentieren, dass für solche Ansagen oder Klänge doch der Screenreader zuständig sein sollte. Bei üblichen UI-Komponenten stimme ich dem auch vorbehaltlos zu. Es gibt jedoch Software wie eben Code-Editoren, die so speziell ist, dass gerechtfertigt ist, Ansagen und Hinweistöne hier selbst zu steuern. Immerhin hat der Editor die besten Informationen über seine Daten. Würde man für jedes Ereignis versuchen wollen, diese in vier verschiedene Zugänglichkeits-APIs (Windows UIA und IAccessible2, Linux GTK und Apple Universal Access für MacOS) zu standardisieren, würde dies Jahre dauern. Und danach müssten fünf Screenreader (JAWS, Narrator und NVDA unter Windows, Orca unter Linux und VoiceOver unter MacOS) diese Ereignisse verarbeiten und entsprechende Verhaltensmuster implementieren. Da ist es deutlich pragmatischer, die Steuerung und Ausgabe selbst zu übernehmen und in einem so speziellen Fall die Zugänglichkeit deutlich schneller herzustellen.
Außerdem ist das Verhalten des Editors auf allen Plattformen gleich. Egal, ob ich also VS Code unter Windows, Linux oder MacOS laufen lasse, bekomme ich immer dieselben Sounds und Ansagen und finde mich sofort zurecht.
Fazit
Die Funktionen zur Zugänglichkeit bei VS Code sind in meinen Augen sehr gelungen und erhöhen die Produktivität ungemein. Der einzige andere Editor, der da vielleicht noch etwas Ähnliches bieten könnte, dürfte Emacs mit der Erweiterung EmacSpeak sein. Dies ist auch eine selbst sprechende Erweiterung, die direkt in Emacs läuft. Ich habe jedoch damit keine Erfahrung, da mir die Lernkurve für Emacs zu hoch ist, um es auszuprobieren.
Ich habe neulich probeweise die Python-Anleitung durchgespielt und hatte jederzeit vollen Zugriff auf die Elemente jedes Schritts. Sei es der Breakpoint, die Debug-Konsole, das Terminal oder die Autovervollständigung, alles konnte ich mir mithilfe der zur Verfügung stehenden Tools problemlos ansagen oder anzeigen lassen.
Ich habe mich bis jetzt nicht entschieden, welche Programmiersprache ich lernen möchte. In der engeren Wahl sind Python, Rust oder auch Swift oder Go. Außerdem mache ich das nur als Hobby. Ich habe also alle Zeit der Welt, mich damit zu beschäftigen und an der guten Zugänglichkeit zu erfreuen.
Auch ermutigen die regelmäßigen Updates zu VS Code mich, dass trotz des geänderten politischen Klimas in den USA das Engagement der Mitarbeitenden am Projekt derzeit ungebrochen scheint. Im Grunde enthält jedes Release einen Abschnitt zur Verbesserung der Zugänglichkeit.