Zum Inhalt springen
Entwurf für Computer Futures · Burak Karaman · 28.10.2026 Projekt 3063041 · CMS Consultant / Template Development

Template-Probe für Projekt 3063041 · Verwaltungsportal

Vom Design-Guide bis zum Release.

Die Leistungsseite eines fiktiven Verwaltungsportals: HTML5, CSS3, JavaScript und Bootstrap 5, barrierearm gebaut, mit Design-Guide, Release und Installationsanleitung.

Template live öffnen Die Anzeige, Punkt für Punkt

Verfügbar ab 01.02.2027 · Vollzeit · remote

Das Template am Rechner: Kopf der fiktiven Stadt Musterstadt mit Servicezeile (Leichte Sprache, Gebärdensprache), Suche und Hauptnavigation, darunter die Leistungsseite „Wohnsitz anmelden“ mit Seitenleiste. Der Tastaturfokus liegt gelb hinterlegt auf „Leben & Wohnen“.
Dieselbe Seite am Handy mit 390 Pixel Breite: Menü-Knopf, Suche und Inhalt untereinander, ohne waagerechtes Scrollen.
Barrierefreiheit28.10.2026
0Verstöße

WCAG 2.1 A + AA
8 automatische Prüfläufe

Anforderungs-Landkarte

Projekt 3063041, Punkt für Punkt.

14 Aufgaben und Anforderungen aus der Anzeige, geordnet danach, wo Sie den Beleg sehen. Zuerst das, was Sie sofort anklicken können.

Im Muster zu sehen7 Punkte

  • Entwicklung mit HTML5, CSS3, JavaScript und Bootstrap 5

    HTML5 mit Landmarken, Theme über CSS-Variablen, Formularprüfung in reinem JavaScript. Bootstrap 5.3.8 liegt lokal und bleibt unverändert.

    Template live

  • Entwicklung und Pflege von Design-Guides

    Farb-Token mit nachgerechneten Kontrasten, Schriftstufen, Abstände im 4er-Raster und Fokusstil in einer Theme-Datei, dazu Regeln für die Redaktion.

    Design-Guide

  • Erstellung und Weiterentwicklung von Templates

    Seitenvorlage „Leistung“ aus fünf Vorlagenteilen und sechs Bausteinen. Beim aktuellen Kunden bisher 137 Bildschirmseiten bearbeitet, in sieben Prototyp-Produkten.

    Template live

  • Umsetzung von BITV- und Usability-Anforderungen

    Nach WCAG 2.1 AA aufgebaut und automatisch geprüft, 0 Verstöße in 8 Läufen. Sprunglink, sichtbarer Fokus, Fehlerliste, Reflow bei 320 px; Erklärung zur Barrierefreiheit, „Barriere melden“, Leichte Sprache und Gebärdensprache sind verlinkt, in der Probe noch als Platzhalter.

    Prüfung

  • Pflege und Weiterentwicklung von Plugins

    Eigener JavaScript-Baustein für die Formularprüfung, eingebunden über ein data-Attribut. In WordPress: Kontaktformulare eines Herstellers von Bildcode auf Cloudflare Turnstile umgestellt.

    Bausteine

  • Erstellung von Releases und Installationsanleitungen

    Release v1.0.0 mit Änderungsprotokoll und Installationsanleitung für Redaktion und Betrieb, beide liegen dem Template als Datei bei.

    Release v1.0.0

  • Beratung von Redaktion und Betriebsteams

    Regeln für die Redaktion im Design-Guide, Anleitung für den Betrieb. Dazu ein zwölfseitiger Bericht aus 522 Suchbegriffen für einen Gesundheits-Blog und über vier Jahre Coaching und Training von Teams.

    Regeln für die Redaktion

Aus Kundenprojekten5 Punkte

  • Versionsverwaltung mit Git

    Im Repository des aktuellen Kunden läuft jede meiner Änderungen als Pull Request mit grüner Pipeline: 85 seit dem 03.09.2026, 84 davon gemergt.

    Arbeitsweise

  • Ticketbearbeitung mit Jira

    Im Jira des aktuellen Kunden, Zugang seit 15.10.2026: ein Bug-Ticket samt Akzeptanzkriterien und Skizzen eingeschätzt, als klickbare Lösungsseite umgesetzt und nach Rückmeldung in weiteren Fassungen geliefert.

    Zeitleiste

  • Unterstützung bei CMS-Migrationen

    Für einen Hersteller über 1.000 alte Adressen aus früheren Website-Umbauten geprüft. 375 davon führen jetzt in einem Schritt zum richtigen Ziel.

    CMS-Praxis

  • Fehleranalyse im 2nd-Level-Support

    In WordPress: technische Prüfung und Fehlerbehebung einer zweisprachigen Website mit WPML und Elementor Pro, mit Vorher-Nachher-Messung. Dazu Eskalationsmanagement als Teamleiter im Kundenservice.

    CMS-Praxis

  • Fachliche CMS-Administration oder CMS-Beratung

    WordPress-Betreuung eines Gesundheits-Blogs seit August 2026, mit Elementor Pro, Newsletter und Search Console. Beim Hersteller liegt seit Oktober die monatliche Betreuung bei mir.

    CMS-Praxis

Aus dem Lebenslauf2 Punkte

  • Schnittstelle zwischen Fachbereichen, Redaktion und Betrieb

    Über vier Jahre Teamleitung mit Teams bis 15 Leute, im Vertrieb erster Ansprechpartner für fachliche und operative Fragen, das letzte Team vollständig aus dem Homeoffice geführt.

  • Deutsch auf mindestens C1-Niveau

    Deutsch ist meine Muttersprache.

Barrierefreiheit · automatische Prüfung

Barrierearm gebaut, offen geprüft.

axe-core lief per Playwright über das Template, in vier Breiten und in den Zuständen, die beim Bedienen entstehen. Dazu ein vollständiger Tastaturdurchlauf.

0

Verstöße in 8 Prüfläufen nach WCAG 2.1 A und AAund 0 in 4 weiteren Läufen mit den Best-Practice-Regeln von axe

axe-core 4.14.0 · Playwright 1.64.0 · Chromium 156.0.8078.4
gemessen am 28.10.2026 um 09:55 Uhr

  • 4 Breiten1440, 768, 390 und 320 px, jeweils ohne waagerechtes Scrollen
  • 3 ZuständeAkkordeon offen, Handy-Menü offen, Formular mit Fehlermeldungen
  • 33 von 33Tab-Halten am Rechner erreicht, am Handy 29 von 29, Fokus jedes Mal sichtbar
  • 0 Fehlerin der Konsole, keine einzige Anfrage an fremde Server

Eine Stelle meldet axe zur Sichtprüfung: Beim Auswahlfeld „Tageszeit“ kann axe den Hintergrund wegen der Pfeil-Grafik nicht bestimmen, nachgerechnet hat der Text dort 16,91 : 1. Automatische Tests finden nicht jede Barriere, zur Abnahme gehört zusätzlich eine manuelle Prüfung mit Tastatur und Screenreader.

  • Leer abgeschicktes Terminformular: oben eine fokussierte Fehlerliste „Bitte prüfen Sie 4 Angaben“ mit vier Links, darunter die Felder mit roter Markierung und Meldung.
    WCAG 3.3.1 · 3.3.3

    Formular mit Fehlerliste

    Liste mit Sprungmarken über dem Formular, Meldung am Feld, der Seitentitel beginnt mit „Fehler:“.

  • Hauptnavigation mit Tastaturfokus auf „Leben & Wohnen“: gelber Hintergrund, dunkler Text, dunkle Unterkante.
    WCAG 2.4.7

    Fokus, sofort sichtbar

    Gelb mit dunkler Kante, auf hellem und dunklem Grund. Er erscheint ohne Überblendung.

  • Servicezeile mit den Links „Leichte Sprache“, „Gebärdensprache“ und „Kontakt“, der Fokus liegt auf „Gebärdensprache“.
    BITV 2.0

    BITV-Pflichtangaben, auf jeder Seite verlinkt

    Im Kopf Leichte Sprache und Gebärdensprache, im Fuß die Erklärung zur Barrierefreiheit und „Barriere melden“. In der Probe führen die Links auf Platzhalter.

Außerdem im Template: Sprunglink (WCAG 2.4.1) · Akkordeon mit ARIA (4.1.2) · Reflow bei 320 px (1.4.10)

Alle 12 Prüfläufe ansehenmit Rohdaten: pruefung/ergebnis.json und pruefung/roh/
Alle automatischen Prüfläufe
Nr.ZustandBreiteRegelnVerstößebestandenzur SichtprüfungRohdatei
1Grundzustand1440 pxWCAG 2.1 A + AA0281axe_grundzustand_1440.json
2Grundzustand768 pxWCAG 2.1 A + AA0281axe_grundzustand_768.json
3Grundzustand390 pxWCAG 2.1 A + AA0281axe_grundzustand_390.json
4Grundzustand320 pxWCAG 2.1 A + AA0281axe_grundzustand_320.json
5Akkordeon offen1440 pxWCAG 2.1 A + AA0291axe_akkordeon-offen_1440.json
6Formular mit Fehlern1440 pxWCAG 2.1 A + AA0291axe_formular-fehler_1440.json
7Handy-Menü offen390 pxWCAG 2.1 A + AA0291axe_menue-offen_390.json
8Formular mit Fehlern390 pxWCAG 2.1 A + AA0291axe_formular-fehler_390.json
9Best-Practice-Regeln1440 pxBest Practice0170axe_best-practice_1440.json
10Best-Practice-Regeln768 pxBest Practice0170axe_best-practice_768.json
11Best-Practice-Regeln390 pxBest Practice0170axe_best-practice_390.json
12Best-Practice-Regeln320 pxBest Practice0170axe_best-practice_320.json

Tastatur am Rechner (1440 px): 33 von 33 Halten erreicht, Fokus 33-mal sichtbar. Am Handy (390 px): 29 von 29. Sprunglink: erster Halt, Enter führt zu #inhalt. Akkordeon: Enter öffnet ja, Leertaste schließt ja. Formular leer abgeschickt: 4 Meldungen, Fehlerliste fokussiert ja, Seitentitel „Fehler: …“.

Reflow: 1440 px: kein waagerechtes Scrollen · 768 px: kein waagerechtes Scrollen · 390 px: kein waagerechtes Scrollen · 320 px: kein waagerechtes Scrollen. Konsole: 0 Meldungen. Fremde Anfragen: 0.

Zusammenfassung: pruefung/ergebnis.json

Design-Guide

Der Design-Guide steckt im Code.

Alle Werte stehen als Token in einer Theme-Datei, abgebildet auf die CSS-Variablen von Bootstrap. Bootstrap bleibt unverändert, ein Update heißt: Dateien tauschen.

Gleiche Bootstrap-Dateien, anderes Ergebnis

Eingabefeld mit Tastaturfokus, auf Weiß

  • Kontrast auf WeißStandardTheme
  • Feldrahmen1,30 : 14,89 : 1
  • Fokus1,41 : 119,59 : 1
  • Linkfarbe4,50 : 17,84 : 1

WCAG 2.1 verlangt für Rahmen und Fokus von Bedienelementen 3 : 1 (1.4.11), für Text 4,5 : 1 (1.4.3). Selbst nachgerechnet mit der WCAG-Formel für relative Leuchtdichte; beim Fokus des Themes zählt die dunkle Kante.

  • #1a1d21
    Text16,91 : 1auf Weiß · Fließtext
  • #47505b
    Text leise8,18 : 1auf Weiß · Hinweise
  • #0b5394
    Blau 7007,84 : 1auf Weiß · Links, Knöpfe
  • #0b2a4a
    Blau 90014,54 : 1Weiß darauf · Navigation
  • #b42318
    Fehler6,57 : 1auf Weiß · Meldungen
  • #1d6b3d
    Erfolg6,52 : 1auf Weiß · Bestätigung
  • #68727d
    Feldrahmen4,89 : 1auf Weiß · verlangt 3 : 1
  • #ffd400
    Fokus10,16 : 1Gelb auf Blau 900

Schrift und Abstände

  • H1Wohnsitz anmelden32–44 px
  • H2So gehen Sie vor24–30 px
  • H3Termin anfragen18 px, im Akkordeon 17 px
  • TextInter, lokal eingebunden, Zeilenhöhe 1,618 px

Abstände im 4er-Raster: 4 · 8 · 16 · 24 · 32 · 48 · 64 px

Regeln für die Redaktion

  1. Eine H1 je Seite, Überschriften ohne Sprung in der Ebene.
  2. Linktexte sagen, wohin sie führen. „Hier klicken“ gibt es nicht.
  3. Frist, Kosten, Ort und Termin stehen im Block „Auf einen Blick“.
  4. Pflichtfelder nennt der Text, Fehlermeldungen sagen, was zu tun ist.
  5. Jedes Bild bekommt einen Alternativtext, der sagt, was zu sehen ist.
Alle Kontrastwerte ansehenToken des Themes und Bootstrap-Standard zum Vergleich, selbst nachgerechnet
Kontraste der Theme-Token
PaarVordergrundHintergrundKontrastverlangtErgebnis
Text auf Weiß#1a1d21#ffffff16,91 : 14,5 : 1erfüllt
Text leise auf Weiß#47505b#ffffff8,18 : 14,5 : 1erfüllt
Text leise auf Grau 50#47505b#f3f5f77,49 : 14,5 : 1erfüllt
Blau 700 auf Weiß (Links)#0b5394#ffffff7,84 : 14,5 : 1erfüllt
Blau 700 auf Blau 50 (Hinweis-Kasten)#0b5394#eaf1f86,88 : 14,5 : 1erfüllt
Weiß auf Blau 700 (Knopf)#ffffff#0b53947,84 : 14,5 : 1erfüllt
Weiß auf Blau 900 (Fuß)#ffffff#0b2a4a14,54 : 14,5 : 1erfüllt
Navigationstext auf Blau 900#dfe8f2#0b2a4a11,74 : 14,5 : 1erfüllt
Fehler auf Weiß#b42318#ffffff6,57 : 14,5 : 1erfüllt
Erfolg auf Weiß#1d6b3d#ffffff6,52 : 14,5 : 1erfüllt
Musterband: Text auf Hellgelb#3d3200#fff4c211,47 : 14,5 : 1erfüllt
Feldrahmen auf Weiß#68727d#ffffff4,89 : 13 : 1erfüllt
Fokus: dunkle Kante auf Weiß#0b0c0c#ffffff19,59 : 13 : 1erfüllt
Fokus: Gelb auf Blau 900#ffd400#0b2a4a10,16 : 13 : 1erfüllt
Fokus: Gelb auf Blau 700#ffd400#0b53945,48 : 13 : 1erfüllt
Text auf Grau 50 (Formular)#1a1d21#f3f5f715,48 : 14,5 : 1erfüllt
Blau 700 auf Grau 50 (Brotkrumen)#0b5394#f3f5f77,17 : 14,5 : 1erfüllt
Text auf Blau 50 (Hinweis-Kasten)#1a1d21#eaf1f814,85 : 14,5 : 1erfüllt
Fehler auf Grau 50 (Formular)#b42318#f3f5f76,02 : 14,5 : 1erfüllt
Feldrahmen auf Grau 50 (Formular)#68727d#f3f5f74,48 : 13 : 1erfüllt

Bootstrap 5.3.8, Standardwerte zum Vergleich

Kontraste der Bootstrap-Standardwerte
PaarVordergrundHintergrundKontrastverlangtErgebnis
Link auf Weiß#0d6efd#ffffff4,50 : 14,5 : 1erfüllt
Weiß auf Primärblau#ffffff#0d6efd4,50 : 14,5 : 1erfüllt
Feldrahmen auf Weiß#dee2e6#ffffff1,30 : 13 : 1zu schwach
Fokusring auf Weiß (25 % Deckkraft)#c3dbff#ffffff1,41 : 13 : 1zu schwach
Sekundärtext auf Weiß (75 % Deckkraft)#595c5f#ffffff6,73 : 14,5 : 1erfüllt
Fehlerrot auf Weiß#dc3545#ffffff4,53 : 14,5 : 1erfüllt

Methode: WCAG 2.1 relative Leuchtdichte, (L1+0.05)/(L2+0.05); Alpha-Farben vorher auf den Hintergrund gerechnet. Rohdatei: pruefung/kontraste.json

Release und Installation

Release v1.0.0, mit Anleitung.

Zu jeder Fassung gehören ein Änderungsprotokoll und eine Installationsanleitung. Beide liegen dem Template als Datei bei: CHANGELOG.md und INSTALLATION.md.

muster/CHANGELOG.mdv1.0.0

Änderungsprotokoll

v1.0.0 · 28.10.2026 · erste Fassung

Neu

  • Seitenvorlage „Leistung“ aus fünf Vorlagenteilen: Kopf, Brotkrumen, Inhalt, Seitenleiste, Fuß
  • Theme-Datei mit Design-Token, Bootstrap 5.3.8 unverändert
  • Baustein Formularprüfung mit Fehlerliste

Geprüft

  • axe-core 4.14.0, WCAG 2.1 A und AA: 0 Verstöße in 8 Läufen
  • Tastatur 33 von 33 Halten, kein waagerechtes Scrollen bis 320 px

Bekannt

  • Leichte Sprache, Gebärdensprache, Erklärung zur Barrierefreiheit und „Barriere melden“ sind Platzhalter
  • Zur Abnahme: manuelle Prüfung mit Screenreader
muster/INSTALLATION.mdv1.0.0

Installation

für Redaktion und Betrieb · ohne Build-Schritt

  1. Ordner assets/ neben die Seitenvorlage legen.
  2. Im Kopf einbinden, das Theme nach Bootstrap:
<link rel="stylesheet" href="assets/bootstrap/bootstrap.min.css">
<link rel="stylesheet" href="assets/css/musterstadt.css">
<script src="assets/bootstrap/bootstrap.bundle.min.js" defer></script>
<script src="assets/js/musterstadt.js" defer></script>
  1. Die fünf Vorlagenteile ins CMS übernehmen, im Code als Kommentar markiert.
  2. Anpassen nur über die Token, neue Farben vorher nachrechnen.
  3. Bootstrap-Update: Dateien tauschen, Theme bleibt, Prüfung wiederholen.

Arbeitsweise

So arbeite ich beim aktuellen Kunden.

Seit September für einen Anbieter von Software für Rechnungs- und Belegmanagement: klickbare Prototypen neuer Programmmodule in reinem HTML, CSS und JavaScript, ohne Build-Schritt, im Design-System des Kunden, auf Deutsch und Englisch.

Git · Pull Requests

Jede Änderung im Repository als Pull Request

85seit 03.09.2026

84 davon gemergt, jeder mit grüner Pipeline. Vorher prüfe ich zusätzlich mit eigenen Browser-Tests in Playwright.

85
Jira · Ticketbearbeitung

Vom Ticket zur klickbaren Lösung

Ein Bug-Ticket des Kunden, mit Akzeptanzkriterien und Skizzen: Tooltips sollten sich je nach Lage im Fenster dynamisch ausrichten.

  1. 14.10.2026Ticket, Akzeptanzkriterien und Skizzen gelesen, Einschätzung geschrieben
  2. 15.10.2026Zugang zum Jira des Kunden, vom Team des Kunden beantragt
  3. 15. und 16.10.2026Klickbare Lösungsseite gebaut und geliefert: drei Designvarianten, neun Positionen
  4. bis 21.10.2026Weitere Fassungen nach Rückmeldung des Teams
Templates · Design-System

Im Design-System des Kunden

137bearbeitete Bildschirmseiten
7Prototyp-Produkte
über 300eigene Commits im Hauptzweig
2Sprachen: Deutsch und Englisch

Reines HTML, CSS und JavaScript ohne Build-Schritt, eng an den Vorgaben des Kunden.

CMS-Praxis · WordPress

Betreuung, Fehleranalyse, Adressen-Umzug

Für einen Hersteller aus der Produktfotografie: technische Prüfung und Fehlerbehebung einer zweisprachigen WordPress-Website mit WPML und Elementor Pro, mit Vorher-Nachher-Messung. Seit Oktober liegt die monatliche Betreuung bei mir. Dazu die WordPress-Betreuung eines Gesundheits-Blogs seit August 2026.

über 1.000alte Adressen aus früheren Website-Umbauten geprüft
375führen jetzt in einem Schritt zum richtigen Ziel

„Unklare Zuordnungen wurden nicht einfach eigenmächtig umgesetzt, sondern vorher mit mir abgestimmt. Alles nachvollziehbar dokumentiert, inklusive Vorher-Nachher-Vergleich.“

Bewertung des Kunden zum Adressen-Auftrag · Hersteller aus der Produktfotografie

Nächster Schritt

Ab 1. Februar 2027 in Vollzeit dabei.

Remote, die Verlängerung auf bis zu vier Jahre ist mir ausdrücklich willkommen.

  1. JetztLebenslauf und diese Template-Probe liegen für das Kundenprofil bereit.
  2. Bis zum StartRückfragen beantworte ich innerhalb eines Werktags.
  3. Ab 01.02.2027Einstieg über Design-Guide und Templates des Kunden, dann die ersten Tickets.
Template live öffnen Die Anzeige, Punkt für Punkt
Burak Karaman Core Guard Karaman · Webentwicklung · Remscheid