Web Content Leitlinien

Unabhängig von der technischen Wahl von Payload als CMS legen wir großen Wert auf grundlegenden Leitlinien:

1. Content Primacy

Es geht darum die Aufmerksamkeit unserer Lesern effizient auf unserer Inhalte zu fokussieren. Alle UI-Elemente sollen in den Hintergrund rücken (headers, navigation, sidebars). Typography, Spacing, Absätze und Struktur dienen der Verständlichkeit und nicht der Ästhetik.

In der Praxis

Navigation ist minimal und stört nicht
Seiten-Struktur/Darstellung wird durch die Art des Inhaltes bestimmt.
Schriftgröße, Schriftart, Zeilenabstand werden auf Lesbarkeit und nicht auf visuellen-Imapakt optimiert.

Referenzen

https://ux-ui-design.de/die-3-30-3-regel-fuer-aufmerksamkeit-und-leseverhalten-auf-webseiten/

2. Zero Visual Noise

Keine visuellen Elemente ohne direkte Funktion in der Informations-Übertragung. Also keine "Dekorationen". Jedes visuelle Element verbraucht Aufmerksamkeit und muss einen konkreten Mehrwert liefern, um sich zu begründen. Auch Leerzeichen / Whitespace sind Information und keine Lückenfüller - im Zweifelsfall lieber weglassen.

In der Praxis

Keine unnötigen horizontalen Separatoren
Keine Rahmen, außer sie haben Bedeutung
Icon-Labels nur wenn die "Accessability" erhöht wird und der Kontext nicht ausreichend ist
keine Schatten oder 3D Effekte

3. Accessibility by Default

Accessibility ist für uns eine grundsätzliche Entscheidung und kein nachträgliches Feature. Unser Ziel ist mindestens WCAG 2.1 / 2.2 Level AA besser AAA.

In der Praxis

Seiten Templates und Daten — `alt` Texte sind erforderlich. Überschriften-Level sind eingeschränkt. Link-Texte sind wichtig und werden validiert.
Komponenten — semantisches HTML. Tastatur-Navigation ist vorgesehen und funktioniert. ARIA nur wo HTLM nicht ausreicht.
Design — hoher Kontrast. Visuelle Fokus Indikatoren. Keine "hover" Informationen (d.h. keine Tooltips).
Testing — automatische axe-core checks in gitlab-CI, manuelle Tastatur und Bildschirm Kontrollen. Auch auf mobilen Endgeräten!

Ein Feature ist **nicht fertig** ohne eine Kontrolle der Tastatur-Naviation und Bildschirm-Tests! Retrofitting ist keine Option.

Referenzen

https://www.w3.org/WAI/standards-guidelines/wcag/

https://www.deque.com/axe/

https://github.com/dequelabs/axe-core

4. Semantische Konsistenz (auf technischer Ebene)

HTML Strukturen spiegeln die Bedeutung der Inhalte wieder. Native HTLM Elemente werden immer vor custom ARIA Lösungen bevorzugt. Vorhersehbarkeit und konsistentes Verhalten sind das Ziel -- kein Überraschungen!

In der Praxis

EINE `<h1>` Überschrift pro Seite. Immer.
Überschriften überspringen niemals Levels (`h1 → h2 → h3`, nie `h1 → h3`)
`<button>` für AKTIONEN, `<a>` for Navigation — nicht umgekehrt.
Strukture/Landmark Elemente wo immer möglich: `<header>`, `<main>`, `<nav>`, `<footer>`
ARIA Attribute nur wenn native HTLM Semantik nicht ausreicht.