Diese Seite erklärt die Bausteine moderner Websites – von Hero und CTA bis clamp() und OKLCH – und lässt dich die Werte direkt live verändern, um die Wirkung sofort zu sehen. Auch diese Überschrift skaliert per clamp() – die passende Formel kannst du im Fluid-Typography-Simulator auf der Simulatoren-Seite live verändern.
a11y, WCAG, AA, ARIA & Co. begegnen dir in praktisch jedem Projekt. Hier die zentralen Begriffe kurz erklärt – mit Links zu den passenden Simulatoren, wo du sie direkt ausprobieren kannst.
Numeronym für „Accessibility“ (a + 11 Buchstaben + y). Beschreibt Websites, die von Menschen mit visuellen, motorischen, auditiven oder kognitiven Einschränkungen uneingeschränkt genutzt werden können.
Tipp: In Deutschland/EU für viele Angebote gesetzlich verpflichtend durch das Barrierefreiheitsstärkungsgesetz (BFSG).
Web Content Accessibility Guidelines – der internationale technische Standard für barrierefreie Webinhalte, herausgegeben vom W3C.
Tipp: Aktuelle Version ist WCAG 2.2; sie ist die fachliche Grundlage hinter dem BFSG.
WCAG kennt drei Stufen: A (Minimum), AA (Standard – in der Praxis meist gefordert) und AAA (Optimum, selten vollständig erreichbar).
Tipp: AA verlangt mind. 4.5:1 Kontrast bei Fließtext, 3:1 bei großem Text/UI. Live ausprobieren: OKLCH-Kontrast-Simulator.
Zusätzliche HTML-Attribute (aria-*, role), die Screenreadern semantische Zusatzinformationen liefern, wenn natives HTML allein nicht ausreicht.
Erste ARIA-Regel: natives HTML bevorzugen – <button> statt <div role="button">.
Assistive Technologie, die Bildschirminhalte als Sprache oder auf einer Braillezeile ausgibt – auf Basis von Semantik, ARIA-Attributen und Alt-Texten.
Tipp: Kostenlos selbst testen mit NVDA (Windows) oder VoiceOver (macOS/iOS).
:focus-visibleSichtbare Markierung des Elements, das gerade per Tastatur (Tab-Taste) fokussiert ist – essenziell für Tastaturnutzer:innen.
Tipp: Niemals outline: none setzen, ohne einen mindestens gleichwertigen Ersatz zu definieren.
WCAG 2.2 verlangt für interaktive Elemente mindestens 24×24px, empfohlen werden 44×44px – wichtig für Nutzer:innen mit motorischen Einschränkungen.
Live ausprobieren: Touch-Target-Simulator.
Ein anfangs unsichtbarer Link ganz oben im HTML, der bei Tastaturfokus sichtbar wird und direkt zum Hauptinhalt springt – ohne die ganze Navigation durchtabben zu müssen.
Tipp: Probier's selbst – drück beim Laden dieser Seite einmal die Tab-Taste.
Textbeschreibung eines Bildes im alt-Attribut, die Screenreader vorlesen und die angezeigt wird, falls das Bild nicht geladen werden kann.
Tipp: Rein dekorative Bilder erhalten alt="" (leer), informative Bilder eine knappe, aussagekräftige Beschreibung.
Kurz erklärt, mit deutscher Übersetzung und einem Accessibility-Tipp. Einige Karten enthalten eine echte Mini-Demo zum Ausprobieren.
Oberste Leiste der Website; enthält meist Logo, Navigation und Schnellzugriffe.
A11y-Tipp: Semantisch als <header> auszeichnen. Bei position: sticky darauf achten, dass der Fokusring beim Scrollen nicht verdeckt wird.
Prominenter Einstiegsbereich „Above the Fold“ mit Hauptversprechen (H1), Bild/Grafik und CTA.
A11y-Tipp: Mindestkontrast Text zu Hintergrund von 4.5:1 (WCAG AA) einhalten – bei Bildhintergründen ein Overlay nutzen.
Kurzer Textblock (1–3 Worte) direkt über der Hauptüberschrift zur thematischen Einordnung.
A11y-Tipp: Nicht als <h1> auszeichnen, sondern als <p> oder <span> vor der eigentlichen Überschrift.
Zentraler Interaktions-Button oder Link, der Besucher zu einer Aktion führt.
A11y-Tipp: Buttons führen Aktionen aus, Links navigieren. Ein sichtbarer Fokus-Indikator ist Pflicht.
Automatische Anpassung von Layout, Typografie und Bildern an verschiedene Bildschirmgrößen.
A11y-Tipp: Mobile-First denken, relative Einheiten (rem, ch, %) statt fester Pixelwerte.
2D-Layoutsystem zur gleichzeitigen Steuerung von Zeilen und Spalten.
Zum Live-Ausprobieren: CSS-Grid-Simulator auf der Simulatoren-Seite.
Ein Accordion stapelt Inhalte vertikal und blendet sie erst bei Bedarf ein – ideal für FAQs. Native <details>/<summary>-Elemente bringen Tastaturbedienbarkeit und Screenreader-Unterstützung automatisch mit, ganz ohne JavaScript.
Öffne mehrere Fragen – dank des name-Attributs (moderne Browser) bleibt hier immer nur ein Panel gleichzeitig geöffnet, ganz ohne JavaScript.
<details> statt einer eigenen JS-Lösung?Native Elemente bringen Tastaturbedienbarkeit (Enter/Space öffnet), korrekte Screenreader-Ansagen und den Auf-/Zu-Zustand automatisch mit – eine handgebaute Lösung müsste all das selbst nachbauen.
Geben alle <details>-Elemente einer Gruppe dasselbe name-Attribut, schließt der Browser automatisch die anderen, sobald eines geöffnet wird – ähnlich wie bei Radio-Buttons.
Den nativen Dreieck-Marker per summary::-webkit-details-marker { display: none; } ausblenden und einen eigenen (z. B. per ::before) mit klarem Auf/Zu-Zustand ergänzen – wie in diesem Beispiel.
Ja – es hilft, komplexe Formulare in überschaubare Abschnitte zu gliedern. Wichtig: Pflichtfelder in eingeklappten Abschnitten sollten Nutzer:innen vorab erkennbar sein (z. B. per Badge in der summary).
Drei horizontale Linien, die mobile Navigation ein-/ausblenden. Damit du das Verhalten unabhängig von deiner tatsächlichen Bildschirmbreite sehen kannst, zeigt dieser Handy-Rahmen eine eigenständige, immer aktive Kopie des Musters.
Öffne das Menü per Klick oder Tastatur (Tab + Enter). Fokus wird eingesperrt, Escape schließt, und beim Schließen springt der Fokus zurück auf den Auslöser-Button.
Menü ist geschlossen.
Eine horizontale Abfolge von Bildern oder Karten, die sich manuell durchblättern lässt. Bewusst ohne Autoplay – Nutzer:innen bestimmen selbst das Tempo.
Sonnenuntergang über den Bergen
Ozean bei Nacht
Skyline bei Nacht
Wald am Morgen
Wüste bei Sonnenuntergang
Bild 1 von 5: Sonnenuntergang über den Bergen