Focus · Adaptive Ring — Cyan-Family · 3-Layer-Stack
Stacked-Shadow-Pattern: 2 px page-bg Band →
2 px Cyan-Ring → 4 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 · AANon-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-ringTeal-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)
.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)
.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.
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-sm16pxInline-Icons, Labels, Badges
--icon-md18pxUI Standard, Schaltflächen
--icon-lg20pxTouch-Targets, Hero-Elemente
Barrierefreiheit & Verwendung
Dekorativaria-hidden="true" auf dem <i> —
kein weiteres Markup nötig. Label kommt aus dem umgebenden Text.
Icon-Buttonaria-label="…" auf dem <button>,
aria-hidden="true" auf dem Icon. Beispiel:
aria-label="Menü schließen".
Status-IconIcon aria-hidden="true" + sichtbarer Text daneben. Status
nie ausschließlich über Icon kommunizieren (WCAG 1.4.1).
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.2BarrierefreiheitEntfernbar
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.
Kritischer Fehler
Formulare ohne Labels sind für Screenreader-Nutzer nicht bedienbar —
Level-A-Verstoß.
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.
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.
Compact · Blog-Artikel TOC (Mobile)
Inhaltsverzeichnis
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.
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
Kostenlos
01
Erstgespräch
30 Minuten, ohne Vertrag. Wir klären, ob wir zueinander passen.
Markus StahmannFreelance Consultant · Digitale BarrierefreiheitBerlin · seit 2018 · auch farbsehschwach
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.
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.13 Mio.
Menschen in Deutschland leben mit einer amtlich anerkannten Behinderung.
Statistisches Bundesamt · 2023
Stat Row · Drei Stats, Hard-Rule Treatment
~30%~30 %
aller Online-Käufe scheitern an Barrieren.
Click-Away Pound 2019 · UK
28.06.202528.06.2025
BFSG tritt in Kraft. Nicht-Compliance wird abmahnfähig.
Barrierefreiheitsstärkungsgesetz · § 37
€100k€100k
maximaler Bußgeldrahmen für Marktüberwachungsverstöße.
BFSG · § 37 Abs. 2
Hero · On Ink Surface
74%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").
Statement — große Typografie, Text + CTA
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.
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
01
Erstgespräch
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.
02
Bestandsaufnahme
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.
03
Audit & Bericht
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.
04
Umsetzung & Begleitung
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
Analyse
Automatisierter Scan + manuelle Sichtung. Ich schaue mir an, was WCAG betrifft und was tatsächlich für echte Nutzer eine Barriere ist.
Bewertung
Befunde werden nach Schwere, WCAG-Kriterium und realem Impact priorisiert. Kein Alarmismus — nur das, was wirklich zählt.
Empfehlung
Du bekommst konkrete Lösungsansätze: Code-Snippets, Design-Anpassungen, oder Verweise auf etablierte Muster.
Begleitung
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
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.
"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.
Was ich tue
Ich mache die Bestandsaufnahme, erkläre was kritisch ist und warum, und gebe eurem Team ein Arbeits-Dokument das als Grundlage dient.
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.
Was ich tue
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.
Was ich tue
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.
Was ich tue
Ich begleite Design und Entwicklung: Review der Komponenten, Patterns und Flows — bevor etwas live geht.
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.
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
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
Befund
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).
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
Abgeschlossen
BFSG verabschiedet
Das Barrierefreiheitsstärkungsgesetz wird vom Deutschen Bundestag beschlossen — Umsetzung des European Accessibility Act (EAA).
Aktuell
BFSG tritt in Kraft
Neue digitale Produkte und Dienstleistungen müssen ab diesem Datum barrierefrei sein.
Ausstehend
Übergangsfrist für Bestandsverträge
Bestehende Verträge für Dienstleistungen müssen bis dahin nachgebessert sein.
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.
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.
10%
30%
100%
10 %
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.
30 %
Notwendig
Besser wäre es
Menschen in situativen Einschränkungen — schlechte Beleuchtung, laute Umgebung, gebrochener Arm, Stress — profitieren täglich von durchdachter Zugänglichkeit.
100 %
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.
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.
Demo-Modus: Die folgende Simulation enthält intentional fehlende Fokusindikatoren
und eine unlogische Tab-Reihenfolge — um Barrieren erfahrbar zu machen.
Gute Tastaturnavigation
Tab-Reihenfolge entspricht der visuellen und logischen Lesereihenfolge. Fokusring ist
immer sichtbar.
Schlechte Tastaturnavigation
Falsche Tab-Reihenfolge durch positive tabindex-Werte. Kein sichtbarer Fokusindikator.
Linktext "Mehr erfahren" ist nicht selbsterklärend.
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.
Web Speech API ist in diesem Browser nicht verfügbar. Text oben zeigt, was vorgelesen werden
würde.
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.
Kein role="alert"Statischer Content braucht keinen Live-Region — das wäre
falsche Semantik und würde Screenreader-Nutzer stören.
aria-labelImmer gesetzt: Variant-Label + Titel (wenn vorhanden), z.B.
"Warnung: BFSG-Pflicht ab Juni 2025". Macht mehrere
Callouts in der Landmark-Liste unterscheidbar.
TastaturKeine interaktiven Elemente im Standard-Callout — der Content
ist im natürlichen Lesefokus erreichbar.
Kontrasttext-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
Avatararia-hidden="true" — rein dekorativ, die Information
steckt im Autorenname
KontrastWeiß auf Teal-700 (Avatar): 7,24:1 — AAA. Text-primary auf
accent-bg (Mist): ≥ 14:1 — AAA.
KursivIBM 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.
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.
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-describedby → role="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änkungCSS-only: kein automatisches Repositionieren bei Viewport-Rand.
Für lange Definitionen Block-Variante bevorzugen.
Redaktionell
Das sagt das Gesetz
Spezialisierte Box für Zitate und Verweise aus Gesetzen und Normen — BFSG,
WCAG, BITV, EN 301 549. Visuell sofort als offiziell erkennbar, klar
getrennt vom redaktionellen Fließtext.
Direktes Zitat — mit Link
Das sagt das Gesetz
Produkte und Dienstleistungen müssen so gestaltet sein, dass sie von
Menschen mit Behinderungen wahrgenommen, bedient und verstanden
werden können und robust genug sind, um mit assistiven Technologien
verwendet zu werden.
Der visuelle Kontrast zwischen Text und Hintergrund muss mindestens
4,5:1 betragen. Für großen Text (≥ 18 pt oder ≥ 14 pt fett) gilt ein
Mindestwert von 3:1.
WCAG 2.2 SC 1.4.3
Normverweis — abweichendes Label
Das sagt die Norm
Webinhalte müssen die Konformitätsstufe AA der WCAG 2.1 erfüllen.
Die europäische Norm harmonisiert damit die Anforderungen für
öffentliche Stellen in der EU.
EN 301 549 · Abschnitt 9
Paraphrase (paraphrase-Prop)
A11Y-Annotation
Zitat-Semantik<figure> +
<blockquote cite="URL"> +
<figcaption>. Das cite-Attribut
referenziert die Quelle maschinenlesbar.
Paraphrase-Semantik<aside> mit
aria-label="Label: Quelle" — kein
<blockquote> bei sinngemäßer Wiedergabe.
Quelle-LinkWenn href gesetzt: <cite>
+ Pfeil-Icon in einem <a>. WCAG 2.4.4:
Link-Text eindeutig durch Quellenname.
IconWaage-Symbol (ph-scales) ist
aria-hidden="true" — die Information "offiziell" steckt
im Label-Text, nicht im Icon.
Dokumentation
Surfaces
surface--ink
Dunkel. Ruhig.
Teal-Links, Amber-Akzente — alle Farbtokens werden überschrieben,
kein manuelles Theming nötig.
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
BaselineWCAG 2.2 AA
StretchAAA, wo machbar
MethodeWCAG + APCA
StandardEN 301 549
Recht (DE)BFSG (Juni 2025)
SR-TestsNVDA · JAWS · VoiceOver
Inhaltsverzeichnis
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)
Paper
17.23
97.7
AAA
text-secondary
Paper
7.17
77.5
AAA
text-muted
Paper
4.60
66.4
AA Body
text-disabled
Paper
3.15
53.0
UI 1.4.11
teal (link)
Paper
7.24
77.8
AAA
amber-text
Paper
6.39
74.6
AA Body
success
Paper
6.33
74.3
AAA
warning
Paper
7.79
75.2
AAA
danger
Paper
5.99
72.9
AA Body
info
Paper
5.91
72.0
AA Body
2.2 Text auf Ink (Dark / .surface--ink)
Token
Surface
WCAG
APCA Lc
Verdict
text-primary (paper)
Ink
17.21
96.4
AAA
text-secondary
Ink
9.40
82.1
AAA
cyan (link)
Ink
10.14
85.8
AAA
amber-on-dark
Ink
7.18
73.1
AAA
success (dark)
Ink
9.91
81.6
AAA
warning (dark)
Ink
8.74
76.9
AAA
danger (dark)
Ink
5.93
66.1
AA Body
info (dark)
Ink
6.30
67.0
AA Body
2.3 Borders + UI-Cues (Non-text WCAG 1.4.11)
Token
Surface
WCAG
Mindest
Verdict
border-subtle
Paper
1.36
≥ 3
FAIL (nur Deko)
border-default
Paper
3.15
≥ 3
UI 1.4.11
border-strong
Paper
6.10
≥ 3
AAA
focus-light
Paper
3.83
≥ 3
UI 1.4.11 ✓
focus-dark
Ink
10.14
≥ 3
AAA ✓
focus-dark
Teal
4.40
≥ 3
UI 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 keintabindex > 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.
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 Iconsaria-hidden="true". Informative Icons (z. B.
Status-Symbol ohne Text daneben) bekommen role="img" + aria-label.
FormulareImmer sichtbares <label for="">. placeholder ist kein Label.
ButtonsSichtbarer Text oder aria-label — niemals nur ein Icon
ohne Namen.
Bilderalt 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.
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)
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.