Glossar

A11y ist die Kurzform von "Accessibility" (das "11" steht für die elf Buchstaben dazwischen). Webseiten sollen für alle nutzbar sein — auch für Menschen mit Sehbehinderung, motorischer Einschränkung oder Lese-Schwächen. WCAG ist der internationale Regelkatalog dazu. Seit dem BFSG (Juni 2025) ist Level AA in Deutschland für fast alle B2C-Webseiten Pflicht.

Am Ende jeder Wasserfall-Phase gibt der Kunde eine Freigabe — typisch per Mail oder Awork-Kommentar. Erst dann startet die nächste Phase. Wichtig, weil eine spätere Änderung an einer freigegebenen Phase einen neuen Durchlauf auslöst (mit neuem Vorlauf und ggf. Mehraufwand). Beispiel: "Konzept freigegeben am 12.4." — ab dann ist der Inhalt fix.

Wird von Screenreadern vorgelesen und von Suchmaschinen indiziert. Bei dekorativen Bildern (reine Optik): leerer Alt-Text (alt=""). Bei informativen Bildern: knapp beschreiben, was zu sehen ist und warum es da ist. Keine Dateinamen ("IMG_3429.jpg"), keine Wiederholung des sichtbaren Texts, kein "Bild von ...". Beispiel gut: alt="Mitarbeiter lächelt am Schreibtisch und tippt auf Laptop". Beispiel schlecht: alt="Bild".

ARIA = Accessible Rich Internet Applications. Mit aria-label, aria-expanded, role usw. teilen wir Screenreadern mit, was ein Element ist und in welchem Zustand. Goldene Regel: erst korrektes HTML (button, nav, h2 ...), dann ARIA nur wenn HTML allein nicht ausreicht. Falsches ARIA ist schlimmer als kein ARIA.

Astro ist eine moderne Sprache, in der Frontend HTML/CSS/JS-Vorlagen schreibt. Bei uns ist Astro reine Vorlage: das Backend übersetzt sie 1:1 in Fluid-Templates für TYPO3, und nur Fluid geht live. Astro ist Style-Guide und Source-of-Truth, kein Headless-CMS-Frontend.

Auftragsverarbeitungsvertrag. Pflicht, wenn ein Dienstleister personenbezogene Daten im Auftrag des Kunden verarbeitet — z.B. Hosting, E-Mail-Provider, Tracking-Tools. Liegt der AVV nicht vor, hat der Kunde ein DSGVO-Problem. Im Briefing prüfen, ob der AVV mit allen eingesetzten Diensten existiert.

Awork ist unser Projekt- und Ticket-Tool. Anfragen, Bugs, Features, Änderungen — alles wird als Ticket angelegt und an Renana adressiert. Renana priorisiert und ordnet ein. KEIN Slack-Pingen, KEINE direkten Mails an Devs, KEINE Teams-Chats für Tickets.

Im CP-Sprachgebrauch ist Backend nicht "API-Server", sondern unser TYPO3-Team (Chris, Lukas, Henri) plus Infrastruktur (Dragan, Klaus). Sie übersetzen Astro in Fluid, bauen TCA-Konfigurationen und kümmern sich um Server, Deployment und Domains.

Barrierefreiheitsstärkungsgesetz, die deutsche Umsetzung der EU-Richtlinie EAA. Macht WCAG 2.2 Level AA für fast alle B2C-Webseiten verpflichtend — Webshops, Buchungen, Bürgerportale, Banken, Reise. Verstöße können abgemahnt werden und kosten ab fünfstellig. Im Briefing fragen: Fällt das Projekt unter BFSG? In den meisten Fällen: ja.

Hero, Card-Grid, FAQ, CTA-Banner, Footer — jedes ist ein Block. In TYPO3 entspricht das einem Content-Element (CE). In der Werkstatt baust du eine Seite aus Blöcken zusammen, jede in der passenden Reihenfolge. Eine Landingpage besteht typisch aus 5–9 Blöcken.

Logo, Farben, Schriften, Bildsprache, Tonalität — alles, was eine Marke wiedererkennbar macht. Wird in einem Brand-Guide festgehalten. Im Frontend kommt die Brand-Identity über Design-Tokens und Style-Guide an. Änderungen am Brand sind nie "Schönheitsfehler" — immer eigenes Briefing.

Breiter als Fließtext (Standard 55rem) — typisch für Karten-Grids, Formulare und mittelgroße Bildblöcke. Inhalte mit class="breakout" erhalten diese maximale Breite zentriert.

Phase 1 des Wasserfall-Workflows. Renana sammelt vom Kunden Ziele, Inhalte, Beispiele, Termin-Erwartung. Ohne vollständiges Briefing keine Konzeption. Briefings, die mit "wir wissen es noch nicht so genau" enden, gehen zurück — das wird sonst später teuer.

Ein Bug ist eine Abweichung vom freigegebenen Soll-Zustand. Beispiel: Ein Filter zeigt keine Ergebnisse, ein Klick auf einen Button macht nichts, ein Bild ist verzerrt. KEIN Bug ist "der Kunde hätte gerne X anders" — das ist ein Feature-Request oder Change-Request.

Bugs werden über Awork an Renana gemeldet, sie ordnet ein. Bugfixes brauchen kein neues Konzept, können aber Vorlauf benötigen, wenn sie Backend-Releases erfordern. Nach dem Fix läuft Bug nochmal durch QS — Vier-Augen-Prinzip.

TYPO3 cached Seiten standardmäßig: einmal gerendert, dann für alle weiteren Besucher aus dem Cache geliefert. Änderungen werden erst sichtbar, wenn der Cache geleert ist (im Backend per Knopf oder automatisch über Nacht). Für Redakteure relevant: Änderung gespeichert ist nicht gleich live sichtbar.

Ein Standard-Block für Listen — Produkte, Services, Leistungen, Blog-Beiträge, Mitarbeiter-Profile. Hat Varianten (Standard, Mit Bild, Mit Tag, Bild + Tag). Cards leben fast immer in einem Card-Grid und passen sich der Container-Breite an.

Auto-Grid mit gleichmäßigen Spalten — typisch für "Produkte im Überblick", "Leistungen", "Team-Mitglieder" oder "Blog-Beiträge". Container-Query-basiert: passt sich der Breite des umschließenden Bereichs an, nicht dem Browserfenster. Drei Cards in 1100px-Breite, eine Card in 400px-Breite — alles automatisch.

Mit Vorsicht einsetzen: Carousels werden oft übersehen — Studien zeigen, dass kaum jemand über den ersten Slide hinausklickt. Nur einsetzen, wenn Reihenfolge sekundär ist und Platz wirklich knapp. Für Listen lieber Card-Grid — da sieht man alle auf einmal.

Statt aus einem Rechenzentrum kommen Bilder, Videos und Skripte aus dem geografisch nächsten Server. Spart Ladezeit für internationale Besucher und entlastet den Origin-Server. Beispiele: Cloudflare, AWS CloudFront. Nicht jedes Projekt braucht ein CDN; ab gewissem Traffic-Volumen oder für schwere Assets sinnvoll.

Anders als ein Bug (etwas ist kaputt) oder Feature (etwas Neues): ein Change-Request ändert etwas, was schon freigegeben war. Beispiel: "Doch lieber Hero ohne Bild statt mit". Löst typisch einen Mini-Wasserfall aus — Briefing der Änderung, Konzept-Anpassung, Umsetzung, neue Freigabe. Vorlauf einplanen.

Eine der drei Core Web Vitals. Misst, wie stark sich das Layout nach dem ersten Render noch verschiebt — z.B. wenn ein spät ladendes Bild Text wegschiebt oder ein Cookie-Banner einspringt. Ziel: unter 0.1. Akzeptabel: bis 0.25. Hohe Werte nerven die Nutzer und sind ein SEO-Faktor.

Software, mit der Redakteure Inhalte pflegen, ohne Code anzufassen. Wir nutzen TYPO3 klassisch — kein Headless. Frontend kommt aus Fluid-Templates, die das Backend aus den Astro-Vorlagen ableitet. Andere CMS sind WordPress, Drupal, Contentful — jedes hat eigene Logik.

Figma-Standard, der Designern direkt im Inspect-Panel den Code eines Components zeigt — ohne Plattform-Wechsel. Pro Component eine .figma.ts-Datei in unserem Repo, die den Astro-Code-Snippet liefert. Vorteil: Designer sehen, was es kostet, eine Variante zu nutzen; Frontend bekommt den Code aus Figma übernommen, statt ihn neu zu schreiben. Pflicht für alle Library-Components, die in Figma als Master existieren.

Eine Astro-Komponente mit Eingaben (Props), Platzhaltern (Slots) und eigenen Styles. Card, Button, Hero, FAQ-Item — alles Components. "Component" beschreibt auch Inline-Bausteine (Tag, Tooltip, Badge), während "Block" eher für ganze Inhaltsbausteine genutzt wird.

Liegt unter registry/components/<name>.json. Single Source of Truth für KI/CLI: Pflichtfelder sind name, category, description, files, dependencies, requiredTokens, useCases, editorialRules, relatedComponents, variants, a11yNotes. Ohne Manifest gibt es kein "cp-add", keine semantische Suche, keine Showcase-Generierung. Wer ein Component anlegt, ohne Manifest zu pflegen, hat das Component nicht fertig.

Eine Consent-Management-Plattform speichert pro Besucher, welchen Tracking- und Marketing-Diensten er zugestimmt hat — und blockiert die anderen. Beispiele: Usercentrics, Cookiebot, Borlabs Cookie. DSGVO-Pflicht, sobald nicht-essentielle Cookies eingesetzt werden. Ohne CMP kein Analytics, kein Marketing.

Mit @container reagiert eine Komponente auf die Breite ihres Eltern-Containers. Eine Card in einer 3-Spalten-Liste verhält sich anders als dieselbe Card in einer 1-Spalten-Sidebar — obwohl der Browser gleich breit ist. Wir nutzen Container Queries durchgängig für Auto-Grids, weil sie Layouts robust und wiederverwendbar machen.

Der Bereich zwischen globaler Navigation und Footer, in dem Blöcke gepflegt werden. Im Briefing ist "Content" alles, was Redakteure später selbst pflegen können. Header und Footer sind meist global und werden nicht pro Seite editiert.

Standard (55rem für Fließtext), .breakout (69rem für Karten-Grids), .wide-content (83rem für breite Bildgalerien), .full-width (100% für Hero-Banner), .no-grid (frei). Jeder Inhalt wählt seine Stufe per CSS-Klasse — Padding und Maximum-Width werden automatisch gesetzt. Sorgt für rhythmisches Lesen über alle Seiten hinweg.

Eine Conversion ist eine Zielhandlung: Newsletter-Anmeldung, Kontaktformular abgeschickt, Produkt gekauft, Termin gebucht. Conversion-Tracking misst, wo Besucher kommen und was sie machen — typisch über Google Analytics, Matomo oder Marketing-Tools. Datenschutz: nur mit Einwilligung über CMP.

Pflicht-Element, sobald nicht-essentielle Cookies (Analytics, Marketing, Embeds wie YouTube/Maps) gesetzt werden. Muss einfache Ablehnung gleichberechtigt zur Zustimmung anbieten — sonst DSGVO-Verstoß. "Alle akzeptieren" mit großem Knopf und "Ablehnen" versteckt im Kleingedruckten = abmahnfähig.

LCP (wie schnell ist das Wichtigste sichtbar), CLS (wie stabil ist das Layout), INP (wie schnell reagiert die Seite auf Klick/Tipp). Google nutzt sie als SEO-Faktor; Nutzer spüren sie sofort. Ziel: alle drei im grünen Bereich. Werden in Google Search Console und mit Tools wie Lighthouse gemessen.

Beispiele: "Newsletter abonnieren", "Termin vereinbaren", "Produkt entdecken", "Kontaktformular öffnen". Goldene Regeln: Verb plus Nutzen, max 5 Wörter, pro Section nur ein primärer CTA. Generisch ist schlecht ("Mehr erfahren", "Klick hier", "Jetzt loslegen") — konkret ist gut ("Demo buchen", "Probemonat starten").

Auf jeder öffentlichen Webseite verlinkt — typisch im Footer. Inhalt: welche personenbezogenen Daten werden erhoben (Server-Logs, Cookies, Formulare), zu welchem Zweck, wie lange gespeichert, an wen weitergegeben (z.B. Hosting-Anbieter), welche Rechte hat der Nutzer (Auskunft, Löschung). Wird typisch von Anwälten oder Generatoren wie eRecht24 erstellt.

Backend (Dragan/Klaus) deployt TYPO3-Änderungen typisch in festen Slots. Reine Inhalte-Änderungen brauchen kein Deployment — sie gehen sofort live (nach Cache-Leeren). Code-Änderungen erfordern einen Deployment-Slot, daher Vorlauf einplanen. Freitag = kein Deploy.

Mehr als ein Style-Guide: ein Design-System enthält Tokens (Farben, Spacings, Schriften), Components (Card, Hero, Button), Patterns (Section-Aufbauten) und Regeln (wann was eingesetzt wird). CP Registry IST ein Design-System für unsere Projekte. Änderungen am Design-System wirken sich auf alle abhängigen Auftritte aus.

Ein Token ist ein Name für einen Wert: --color-brand-primary für die Hauptfarbe, --spacing-md für einen Standard-Abstand, --text-h1 für die H1-Größe. Tokens sind Source-of-Truth: Tailwind-Klassen, CSS-Variablen, Figma-Variables und Backend-SCSS spiegeln dieselben Tokens. Ändert man den Token, ändert sich alles abhängige.

Bei uns: Lina (UI & Motion), Marc-Andre (Lead UI/UX). Designer arbeiten in Figma, definieren Tokens, Layouts, Komponenten und Microinteractions. Output: ein Design, das Frontend in Astro-Vorlagen übersetzt. Typische Phase: 3 (Design) im Wasserfall, mit FE-Abstimmung in Phase 4.

Gilt für alle Webseiten mit EU-Bezug. Relevant: Cookie-Banner, Formular-Datenschutz, Einbettungen wie YouTube oder Google Maps, Tracking-Tools. Verstöße sind teuer (bis 4% des weltweiten Jahresumsatzes oder 20 Mio. Euro). Im Briefing prüfen, welche Daten erhoben werden und ob ein AVV mit allen Dienstleistern besteht.

Im Standardfall: Anfrage geht über Awork an Renana. Wenn Renana nicht verfügbar ist oder eine strategische Entscheidung nötig wird: Eskalation an Hendrik (Geschäftsführung). Eskalation ist KEIN Erstkanal — sie soll Ausnahme bleiben, sonst verliert sie ihre Wirkung.

Block-Typ, der Restzweifel abfängt und den Verkaufs-/Conversion-Zyklus verkürzt. Typisch als Accordion (Antworten ein-/ausklappbar). Goldene Regel: 5–7 Fragen, sonst Listen-Fatigue. Fragen kurz halten, Antworten 2–4 Sätze. Fragen sollten echte Kunden-Fragen sein, nicht Marketing-Inszenierung.

Im Gegensatz zum Bug ist ein Feature-Request eine Erweiterung über den freigegebenen Stand hinaus. Lauft den vollen Phasen-Workflow durch: Briefing, Konzeption, Umsetzung, QS, Freigabe, ggf. Deployment. Auch "kleine Features" haben Vorlauf.

Lina, Marc-Andre und Hendrik arbeiten in Figma. Designs werden mit Tokens, Auto-Layout und Komponenten gebaut. Frontend übersetzt das in Astro-Vorlagen — die wiederum in Fluid-Templates übergehen. Figma-Variables und CSS-Tokens sollten denselben Namen tragen.

TYPO3-eigene Template-Engine mit ViewHelpern. Das Backend-Team übersetzt unsere Astro-Vorlagen in Fluid-Templates, die echte TYPO3-Datenfelder rendern. Nur Fluid geht live, nie Astro selbst. Schnittstellen-Definitionen klären, welche Daten und Klassen 1:1 übertragen werden.

Wenn Nutzer per Tab-Taste durch eine Seite navigieren, müssen sie sehen, wo sie gerade sind — typisch ein farbiger Rand oder Schatten. WCAG fordert mindestens 2px Dicke und 3:1 Kontrast zur Umgebung. Das berüchtigte outline:0 ohne Ersatz ist Hard-Block: dann ist die Seite nicht keyboard-bedienbar.

Frontend ist beides: das Team (Brandon und Marc-Andre als Lead), das Astro-Vorlagen baut, UND der ausgelieferte Code in Form von HTML, CSS und JavaScript. Live geht der Output über Fluid-Templates raus — Astro selbst nicht.

Tickets via Awork an Renana. Online ist nicht gleich fertig (Phase 9: Pflege). Briefing vor Konzeption, Konzeption vor Umsetzung. Vorlaufzeit beachten. Eskalation nur über Hendrik. Bug schlägt Deadline schlägt Feature. Freitag kein Deploy. Diese Regeln sind nicht Empfehlung, sondern Operating-Modell.

Pro Seite genau ein H1, dann H2 für Hauptbereiche, H3 für Untertopics, H4 wenn noch tiefer. Keine Sprünge (H1 direkt zu H3 — verboten). Screenreader navigieren primär über Headings; eine kaputte Hierarchie ist wie ein zerrissenes Inhaltsverzeichnis. Auch für SEO wichtig: Google liest die Hierarchie als Inhaltsstruktur.

Die Eintrittsstelle einer Landingpage oder Hub-Seite. Aufgabe: in den ersten 3 Sekunden klar machen, worum es geht und was als nächstes zu tun ist. Standard-Aufbau: kurze Headline (max 8 Wörter), 1–2 Sätze Erklärung, ein Haupt-CTA. Bild oder Video optional. Hero ohne CTA ist eine Visitenkarte, kein Hero.

CSS hyphens:auto sorgt für saubere Umbrüche bei langen Komposita ("Auftragsverarbeitungsvertrag", "Datenschutzerklärung"). Wichtig auf schmalen Spalten und mobilen Geräten — sonst sprengen lange Wörter das Layout oder werden abgeschnitten.

Icons stammen typisch aus einem Set (z.B. lucide). Strichstärke und Stil dürfen nicht gemischt werden — ein Set pro Auftritt. Icons begleiten Text, ersetzen ihn nicht: Screenreader interpretieren reine Icons selten korrekt, daher Text-Label oder aria-label setzen.

Knopf in der Werkstatt: erzeugt PNG oder WebP der aktuellen Konfig in Desktop, Tablet und Mobile. Läuft serverseitig über Playwright. Nützlich, um Layout-Stand für Mail-Anhang oder Slack-Post zu zeigen, ohne den Empfänger durch die Werkstatt-URL zu schicken. Nicht zu verwechseln mit Code-Export (cp-werkstatt-export).

In Deutschland für fast alle Webseiten Pflicht (TMG/MStV). Inhalt: Anbieter (Firma, Adresse), Vertretungsberechtigte, Kontaktdaten (E-Mail, Telefon), Handelsregister, USt-IdNr., bei journalistischen Inhalten ein Verantwortlicher i.S.d. MStV. Typisch im Footer verlinkt. Fehlt das Impressum, drohen Abmahnungen.

Eine der drei Core Web Vitals (löst 2024 den alten FID-Wert ab). Misst die Verzögerung zwischen Nutzer-Aktion (Klick, Tipp, Tastendruck) und der nächsten visuellen Reaktion. Ziel: unter 200ms. Akzeptabel: bis 500ms. Schlechte INP-Werte fühlen sich "hängend" an — typisch durch zu viel JavaScript.

Erstes gemeinsames Treffen zwischen Kunde und Digital-Unit. Klärt Erwartungen, Personen, Kommunikationswege, Zeitplan, Tools. Typisch nach Beauftragung und vor dem eigentlichen Briefing. Wer hier nicht da ist, wird später teurer. Renana führt typisch durch.

WCAG fordert mindestens 4.5:1 für Fließtext, 3:1 für große Headlines (>=18pt) und 3:1 für Bedien-Elemente wie Buttons und Borders. Helle Farben auf hellem Hintergrund (z.B. weiß auf hellgrau) sind klassische Verstöße. Tools wie WebAIM Contrast Checker oder das Browser-DevTools messen den Wert.

Nach dem Briefing definiert das Team Inhalte, Struktur, Bauteile, ggf. Wireframes und erste Designentwürfe. Kunde gibt das Konzept frei, dann erst startet die Umsetzung. Späte Änderungen gehen über Phase 1 zurück — das wird teuer.

Eine der drei Core Web Vitals. Misst, wie lange es dauert, bis das größte Inhaltselement (oft Hero-Bild oder Headline) im Viewport sichtbar ist. Ziel: unter 2.5 Sekunden. Akzeptabel: bis 4 Sekunden. Schlechte LCP-Werte kommen typisch von schweren Bildern, langsamen Servern oder fehlendem Lazy-Loading.

Annahme: 70% der Leser hören nach dem Lead-Absatz auf zu lesen. Daher müssen die ersten ca. 50 Wörter das Wesentliche tragen — was es gibt, für wen, was als nächstes. Kein Aufwärm-Geschwurbel ("In den letzten Jahren ..."). Im Frontend oft als eigener Block (Lead-Paragraph) mit eigener Typografie.

Beide Modi werden über CSS Custom Properties gesteuert — dieselben Tokens, andere Werte. Nicht jede Seite braucht beide Modi; wenn aktiviert, dann konsistent über alle Komponenten und mit System-Preference (prefers-color-scheme).

Reine CSS-Filter-Variante: keine echten Inhalte, keine Brand-Farben, nur Block-Position und Beschriftung. Nützlich, um Strukturentscheidungen ohne Visual-Bias zu diskutieren. Anders als ein echtes Wireframe-Tool: Daten bleiben gleich, nur die Darstellung wechselt. Toggle in der Werkstatt-Toolbar.

Erweiterung des ursprünglichen Schemas. Pflicht ab April 2026 für alle Components. Neue Felder: useCases (kebab-case-Slugs aus dem Use-Case-Vokabular), editorialRules (Object mit Wort-/Zeichen-Limits pro Edit-Spot), relatedComponents (PascalCase-Liste verwandter Components). Validierung über den cp-manifest-validator-Agent. Alte Manifeste ohne diese Felder gelten als unvollständig.

Standard, über den Claude und andere LLMs Resourcen lesen und Tools aufrufen können — ohne Custom-Integration pro Tool. Wir nutzen den Figma-MCP (Lesen von Figma-Files, Code-Connect) und Playwright-MCP (Browser-Automation, Screenshots). Geplant: cp-registry-MCP, der die Library als Resource exponiert. Heisst: ein Agent in einem Kundenprojekt kann über MCP unsere Components abfragen, ohne sie zu installieren.

Pro Seite ein eindeutiger Text, max 155–160 Zeichen. Sollte das Seiten-Thema kurz beschreiben und zum Klick einladen. Google nutzt sie nicht zwingend (mal ja, mal selbst generiert) — aber wenn sie genutzt wird, ist sie oft das Erste, was Suchende lesen. Pro Seite individuell, keine Wiederholungen.

Pro Seite ein eindeutiger Titel, max 50–60 Zeichen. Sollte das Wichtigste am Anfang haben und nicht zu generisch sein ("Startseite" ist schlecht). Format-Konvention: "Seitenthema | Marke" oder "Seitenthema – Marke". Wichtigster SEO-Hebel überhaupt nach dem H1.

Microcopy ist der Text in Mikro-Doses: Button-Beschriftung, Platzhalter-Text in Eingabefeldern, Fehlermeldungen, Hilfetexte, Tooltips, Empty-States. Oft entscheidend für Conversion: ein guter Submit-Button ("Termin sichern") schlägt einen schlechten ("Absenden") deutlich. Klein, konkret, hilfreich.

Hover-Zustand, Klick-Bestätigung, Toggle-Wechsel, Lade-Pulsen. Zweck: Verständnis, dass die Aktion angekommen ist und was als nächstes passiert. Nicht Selbstzweck — bei prefers-reduced-motion ausschalten oder reduzieren (WCAG-Pflicht).

Anders als Wireframe (Skizze, Grobstruktur) ist ein Mockup ein realistisches Abbild der finalen Seite — mit Farben, Typografie, Bildern. Typisch in Figma erstellt. Dient als Vorlage für das Frontend und als Freigabe-Stück für den Kunden in Phase 3 (Design).

Component-Name in PascalCase (BentoGrid), Verzeichnis genauso (src/components/BentoGrid/), Astro-Datei in PascalCase (BentoGrid.astro). Manifest-Datei und Showcase-URL in kebab-case (bento-grid.json, /components/bento-grid). useCase-Slugs ebenfalls kebab-case. Mehr-Wort-Namen IMMER mit Bindestrich (pull-quote, NICHT pullquote). Single Source of Truth für Mapping ist registry/index.json.

Wahrnehmungsgleicher Farbraum: eine Änderung des Lightness-Werts wirkt visuell gleich gross, egal welcher Hue (Farbton). Wir nutzen oklch für alle Brand-Farben — bessere Tonwerte als hsl/rgb, native Mischung via oklch(from ...). Vorteil: berechnete Light/Dark-Varianten sehen überall korrekt aus.

Wenn jemand einen Link auf LinkedIn, Facebook, WhatsApp oder Slack teilt, lesen diese Plattformen die og:title, og:description und og:image-Tags der Seite. Ohne Open-Graph zeigen sie generischen oder gar keinen Vorschau-Inhalt. Pro Seite ein eigenes 1200x630px-Vorschau-Bild ist Best Practice.

Beispiel "Service-Landingpage": Hero plus Card-Grid plus FAQ plus CTA-Banner. Im Pattern-Katalog kannst du Patterns als Werkstatt-Konfig laden — sofort startklar. Patterns sparen Zeit und sorgen für Konsistenz über Projekte hinweg.

Eine Persona enthält Name, Rolle, Ziele, Hindernisse, technisches Niveau, typische Nutzungssituation. Beispiel: "Sandra, 42, Buchhalterin im Mittelstand, sucht eine Steuerberater-Agentur, hat wenig Zeit, Smartphone-First, B2B-skeptisch". Hilft Redaktion und Design, Entscheidungen am echten Bedarf statt am Bauchgefühl zu treffen.

Online ist nicht Fertig. Inhalte aktualisieren, Kampagnen-Banner schalten, neue Mitarbeiter einpflegen, alte Aktionen entfernen. Pflege gehört zum Auftrag dazu, nicht ans Projekt-Ende. Wer bei Pflege spart, hat nach 6 Monaten eine veraltete Seite.

Briefing (1), Konzeption (2), Design (3), Frontend (4), Backend / Fluid / TCA (5), Inhalte (6), Übernahme des Frontends ins TYPO3 (7), QS und Freigabe (8), Pflege (9). Phasen sind sequenziell mit Stage-Gates. Sprung zurück = neuer Vorlauf.

Lange Seite, die ein zentrales Thema umfassend abdeckt und zu Detail-Seiten verlinkt — z.B. "Alles zu Steuerberatung für den Mittelstand" mit Untertopics wie Buchhaltung, Lohn, Bilanz, Beratung. Hilft SEO (interne Verlinkung) und Navigation. Typisch laengere Lese-Zeit, daher Sticky Sub-Nav sinnvoll.

Wir steuern Projekte über Phasen, Meilensteine und Stage-Gates. Renana führt das operative PM. Kein Sprint-Vokabular, keine Discovery/Delivery-Trennung, kein OKR-Setup. Wer Sprint sagt, meint die interne Wochenplanung, nicht Scrum.

Prüfung gegen Briefing und Konzept: Inhalte korrekt, Links funktionieren, Mobile-Ansicht läuft, Barrierefreiheit ok, Performance ok, Tracking läuft. Erst nach QS-Freigabe geht es live. Vier-Augen-Prinzip ist Pflicht — niemand checkt seinen eigenen Output.

Redakteure arbeiten im TYPO3-Backend: pflegen Texte, Bilder, Blöcke, schalten Kampagnen frei, halten Seiten aktuell. Brauchen Verständnis für Heading-Hierarchie, Alt-Texte, SEO-Basics, Tonalität. Sind erste Anlaufstelle für Pflege-Tickets via Awork.

Liegt unter registry/index.json. Enthält alle Components mit Manifest-Pfad, useCase-Slugs, Kategorie und Naming-Mapping (PascalCase ↔ kebab-case). Plus invertierter Index useCase → component[]. Wird von cp-search, cp-list, cp-page-scaffold und externen Agents konsumiert. Manuelles Bearbeiten verboten — Datei wird aus den Manifesten generiert (Skript: npm run registry:index).

Renana ist der zentrale Eingangspunkt für Tickets der Digital-Unit. Sie priorisiert, ordnet ein und delegiert. Direkter Zugriff auf Devs oder Designer ohne Renana ist nicht der Weg — das führt zu doppelter Arbeit, vergessenen Tickets und gestörten Prioritäten.

Wenn Frontend eine Vorlage liefert, einigt es sich mit Backend auf Datenfelder, CSS-Klassen und Strukturen, die in Fluid 1:1 nachgebaut werden. Gut dokumentierte Schnittstellen sparen Reibung in Phase 7 (Übernahme) — schlechte führen zu Naharbeit und Inkonsistenzen.

Beispiel: 2px Abstand zu wenig, leichtes Farb-Off bei Hover, Headline minimal anders gewichtet als im Figma. Wird gesammelt und in einem Pflege-Slot gebündelt erledigt, nicht in Eil-Tickets. Wenn Schönheitsfehler die Funktion stören, sind sie keine — dann ist es ein Bug.

Im Briefing wird der Scope (Umfang) festgelegt: welche Seiten, welche Blöcke, welche Sprachversionen. "Out-of-Scope" sind explizit ausgeschlossene Punkte — wichtig, weil sie später als Change-Request dazukommen können, mit eigenem Vorlauf und Budget. "Schnell mal noch X mit rein" ist klassischer Scope-Creep.

Bekannte Screenreader: NVDA, JAWS (Windows), VoiceOver (macOS/iOS), TalkBack (Android). Sie navigieren über Headings, Listen, Links, Buttons — nicht über Optik. Eine kaputte Heading-Hierarchie oder fehlende Alt-Texte machen Inhalte für sie unzugänglich. Im A11y-Audit immer mit echtem Screenreader testen, nicht nur mit DevTools.

Zwei Varianten. (1) HTML-Sitemap: öffentliche Seite, die alle Seiten verlinkt — nützlich für Nutzer und Verständnis. (2) sitemap.xml: maschinenlesbare Datei für Suchmaschinen, typisch unter /sitemap.xml. Wird in Search Console eingereicht, hilft Google beim Indexieren neuer Seiten.

Astro-Konzept: eine Komponente definiert einen <slot name="actions" />, der Aufrufer schiebt eigenen Inhalt rein. Hero hat z.B. einen actions-Slot für die Buttons. Slots machen Components flexibel, ohne dass jede Variante als eigene Komponente gebaut werden muss.

Konsistente Abstandsstufen statt willkürliche Pixel-Werte. Sorgt für rhythmische Layouts und einfache Skalierung. Designer in Figma und Frontend im Code nutzen dieselben Werte. Wer eigenmächtig 13px statt --spacing-sm setzt, bricht den Rhythmus.

Heute Pflicht: Webseiten ohne HTTPS werden vom Browser als unsicher markiert und von Google abgewertet. SSL-Zertifikate kommen typisch von Lets Encrypt (kostenlos) oder kostenpflichtig vom Hoster. Im Briefing prüfen, dass HTTPS auch für alle Subdomains gilt.

Am Ende jeder Phase steht eine schriftliche Freigabe (Briefing freigegeben, Konzept freigegeben, Design freigegeben...). Ohne Stage-Gate-Freigabe geht die nächste Phase nicht los. Das schützt vor unklaren "wir machen einfach weiter" und macht spätere Discussion-Loops nachvollziehbar.

Eine Kopie des Live-Systems mit eigenem Zugang. Hier läuft die QS in Phase 8: Inhalte prüfen, Links checken, A11y testen, Performance messen. Erst nach Staging-Freigabe geht der Stand auf Live. Staging ist nicht öffentlich erreichbar (Passwort-geschützt oder per IP gesperrt).

Bleibt beim Scrollen sichtbar (links auf Desktop, oben auf Mobile), springt per Smooth-Scroll zu Abschnitten. Nutzen wir auf Pillar-Pages und Wissensbasis-Hubs, damit Leser jederzeit wissen, wo sie sind und schnell zu anderen Abschnitten springen können.

Eine "lebende Bibliothek" der Components mit allen Varianten und Zuständen. Nützlich für Designer (Visual-Check), Frontend (Test während Entwicklung) und QS (alle States auf einen Blick). Wir nutzen Storybook für CP Registry und projektweise.

Helfen Suchmaschinen, Inhalte zu verstehen: ist das ein Produkt, ein Event, ein Rezept, ein Stellenangebot? Werden in den Trefferlisten als Rich Snippets angezeigt (Sterne, Preise, Termine). Schema.org definiert die Vokabulare. Pflicht für Shop-Produkte, Events, FAQ-Pages und Stellen-Boards.

Tokens, Typografie, Farben, Komponenten, Iconografie, Bildsprache. CP Registry IST im Kern ein Style-Guide — die Astro-Vorlagen sind seine ausführbare Form. Pro Kunden-Projekt typisch eine eigene Style-Guide-Variante mit Brand-Override.

Tab springt zum nächsten Element, Shift+Tab zurück, Enter aktiviert, Pfeiltasten in Listen und Menüs, Esc schließt Dialoge. WCAG-Pflicht: alles muss per Tastatur erreichbar sein. Test-Methode: Maus weglegen, Seite mit Tab durchgehen — wenn dabei ein Element nicht erreichbar ist, ist die Seite kaputt.

PHP-Array, das für einen TYPO3-Datensatz-Typ festlegt, welche Felder existieren, wie das Backend-Formular aussieht und welche Validierungen gelten. Pflicht für jedes Custom-Content-Element. Backend-Team-Domain.

Für schnelle Abstimmungen, Meetings, Team-Kanäle. Tickets gehören NICHT in Teams-Chats — die laufen über Awork. Teams-Posts ohne Awork-Ticket gehen verloren. Für Status-Updates ok, für Aufträge nicht.

Ein Token ist ein benannter Wert. Tokens halten Design (Figma), Code (CSS Custom Properties / Tailwind) und Backend-SCSS synchron. Änderung an einer Stelle, Wirkung an allen abhängigen Stellen. Ohne Tokens: hartkodierte Werte verstreut im Code, Änderungen werden zur Suchaufgabe.

Teil der Brand-Identity. Sie/Du, Aktiv/Passiv, Satzlänge, erlaubte Floskeln, Anti-Floskeln, Anrede. Pro Marke unterschiedlich: Anwaltskanzlei tickt anders als Lifestyle-Brand, Behörde anders als Startup. Tonalität wird in einem Tone-of-Voice-Guide festgehalten und gilt für alle Texte — von Hero bis FAQ.

Welche Seiten werden besucht, wo brechen Nutzer ab, wo kommen sie her (Google, Direkt, Social), wie lange bleiben sie, welche CTAs werden geklickt? Tools: Google Analytics, Matomo, Plausible. DSGVO-Pflicht: nur mit Einwilligung über CMP, AVV mit Anbieter, in der Datenschutzerklärung benannt.

Ergänzt die DSGVO speziell für Cookies und Tracking. § 25 TTDSG fordert Einwilligung für alle nicht-essenziellen Cookies und Tracker. Praktisch: ohne CMP und Cookie-Banner geht in Deutschland nichts mehr. Verstöße sind abmahnfähig.

Open-Source-Enterprise-CMS auf PHP-Basis. Redakteure pflegen Inhalte über das TYPO3-Backend. Frontend-Templates kommen aus Fluid + TCA. CP Registry liefert die Astro-Vorlagen, das Backend-Team übersetzt sie für TYPO3.

Pflichtfeld useCases im Manifest. Vokabular ist agentur-neutral und liegt zentral in registry/use-cases.json (~50 Slugs in 9 Kategorien). Beispiele: landingpage-hero, feature-showcase, service-portal-hero, kontakt-formular, leerer-zustand. Verboten: Vollsätze und Kunden-Vokabular (kein klima-*, oepnv-*, foerder-*, lade-app-*) — cp-registry ist Werkzeug der Digital-Unit, nicht eines Kunden.

Beispiel: Nutzer kommt aus Google auf eine Service-Landingpage, scrollt zur FAQ, klickt zu einer Detail-Seite, füllt Kontaktformular aus. Eine User-Journey-Map zeigt diesen Pfad mit Schritten, Erwartungen, Hindernissen. Hilft, Lückstellen zu finden — z.B. fehlende CTAs, überflüssige Klicks, unklare Navigation.

Beispiel Card: Standard, Mit Tag, Mit Bild, Bild plus Tag — vier Varianten. Sie nutzen denselben Component, aber andere Prop-Kombinationen. Im Werkstatt-Grid-Katalog waehlst du beim Hinzufügen die passende Variante.

Auch kleine Anfragen haben Vorlauf — wegen QS, Deployment-Slots und paralleler Auslastung. Renana kommuniziert den Termin. "Schnell mal" gibt es nicht, ohne andere Tickets zu verschieben. Faustregel: Text/Bild 1–2 Tage, Element-Anpassung 3–5 Tage, neues Element 1–2 Wochen, neues Projekt 4 Wochen plus.

Phasen folgen aufeinander, jede mit Stage-Gate. Änderungen an freigegebenen Phasen erzeugen einen neuen Durchlauf. Wir arbeiten klassisch — kein Scrum, kein Dual-Track-Agile, keine Discovery/Delivery-Trennung. Der Begriff "Sprint" ist intern Wochen-Planung, nicht Scrum-Iteration.

Web Content Accessibility Guidelines 2.2. Drei Stufen (A, AA, AAA). BFSG verpflichtet auf Level AA. Kriterien u.a.: Tastaturbedienbarkeit, Mindest-Kontraste, Fokus-Indikatoren, klare Fehlermeldungen, Touch-Target größe. WCAG ist live-Standard, wird alle paar Jahre erweitert.

Vollbild-Anwendung in CP Registry: Blöcke per Plus-Knopf hinzufügen, sortieren, Optionen anpassen, Inhalte editieren, Konfiguration speichern und teilen. Generiert am Ende echten Astro-Code zum Kopieren. Vorlagen können geladen werden, um Patterns als Startpunkt zu nutzen.

Liegt unter data/werkstatt/<id>.json. Enthält den BlockNode-Tree (Block-Typ, Variante, Controls, Children, Inhalte) plus Metadaten (Name, Description, Snapshot-Liste). Wird von der Werkstatt-API (REST) verwaltet und kann via cp-werkstatt-export in eine fertige Astro-Page umgewandelt werden. Snapshots werden automatisch bei Updates angelegt (max 15 pro Config) — früheren Stand kann jeder wiederherstellen.

Sehr breite Layouts — Bildgalerien, Dashboards, Tab-Listen, breite Card-Grids. Breiter als der Standard-Karten-Bereich (Breakout 1100px), aber nicht voll-bleed bis zum Browser-Rand.

Schwarz-weiß oder Graustufen, Platzhalter-Texte, Boxen statt Bilder. Zeigt Struktur und Reihenfolge, nicht das finale Aussehen. Typisch in Phase 2 (Konzeption), oft in Figma. Spart Zeit, weil Diskussionen über Struktur nicht durch Farb-Geschmacksfragen gestört werden.