Lab

Dark-only und eine H1 aus rohen Zeichen: der Umbau dieser Site

pad.software ist jetzt das Labor der pad Software GmbH. Was beim Umbau technisch passiert ist und welche zwei Kontrast-Fehler Lighthouse nicht gefunden hätte.

Diese Site sah bis gestern aus wie eine ordentliche Broschüre: Pergamenttöne, Serifenschrift, Kupfer-Akzent, Light- und Dark-Mode. Jetzt ist sie dark-only, blau, und die Überschrift der Startseite setzt sich beim Laden aus rohen Zeichen zusammen. Der Grund steht im Footer: Diese Site ist unser Labor. Hier steht, was beim Umbau technisch passiert ist.

Ein Modus statt zwei

Der Light-Mode ist komplett weg: kein Toggle, kein Init-Script gegen das Aufblitzen der falschen Farbe, keine doppelte Palette. Die gesamte Farbwelt sind dreizehn OKLCH-Tokens in einer Tailwind-@theme-Definition. OKLCH deshalb, weil die Helligkeitsachse perzeptuell gleichmäßig ist: Wer Kontraste rechnen will, will eine Skala, auf der 0,04 Unterschied überall ungefähr gleich viel bedeutet.

Die H1 setzt sich zusammen

Der Startseiten-Hero würfelt Zeichen, bis die echte Überschrift steht. Etwa sechzig Zeilen Vanilla-TypeScript, kein Framework. Drei Details, die den Unterschied zwischen Effekt und Ärgernis machen:

  • Ohne JavaScript steht der Text. Das Skript zerlegt die fertige H1 erst zur Laufzeit. Wer mit deaktiviertem JS kommt (oder eine Suchmaschine ist), sieht die Überschrift sofort.
  • prefers-reduced-motion beendet die Sache, bevor sie anfängt — ein Early Return in Zeile eins der Funktion.
  • Die Breite jedes Zeichens wird vor dem Würfeln festgenagelt, sonst zittert die Zeile bei jedem Frame, weil W breiter ist als i.

Für Screenreader bekommt die H1 ein aria-label mit dem finalen Text, die animierten Spans sind aria-hidden.

Zwei Fehler, die Lighthouse nicht findet

Der Umbau endete mit Lighthouse 100/100/100/100 auf der Startseite. Trotzdem steckten zwei echte Kontrastfehler drin, beide außerhalb dessen, was das Werkzeug misst:

  1. Lighthouse prüft keine Hover-Zustände. Unsere schwächste Textfarbe stand auf Karten, die beim Hover heller werden. Gegen die Grundfläche: bestanden. Gegen die Hover-Fläche: 4,28 : 1, unter der AA-Grenze von 4,5 : 1. Aufgefallen ist es erst beim Nachrechnen aller Flächen-Kombinationen.
  2. Die hellste Fläche ist der Worst Case, nicht die dunkelste. In einem dunklen Theme ist „angehoben” gleich „heller”. Wer Kontraste nur gegen den Seitengrund prüft, prüft die falsche Fläche.

Beide Werte stehen jetzt als Kommentar neben dem Token in der CSS-Datei, damit der nächste Umbau sie nicht wieder verliert.

Strichbilder statt Stock-Fotos

Seit dem Umbau trägt jede Seite eine Blueprint-Strichzeichnung im Hintergrund: unser Maskottchen und sein Blechroboter beim Mauern, am Schaltpult, am Fließband, im Archiv. Die Motive sind KI-generiert (mit einem bestehenden Motiv als Stil-Referenz, sonst driften die Figuren ab), aber der interessante Teil ist die Einbindung:

  • Der Bildhintergrund ist buchstäblich die Seitenfarbe. Die Renders kommen nie mit exakt dem Seitengrund zurück. Statt den Farbwert ins Bild zu brennen, wird der Grund per Pegel-Korrektur auf echtes Schwarz gezogen und das Bild mit mix-blend-mode: lighten eingebunden. Schwarz ist für lighten neutral: Der Hintergrund verschwindet in dem, was darunter liegt, und zieht automatisch mit, falls sich die Seitenfarbe je ändert.
  • Linienhelligkeit wird gemessen, nicht geschätzt. Die Renders schwanken um ±25 Prozent. Bei identischer CSS-Opacity wirken die Motive dann unterschiedlich kräftig. Deshalb hat jedes Bild vor dem Einbau denselben Helligkeits-Anker bekommen (99. Luminanz-Perzentil ≈ 150), per Skript nachgemessen statt nach Augenmaß.
  • Eine Falle beim Messen: sharp cached dekodierte Dateien nach Pfad. Wer in einer Schleife dieselbe Ausgabedatei schreibt und wieder einliest, misst dreimal denselben stalen Wert und hält jeden Gain für wirkungslos. Abhilfe: sharp.cache(false) vor der Messschleife.

Die Footer-Zeile „Gebaut aus Tokens, nicht aus Stock-Fotos” stimmt damit schärfer als je: Die Bilder sind eigene, und ihr Hintergrund ist ein Token.

Was daraus geworden ist

Die Kernseiten haben inzwischen ihre eigenen Mechanismen: eine durchsteppbare Prüfstrecke, eine scroll-getriebene Erzählung, ein Terminal. Was dabei an Technik anfällt, landet hier im Journal. Wo es geht, läuft es im Beitrag statt als Screenshot.

Gebaut aus Tokens, nicht aus Stock-Fotos. Keine Cookies an Bord.