Disziplinen 01 · Websites

Websites

Im Web treffen Design und Code für mich am unmittelbarsten aufeinander. In vollständigen Konzeptprojekten erkunde ich Struktur, Typografie, responsives Verhalten, Barrierefreiheit und Interaktion als ein System.

Form: Eine Seite oder fünf bis acht Sektionen. Die Methode bleibt dieselbe.
Vorgehen: Geplant, bevor es losgeht, iteriert unterwegs, fertiggestellt statt liegen gelassen.
Überarbeitungen: Iteriert in echten Runden, weil ein erster Entwurf selten das letzte Wort ist.
Barrierefreiheit: Vom ersten Commit an nach WCAG 2.1 AA gebaut, nicht als Durchgang am Ende.
Quellcode: Jeder Build besteht aus drei lesbaren Dateien — öffnen, ausführen und jede davon inspizieren.

01 · Was das ist

Eine Website, und was das Wort hier umfasst

Eine fertige, vollständige Website nach eigenem Entwurf, von Hand geschrieben. Kein gekauftes Template aus einem Marktplatz, kein Page-Builder — jede der zehn ist ein Projekt, das ich mir selbst gestellt und von Anfang bis Ende durchgearbeitet habe.

Die meisten der zehn Builds auf dieser Website begannen mit derselben Frage: Wie sähe das aus, richtig gemacht? Ein Restaurant, eine Klinik, ein SaaS-Produkt — jedes eine Gelegenheit, ein echtes Problem von Anfang bis Ende durchzuarbeiten, selbst gestellt statt zugewiesen.

struktur

Semantisches HTML, gelesen, bevor es gesehen wird

Informationshierarchie und Inhalte, die ohne visuelle Effekte verständlich bleiben. Struktur, Design und Verhalten, in dieser Reihenfolge der Wichtigkeit.

layout

Komposition, die sich anpasst, statt nur zu schrumpfen

CSS Grid, Flexbox, fluide Typografie. Die Spalten brechen in einer Reihenfolge um, die ich festgelegt habe, und die schmalste Version ist gestaltet, nicht bloß überlebt.

performance

Die Seite ist benutzbar, bevor die Extras eintreffen

Unnötige Abhängigkeiten draußen halten, Medien mit Bedacht laden und verstehen, was der Browser tatsächlich tut.

barrierefreiheit

Jedes Bedienelement ohne Maus erreichbar

Fokusverhalten, Kontrast, semantisches Markup, ARIA wo nötig — Interfaces, die nicht von Animation abhängen. Von Hand durchlaufen, Taste für Taste.

interaktion

Navigation, Formulare und Bewegung, die benutzbar bleiben

Akkordeons, Galerien und Formulare, die mit der Tastatur bedienbar bleiben und reduzierte Bewegung respektieren.

experimente

Vanilla JS, und modernes Tooling, wo es seinen Platz verdient

Die meisten der zehn sind handgeschriebenes HTML, CSS und JavaScript. An anderer Stelle auf dieser Website arbeite ich auch mit React, Next.js und Vue — das Werkzeug folgt der Frage, nicht umgekehrt.

02 · Woraus ein Build besteht

Drei Dateien. Das ist die ganze Lieferung.

Keine Metapher und keine Vereinfachung. Jeder der zehn Builds im Portfolio besteht aus diesen drei Dateien plus seinen selbst gehosteten Schriften — öffnen Sie einen beliebigen davon und lesen Sie den Quellcode; nur deshalb ist dieser Absatz überhaupt etwas wert.

index.html struktur

script.js verhalten

index.html — der Inhalt und seine Reihenfolge. Überschriften, die eine Ebene nach der anderen absteigen, Landmarken, die bedeuten, was sie heißen, jedes Bedienelement ein echter Button oder ein echter Link. Das ist die Datei, die ein Screenreader liest und eine Suchmaschine indexiert — deshalb darf nichts Dekoratives darin wohnen.
styles.css — Farbe, Typografie, Abstände und Easing einmal oben als benannte Werte deklariert, dann überall verwendet. Ändern Sie acht davon, und die ganze Website wechselt die Stimmung. Wo ein Kontrastpaar knapp ist, steht das gemessene Verhältnis im Kommentar daneben.
script.js — so geschrieben, dass ein fehlendes Element ein No-op ist statt eines geworfenen Fehlers, und dass jede Animation zuerst fragt, ob Sie Ihrem Gerät gesagt haben, dass Sie weniger davon möchten. Die Seite funktioniert auch, wenn ein beliebiger Teil dieser Datei entfernt wird.

Das ist der Punkt an der Zahl Drei: Die nächste Person, die den Code anfasst, muss mich nicht kennen und muss kein Framework kennen, das ich zufällig gewählt habe.

03 · Worauf ich teste

Was zum Build gehört und was ich einem anderen Projekt überlasse

Beide Spalten sind absichtlich gleich groß. Zu wissen, wo die Grenzen eines Builds liegen, ist genauso eine Designentscheidung wie alles innerhalb davon.

Teil des Builds

Art Direction, gemacht für das Projekt, nicht aus einem Fünferset gewählt.
Texte, geschrieben passend zum Design, nicht nachträglich als Füllmaterial eingesetzt.
Jede Seite allein mit der Tastatur bedienbar, und genau so von Hand getestet.
Bewegung, die stoppt, wenn das Gerät des Besuchers es verlangt.
Ein Performance-Budget, am Anfang festgelegt und am Ende erneut gemessen.
Formulare mit echten Labels, und Fehler, die angesagt werden statt nur rot gefärbt zu sein.
Struktur, bereit für eine zweite Sprache, auch wo noch keine existiert.
Vollständiger Quellcode, lesbar von Anfang bis Ende.
Echte Iteration, kein erster Entwurf, der final genannt wird.

Außerhalb dieser Erkundung

Eigene Fotografie — wo ein Build sie braucht, wird sie separat beschafft oder lizenziert.
Komplettes Texten von Grund auf, im Gegensatz zum Strukturieren und Einpassen vorhandener Texte.
Übersetzung in eine andere Sprache.
Integrationen von Drittanbietern — ein Buchungssystem, ein CRM, ein Zahlungsanbieter — jede eine eigene Erkundung.
Laufende Inhaltsänderungen, sobald ein Build fertig ist.
Suchmaschinenoptimierung als eigene Disziplin.
Domain- und Hostingkosten sowie jede kostenpflichtige Schrift oder API.
Jede Aussage über Rankings, Traffic oder Conversion. Dies sind Konzept-Builds, keine gemessenen Kampagnen.

04 · Die Fragen

Beantwortet statt ausgewichen

Lässt sich eine solche Website bearbeiten, ohne Code anzufassen?

Standardmäßig nicht, und das sage ich lieber offen, als auszuweichen. Eine von Hand gebaute Website wird als Dateien ausgeliefert — einen Satz zu ändern heißt also, eine Datei zu bearbeiten.

Es gibt eine echte Antwort, die es zu erkunden lohnt: eine Bearbeitungsschicht über demselben statischen Build, sodass benannte Teile einer Website im Browser editierbar werden, ohne Code anzufassen. Das ist ein eigenes kleines System — ein Editor, ein Login, ein Deploy-Schritt — drei weitere bewegliche Teile, die man auf eigene Weise verstehen muss.

Warum drei Dateien von Hand schreiben, statt ein Framework zu benutzen?

Weil die Beschränkung der Punkt ist. Reines HTML, CSS und JavaScript zwingen jede Entscheidung, sichtbar zu sein — keine Abstraktion verbirgt, was eine Seite tatsächlich tut.

Es bedeutet auch, dass jeder — auch eine zukünftige Version von mir — die Dateien öffnen und genau lesen kann, was dort steht. Keine Abhängigkeit, die aktualisiert werden muss, kein Build-Schritt, der brechen kann, nichts zwischen dem Quellcode und dem Browser, der ihn liest.

Woher wissen Sie, dass ein Build tatsächlich barrierefrei ist?

Durch Prüfen — das dauert etwa neunzig Sekunden und braucht kein besonderes Werkzeug. Legen Sie die Maus weg, drücken Sie Tab und beobachten Sie, wohin die Umrandung wandert.

Der Maßstab hier ist gebaut nach WCAG 2.1 AA — eine Beschreibung, wie gearbeitet wird, kein Siegel, denn ein Siegel ist kein Audit. Was ich stattdessen anbieten kann, ist eine Messung dieser Website, mit Datum und Methode, sodass sie nachprüfbar ist statt auf Treu und Glauben genommen.

Gemessen auf dieser Website, 10. August 2026
axe‑core: 0 Verstöße über 23 Routen × 2 Viewports
Tastatur: 0 von 1,526 Tabstopps ohne sichtbaren Fokusindikator
Jeder Stopp mit echten Tastendrücken durchlaufen, das aktive Element nach jedem ausgelesen.

05 · Die Arbeit

Drei der zehn, gewählt für die Bandbreite

Alle zehn sind eigeninitiiert, alle zehn sind live, und zu jedem gibt es einen Bericht darüber, was es erreichen sollte und was sich gewehrt hat. Diese drei stehen hier, weil sie einander nicht im Geringsten ähneln. Sollte eines zufällig Ihre Branche sein, ist das ein Zufall und nicht der Grund, warum es auf dieser Seite steht.