Markus Stahmann

Design System

Brand-Tokens, Typografie und alle UI-Komponenten — als lebendes Dokument.

Tokens

Brand

Icon / Favicon — favicon.svg · 256 × 256

Favicon Icon-Mark
Transparent
Favicon auf hellem Hintergrund
Hell
Favicon auf dunklem Hintergrund
Dunkel

Logo Standard (gestapelt) — logo.svg · 314 × 154

Logo markus stahmann – hell
Hell
Logo markus stahmann – dunkel
Dunkel

Logo Alt (horizontal) — logo-alt.svg · 583 × 118

Logo horizontal – hell
Hell
Logo horizontal – dunkel
Dunkel
Tokens

Farben

Brand Palette — Primitive

Rohe OKLCH-Werte in _primitives.css. Nie direkt in Komponenten verwenden — immer semantische Tokens (--color-*) nutzen.

Brand Teal — Primärfarbe

Teal Light --_teal-600 oklch(0.5318 0.0879 202.03) Akzent hell
Teal --_teal-700 oklch(0.4269 0.0706 202.96) Akzent · Links
Teal Dark --_teal-800 oklch(0.3324 0.0541 202.39) Akzent Hover

Brand Amber — Sekundärfarbe

Amber --_amber-500 oklch(0.6658 0.1574 58.32) Dekorativ (Logo-Punkt)
Amber Mid --_amber-700 oklch(0.4715 0.1083 60.4) Amber Mittel
Amber Dark --_amber-900 oklch(0.3651 0.0815 62.43) Amber Dunkel
Amber Text --_amber-text oklch(0.430 0.107 60.4) Text-sicher · 6.39:1 auf Paper

Brand Cyan — Dark-Mode-Akzent

Cyan --_cyan-400 oklch(0.7864 0.1143 186.56) Akzent Dark Mode
Cyan Dark --_cyan-700 oklch(0.5718 0.0971 187.54) Fokus-Ring Light

Gray — Neutrale Skala

Ink --_gray-950 oklch(0.1767 0.0114 260.64) Fast Schwarz · Haupttext
Ink 2 --_gray-900 oklch(0.309 0.021 265.9) Dark-BG erhöht
Ink 3 --_gray-700 oklch(0.4368 0.0253 261.66) Sekundärtext
Muted --_gray-500 oklch(0.5207 0.0143 91.63) Gedämpfter Text
Muted Light --_gray-400 oklch(0.6327 0.012 95.25) Deaktiviert

Paper — Hintergrund-Skala

Paper --_paper oklch(0.9678 0.0086 84.57) Haupt-BG Light
Paper Muted --_paper-100 oklch(0.9382 0.0144 84.58) BG Sunken
Paper Sunken --_paper-200 oklch(0.9046 0.0199 87.52) BG Elevated Light
White --_white oklch(1 0 0) Reines Weiß

Semantische Tokens

Diese Tokens ändern sich je nach Light/Dark Mode via light-dark(). Immer diese verwenden, nie Primitive direkt.

Hintergrund

Paper --color-bg
White (Card) --color-bg-elevated
Paper-muted --color-bg-muted
Paper-sunken --color-bg-sunken

Text

Primärtext --color-text
Sekundärtext --color-text-secondary
Gedämpft --color-text-muted
Deaktiviert --color-text-disabled

Akzent

Akzent --color-accent
Akzent Hover --color-accent-hover
Amber --color-amber
Amber Text --color-amber-text

Feedback

Erfolg --color-success
Erfolg BG --color-success-bg
Warnung --color-warning-text
Warnung BG --color-warning-bg
Gefahr --color-danger
Gefahr BG --color-danger-bg
Info --color-info
Info BG --color-info-bg

Rahmen

Rahmen Fein --color-border-subtle
Rahmen --color-border-default
Rahmen Stark --color-border-strong

Oberflächen

Ink Surface --color-surface-ink
Teal Surface --color-surface-teal
Tokens

Farbkontraste

Live aus den CSS-Tokens berechnet — spiegelt den aktiven Farbmodus wider. WCAG 2.x Ratio + APCA Lc (WCAG 3.0 Entwurf).

Haupttext

--color-text
--color-bg

APCA Lc: —

Fließtext, Überschriften, UI-Labels

Sekundärtext

--color-text-secondary
--color-bg

APCA Lc: —

Captions, Hilfstexte, Metadaten

Gedämpfter Text

--color-text-muted
--color-bg

APCA Lc: —

Placeholder, dekorative Beschriftungen

Akzentfarbe / Link

--color-accent
--color-bg

APCA Lc: —

Links, aktive Zustände, Fokus-Indikatoren

Text auf Akzent-Button

--color-on-accent
--color-accent

APCA Lc: —

Primäre Buttons, CTAs

Amber Text

--color-amber-text
--color-bg

APCA Lc: —

Hervorhebungen, Warnhinweise

Text auf Karte

--color-text
--color-bg-elevated

APCA Lc: —

Card-Inhalte, Modals, Tooltips

Selbst-Check

Beliebige Token-Kombinationen live prüfen.

APCA Lc: —

Grundlagen

Abstände & Co.

Abstände · 4 px Grid

Tokens. --spacing-xs (4 px) → --spacing-4xl (96 px) — alle Vielfache von 4 px.

Skala. 4 · 8 · 16 · 24 · 32 · 48 · 64 · 96

Anwendung.

  • Tight UI Density: xs–sm · 4–8 px
  • Standard Body: md–lg · 16–24 px
  • Section Pivots: xl–2xl · 32–48 px
  • Hero / Page Pivots: 3xl–4xl · 64–96 px+

Kein Magic Number im Markup — immer Token. Wenn ein Wert nicht passt, sagt er etwas über die Skala, nicht über den Fall.

Border Radius

--border-radius-none 0
--border-radius-xs 2px
--border-radius-sm 4px
--border-radius-md 6px
--border-radius-lg 10px
--border-radius-pill 999px

Rahmen (Borders)

--color-border-subtle Dekorativ · 1 px · Nur wo Inhalt bereits strukturiert ist. Kein Ersatz für UI-Rahmen — zu schwach für 1.4.11.
--color-border-default UI-Grenze · 1.5 px · Inputs, Cards, fokussierbare Flächen. Erfüllt WCAG 1.4.11 Non-text Contrast (≥ 3:1).
--color-border-strong Strukturlinie · 1 px · Tabellenzeilen, thematische Trenner. Kein interaktives Element.
--color-accent Selektion · 1 px · Aktiver Zustand, current-Indikator, Auswahlrahmen.

Schatten (Shadows)

--shadow-sm Card, leicht erhöht
--shadow-md Dropdown, Modal
--shadow-lg Overlay, Popover
--shadow-inset Input-Hintergrund (eingesunken)
--shadow-focus Fokus-Ring + Halo (siehe unten)

Focus · Adaptive Ring — Cyan-Family · 3-Layer-Stack

Stacked-Shadow-Pattern: 2 px page-bg Band2 px Cyan-Ring4 px Halo @ 0.20. Eine Regel (:focus-visible) für alle Oberflächen — der Ring passt sich dem Hintergrund an. WCAG 2.4.7 AA / 2.4.11 AA / 2.4.13 AAA.

LIGHT · #0E8A82 Ring · ≈ 3.83 (AA LG)

3.83 · AA Non-text

INK · #4FD1C5 Ring · ≈ 10.14 AAA

10.14 · AAA

TEAL · #FFFFFF Ring · ≈ 9:1 · Weiß auf Teal · band + ring + halo

Hinweis für spätere Komponenten-Arbeit. Auf surface--teal sind --color-accent und --color-focus-ring auf Weiß überschrieben. Das funktioniert für einfache Buttons und Links gut — bei komplexeren Kombinationen (z. B. Badge auf Button, Icon-Button, aktive Nav-Items) sollte man prüfen, ob Weiß-auf-Weiß-Konstellationen entstehen oder ob weitere Token-Overrides nötig sind.

--color-focus-ring Teal-700 #0E8A82 (Light, 3.83 auf Paper, AA Non-text) / Cyan-400 #4FD1C5 (Dark/Ink, 10.14 auf Ink, AAA) / Weiß #FFFFFF (Teal-Surface, ~9:1, surface--teal override)
--color-focus-halo 20 % Teal (Light) / 20 % Cyan (Dark/Ink) / 18 % Weiß (Teal-Surface)
Implementierung outline: 2px solid transparent + box-shadow: 0 0 0 2px var(--color-bg), 0 0 0 4px var(--color-focus-ring), 0 0 0 8px var(--color-focus-halo)

Motion · Easing + Duration + Reduced-Motion

Ease cubic-bezier(.2,.8,.2,1) primary curve
Hover · 120ms colors · transform instant feel
State · 200ms toggle · expand noticeable, not slow
Reveal · 320ms opacity + 8 px Y entrance
Y-shift · 8 px reveal · hover lift small > flashy
Reduced motion respected globally all anims → 0.01ms

Tokens. --duration-instant 80 · --duration-hover 120 · --duration-state 200 · --duration-reveal 320 · --duration-stage 480 — --ease-out-quart cubic-bezier(.2,.8,.2,1) primäre Brand-Kurve — --motion-y 8px Y-Shift bei Reveal/Hover-Lift

Wann was.

instant 80msTap-Acknowledge, Active-State hover 120msColor/Transform/Shadow auf Hover state 200msToggle, Disclosure, Fade reveal 320msEntrance (opacity + 8 px Y) stage 480msPage-Level / Route-Transition

Reduced Motion. Globaler @media (prefers-reduced-motion: reduce)-Block setzt alle Transitions/Animations auf 0,01ms. Keine Ausnahmen. Funktion bleibt, Bewegung geht.

Nicht. Keine Bounce-Eases bei Default-UI (Spring nur für Spielerei). Kein Y-Shift > 8 px (große Bewegungen lesen sich nervös).

Breakpoints · Mobile-first

--bp-sm --bp-md --bp-lg --bp-xl · Gutters: --spacing-sm / --spacing-lg / --spacing-xl (8 / 24 / 32 px)

Container-Breiten

OpenType-Features

Das System setzt font-variant-numeric: slashed-zero global auf body. Mono-Elemente und Ziffern in Komponenten erhalten zusätzlich tabular-nums.

slashed-zero — Null vs. O
0 Null (slash)
0 Null (normal)
O Buchstabe O

Global aktiv auf body — IBM Plex Sans unterstützt "zero" sicher. Space Grotesk (Display) nicht garantiert.

tabular-nums — Spaltenausrichtung

1.234,56
987,00
10.000,00

tabular ✓

1.234,56
987,00
10.000,00

proportional

font-variant-numeric: tabular-nums slashed-zero — in Tabellen, Kontrast-Checker, Stepper

Disambiguierung — kritische Zeichenpaare
I l 1 | Capital-I, Lowercase-l, Eins, Pipe
O 0 o Q O, Null, o, Q
rn m rn-Folge vs. m
vv w vv-Folge vs. w
f l fl fl f+l, fl-Ligatur

IBM Plex Sans differenziert I / l / 1 klar — gut für technische Inhalte.

Anführungszeichen — :lang(de)

Hauptzitat

Zitat mit Binnenzitat

:lang(de) q { quotes: "„" "\201C" "‚" "\2018" }

Grundlagen

Grid · 12-Spalten

12-Spalten-Grid mit festem Gap (--spacing-lg · 24 px). Spalten via .col-N (1–12), responsiv: sm:col-N, md:col-N, lg:col-N.

.grid-12 · .col-N · responsive: sm:col-N · md:col-N · lg:col-N

Grundlagen

Typografie

.t-display-xl — Space Grotesk Bold, clamp(3rem–5.5rem) · Hero-Headlines

Zugänglich.

.t-display — Space Grotesk Bold, clamp(2.5rem–4rem) · Seitenüberschriften

Digitale Teilhabe für alle.

h1 — IBM Plex Sans Bold, clamp(2rem–3rem), tracking-tight

Barrierefreiheit im Web

h2 — IBM Plex Sans Bold, clamp(1.5rem–2.25rem), tracking-tight

WCAG 2.2 AA-Konformität

h3 — IBM Plex Sans Semibold, clamp(1.25rem–1.75rem)

Fokus-Management & Tastaturbedienung

h4 — IBM Plex Sans Medium, clamp(1.25rem–1.375rem)

Alternativtexte für Bilder

.t-lead — IBM Plex Sans Light, 1.125rem, relaxed · Einleitungstext

Barrierefreiheit ist kein Add-on — sie ist die Grundlage guten digitalen Designs.

Body (p) — IBM Plex Sans Regular, 1rem / leading-normal (1.55)

Fließtext. WCAG 2.2 verlangt mindestens 4,5:1 Kontrast für Normaltext — dieses System liegt überall darüber. Auch auf Dark-Surfaces und Teal-Backgrounds.

.t-small — IBM Plex Sans Regular, 0.875rem, color-text-secondary

Kleiner Hilfstext für Metadaten, Captions und Nebeninformationen.

.t-meta — IBM Plex Mono, 0.75rem, tabular-nums, tracking-wider (0.14em) · für strukturierte Metadaten wie Datum, Dauer, Tags

2024-11-14 · 8 min · WCAG 2.2 · Barrierefreiheit

.t-eyebrow — IBM Plex Mono, 0.75rem, uppercase, Akzentfarbe, tracking-wide (0.08em)

Kategorie · Eyebrow-Label

.t-accent — IBM Plex Serif Italic Bold, color-accent-italic · Inline-Akzent, sparsam einsetzen

Websites die tatsächlich barrierefrei sind.

Display im Kontext · t-accent auf drei Surfaces

.t-accent (IBM Plex Serif Italic Bold) als einzige Akzent-Stimme der Marke. Regel: eine italic-Geste pro View — entweder inline im Heading oder als ganzer Pull-Quote-Satz, nie zwei gleichzeitig. Phrase-Level, nie mitten im Wort.

Paper

Barrierefreiheit ist kein Feature.

Ink Surface

Form folgt Funktion.

Teal Surface

Ich übersetze WCAG in Pull Requests.

Fließtext im Kontext · Body + Headings auf zwei Hintergründen

Realistische Anordnung — h3, h4, Body und Small auf Paper und Card-Bg mit annotierten Kontrastverhältnissen.

Audit ohne 80-Seiten-PDF

Markus übersetzt WCAG in Pull Requests — auf Augenhöhe, ohne Paragrafenklopapier.

Wir identifizieren, was kaputt ist, und priorisieren konkret nach Aufwand und Wirkung. Du bekommst Tickets für deine Backlog, nicht eine PDF-Wüste.

Was wir nicht tun

Wir liefern keine generischen Berichte. Jedes Finding hat einen konkreten Ort im Code und einen Lösungsvorschlag, der in dein Setup passt.

Welche Tools im Einsatz sind

axe-core, NVDA, JAWS, VoiceOver, Tastatur-only Browsing. Automatisierte Scans als Erstindikator, manuelle Prüfung als Quelle der Wahrheit.

Small text auf Paper — 7.17 : 1 AAA. Für Captions, Hints, Metadaten.

Audit ohne 80-Seiten-PDF

Markus übersetzt WCAG in Pull Requests — auf Augenhöhe, ohne Paragrafenklopapier.

Wir identifizieren, was kaputt ist, und priorisieren konkret nach Aufwand und Wirkung. Du bekommst Tickets für deine Backlog, nicht eine PDF-Wüste.

Small text auf White (Card-Bg) — 7.65 : 1 AAA. Mindestgröße für Body · auf beiden Surfaces geprüft.

Kritische Zeichen (Character Set)
„ " Anführungszeichen DE „ “
‚ ' Einfache Anführungszeichen DE ‚ ‘
Gedankenstrich (Em Dash) —
Halbgeviertstrich (En Dash) –
Auslassungspunkte (Ellipsis) …
© Copyright ©
· Mittelpunkt (Separator) ·
× Multiplikationszeichen ×
Grundlagen

Icons

Phosphor Icons — Regular, Bold und Fill werden geladen; Light, Thin und Duotone sind nicht im Einsatz. Alle Icons erhalten aria-hidden="true" — der semantische Kontext kommt aus dem umgebenden Text oder dem aria-label des interaktiven Elements.

Brand-Subset · 24 Icons

Nur diese Icons für neue UI-Elemente verwenden — Ergänzungen nach Abstimmung.

  • eye
  • ear
  • hand-pointing
  • magnifying-glass
  • check-circle
  • warning
  • info
  • x-circle
  • file-text
  • list-checks
  • keyboard
  • code
  • graduation-cap
  • chat-circle-text
  • user
  • arrow-right
  • certificate
  • globe
  • device-mobile
  • headphones
  • envelope
  • chart-bar
  • shield-check
  • lightbulb

Icon-Weights · Regular · Bold · Fill (Light/Thin/Duotone unbenutzt)

Regular

Fließtext, UI, Default

Standardgewicht für kontextuelle Icons im Fließtext und neutralen UI-Elementen.

phph-*
Bold

Buttons, Touch-Targets

Erhöhte Sichtbarkeit für interaktive Elemente — Mindestgröße 20 px empfohlen.

ph-boldph-*
Fill

Status, Aktiv-Zustände

Gefüllte Variante für aktive, selektierte oder Status-Indikatoren.

ph-fillph-*

Icon-Größen

--icon-sm 16px Inline-Icons, Labels, Badges
--icon-md 18px UI Standard, Schaltflächen
--icon-lg 20px Touch-Targets, Hero-Elemente

Barrierefreiheit & Verwendung

Dekorativ aria-hidden="true" auf dem <i> — kein weiteres Markup nötig. Label kommt aus dem umgebenden Text.
Icon-Button aria-label="…" auf dem <button>, aria-hidden="true" auf dem Icon. Beispiel: aria-label="Menü schließen".
Status-Icon Icon aria-hidden="true" + sichtbarer Text daneben. Status nie ausschließlich über Icon kommunizieren (WCAG 1.4.1).
Mindestgröße Touch-Targets mindestens 24 × 24 px (WCAG 2.5.8 AA). Interaktive Icon-Buttons: 44 × 44 px empfohlen.
Grundlagen

Prose-Styles

Typografie für Artikel- und Dokumentationsinhalte. Alle Stile gelten innerhalb von <article>-Elementen oder explizit über die Klasse .prose.

Inline-Code

code — IBM Plex Mono, 0.875em, leicht hervorgehoben

Die Eigenschaft font-variant-numeric: tabular-nums sorgt dafür, dass Ziffern die gleiche Breite haben — wichtig für Tabellen und Code-Ausgaben.

Tastenkombinationen — <kbd>

kbd — Monospace, Border, leichte Erhöhung via Schatten

Fokus wechseln: Tab vorwärts, Shift+Tab rückwärts. Dialog schließen: Escape. Bestätigen: Enter.

Hervorhebung — <mark>

mark — Hintergrundfarbe Amber, nicht nur Farbe als Signal (WCAG 1.4.1)

Das Kriterium 1.4.3 Kontrast (Minimum) ist eines der häufigsten Fehler bei Webseiten-Audits.

Ausgabe & Variablen — <samp>, <var>

samp — Programm-Ausgabe; var — Variablen oder Platzhalter in Formeln

Kontrastverhältnis: 4.52:1 — Formel: L1 + 0.05) / (L2 + 0.05).

Komponenten

Buttons

Varianten

Größen

Als Link · Deaktiviert

Als Link-Element

TODO — Button-Varianten auf surface--teal brauchen Design-Review. Aktueller Stand: btn--primary = weißer Hintergrund + Teal-Text (technisch funktional, ≈ 5.5:1), btn--secondary = weißer Rahmen + Text auf Teal. Ob das die gewünschte visuelle Hierarchie abbildet, muss noch entschieden werden — ggf. weitere Overrides in surfaces.css ergänzen.

Komponenten

Badges & Tags

Badges — gefüllt

Neutral Primary Erfolg Warnung Fehler Info

Badges — Outline

Neutral Primary Erfolg Warnung Fehler

Badges — mit Dot

Aktiv In Bearbeitung Kritisch Entwurf

Badges — Outline mit Dot · Status

Live In Audit 14 Verstöße Entwurf

Tags

WCAG 2.2 Barrierefreiheit Entfernbar
Komponenten

Alerts

Hinweis

Die WCAG 2.2 ist seit Oktober 2023 offiziell verabschiedet und löst WCAG 2.1 ab.

Prüfung bestanden

Alle 50 Kriterien wurden für Level AA erfüllt. Konformitätserklärung kann erstellt werden.

Handlungsbedarf

3 Kriterien unterschreiten den Mindestkontrast von 4,5:1 nach WCAG 1.4.3.

Dieser Alert hat keinen Titel und ist schließbar.

Komponenten

Formulare

Für die Projektkorrespondenz.

Bitte eine gültige URL eingeben.

Checkboxen, Radio & Toggle

Form-Validierung · 8 Zustände

Alle States eines E-Mail-Feldes — Default, Focus, Error, Success, Required, Disabled, Submit-Fehler-Summary und Inline-Confirmation.

1 · Default — Hint visible

Antworte ich werktags innerhalb 24 h.

2 · Focus — Cyan-Ring

Border bleibt grau; Cyan-Ring = Fokus-Indikator.

3 · Error — aria-invalid + describedby

Bitte gültige E-Mail eingeben — fehlende Domain nach @.

Antworte ich werktags innerhalb 24 h.

4 · Success — sparsam

Domain erreichbar.

5 · Required — Anzeige + ARIA

Pflichtfeld. Sternchen ist dekorativ — ARIA trägt die Information.

6 · Disabled — Solid Surface

Aus Profil übernommen. Über Account-Einstellungen ändern.

7 · Submit-Fehler — Error Summary mit Sprungmarken

Pattern: Nach Submit — Summary role="alert" oben einfügen, Fokus per JS auf die Summary (tabindex="-1"), Links zu #field-id. Submit-Button nicht deaktivieren.

8 · Submit-Erfolg — Inline-Confirmation (kein Toast)

Anfrage gesendet

Bestätigung an markus@stahmann.de · ich melde mich innerhalb 24 h werktags.

Kein Toast: SR-Timing (role="status") unzuverlässig. Formular durch Inline-Alert ersetzen · aria-live="polite".

Komponenten

Code Block

Standard mit Caption

src/styles/base/_tokens.css CSS
/* Semantische Farbtokens */
--color-accent: light-dark(var(--_teal-600), var(--_teal-400));
--color-text:   light-dark(var(--_gray-950), var(--_paper));
--color-bg:     light-dark(var(--_paper), var(--_gray-950));

Nummeriert mit Diff

src/components/Button.astro Astro
---
interface Props {
    variant?: "primary" | "secondary";
    variant?: "primary" | "secondary" | "ghost" | "danger";
    href?: string;
    disabled?: boolean;
}
---

Ink-Variante (dark)

styles/focus.css CSS
/* Cyan-family, 3-layer focus — band + ring + halo */
:focus-visible {
    outline: 2px solid transparent;
    box-shadow:
        0 0 0 2px    (--bg),
        0 0 0 4px    (--focus-ring),
        0 0 0 8px    (--focus-ring-halo);
}
Komponenten

Tabelle

Audit-Findings · Default · Mono Numerics + Status Pills

WCAG-Ratio + APCA Lc gegen die jeweils relevante Surface. APCA-Werte vorläufig (W3C Draft) — WCAG-Verhältnisse bleiben verbindlich.

Kontrast-Audit: Token-Paarungen gegen Paper-Hintergrund
Token Surface WCAG APCA Lc Status
--teal #075A60 auf Paper 7.24 77.8 AAA Body
--amber-text #864A04 auf Paper 6.39 74.6 AA+ Body
--amber #D97706 auf Paper · als Text 2.90 50.1 Fail Text
--border-subtle #D6D3CB auf Paper 1.36 15.9 Decor Only
--border-default #6E6C66 auf Paper 4.78 53.0 UI 1.4.11
APCA-Werte vorläufig (W3C Draft). WCAG-Verhältnisse bleiben verbindlich.

Compact + Bordered · BFSG-Schwellen

BFSG Bußgeldrahmen nach Verstoß-Art
Verstoß Bußgeldrahmen Quelle
Marktüberwachungsverstoß €100 000 BFSG § 37 Abs. 2
Falsche Konformitätserklärung €10 000 BFSG § 37 Abs. 1 Nr. 3
Informationspflicht-Verstoß €2 500 BFSG § 37 Abs. 1 Nr. 5

Standard · WCAG-Stichprobe

WCAG 2.2 — Stichprobe Erfolgskriterien
Kriterium Level Status Score
1.1.1 Nicht-Text-Inhalt A Pass 100
1.3.1 Info und Beziehungen A Warn 72
1.4.3 Kontrast (Minimum) AA Fail 44
2.4.7 Fokus sichtbar AA Pass 98
4.1.2 Name, Rolle, Wert A N/A
Stichprobe, keine vollständige Prüfung.
Muster

Cards

Feature Card — Icon · kein card__body-Wrapper

WCAG-Prüfung

Manuelle Evaluation nach WCAG 2.2 AA inkl. Screenreader-Tests mit NVDA, JAWS und VoiceOver.

Sensibilisierung

Workshops für Entwicklung, Design und Redaktion — praxisnah, ohne Theorie-Overload.

Prüfbericht

Priorisierter Befundbericht mit konkreten Handlungsempfehlungen — keine 80-Seiten-PDFs.

Muted Card — Sekundäre Inhalte

Hinweis

Für eingebettete oder sekundäre Inhalte — gedämpfter Hintergrund, kein Shadow.

Muted + Link

Kombination aus gedämpftem Hintergrund und klickbarer Fläche.

Kontext-Info

Ergänzende Information neben einem Hauptinhalt — z. B. Sidebar, Footnote oder Empfehlung.

Muster

Disclosure

FAQ · Grouped, nummerierte Eyebrows · Default expanded

01 · Audit Wie lange dauert ein Accessibility-Audit?

Je nach Umfang zwischen 5 und 15 Werktagen. Ein typisches Audit umfasst etwa 30–50 Templates / Komponenten und endet mit einem priorisierten Maßnahmenplan — keine 80-Seiten-PDFs, sondern konkrete Tickets für deine Backlog.

02 · BFSG Was bedeutet das Barrierefreiheitsstärkungsgesetz für mich konkret?

Das BFSG gilt ab Juni 2025 für Unternehmen, die bestimmte digitale Produkte und Dienstleistungen anbieten. Es verpflichtet zur Konformität mit EN 301 549 — was im Kern WCAG 2.1 AA entspricht.

03 · Schulung Schult ihr nur Entwicklerinnen oder auch Design-Teams?

Beide. Für Entwickelnde liegt der Fokus auf semantischem Markup, Tastaturnavigation und ARIA. Für Design-Teams auf Kontrast, Touch-Target-Größen und zugänglichen Interaction-Patterns.

04 · Preis Was kostet ein Audit?

Das hängt vom Umfang ab. Ich arbeite auf Tagessatzbasis — ein Erstgespräch (30 Min., kostenlos) gibt dir eine belastbare Schätzung.

Single · Audit-Finding mit kollabiertem Detail

Finding #14 · WCAG 1.4.3 · Severity High Kontrast Body-Text auf Hero-Image

Problem: Body-Text #9E9E9E auf Hero-Image-Overlay erreicht nur 2.1:1 — WCAG 1.4.3 fordert 4.5:1 für Normaltext.

Empfehlung: Overlay-Opacity von 0.4 auf 0.65 erhöhen oder Text-Color auf #FFFFFF + Drop-Shadow setzen. Beide Optionen reichen aus.

Wo: components/Hero.astro Zeile 42, components/HeroSmall.astro Zeile 28.

Muster

Stepper

Rich · Icon-tiled Cards · With Current + Done States

  1. 01

    Erstgespräch

    30 Minuten, kostenlos. Ausgangslage, Ziele, Passung — bevor wir Verträge anfassen.

    30 Min · Kostenlos

  2. 02

    Bestandsaufnahme

    Automatisierter Scan und erste manuelle Sichtung. Sofort-Einschätzung inklusive.

    ½ Tag

  3. 03

    Audit & Bericht

    Manuelle Prüfung, Screenreader-Tests, priorisierter Maßnahmenplan. Tickets, keine PDFs.

    5–15 Werktage

  4. 04

    Umsetzung & Begleitung

    Sparringspartner, Reviewer oder direkt im Code. WCAG → Pull Requests.

    nach Bedarf

Vertikal · Narrow Column · With Progress Line + State Markers

  1. Erstgespräch

    Stattgefunden am 14. April · Termin für Bestandsaufnahme vereinbart.

  2. Bestandsaufnahme

    Scan abgeschlossen. 47 Findings dokumentiert, davon 12 kritisch.

  3. Audit & Bericht

    Aktuelle Phase. Manuelle Prüfung läuft. Zwischenstand: 8 / 47 verifiziert.

  4. Umsetzung & Begleitung

    Geplant ab KW 22. Bin Sparringspartner pro Sprint, kein Pauschal-Retainer.

TODO · WCAG 1.4.1 — Der Done-State nutzt aktuell nur Farbe als Indikator (gedämpfte Zahl + grüne Linie). Das verstößt gegen WCAG 1.4.1 (Use of Color). Lösung: einen Non-Color-Cue ergänzen — z. B. einen kleinen CSS-gezeichneten Kreis auf der Verbindungslinie als Shape-Wechsel. Muss vor Produktiveinsatz des Vertical Stepper umgesetzt werden.

Hero · Opener / Section Divider · Outlined Numerals · On Paper

  1. Kostenlos

    Erstgespräch

    30 Minuten, ohne Vertrag. Wir klären, ob wir zueinander passen.

  2. ½ Tag

    Bestandsaufnahme

    Scan, manuelle Sichtung, Sofort-Einschätzung.

  3. 5–15 Tage

    Audit & Bericht

    Manuelle Prüfung, Screenreader-Tests, priorisierter Plan.

  4. Optional

    Umsetzung

    WCAG → Pull Requests. Direkt im Code, wenn gewünscht.

Kompakt · Sidebar / Card Use

  1. 1–2 Tage

    IST-Analyse

    Bestehende Website auf Barrieren prüfen.

  2. 2–3 Tage

    Konzept

    Priorisierter Maßnahmenplan nach WCAG 2.2.

  3. variabel

    Umsetzung

    Barrierefreiheit direkt implementieren.

  4. 1 Tag

    Abnahme

    Konformität prüfen, Erklärung erstellen.

Muster

Zitate

Serif Italic als einzige Akzent-Stimme. Regel: eine italic-Geste pro View. <em> innerhalb des Zitats wird Bold + Akzentfarbe.

Default · Serif Italic 400 + Teal Keyline + Mono Attribution

Bei jeder Gestaltungsentscheidung: hilft dieses Element beim Verstehen — oder ist es nur Schmuck? Schmuck wird gestrichen.

Markus Stahmann Digitale Barrierefreiheit · 2025

Large · Hero / Opening Quote

Barrierefreies Design ist kein Kompromiss — es ist der höchste Standard, den gutes Design erreichen kann.

Karwai Pun Home Office · UK

Small · Inline within Long-form Article

„Accessible by default" heißt: ich muss mich später nicht erinnern, was ich vergessen habe.

Heydon Pickering Inclusive Components

Pull-Quote auf Ink-Surface — Italic Emphasis kippt zu Raw Amber

Ich übersetze WCAG in Pull Requests.

Markus Stahmann Über die Arbeit
Muster

Avatar & Byline

1 · Größen — SM 32 · MD 48 (Default) · LG 80

SM · 32
MD · 48
LG · 80

aria-hidden="true" auf dem Avatar — Name wird aus dem Kontext (Byline) gelesen.

2 · Square — Logo-Slot / Organisation

--radius-sm statt 50 % — für Org-/Logo-Slots in Testimonials.

3 · Ring — Brand-Akzent Outline (Theme-aware)

2 px page-bg Band + 2 px var(--accent) — Teal in Light, Cyan in Dark.

4 · Byline — Drei Dichten

.byline.byline--compact — List rows, inline meta

.byline — Standard für Posts, Karten

.byline.byline--stacked — Testimonial · About-Hero

5 · Im Kontext — Testimonial-Karte

Eine Sache war anders: Markus hat unsere Devs nicht mit WCAG-Paragraphen zugemüllt. Er hat Tickets geschrieben, die wir am Montag in den Sprint ziehen konnten.

Author-Hero — Komposition aus bestehenden Bausteinen

Avatar · Card · Eyebrow · Body · Accent-Italic · Outline-Badges · Mono-Meta-Liste — kein neuer Component-Code nötig.

Über mich

Markus Stahmann

Freelance Consultant für digitale Barrierefreiheit · WCAG 2.2 · BFSG

Ich übersetze WCAG in Pull Requests. Audits, Schulungen, inhouse-Begleitung — für Teams, die Barrierefreiheit als Engineering-Aufgabe verstehen, nicht als Checkliste am Releasetag.

WCAG 2.2 BFSG EN 301 549 CPACC seit 2022 Frontend · 14 J.
Standort
Berlin · remote DACH
Sprachen
Deutsch, Englisch
Aktiv seit
2018
Muster

Statistiken

Hero · Count-Up Animation (Scroll into View)

96%

der Top-Websites haben messbare WCAG-Verstöße auf der Startseite.

WebAIM Million · 2024 · 1 000 000 Homepages

Hero · With Serif Italic Accent + Decimal Count-Up

13 Mio.

Menschen in Deutschland leben mit einer amtlich anerkannten Behinderung.

Statistisches Bundesamt · 2023

Stat Row · Drei Stats, Hard-Rule Treatment

~30%

aller Online-Käufe scheitern an Barrieren.

Click-Away Pound 2019 · UK

28.06.2025

BFSG tritt in Kraft. Nicht-Compliance wird abmahnfähig.

Barrierefreiheitsstärkungsgesetz · § 37

€100k

maximaler Bußgeldrahmen für Marktüberwachungsverstöße.

BFSG · § 37 Abs. 2

Hero · On Ink Surface

74%

der geprüften Komponenten waren mit Screen-Readers nicht vollständig bedienbar.

Eigene Messung · NVDA 2024.4 · N=42

Muster

Hero

Seiteneinleitende Abschnitte in drei Varianten — je nach Seitentyp und Hierarchiestufe. Alle Varianten unterstützen einen optionalen Bild-Slot (slot="image").

A11y-Consultant · Hamburg

Digitale Teilhabe.
Für alle.

Ich helfe Agenturen und Unternehmen, digitale Produkte zugänglich zu machen — von der Analyse bis zur WCAG-konformen Umsetzung.

Barrierefreiheitsprüfung

Ihr Audit-Report in 2 Wochen.

Strukturierte WCAG 2.2 Prüfung mit priorisierten Maßnahmen — für Teams, die jetzt handeln müssen.

96%

der Homepages haben messbare WCAG-Fehler.

WebAIM Million 2024

Leistungen

A11y-Beratung & Audit

Vom ersten Audit bis zur Konformitätserklärung — strukturiert, messbar, nachhaltig.

Muster

Ablauf

Für Prozesse und Abläufe — z.B. "Wie läuft ein Audit ab?". Abgrenzung zum Stepper: kein Status, kein Grid, Fokus auf ausführlichen Beschreibungen. <ProcessFlow steps={[...]} />

A11Y-Annotation
  • <ol> für numerierte Variante (native Reihenfolge-Semantik), <ul> für Icon-Variante.
  • aria-label="Schritt X von Y: [Titel]" auf jedem <li> — Screenreader hören Kontext bei der Listen-Navigation.
  • Visueller Marker (aria-hidden) — Zählung kommt aus aria-label, nicht aus dem Marker-Text.
  • <aside aria-label="Hinweis"> für optionale Callout-Boxen innerhalb von Schritten (WCAG 1.3.1).
  • Keyboard: kein interaktives Element — nur lesend. Kein Fokus-Management nötig.

Nummeriert (Default) · mit Hinweis-Boxen

So läuft die Zusammenarbeit ab

  1. In einem 30-minütigen Video-Call klären wir, ob und wie ich helfen kann. Kein Pitch, kein Angebot — nur ein ehrliches Gespräch über den Status quo und was sinnvoll ist.

  2. Ich analysiere deine digitalen Angebote mit automatisierten Tools und manueller Sichtung. Ergebnis: ein Überblick über kritische Barrieren und den ungefähren Aufwand für die Behebung.

  3. Manuelle Prüfung nach WCAG 2.2, Screenreader-Tests (VoiceOver, NVDA), Tastatur-only-Navigation. Der Bericht priorisiert Befunde nach Schwere und Aufwand — kein akademisches PDF, sondern ein Arbeits-Dokument.

  4. Je nach Bedarf: Sparringspartner für dein Team, Reviewer für Pull Requests, oder ich arbeite direkt im Code. Das Ziel ist eine nachhaltige Verbesserung, nicht ein einmaliger Fix.

Icons · ohne Titel

  • Automatisierter Scan + manuelle Sichtung. Ich schaue mir an, was WCAG betrifft und was tatsächlich für echte Nutzer eine Barriere ist.

  • Befunde werden nach Schwere, WCAG-Kriterium und realem Impact priorisiert. Kein Alarmismus — nur das, was wirklich zählt.

  • Du bekommst konkrete Lösungsansätze: Code-Snippets, Design-Anpassungen, oder Verweise auf etablierte Muster.

  • Ich stehe für Rückfragen zur Verfügung, reviewe Umsetzungen und bestätige die Behebung — auch nach dem Bericht.

Muster

FAQ-Akkordeon

Gruppe von Disclosure-Elementen mit optionalem Kategoriefilter. Basis: native <details>/<summary> — kein JS für das Akkordeon selbst. Der Filter nutzt vanilla JS als progressive Enhancement (ohne JS: alle Items sichtbar).

A11Y-Annotation
  • Natives <details>/<summary> — kein ARIA für Toggle nötig. Zugänglich in VoiceOver, NVDA, JAWS.
  • Filter: <fieldset>/<legend> gruppieren die Radio-Buttons (WCAG 1.3.1).
  • Chip-Radio: Input visuell versteckt (sr-only-Technik), bleibt aber im Accessibility Tree. Focus-Indikator relay auf den sichtbaren Chip-Span via input:focus-visible + span (WCAG 2.4.11).
  • Filter-State: hidden-Attribut auf .faq__item — AT überspringt hidden-Elemente korrekt (semantisch besser als display:none via Klasse).
  • Mehrere FAQ-Komponenten auf einer Seite: eindeutige name-Attribute via uid — keine Radio-Gruppe-Konflikte.

Ohne Kategoriefilter

Häufige Fragen

Arbeitest du remote oder vor Ort?

Primär remote — das passt für fast alle Aufgaben. Workshops oder Schulungen mache ich auch vor Ort, hauptsächlich im norddeutschen Raum.

Was passiert nach dem Audit?

Du bekommst den Bericht und entscheidest, wie du weiter machst. Ich kann als Sparringspartner da sein, Umsetzungen reviewen, oder mich komplett raushalten. Kein Lock-in.

Wie lange dauert ein Audit?

Abhängig vom Umfang. Eine einzelne Webanwendung mit 5–10 Seiten: 5–10 Werktage. Komplexere Systeme oder native Apps können länger dauern.

Mit Kategoriefilter · Vanilla JS Progressive Enhancement

Nach Thema filtern
Was ist der Unterschied zwischen einem Quickcheck und einem Audit?

Der Quickcheck ist ein schneller Überblick in 1–2 Tagen: automatisierte Tools + manuelle Sichtung, Ergebnis als priorisierte Liste. Ein Audit ist tiefer — manuelle Prüfung aller Seiten nach WCAG 2.2, Screenreader-Tests, und ein ausführlicher Bericht mit konkreten Maßnahmen.

Brauche ich ein BFSG-konformes Produkt oder eine Barrierefreiheitserklärung?

Das kommt auf deinen Kontext an. Das BFSG gilt ab dem 28. Juni 2025 für Unternehmen mit digitalen Diensten an Verbraucher. Öffentliche Stellen sind seit 2020 durch die BITV verpflichtet. Ich helfe dir, den Bedarf einzuschätzen — ohne Juristerei, aber mit Blick auf die Realität.

Wie lange dauert ein Audit?

Abhängig vom Umfang. Eine einzelne Webanwendung mit 5–10 Seiten: 5–10 Werktage. Komplexere Systeme oder native Apps können länger dauern. Ich gebe dir nach der Bestandsaufnahme eine realistischere Schätzung.

Arbeitest du remote oder vor Ort?

Primär remote — das passt für fast alle Aufgaben. Workshops oder Schulungen mache ich auch vor Ort, hauptsächlich im norddeutschen Raum.

Was passiert nach dem Audit?

Du bekommst den Bericht und entscheidest, wie du weiter machst. Ich kann als Sparringspartner da sein, Umsetzungen reviewen, oder mich komplett raushalten. Kein Lock-in.

Muster

Szenarien

Für "Wer kommt zu mir und warum?" — auf Leistungsseiten und Landingpages. Zwei Varianten: Card-Grid und kompakte Liste. Jedes Szenario hat eine Situation, eine Reaktion und einen optionalen CTA.

A11Y-Annotation
  • Cards: <ul role="list"> mit <article> pro Item (WCAG 1.3.1: <article> kommuniziert Eigenständigkeit). role="list" stellt VoiceOver-Listensemantik wieder her.
  • CTA-Links: aria-label="[CTA-Text] – [Szenario-Titel]" — verhindert nicht-kontextuelle "Mehr erfahren"-Links (WCAG 2.4.4).
  • "Was ich tue"-Label ist aria-hidden — der folgende Text ist selbsterklärend. Label ist nur visuell hilfreich.
  • Keine dekorativen Bilder — Komponente erlaubt keine freien <img>-Tags ohne kontrollierten alt-Text.
  • Touch-Target CTAs: min-height durch Padding ≥ 44 px (WCAG 2.5.8).

Cards (Default) · Grid 3 Spalten

Wer kommt zu mir?

  • Ihr habt kein A11y-Know-how intern

    Euer Team ist stark in UI und Entwicklung, aber Barrierefreiheit ist konzeptionelles Neuland. Ihr wisst, dass ihr handeln müsst — aber nicht wie und wo anfangen.

    Ich mache die Bestandsaufnahme, erkläre was kritisch ist und warum, und gebe eurem Team ein Arbeits-Dokument das als Grundlage dient.

    Mehr zu Quickcheck & Audit
  • BFSG-Frist rückt näher

    Der 28. Juni 2025 ist ein harter Termin. Ihr seid unter Zeitdruck und braucht schnell eine realistische Einschätzung, was dringend ist — und was warten kann.

    Ich priorisiere nach Risiko, nicht nach WCAG-Vollständigkeit. Ihr bekommt einen realistischen Plan für die kritischsten Punkte.

  • Ihr habt bereits ein Audit — aber die Umsetzung stockt

    Befunde liegen vor, aber das Team kommt nicht voran: Unklarheiten, zu vage Formulierungen, fehlender Kontext für die Technologie.

    Ich übersetze den Bericht in konkrete technische Aufgaben, reviewe Pull Requests und stehe für Fragen zur Verfügung.

  • Ihr baut gerade neu — und wollt es von Anfang an richtig machen

    Neues Produkt, neues Design System, oder ein Relaunch. Ihr wollt Barrierefreiheit von Anfang an einbauen, nicht nachträglich flicken.

    Ich begleite Design und Entwicklung: Review der Komponenten, Patterns und Flows — bevor etwas live geht.

    Begleitung anfragen

Liste · kompakt · 2-spaltig ab 48rem

  • Ihr habt kein A11y-Know-how intern

    Euer Team ist stark in UI und Entwicklung, aber Barrierefreiheit ist konzeptionelles Neuland. Ihr wisst, dass ihr handeln müsst — aber nicht wie und wo anfangen.

    Ich mache die Bestandsaufnahme, erkläre was kritisch ist und warum, und gebe eurem Team ein Arbeits-Dokument das als Grundlage dient.

    Mehr zu Quickcheck & Audit
  • BFSG-Frist rückt näher

    Der 28. Juni 2025 ist ein harter Termin. Ihr seid unter Zeitdruck und braucht schnell eine realistische Einschätzung, was dringend ist — und was warten kann.

    Ich priorisiere nach Risiko, nicht nach WCAG-Vollständigkeit. Ihr bekommt einen realistischen Plan für die kritischsten Punkte.

  • Ihr habt bereits ein Audit — aber die Umsetzung stockt

    Befunde liegen vor, aber das Team kommt nicht voran: Unklarheiten, zu vage Formulierungen, fehlender Kontext für die Technologie.

    Ich übersetze den Bericht in konkrete technische Aufgaben, reviewe Pull Requests und stehe für Fragen zur Verfügung.

Muster

Vergleich

Zeigt denselben Befund einmal im Quickcheck-Format und einmal im Audit-Format. Macht den Unterschied der Leistungstiefe sichtbar. Side-by-Side statt Tabs: direkter Vergleich ohne JS, kein ARIA Tabs-Pattern nötig. Auf Mobile gestapelt.

Inhalte über Named Slots: slot="finding", slot="quickcheck", slot="audit". Labels als Props labelQuickcheck / labelAudit.

A11Y-Annotation
  • Kein ARIA Tabs-Pattern — Side-by-Side mit <h3>-Überschriften für die Spalten (WCAG 1.3.1). Die Unterscheidung liegt in den Überschriften, nicht nur in der Farbe (WCAG 1.4.1).
  • "Befund"-Label ist aria-hidden — der Slot-Inhalt spricht für sich. Das Label ist nur visueller Kontext.
  • Kein JS, kein State-Management — vollständig zugänglich ohne assistive Technologie-Anpassungen.
  • Keyboard: kein interaktives Element — rein lesend. Wenn der Slot interaktive Elemente enthält, gelten deren eigenen a11y-Regeln.

Reales Beispiel · Farbkontrast-Befund

Fehler: Schaltfläche "Weiter" hat einen Kontrast von 2,3:1 — deutlich unter dem WCAG 2.1 AA-Minimum von 4,5:1 für normalen Text.

Quickcheck

Kritisch (WCAG 1.4.3) — Button-Text auf Hintergrund nicht lesbar.

Empfehlung: Dunklere Textfarbe oder helleren Hintergrund wählen.

Audit

Failure: SC 1.4.3 Contrast (Minimum)

  • Gemessen: #9CA3AF auf #FFFFFF = 2,31:1 (WCAG Minimum: 4,5:1)
  • Betroffene Zustände: default, hover, focus
  • Lösung A: Text → #6B7280 ergibt 4,62:1 (knapp ausreichend)
  • Lösung B: Text → #374151 ergibt 8,59:1 (robust, empfohlen)
  • Reproduzierbar: Chrome 124, macOS 14, Light Mode

Beispiel · Fehlende Alt-Texte

Produktbilder in der Galerie haben kein alt-Attribut oder leeres alt="" — obwohl sie inhaltlich relevant sind.

Quickcheck

Hoch (WCAG 1.1.1) — Bilder ohne Textalternative.

Alle informationellen Bilder brauchen aussagekräftigen alt-Text.

Vollaudit

Failure: SC 1.1.1 Non-text Content

  • 14 von 17 Produktbildern: alt="" (leer, aber inhaltlich)
  • 3 Bilder: kein alt-Attribut — Screenreader liest Dateinamen
  • Kontext: Bilder zeigen Farbvarianten — diese Info fehlt nicht-visuellen Nutzern komplett
  • Empfohlenes Format: "Rucksack in Farbe Petrol, Vorderansicht"
  • Reproduziert mit VoiceOver/Safari, NVDA/Firefox
Muster

Logo-Leiste

Für Presse-Logos und Referenzen. Funktioniert mit SVG/PNG-Logos und als reinem Text-Fallback (Default). Logos werden in Graustufen gezeigt und auf Hover eingefärbt. Anonyme Referenzen zeigen einen neutralen Platzhalter.

Lizenzen beachten: Logos großer Medien/Unternehmen sind urheberrechtlich geschützt. Logos nur einbinden wenn eine entsprechende Genehmigung vorliegt. Text-Fallback ist der sichere Default.

A11Y-Annotation
  • Logos als <img> mit alt="[Firmenname]" (WCAG 1.1.1). Nicht als Background-Image (wäre für AT unsichtbar).
  • Anonyme Items: alt="" (dekorativ) + aria-label="Referenz" auf dem <li> — kein Klarname in der AT (WCAG 1.1.1).
  • Verlinkte Logos: aria-label="[Name] besuchen" auf dem <a> — Linkzweck alleine verständlich (WCAG 2.4.4).
  • role="list" auf <ul> — stellt VoiceOver-Listensemantik bei list-style:none wieder her.
  • Grayscale-Filter: rein visuell. alt-Text enthält immer den Firmennamen — kein Informationsverlust durch Graustufen (WCAG 1.4.1).

Press · Text-Fallback (Default)

Reference · Gemischt anonym / nicht-anonym · Text-Fallback

Reference · Vollständig anonym

Muster

Timeline

Für zeitliche Abläufe mit Datum und Status — BFSG-Fristen, Projektphasen. Abgrenzung zum Stepper: hat date-Felder und done / current / upcoming-States. Stepper = laufender Prozess, Timeline = Zeitachse.

A11Y-Annotation
  • <ol> — Reihenfolge ist bedeutungstragend (WCAG 1.3.1).
  • aria-current="step" am aktuellen Zeitpunkt (WCAG 4.1.3).
  • Status NICHT nur durch Farbe: jeder Punkt hat Text-Label ("Abgeschlossen" / "Aktuell" / "Ausstehend") + Icon-Shape (Haken / Punkt / Kreis) — WCAG 1.4.1.
  • Horizontale Variante kollabiert auf Mobile automatisch zu Vertikal (WCAG 1.4.10 Reflow).
  • Puls-Animation am "aktuell"-Marker: deaktiviert bei prefers-reduced-motion.

Horizontal (Default) · BFSG-Fristen

BFSG-Zeitplan

  1. Abgeschlossen

    BFSG verabschiedet

    Das Barrierefreiheitsstärkungsgesetz wird vom Deutschen Bundestag beschlossen — Umsetzung des European Accessibility Act (EAA).

  2. Aktuell

    BFSG tritt in Kraft

    Neue digitale Produkte und Dienstleistungen müssen ab diesem Datum barrierefrei sein.

  3. Ausstehend

    Übergangsfrist für Bestandsverträge

    Bestehende Verträge für Dienstleistungen müssen bis dahin nachgebessert sein.

Vertikal · Projektphasen

Projektverlauf

  1. Abgeschlossen

    Kick-off & Bestandsaufnahme

  2. Abgeschlossen

    Manueller Audit (WCAG 2.2)

    Screenreader-Tests, Tastatur-Navigation, Kontrast-Prüfung.

  3. Aktuell

    Bericht & Maßnahmenplan

    Aktuell in Bearbeitung. Rückfragen bis Freitag.

  4. Ausstehend

    Umsetzung & Begleitung

Muster

Hierarchiediagramm

Für Normenhierarchien und Beziehungsdiagramme. HTML-Lösung mit verschachtelten <ul> — zugänglicher als SVG bei 3–4 Ebenen. Unterstützt optionale Links und Beschreibungen pro Knoten.

A11Y-Annotation
  • Verschachtelte <ul>: Hierarchietiefe und Zugehörigkeit nativ kommuniziert (WCAG 1.3.1).
  • role="list" auf jeder <ul> — stellt VoiceOver-Listensemantik bei list-style:none wieder her.
  • Verbindungslinien: rein dekorative ::before/::after-Pseudo-Elemente — kein semantischer Inhalt.
  • Links: a.hierarchy-diagram__name hat selbsterklärenden Text (WCAG 2.4.4). Fokusring explizit gesetzt.
  • Horizontales Scrollen bei Überlauf (WCAG 1.4.10).

BFSG → EN 301 549 → WCAG 2.2 → DIN

Normenhierarchie: Barrierefreiheit

  • BFSG

    Barrierefreiheitsstärkungsgesetz · DE

    • EN 301 549

      Europ. Norm für IKT-Barrierefreiheit

      • WCAG 2.2

        W3C · Web Content Accessibility Guidelines

        • DIN EN 301 549

          Deutsche Fassung der EN 301 549

Muster

10–30–100

Visualisiert das Prinzip: Barrierefreiheit ist für 10% unerlässlich, für 30% notwendig, für 100% hilfreich. Eigene Formulierung — kein Zitat. Animation wird beim Einrollen in den Viewport ausgelöst (IntersectionObserver).

A11Y-Annotation
  • Konzentrische Ringe: aria-hidden="true" — rein dekorativ. Alle Inhalte als echter Text in der Tier-Liste.
  • .sr-only-Zusammenfassung der Grafik (WCAG 1.1.1).
  • Farbe + Rahmen + Text als kombiniertes Signal (WCAG 1.3.3 + 1.4.1).
  • Animation: --duration-* Tokens werden bei prefers-reduced-motion auf 0.01ms gesetzt (via _tokens.css) — kein separater Check nötig.

Barrierefreiheit betrifft alle

Visualisierung des 10-30-100-Prinzips: Barrierefreiheit ist für 10% der Menschen unerlässlich, für 30% notwendig und für 100% hilfreich.

  1. Unerlässlich

    Ohne geht es nicht

    Für Menschen mit dauerhaften Behinderungen ist Barrierefreiheit keine Komfortsache — sie ist die Voraussetzung für Teilhabe. Fehlende Zugänglichkeit schließt aus.

  2. Notwendig

    Besser wäre es

    Menschen in situativen Einschränkungen — schlechte Beleuchtung, laute Umgebung, gebrochener Arm, Stress — profitieren täglich von durchdachter Zugänglichkeit.

  3. Hilfreich für alle

    Gutes Design

    Klare Struktur, ausreichender Kontrast, präzise Sprache, verlässliche Navigation — das hilft allen. Barrierefreiheit und gutes Design sind kein Widerspruch.

Demo-Elemente

Demo: Farbfehlsichtigkeit

Interaktive Simulation der drei häufigsten Farbfehlsichtigkeiten. SVG-Filtermatrizen (Wickline-Näherung) auf einem Vorschaubereich. Hinweis auf Vereinfachung ist immer sichtbar.

A11Y-Annotation
  • Filter-Toggle: role="group" + aria-pressed pro Button (WCAG 4.1.2).
  • Die Simulation selbst ist nicht zugänglich (intentional demonstrativ) — der Hinweis "Vereinfachte Simulation" ist es.
  • SVG-Filterdefinitionen: aria-hidden="true" + focusable="false" (IE-Workaround).
  • transition: filter auf dem Vorschaubereich — visuell, kein Bezug zu prefers-reduced-motion.
  • Slot: eigener Content kann eingebettet werden. Default-Content demonstriert Farbe-als-einziges-Signal (Anti-Pattern).

Default-Content (Farbe als einziges Signal)

Wie sehen Farbfehlsichtige diese Seite?

Vereinfachte Simulation. CSS-Filter nähern Farbfehlsichtigkeit nur an — kein Ersatz für echte Simulationstools oder Nutzertests mit betroffenen Menschen.

Beispiel: Farbe als einziges Signal

Beispiel: Balkendiagramm ohne Legende (schlecht)

Beispiel: Text mit Farbkontrast-Unterschied

Guter Kontrast, grüner Text

Schlechter Kontrast, helles Grün

Guter Kontrast, roter Text

Schlechter Kontrast, helles Rot

Demo-Elemente

Demo: Tastaturnavigation

Zeigt gut vs. schlecht: sichtbare Fokusindikatoren und logische Tab-Reihenfolge vs. fehlende Indikatoren und falsche Reihenfolge via positiver tabindex-Werte. Besucher kann selbst durchnavigieren.

A11Y-Annotation
  • Toggle: role="group" + aria-pressed.
  • Warnhinweis vor der schlechten Demo: role="alert" — wird bei Aktivierung angekündigt (WCAG 4.1.3).
  • Schlechte Demo: outline:none nur scoped auf .keyboard-demo__input--no-focus — kein globales Reset.
  • Keine Fokus-Falle: Nutzer können jederzeit aus der Demo heraus-tabben.
  • Tab-Order-Badges: aria-hidden="true" — die Reihenfolge wird durch den DOM-Fluss / tabindex kommuniziert, nicht durch die Zahlen.

Tastaturnavigation: gut vs. schlecht

Drücke Tab um durch die fokussierbaren Elemente zu navigieren. Du kannst die Demo jederzeit mit Shift+Tab rückwärts oder durch Klick auf den Toggle verlassen.

Gute Tastaturnavigation

Kontaktformular

Tab-Reihenfolge entspricht der visuellen und logischen Lesereihenfolge. Fokusring ist immer sichtbar.

Demo-Elemente

Demo: Screenreader-Ausgabe

Zeigt vereinfacht, was ein Screenreader bei gut vs. schlecht strukturiertem HTML vorliest. Web Speech API (Browser-TTS). Hinweis auf Vereinfachung immer sichtbar. Graceful Degradation wenn API nicht verfügbar.

A11Y-Annotation
  • Play/Stop: zugängliche <button>-Elemente mit aria-label (WCAG 4.1.2).
  • aria-live="polite"-Region gibt Vorlese-Status bekannt (WCAG 4.1.3).
  • Kein Autoplay — Nutzer startet aktiv (WCAG 1.4.2 Audio Control).
  • Graceful Degradation: Play-Button wird disabled mit erklärendem Label wenn speechSynthesis fehlt.
  • Transcript-Text ist immer sichtbar — auch ohne TTS nutzbar.

Was der Screenreader vorliest

Stark vereinfacht. Echte Screenreader (NVDA, JAWS, VoiceOver) sind viel komplexer. Diese Simulation zeigt nur das Prinzip — kein Ersatz für echte Tests.

Was ein Screenreader vorliest

Das zugehörige HTML

<main>
  <section aria-labelledby="form-heading">
    <h2 id="form-heading">Kontaktformular</h2>
    <form>
      <label for="name">Ihr Name <span aria-label="Pflichtfeld">*</span></label>
      <input type="text" id="name" required />
      <button type="submit">Absenden</button>
    </form>
  </section>
</main>
Redaktionell

Callout-Box

Hervorgehobene Box für statischen redaktionellen Content — wichtige Hinweise, Warnungen oder Kerninformationen. Kein Ersatz für Alert (kein Live-Region, kein dynamisches Feedback).

Varianten

Redaktioneller Hinweis

Barrierefreiheit ist kein Add-on — sie muss von Anfang an in den Entwicklungsprozess integriert werden, nicht nachträglich hinzugefügt.

WCAG 2.2 — Oktober 2023

Die aktuelle Version der Web Content Accessibility Guidelines löst WCAG 2.1 ab und ergänzt u.a. Kriterien für kognitive Barrierefreiheit und Drag-and-Drop-Alternativen.

BFSG-Pflicht ab Juni 2025

Viele private Anbieter digitaler Produkte und Dienstleistungen fallen ab dem 28. Juni 2025 unter das Barrierefreiheitsstärkungsgesetz. Ausnahmen gelten nur für Kleinstunternehmen.

Praxistipp

Beginnt ein Audit mit automatisierten Tests (z.B. axe, WAVE) — diese decken ca. 30 % der WCAG-Kriterien ab und liefern schnell eine Übersicht. Den Rest findet nur manuelles Testen.

Ohne Titel

Kurze, eigenständige Hinweise können ohne Titel verwendet werden — der Variant-Typ dient dann als Accessible Name für Screenreader.
Ohne title erhält die Box aria-label="Warnung" — bei mehreren gleichen Varianten auf einer Seite sollten Titel gesetzt werden.

A11Y-Annotation

Semantik <aside> (complementary landmark) — supplementärer redaktioneller Content
Kein role="alert" Statischer Content braucht keinen Live-Region — das wäre falsche Semantik und würde Screenreader-Nutzer stören.
aria-label Immer gesetzt: Variant-Label + Titel (wenn vorhanden), z.B. "Warnung: BFSG-Pflicht ab Juni 2025". Macht mehrere Callouts in der Landmark-Liste unterscheidbar.
Tastatur Keine interaktiven Elemente im Standard-Callout — der Content ist im natürlichen Lesefokus erreichbar.
Kontrast text-primary auf allen tinted Backgrounds ≥ 14:1 (AAA). Titel je Variante mit Akzentfarbe: info-text, warning-text, teal-800 — alle ≥ 5,9:1.
Redaktionell

Persönlicher Einschub

Für persönliche Anmerkungen von Markus innerhalb von Fließtext oder Artikeln — klar als "Ich-Stimme" erkennbar. IBM Plex Serif kursiv als definierter Markenmoment. Nur ein Einschub pro Bildschirm verwenden.

Standard

Mit Betonung (em)

Abweichender Autor

A11Y-Annotation

Semantik <aside> mit aria-label="Persönliche Anmerkung von Markus Stahmann" — eindeutiger Landmark
Avatar aria-hidden="true" — rein dekorativ, die Information steckt im Autorenname
Kontrast Weiß auf Teal-700 (Avatar): 7,24:1 — AAA. Text-primary auf accent-bg (Mist): ≥ 14:1 — AAA.
Kursiv IBM Plex Serif italic ist keine rein dekorative Entscheidung — sie signalisiert "persönliche Stimme" und ist konsistent mit dem Pull-Quote-Muster.
Redaktionell

Definition / Glossar

Fachbegriffe erklären — inline im Text oder als eigenständiger Block. Macht Begriffe wie WCAG, BFSG oder ARIA verständlich ohne den Lesefluss zu unterbrechen.

Inline — Abkürzung (abbr)

Konformitätserklärungen nach WCAGWeb Content Accessibility Guidelines — internationaler Standard für digitale Barrierefreiheit (W3C) sind für viele Anbieter unter dem BFSGBarrierefreiheitsstärkungsgesetz — deutsches Umsetzungsgesetz der EU-Richtlinie 2019/882, gültig ab Juni 2025 ab Juni 2025 Pflicht.

Inline — Erstdefinition (dfn)

Der Begriff ScreenreaderAssistive Technologie, die Bildschirminhalte in Sprache oder Braille-Ausgabe überträgt — genutzt von blinden und sehbehinderten Menschen ist zentral für das Verständnis von Barrierefreiheit.

Block — mit Quelle und Link

WCAG
Web Content Accessibility Guidelines. Die vom W3C entwickelten internationalen Standards für digitale Barrierefreiheit — aktuell in Version 2.2 (Oktober 2023). Definieren Erfolgskriterien auf drei Konformitätsstufen: A, AA und AAA.
W3C · WCAG 2.2
BFSG
Barrierefreiheitsstärkungsgesetz. Deutsches Umsetzungsgesetz der EU-Barrierefreiheitsrichtlinie (2019/882). Verpflichtet viele private Anbieter digitaler Produkte und Dienstleistungen ab dem 28. Juni 2025 zur Einhaltung von Barrierefreiheitsanforderungen.
BFSG (BGBl. 2021 I Nr. 87)
ARIA
Accessible Rich Internet Applications. W3C-Spezifikation, die zusätzliche semantische Informationen für assistive Technologien bereitstellt — besonders für dynamische Inhalte und komplexe Widgets, für die natives HTML allein nicht ausreicht.
WAI-ARIA 1.2 · W3C

Block — ohne Quelle

Audit
Systematische Überprüfung eines digitalen Produkts auf Konformität mit WCAG-Erfolgskriterien. Umfasst automatisierte Tests, manuelle Prüfung und Screenreader-Tests.

A11Y-Annotation

Inline-Semantik <abbr> für Abkürzungen, <dfn> für Erstdefinitionen — je nach Kontext
Tastatur (Inline) tabindex="0" auf dem Wrapper-Span — per Tab fokussierbar, Tooltip erscheint bei :focus-visible. WCAG 2.1.1.
Screenreader (Inline) aria-describedbyrole="tooltip": Kurzform + Vollform werden vorgelesen. Kein title-Attribut (nicht per Tastatur erreichbar).
Block-Semantik <dl> / <dt> / <dd> — semantisch korrekt für Definitionen. <dfn> in <dt> markiert den definierten Begriff.
Tooltip-Einschränkung CSS-only: kein automatisches Repositionieren bei Viewport-Rand. Für lange Definitionen Block-Variante bevorzugen.
Dokumentation

Surfaces

surface--ink

Dunkel. Ruhig.

Teal-Links, Amber-Akzente — alle Farbtokens werden überschrieben, kein manuelles Theming nötig.

Erfolg Warnung Fehler Teal-Link

Alert auf Ink-Surface

Kontrast wird durch Surface-Token-Overrides sichergestellt.

surface--teal

Teal. Markant.

Weißer Text auf Teal — für Hero-Bereiche und starke CTAs.

Dokumentation

A11Y-Dokumentation

Baseline WCAG 2.2 AA
Stretch AAA, wo machbar
Methode WCAG + APCA
Standard EN 301 549
Recht (DE) BFSG (Juni 2025)
SR-Tests NVDA · JAWS · VoiceOver

1 · Compliance-Baseline

Das System zielt auf WCAG 2.2 AA als Minimum. AAA wird gehalten, wo es nicht mit Lesbarkeit, Wartbarkeit oder Brand-Voice kollidiert — das ist häufiger als oft angenommen, aber nicht überall.

APCA wird zusätzlich geprüft, weil WCAG-Kontrast bei sehr hellen oder warmen Hintergründen (z. B. --paper #F7F4EE) systematisch optimistische Werte liefert. APCA Lc ≥ 75 für Body, Lc ≥ 60 für Large Body, Lc ≥ 45 für Non-Text.

Wo WCAG und APCA divergieren, gewinnt das strengere der beiden. Token-Kommentare in colors_and_type.css notieren beide Werte pro Paarung.

BFSG (Juni 2025) ist die rechtliche Mindestkette in Deutschland für viele private Anbieter. Erfüllung von WCAG 2.2 AA reicht in den meisten Fällen aus — Details immer fallspezifisch prüfen.

2 · Kontrast-Matrix

Vollständige Audit-Tabelle der Token-Paarungen. Werte WCAG · APCA Lc gegen die jeweils relevante Surface (--paper oder --ink).

2.1 Text auf Surface (Paper #F7F4EE)

Token Surface WCAG APCA Lc Verdict
text-primary (ink)Paper17.2397.7AAA
text-secondaryPaper7.1777.5AAA
text-mutedPaper4.6066.4AA Body
text-disabledPaper3.1553.0UI 1.4.11
teal (link)Paper7.2477.8AAA
amber-textPaper6.3974.6AA Body
successPaper6.3374.3AAA
warningPaper7.7975.2AAA
dangerPaper5.9972.9AA Body
infoPaper5.9172.0AA Body

2.2 Text auf Ink (Dark / .surface--ink)

Token Surface WCAG APCA Lc Verdict
text-primary (paper)Ink17.2196.4AAA
text-secondaryInk9.4082.1AAA
cyan (link)Ink10.1485.8AAA
amber-on-darkInk7.1873.1AAA
success (dark)Ink9.9181.6AAA
warning (dark)Ink8.7476.9AAA
danger (dark)Ink5.9366.1AA Body
info (dark)Ink6.3067.0AA Body

2.3 Borders + UI-Cues (Non-text WCAG 1.4.11)

Token Surface WCAG Mindest Verdict
border-subtlePaper1.36≥ 3FAIL (nur Deko)
border-defaultPaper3.15≥ 3UI 1.4.11
border-strongPaper6.10≥ 3AAA
focus-lightPaper3.83≥ 3UI 1.4.11 ✓
focus-darkInk10.14≥ 3AAA ✓
focus-darkTeal4.40≥ 3UI 1.4.11 ✓

border-subtle ist explizit als dekorative Trennung in bereits gegliedertem Inhalt deklariert. Niemals als Border eines interaktiven Elements oder Inputs — dafür ist border-default da.

3 · Focus-Order & Skip-Link

DOM-Order = Focus-Order. Wir nutzen kein tabindex > 0. Skip-Link ist erstes fokussierbares Element auf jeder Seite, springt zum <main id="main">.

Fokus-Ring · Was zu erwarten ist. Stacked-Shadow-Pattern: 2 px page-bg Band → 2 px Cyan-Ring → 4 px Halo @ 0.20. Eine Regel ( :focus-visible) für alles. Auf hellen Surfaces nutzt sie --focus-light #0E8A82 (3.83 auf Paper, UI 1.4.11 ✓), auf dunklen --focus-dark #4FD1C5 (10.14 auf Ink, AAA).

4 · Tastatur-Map

Pro Komponente: was passiert, welche Tasten greifen, was nicht greift.

Erwartete Tastaturinteraktionen nach Komponente
Komponente Tasten Verhalten
Button Tab · Space · Enter Tab fokussiert, Space/Enter aktiviert. Native <button> — keine eigene Logik.
Link Tab · Enter Enter aktiviert (Space nicht — wäre Button-Verhalten).
Input · Textarea Tab · Texteingabe Direkte Eingabe. Enter in Single-line submitted das Formular.
Checkbox Tab · Space Space toggled. Native <input type="checkbox">.
Radio-Gruppe Tab · Tab fokussiert Gruppe, Pfeile bewegen Auswahl. Native Browser-Verhalten.
Select Tab · Space / Space öffnet, Pfeile navigieren Options. Native Browser-Verhalten.
Toggle Tab · Space Visuell Toggle, semantisch Checkbox. Space toggled.
Disclosure (<details>) Tab · Space / Enter Summary toggled Disclosure. Native — kein aria-expanded-Handling nötig.
Stepper Tab Stepper ist statisch, zeigt Fortschritt — keine Tastatur-Aktivierung. Wenn Steps Links sind: Enter springt.
Tabelle (sortierbar) Tab · Space / Enter Header-Button fokussierbar, Space/Enter sortiert. aria-sort spricht den Zustand aus.
Skip-Link Tab (erste Tab-Aktion) · Enter Erscheint bei :focus, Enter springt zu #main, fokussiert tabindex="-1"-Target.
Modal / Dialog (optional) Tab (gefangen) · Esc Native <dialog> mit showModal(). Esc schließt automatisch. Background inert.

Keine Tastatur-Falle.

Jede Tab-Reise muss verlassbar sein.

Kein tabindex > 0.

Reihenfolge regelt der DOM.

Focus visible.

Wir entfernen niemals den Focus-Ring — wir gestalten ihn.

Hover-only-Inhalte vermeiden.

Was bei Hover sichtbar wird, muss bei Fokus auch sichtbar werden.

5 · Screenreader-Konventionen

5.1 aria-live & Status-Regionen — Drei Stufen, klar getrennt

role="status" + aria-live="polite" Erfolg, Hinweise, Soft-Updates. SR liest, sobald die aktuelle Lesung pausiert.
role="alert" Submit-Fehler, kritische Server-Antworten. SR unterbricht. Sparsam.
aria-live="assertive" Nicht verwenden außer für Sicherheit (z. B. "Sitzung läuft ab in 30 s"). role="alert" reicht in 99 % der Fälle.

5.2 Versteckter Text — .sr-only

Klassisches visually hidden-Pattern, in utilities.css definiert. Verwendung: Icon-only Button-Labels, Kontext für Links (<a>Mehr<span class="sr-only"> — zum Audit-Beispiel</span ></a>), zusätzliche Tabellenhinweise.

5.3 Beschriftungs-Regeln

Eine Beschriftung pro Element. Nicht gleichzeitig aria-label + sichtbares Label — SR liest sonst doppelt oder das falsche.
Dekorative Icons aria-hidden="true". Informative Icons (z. B. Status-Symbol ohne Text daneben) bekommen role="img" + aria-label.
Formulare Immer sichtbares <label for="">. placeholder ist kein Label.
Buttons Sichtbarer Text oder aria-label — niemals nur ein Icon ohne Namen.
Bilder alt beschreibt Bedeutung, nicht Pixel. Dekorativ → alt="" (nie weglassen).

5.4 Tooltip — bewusst kein Component

Statt Hover-Bubble: sichtbarer Hinweis-Text unter dem Feld (.field__hint), via aria-describedby verknüpft. Keine versteckte Information, kein Touch-/Reduced-Motion-Problem, kein z-index-Kampf.

6 · Reduced Motion

@media (prefers-reduced-motion: reduce) setzt alle Transitionen auf 0,01 ms. Die Regel ist ausnahmslos — kein "wir lassen aber den Erfolgs-Bounce drin". Faustregel: Funktion bleibt, Bewegung geht.

SCHALTET AB

  • Alle CSS-Transitions (color, transform, shadow)
  • Hover-Lifts auf Cards
  • Animierte Reveals (Y-Shift + Fade)
  • Count-Up-Animation in Stat-Hero (snappt auf Endwert)
  • Toggle-Slide, Modal-Fade

BLEIBT AKTIV

  • Funktion der Komponente — Toggle toggled, Modal öffnet
  • Focus-Ring-Erscheinen (instant ist OK)
  • Skip-Link-Erscheinen (instant ist OK)
  • Layout-Verschiebungen aus echter DOM-Änderung (kein Animations-Issue)

7 · Dialog — optionales Pattern

Im System bewusst nicht gebaut, aber dokumentiert für den Fall, dass eine Funktion es braucht (Kontakt-Overlay, Cookie-Banner). Wenn ja: das native <dialog> nutzen, keinen Custom-Builder.

Minimales Dialog-Pattern HTML + JS
<dialog id="contact" aria-labelledby="contact-title">
  <h2 id="contact-title">Anfrage senden</h2>
  <!-- Formular-Inhalt -->
  <button type="button" data-close>Schließen</button>
</dialog>

document.querySelector('[data-open]')
  .addEventListener('click', () => contact.showModal());
document.querySelector('[data-close]')
  .addEventListener('click', () => contact.close());

showModal() handhabt automatisch: Focus-Trap innerhalb des Dialogs, Esc schließt, Rest der Seite ist programmatisch inert. Setze inert zusätzlich auf <body>-Kindern für Browser, die noch nicht voll konform sind.

Initialer Fokus aufs erste Form-Feld oder den primären Action-Button — nicht aufs Schließen-Kreuz. Bei Schließen: Fokus zurück auf das Trigger-Element.

8 · Forced Colors / Windows High Contrast

Wir setzen outline: 2px solid transparent auf jeden Focus-Ring. Das System rendert den Ring als box-shadow-Stack, der in Forced-Colors-Mode unsichtbar wäre — aber die transparente outline wird vom System auf Highlight umgefärbt und übernimmt nahtlos.

Status-Icons (Check, Warning, X) tragen die Bedeutung in Form, nicht in Farbe. Selbst wenn der OS-Modus alle Farben auf zwei Werte herunterbricht, bleibt der Status erkennbar.

9 · Was wir nicht tun

VISUELL / SYMBOLISCH

  • Rollstuhl-Piktogramm als A11Y-Symbol
  • Emoji als Status-/Brand-Element
  • Unicode-Symbole (✓ × ★) für Status (statt Phosphor-Fill)
  • Stock-Bilder von "diversen Teams"
  • Rounded Card mit farbigem Left-Border

INTERAKTION

  • Toast für Erfolg/Fehler (zu kurz, SR-Timing unsicher)
  • Hover-only Information
  • Disabled Submit-Button (Versuch verbieten = Frust)
  • opacity: 0.5 für disabled (Kontrast unkontrolliert)
  • placeholder als Label

10 · Checkliste vor Launch

Pragmatisches Minimum für jeden neuen Screen:

  • Tab-Reise einmal komplett — kein Trap, keine versteckten Stops, Focus-Ring überall sichtbar.
  • Skip-Link sichtbar bei erstem Tab, springt zum Main-Heading.
  • Headings in Reihenfolge (H1 → H2 → H3, nicht H1 → H3).
  • Bilder haben alt (nie absent, "" für Deko).
  • Formulare haben sichtbare <label>, Fehler haben aria-describedby.
  • Kontrast der wichtigsten Paarungen mit APCA gegengecheckt (nicht nur WCAG).
  • Reduced-Motion einmal mit OS-Setting reduce durchgeklickt.
  • SR-Test auf die Hauptaktion (NVDA oder VoiceOver) — wird das richtige Element angekündigt?
  • Forced-Colors mit Windows-High-Contrast-Mode geprüft.
  • Mobile-Touch-Targets ≥ 44 × 44 px (WCAG 2.5.5).

Menschliche Tests sind Pflicht. Automatisierte Tests (pa11y, Axe) finden ca. 30–40 % aller Barrieren. Echte Nutzbarkeit erfordert Tests mit Screenreader (VoiceOver, NVDA) und Tastatur-only. Alle größeren Änderungen am Interaktionsmodell sind durch eine Person mit Behinderung zu evaluieren.