Visual Studio Code Themes 2026: Die besten finden — und selbst eins bauen, das barrierefrei ist

Visual Studio Code Themes sind die meistinstallierte Kategorie im gesamten Marketplace — und die am schlechtesten geprüfte. Fast jede Anleitung im Netz zeigt dieselben zehn beliebten Themes, erklärt den Klick auf „Installieren” und hört genau da auf, wo es interessant wird.

Dieser Artikel macht es anders. Wir haben nicht recherchiert, sondern gemessen: die komplette Themes-Kategorie des Marketplace ausgezählt (18.420 Erweiterungen), die 60 meistinstallierten heruntergeladen, entpackt und 302 Farbthemes durch einen WCAG-Kontrastrechner geschickt. Danach haben wir ein eigenes Theme gebaut und systematisch versucht, es kaputtzumachen.

Zwei Ergebnisse vorweg, und beide widersprechen dem, was man üblicherweise liest:

Erstens: Bei 86 % der gemessenen Themes hat die Kommentarfarbe weniger Kontrast, als die WCAG-Richtlinie für normalen Text verlangt. Der Median liegt bei 2,95 — nötig wären 4,5. Das betrifft nicht Nischenprodukte, sondern die meistgenutzten Themes überhaupt.

Zweitens: Themes, die „High Contrast” im Namen tragen, sind davon nicht ausgenommen. 18 von 21 fallen durch. Eines davon misst am Editor-Text 2,59 — weniger als die 3,0, die nicht einmal für große Schrift reichen.

Die Kurzfassung

Methodik: Alle Marktzahlen am 02.09.2026 über die offizielle Marketplace-API (/_apis/public/gallery/extensionquery) abgerufen, Kategorie „Themes”, 197 Seiten à 100 Einträge, auf eindeutige Erweiterungs-IDs reduziert. Die 60 meistinstallierten wurden als VSIX heruntergeladen, entpackt und ihre package.json sowie alle referenzierten Theme-Dateien ausgewertet. Kontraste nach WCAG 2.1 (relative Luminanz) berechnet, Alphawerte gegen die jeweilige Editor-Hintergrundfarbe verrechnet. Farbschlüssel aus src/vs/platform/theme/ in microsoft/vscode (Stand 1.137.0) gezählt. vsce 3.9.2.

Was ein VS Code Theme technisch ist

Ein Theme ist eine Erweiterung ohne Code. Es hat dieselbe Verpackung wie jede andere VS-Code-Erweiterung — ein ZIP-Archiv mit package.json — nur dass darin kein JavaScript liegt, sondern ausschließlich Farbangaben.

VS Code unterscheidet drei Sorten, die oft verwechselt werden:

• Farbthemes (contributes.themes) färben Editor und Oberfläche. Das ist gemeint, wenn von „Themes” die Rede ist.
• Datei-Icon-Themes (contributes.iconThemes) tauschen die Symbole im Dateibaum aus. Sie enthalten keine einzige Farbe für den Editor.
• Produkt-Icon-Themes (contributes.productIconThemes) ersetzen die Symbole der Oberfläche selbst — Zahnrad, Lupe, Debug-Pfeil.

Die Unterscheidung ist keine Haarspalterei, denn sie erklärt eine Merkwürdigkeit der Rangliste. Unter den 25 meistinstallierten Einträgen der Themes-Kategorie sind sechs reine Icon-Pakete, die überhaupt keine Farben setzen — darunter Platz 2 und 3.

Und der Spitzenreiter ist noch kurioser. Auf Platz 1 der Themes-Kategorie steht mit 58,9 Millionen Installationen ms-vscode.cpptools-themes — ein Begleitpaket der C/C++-Erweiterung, das vier Visual-Studio-Farbschemata mitliefert und seit Oktober 2022 nicht aktualisiert wurde. Kaum jemand installiert es bewusst; es kommt als Abhängigkeit mit.

Das Ranking misst nicht, was man denkt

Auf Platz 10 der Themes-Kategorie steht ein Paket namens „No Code” mit 5,8 Millionen Installationen. Seine Beschreibung: „No code is the best way to write secure and reliable applications. Write nothing; deploy nowhere.”

Wir haben es entpackt. Sein contributes-Objekt ist buchstäblich leer:

"contributes": {}

Es enthält kein Theme, keine Farbe, keine Funktion — nur eine README.md und ein Bild. In der Themes-Kategorie taucht es auf, weil es sich in seiner package.json in alle 15 Kategorien gleichzeitig einträgt: Azure, Data Science, Debuggers, Formatters, Keymaps, Snippets, Themes und so weiter.

🔑 Das ist der erste Fund, und er hat Folgen für jede „Top 10 Themes”-Liste im Netz: Die Kategoriezuordnung im Marketplace ist eine Selbstauskunft des Autors, keine Prüfung. Wer die Rangliste ungefiltert abschreibt, empfiehlt am Ende ein Compiler-Beipack, sechs Icon-Sets und einen Scherz — und hat davon dreizehn Plätze der Top 25 belegt.

Für diesen Artikel haben wir deshalb jedes Paket geöffnet und nachgesehen, ob überhaupt contributes.themes drinsteht, statt der Kategorie zu glauben.

Wie viele Themes es wirklich gibt — und wie wenige benutzt werden

Die Kategorie „Themes” meldet 19.679 Treffer. Nach Bereinigung um Dubletten aus der Paginierung bleiben 18.420 eindeutige Erweiterungen von 15.179 verschiedenen Herausgebern.

Diese Zahl wird gern als Argument benutzt: „riesige Auswahl”. Sie ist als Qualitätsmerkmal wertlos, und das lässt sich zeigen.

Vollzählung aller 18.420 eindeutigen Einträge der Kategorie „Themes”, Marketplace-API, 02.09.2026. „Installationen” ist die vom Marketplace gemeldete Statistik install.

Der Median liegt bei 377 Installationen. Zwei Drittel aller Themes haben weniger als tausend. Gleichzeitig entfallen 73,4 % aller 375 Millionen Installationen auf die Top 50, und 90,4 % auf die Top 500.

Anders gesagt: Von 18.420 Themes sind rund 500 relevant, und der Rest ist statistisches Rauschen. Wer die Rangliste weit genug durchblättert, findet ab etwa Rang 15.000 Einträge mit einstelligen Installationszahlen und Namen, die mit Codeeditoren nichts zu tun haben — bei unseren Stichproben etwa Letempsdessecrets-vostfr-en-streaming und stellar-taiwan-online. Der Marketplace wird als Streaming-Verzeichnis missbraucht, und die Themes-Kategorie ist dafür offenbar ein beliebter Ablageort.

Zwei Drittel sind stehengeblieben

Noch aussagekräftiger als die Installationszahl ist das Datum der letzten Aktualisierung. Wir haben für jeden Eintrag lastUpdated ausgelesen:

• Median-Alter: 1.170 Tage — mehr als drei Jahre.
• 65,6 % wurden seit über zwei Jahren nicht angefasst.
• 39,4 % seit über vier Jahren nicht.

Bei einem Theme ist das weniger dramatisch als bei einer Erweiterung mit Code — ein Theme kann nicht wirklich „kaputtgehen”. Aber es veraltet trotzdem, und zwar auf eine Art, die man nicht sofort sieht: VS Code führt laufend neue Farbschlüssel ein. Ein Theme von 2021 kennt die Schlüssel für neuere Oberflächenteile schlicht nicht, und dort greift dann die Standardfarbe. Das Ergebnis sind Bereiche, die farblich aus dem Rahmen fallen — der häufigste Grund für das Gefühl, ein Theme sei „irgendwie unfertig”.

Der Test, den niemand macht: Kontrast

Hier wird es ernst. Ein Theme ist kein Dekorationsobjekt — es ist die Oberfläche, auf die Entwickler acht Stunden am Tag starren. Ob Text darauf lesbar ist, lässt sich objektiv messen: Die WCAG-Richtlinie definiert einen Kontrastwert zwischen Vorder- und Hintergrundfarbe. 4,5 gilt als Mindestmaß für normalen Text (Stufe AA), 7,0 für die strengere Stufe AAA. Unter 3,0 ist selbst für große Schrift zu wenig.

Wir haben aus den 60 heruntergeladenen Paketen alle 302 Farbthemes extrahiert und für jedes berechnet:

• den Kontrast von editor.foreground gegen editor.background,
• und die Kontraste der drei meistgelesenen Token-Sorten: Kommentare, Zeichenketten und Schlüsselwörter.

289 Themes ließen sich vollständig auswerten (6 Dateien hatten defektes JSON, 2 setzen gar keinen Editor-Hintergrund). Das Ergebnis:

Kontrast nach WCAG 2.1 aus der relativen Luminanz berechnet. Token-Farben über den jeweiligen tokenColors-Eintrag für die Scopes comment, string und keyword ermittelt; Farben mit Alphakanal wurden gegen die Editor-Hintergrundfarbe verrechnet, nicht verworfen. n = 289 Themes aus 44 Paketen.

🔑 Der zentrale Befund: Der Fließtext ist fast überall in Ordnung, die Kommentare sind es fast nirgends. Bei 86 % der Themes liegt die Kommentarfarbe unter dem AA-Schwellwert, bei 147 Themes sogar unter 3,0.

Das ist kein Zufall, sondern Absicht — und genau das macht es diskutabel. Themedesigner dämpfen Kommentare bewusst, damit sie den Code nicht überlagern. Die Logik dahinter: Kommentare sind „sekundär”. Nur stimmt diese Annahme in dem Moment nicht mehr, in dem jemand fremden Code liest und ausgerechnet die Erklärungen braucht. Oder eine Sehschwäche hat. Oder bei Tageslicht am Laptop sitzt.

Man kann diese Designentscheidung gut finden. Aber man sollte wissen, dass sie getroffen wurde — in den Marketplace-Beschreibungen steht sie nirgends.

„High Contrast” im Namen heißt gar nichts

Der auffälligste Einzelfund unserer Messung. Wir haben alle Themes herausgefiltert, die „High Contrast” oder „HC” im Namen tragen — also genau die, die man auswählen würde, wenn Lesbarkeit das Problem ist. 21 Stück. Davon fallen 18 beim Kommentar-Kontrast durch, und zwar alle 18 unter 3,0:

Auszug aus 21 Themes mit „High Contrast”/„HC” im Namen. ✅ = erfüllt WCAG AA für normalen Text.

Der Fall Material Theme Lighter High Contrast ist der krasseste, deshalb haben wir ihn einzeln nachgerechnet, statt dem Skript zu glauben. Die Werte aus der Theme-Datei:

editor.background = #FFFFFF
editor.foreground = #90A4AE

Ein mittleres Blaugrau auf Weiß. Nachgerechnet ergibt das 2,59 — nicht einmal die 3,0, die für große Schrift ausreichen würden. Ein Theme, das „High Contrast” heißt, hat den niedrigsten Grundkontrast unserer gesamten Messreihe.

🔑 Regel daraus: Der Name eines Themes ist Marketing, kein Messwert. Und das lässt sich nicht mit „ist halt Geschmackssache” abtun — „High Contrast” ist kein Stilbegriff, sondern ein Barrierefreiheits-Versprechen. Hier wird es gebrochen, ohne dass irgendetwas widerspricht.

Positive Gegenprobe: GitHub Dark High Contrast hält, was der Name sagt — 17,57 am Editor-Text und 11,12 bei Kommentaren, also klar über AAA. Es geht also. Es wird nur nicht geprüft.

Übrigens ist auch das Feld uiTheme kein Schutz. Es kennt die Werte hc-black und hc-light für echte Barrierefreiheits-Themes. 16 Themes unserer Messreihe deklarieren das — und 13 davon liegen beim Kommentar-Kontrast trotzdem unter 4,5.

Wie beliebte Themes abschneiden

Damit das nicht abstrakt bleibt: die Werte der bekanntesten Themes, gemessen an denselben Kriterien.

✅ = Kommentar erfüllt WCAG AA (≥ 4,5). Gemessen aus den ausgelieferten Theme-Dateien der jeweils aktuellen Marketplace-Version, 02.09.2026.

Zwei Beobachtungen dazu:

Helle Themes sind nicht automatisch besser. Der verbreitete Reflex „hell = lesbarer” hält der Messung nicht stand: Bei dunklen Themes liegt der Median-Kommentarkontrast bei 3,05, bei hellen bei 2,83. Der Anteil unter AA ist bei hellen Themes nur wenig geringer (76 % gegenüber 89 %).

Ein hoher Grundkontrast rettet nichts. Min Light hat mit 16,10 einen exzellenten Editor-Kontrast und mit 1,76 einen der schlechtesten Kommentarwerte überhaupt. Wer nur die Hauptfarbe prüft, übersieht genau das.

Selbst eins bauen: die kürzeste vollständige Anleitung

Der beste Weg, ein Theme zu bekommen, das die eigenen Anforderungen erfüllt, ist es selbst zu schreiben. Der Aufwand ist deutlich geringer, als die meisten annehmen — unser vollständiges, paketierbares Theme ist 2.124 Byte groß und besteht aus zwei Dateien.

Schritt 1: package.json

{
  "name": "getmind-nord-test",
  "displayName": "GetMind Test Theme",
  "description": "Ein Theme mit gemessenen Kontrastwerten",
  "version": "0.0.1",
  "publisher": "getmind",
  "engines": { "vscode": "^1.90.0" },
  "categories": ["Themes"],
  "contributes": {
    "themes": [
      {
        "label": "GetMind Dark",
        "uiTheme": "vs-dark",
        "path": "./themes/getmind-dark.json"
      }
    ]
  }
}

Drei Felder sind hier nicht optional, und vsce bricht ohne sie ab: engines.vscode, eine gültige version und publisher. Beim uiTheme gibt es vier zulässige Werte — vs (hell), vs-dark (dunkel), hc-black und hc-light (Barrierefreiheit). Er steuert die Standardfarben für alles, was das Theme selbst nicht setzt.

Schritt 2: die Theme-Datei

{
  "name": "GetMind Dark",
  "type": "dark",
  "colors": {
    "editor.background": "#1B2028",
    "editor.foreground": "#D8DEE9",
    "editorLineNumber.foreground": "#6B7689",
    "editor.selectionBackground": "#39404D",
    "editorCursor.foreground": "#88C0D0",
    "sideBar.background": "#161A21",
    "activityBar.background": "#161A21",
    "statusBar.background": "#2E3440"
  },
  "tokenColors": [
    { "scope": ["comment"],
      "settings": { "foreground": "#8B95A7", "fontStyle": "italic" } },
    { "scope": ["string"],
      "settings": { "foreground": "#A3BE8C" } },
    { "scope": ["keyword", "storage.type"],
      "settings": { "foreground": "#81A1C1" } },
    { "scope": ["entity.name.function"],
      "settings": { "foreground": "#88C0D0" } },
    { "scope": ["constant.numeric"],
      "settings": { "foreground": "#B48EAD" } }
  ]
}

Das ist alles. Kein Build-Prozess, kein Framework, keine Zeile JavaScript.

Wichtig ist die Zweiteilung, an der viele scheitern: colors färbt die Oberfläche (Editor-Hintergrund, Seitenleiste, Statusleiste) und arbeitet mit festen Schlüsseln. tokenColors färbt den Quelltext selbst und arbeitet mit TextMate-Scopes wie comment oder entity.name.function. Wer im Editor Farben vermisst, sucht meist im falschen der beiden Blöcke.

Wie viele Farbschlüssel gibt es eigentlich?

Diese Zahl kursiert in Blogs in allen Varianten, deshalb haben wir sie im Quellcode gezählt statt abgeschrieben. In microsoft/vscode (Stand 1.137.0) registriert der Code über den gesamten src-Baum 964 Aufrufe von registerColor(), die 843 eindeutige Farb-IDs ergeben.

Man braucht sie nicht alle. Der Median unserer 289 gemessenen Themes liegt bei 237 gesetzten Farbschlüsseln, das Minimum bei 22, das Maximum bei 605. Für alles Nichtgesetzte greift die Standardfarbe des gewählten uiTheme.

Bei den tokenColors ist die Spanne noch größer: Median 55 Regeln, Minimum 12, Maximum 951.

Schritt 3: Farben prüfen, bevor sie jemand benutzt

Das ist der Schritt, den die 86 % aus unserer Messreihe ausgelassen haben. Der Kontrast lässt sich in wenigen Zeilen berechnen — hier in Python, damit es ohne Abhängigkeiten läuft:

def luminanz(hexfarbe):
    h = hexfarbe.lstrip('#')
    r, g, b = [int(h[i:i+2], 16) / 255 for i in (0, 2, 4)]
    f = lambda v: v/12.92 if v <= 0.03928 else ((v+0.055)/1.055) ** 2.4
    return 0.2126*f(r) + 0.7152*f(g) + 0.0722*f(b)

def kontrast(vorder, hinter):
    a, b = luminanz(vorder), luminanz(hinter)
    hell, dunkel = max(a, b), min(a, b)
    return (hell + 0.05) / (dunkel + 0.05)

bg = '#1B2028'
for name, farbe in [('Text', '#D8DEE9'), ('Kommentar', '#8B95A7'),
                    ('String', '#A3BE8C'), ('Keyword', '#81A1C1')]:
    print(f'{name:10} {kontrast(farbe, bg):.2f}')

Für unser Theme ergibt das:

Die Zeilennummer liegt bewusst unter 4,5 und wir lassen sie so stehen — mit Begründung: Sie ist reines Orientierungselement, kein Fließtext, und liegt über der 3,0-Schwelle für UI-Komponenten. Der Unterschied zu den gemessenen Themes ist nicht, dass wir überall AA erreichen, sondern dass wir wissen, wo wir es nicht tun.

Schritt 4: Paketieren

npm install -g @vscode/vsce
vsce package

Ergebnis bei uns: 2.07 KB, fünf Dateien. Die entstandene .vsix lässt sich sofort lokal installieren — über die Befehlspalette mit Extensions: Install from VSIX, oder auf der Kommandozeile:

code --install-extension getmind-nord-test-0.0.1.vsix

Zum Veröffentlichen braucht es zusätzlich ein Azure-DevOps-Konto, einen Herausgebernamen und ein Personal Access Token; dann genügt vsce publish. Für den Eigenbedarf ist das nicht nötig — die lokale Installation reicht vollkommen.

Der Rot-Test: Was prüft vsce eigentlich?

An dieser Stelle wollten wir es genau wissen. Ein grüner Paketierlauf fühlt sich wie eine Freigabe an — aber wofür genau? Wir haben unser funktionierendes Theme genommen und systematisch beschädigt, jeweils einen Defekt auf einmal.

Fünf Defekte in den Farbwerten, alle mit vsce package geprüft:

Kein einziger Defekt wurde gemeldet. Nicht als Fehler, nicht als Warnung. Das Paket wurde in allen fünf Fällen erzeugt, mit praktisch identischer Größe.

🔑 Das ist der dritte Fund, und der praktisch wichtigste: vsce prüft die Struktur des Manifests, nicht den Inhalt des Themes. Ein Tippfehler im Farbschlüssel (T4) ist besonders tückisch, weil er nirgends auffällt: VS Code ignoriert unbekannte Schlüssel stillschweigend, der betroffene Bereich behält einfach die Standardfarbe. Und T5 — ein Theme, in dem der Text unsichtbar ist — gilt als vollkommen in Ordnung.

Damit das keine Behauptung über ein Werkzeug bleibt, das vielleicht generell nichts prüft, die Gegenprobe: Was fängt vsce ab?

Nur zwei von zehn Manipulationen führten zu einem Fehler — und beide betreffen Pflichtfelder des Manifests, nicht das Theme.

G1 haben wir wegen der Tragweite einzeln nachgeprüft, statt der Erfolgsmeldung zu glauben. Wir haben den Pfad auf eine nicht existierende Datei gesetzt, paketiert und dann in das erzeugte Archiv hineingesehen:

extension/package.json          443 Bytes
extension/themes/getmind-dark.json  897 Bytes

Die package.json im fertigen Paket verweist auf ./themes/does-not-exist.json — eine Datei, die im Archiv nicht enthalten ist. vsce meldet DONE Packaged, und das Theme kann unmöglich funktionieren.

🔑 Regel daraus: Ein grüner Werkzeuglauf ist eine Aussage über das Format, nicht über das Ergebnis. Wer sich beim Theme-Bau auf vsce verlässt, hat geprüft, dass sein Paket ein gültiges ZIP mit gültigem Manifest ist. Über Lesbarkeit, Farbrichtigkeit oder auch nur die Existenz der Theme-Datei sagt das nichts. Genau hier entstehen die 86 %.

Der praktische Schluss ist einfach: Die Kontrastprüfung aus Schritt 3 muss man selbst machen, weil es sonst niemand tut. Zehn Zeilen Python vor dem Veröffentlichen — mehr braucht es nicht, um nicht Teil der 86 % zu werden.

Ein bestehendes Theme anpassen, ohne eins zu bauen

Für die meisten Fälle ist der schnellste Weg gar kein eigenes Theme, sondern eine Korrektur am vorhandenen. VS Code erlaubt, einzelne Farben zu überschreiben — in settings.json, ohne das Theme anzufassen.

Wer also Tokyo Night mag, aber mit dem Kommentar-Kontrast von 2,50 nicht leben will:

{
  "workbench.colorCustomizations": {
    "[Tokyo Night]": {
      "editorLineNumber.foreground": "#8A94AB"
    }
  },
  "editor.tokenColorCustomizations": {
    "[Tokyo Night]": {
      "comments": "#9AA5C0"
    }
  }
}

Zwei Details, die häufig Ärger machen:

• Die Angabe in eckigen Klammern bindet die Anpassung an genau dieses Theme. Ohne sie gilt sie für alle — und sieht beim nächsten Themewechsel falsch aus.
• Oberfläche und Quelltext sind getrennt, wie oben beschrieben: workbench.colorCustomizations für die Oberfläche, editor.tokenColorCustomizations für den Code.

Für feinere Eingriffe gibt es textMateRules, mit denen sich einzelne Scopes gezielt umfärben lassen:

{
  "editor.tokenColorCustomizations": {
    "[Tokyo Night]": {
      "textMateRules": [
        {
          "scope": ["comment", "punctuation.definition.comment"],
          "settings": { "foreground": "#9AA5C0", "fontStyle": "italic" }
        }
      ]
    }
  }
}

Welcher Scope an der Cursorposition gilt, verrät der Befehl Developer: Inspect Editor Tokens and Scopes aus der Befehlspalette. Er zeigt außerdem, welche Theme-Regel gerade greift — deutlich schneller als Raten.

Der aufgerundete Wert #9AA5C0 im Beispiel hebt den Kommentar-Kontrast von 2,50 auf über 4,5, ohne den Charakter des Themes zu zerstören. Das ist die pragmatischste Lösung überhaupt: ein beliebtes Theme behalten und die eine Farbe reparieren, die stört.

Was wir selbst benutzen

Wir schreiben hier viel über Messwerte, deshalb der ehrliche Teil: Bei uns läuft im Alltag ein dunkles Theme aus der oberen Hälfte dieser Tabelle, nicht das mit dem besten Kontrastwert. Farbwahl ist auch Gewohnheit, und ein Theme mit perfekten Zahlen, das man unangenehm findet, benutzt man nicht.

Was wir geändert haben, ist die Kommentarfarbe — genau über den textMateRules-Weg oben. Das ist ein Eingriff von drei Zeilen, der bleibt, und er hat mehr gebracht als jeder Themewechsel davor.

Die Empfehlung, die daraus folgt, ist deshalb nicht „nimm Theme X”, sondern: Miss dein aktuelles Theme einmal durch. Zehn Zeilen Python, zwei Minuten Aufwand. Wenn der Kommentarwert unter 4,5 liegt — was er mit 86 % Wahrscheinlichkeit tut — reparier ihn in settings.json und behalte alles andere.

Häufige Fragen

Wie viele Visual Studio Code Themes gibt es?

Der Marketplace listet in der Kategorie „Themes” 19.679 Treffer, was nach Bereinigung um Paginierungs-Dubletten 18.420 eindeutigen Erweiterungen entspricht (gemessen am 02.09.2026). Diese Zahl ist als Auswahlargument allerdings irreführend: Zwei Drittel haben weniger als 1.000 Installationen, und 73,4 % aller Installationen entfallen auf die Top 50.

Welches VS Code Theme hat den besten Kontrast?

In unserer Messreihe schneidet GitHub Dark High Contrast am besten ab: 17,57 beim Editor-Text und 11,12 bei Kommentaren — beides deutlich über der strengsten WCAG-Stufe AAA. Unter den populären Standardthemes liegen GitHub Dark Default (6,15) und Winter is Coming (Dark Blue) (6,44) beim Kommentar-Kontrast vorn.

Sind Themes mit „High Contrast” im Namen barrierefrei?

Nicht zuverlässig. Von 21 Themes mit „High Contrast” oder „HC” im Namen erfüllen 18 die WCAG-AA-Anforderung bei Kommentaren nicht. Das extremste Beispiel ist Material Theme Lighter High Contrast mit einem Grundkontrast von 2,59 — dem niedrigsten Wert unserer gesamten Messreihe. Der Name ist kein Prüfsiegel.

Wie erstelle ich ein eigenes VS Code Theme?

Es genügen zwei Dateien: eine package.json mit einem contributes.themes-Eintrag und eine JSON-Datei mit den Blöcken colors (Oberfläche) und tokenColors (Quelltext). Danach vsce package ausführen. Unser vollständiges Beispiel-Theme ist 2.124 Byte groß und kommt ohne Build-Prozess, Framework oder JavaScript aus.

Prüft vsce meine Farbwerte?

Nein. Wir haben fünf verschiedene Farbdefekte eingebaut — ungültige Farbnamen, unmögliche Hex-Werte, einen Tippfehler im Schlüsselnamen und ein Theme mit Kontrast 1,00 — und alle fünf wurden ohne Fehler oder Warnung paketiert. vsce prüft die Struktur des Manifests, nicht den Inhalt des Themes. Sogar ein Verweis auf eine nicht existierende Theme-Datei wird durchgewinkt.

Was ist der Unterschied zwischen colors und tokenColors?

colors färbt die Oberfläche von VS Code — Editor-Hintergrund, Seitenleiste, Statusleiste — und verwendet feste Schlüssel wie editor.background. tokenColors färbt den Quelltext selbst und arbeitet mit TextMate-Scopes wie comment oder entity.name.function. Wer eine Farbe vermisst, sucht meist im falschen der beiden Blöcke.

Wie viele Farbschlüssel kennt VS Code?

Im Quellcode von microsoft/vscode (Stand 1.137.0) finden sich 964 Aufrufe von registerColor(), die 843 eindeutige Farb-IDs ergeben. Man muss sie nicht alle setzen: Der Median unserer gemessenen Themes liegt bei 237 gesetzten Schlüsseln, das Minimum bei 22. Alles Nichtgesetzte übernimmt die Standardfarbe des gewählten uiTheme.

Kann ich nur eine einzelne Farbe eines Themes ändern?

Ja, über workbench.colorCustomizations (Oberfläche) und editor.tokenColorCustomizations (Quelltext) in der settings.json. Mit dem Themenamen in eckigen Klammern gilt die Anpassung nur für dieses eine Theme. Das ist der praktischste Weg, um etwa einen zu schwachen Kommentar-Kontrast zu reparieren, ohne das Theme zu wechseln.

Warum sind Kommentare in fast allen Themes so blass?

Das ist eine bewusste Designentscheidung: Kommentare sollen den Code optisch nicht überlagern. In unserer Messung liegt der Median bei 2,95 — deutlich unter dem AA-Schwellwert von 4,5, bei 86 % der Themes. Die Annahme dahinter („Kommentare sind sekundär”) trägt aber nicht, sobald jemand fremden Code liest oder eine Sehschwäche hat.

Sind helle Themes besser lesbar als dunkle?

Nach unseren Daten nein. Der Median-Kommentarkontrast liegt bei dunklen Themes bei 3,05, bei hellen bei 2,83. Der Anteil unterhalb von WCAG AA ist bei hellen Themes nur wenig geringer (76 % gegenüber 89 %). Die Farbwahl des Autors entscheidet, nicht die Grundhelligkeit.

Wie finde ich heraus, welcher Scope unter meinem Cursor liegt?

Über die Befehlspalette mit Developer: Inspect Editor Tokens and Scopes. Der Befehl zeigt den TextMate-Scope an der Cursorposition und zusätzlich, welche Theme-Regel gerade greift — die schnellste Methode, um gezielt eine einzelne Farbe zu ändern.

Fazit

Die Themes-Kategorie des VS-Code-Marketplace ist größer und leerer, als sie aussieht: 18.420 Einträge, von denen 500 praktisch den gesamten Gebrauch abdecken, zwei Drittel seit Jahren nicht aktualisiert, und eine Rangliste, die sich aus Selbstauskünften speist — mit einem Scherzpaket ohne Inhalt auf Platz 10.

Der eigentliche Befund liegt aber tiefer. Bei 86 % der gemessenen Themes ist die Kommentarfarbe nach WCAG nicht ausreichend lesbar, und ausgerechnet die Themes, die „High Contrast” heißen, gehören mehrheitlich dazu. Das ist kein Versehen einzelner Autoren, sondern eine strukturelle Lücke: Nichts im Werkzeugkasten prüft es. vsce hat in unserem Rot-Test kein einziges von fünf Farbproblemen gemeldet — nicht einmal ein Theme mit Kontrast 1,00 oder eine fehlende Theme-Datei.

Daraus folgen drei praktische Dinge:

1. Miss dein aktuelles Theme. Zehn Zeilen Python, zwei Minuten. Die Wahrscheinlichkeit, dass der Kommentarwert durchfällt, liegt bei 86 %.
2. Repariere statt zu wechseln. Drei Zeilen in settings.json heben eine einzelne Farbe über die Schwelle, ohne den Look aufzugeben.
3. Wenn du selbst eins baust: Der Bau dauert zehn Minuten und ergibt 2 KB. Die Kontrastprüfung ist der Teil, der es von den 86 % unterscheidet — und den musst du selbst machen, weil es sonst niemand tut.

Ein Theme ist kein Dekorationsobjekt. Es ist die Oberfläche, auf die man den ganzen Arbeitstag schaut. Es einmal nachzumessen, ist der Aufwand wert.

---

Weiterlesen:

• Firefox Themes: Finden, installieren und selbst bauen — dieselbe Untersuchung für den Browser, mit einem sehr ähnlichen Ergebnis beim offiziellen Prüfwerkzeug
• TypeScript lernen: Der ehrliche Einstieg — für alle, die im Editor mehr als die Farben ändern wollen
• Open-Source-Webbrowser im Vergleich — warum „Open Source” als Auswahlkriterium wenig taugt
• Was ist eine .md-Datei? — Markdown-Grundlagen, inklusive unseres kostenlosen Generators