// stack · a11y
Barrierefreiheit ist bei siteway kein Modul, das man dazukauft, sondern die Art, wie wir bauen. Jede Seite entsteht standardmäßig nach WCAG 2.2 auf Stufe AA und dem BFSG: semantisches HTML, sichtbarer Fokus, volle Tastatur-Bedienung, Kontraste ≥ 4,5:1 und Skalierung bis 200 %. Diese Seite zeigt das Handwerk dahinter — die Leistung buchst du bei Barrierefreiheit.
// definition
WCAG 2.2 sind die Web Content Accessibility Guidelines des W3C — der internationale Standard, der in prüfbaren Erfolgskriterien festlegt, wann eine Website barrierefrei ist. Seit Oktober 2023 ist die Fassung 2.2 die aktuelle Empfehlung. Ihre Kriterien ordnen sich vier Prinzipien zu: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein.
Für den deutschen Markt ist die Konformitätsstufe AA der Maßstab. Genau darauf verweist das BFSG über die EU-Norm EN 301 549 — wer seit Juni 2025 gesetzlich barrierefrei sein muss, baut nach WCAG-AA. Wir behandeln diese Kriterien nicht als Checkliste zum Schluss, sondern als Baumaterial: Sie stecken im Markup, in den Farb-Token und in jeder Komponente.
// praxis
standard, kein nachrüsten
Die meisten Ratgeber zu WCAG 2.2 erklären, was ein Kriterium verlangt. Die spannendere Frage ist, wie man es baut, ohne dass die Seite langsamer, komplizierter oder hässlicher wird. Unser Ansatz: Barrierefreiheit entsteht aus der Struktur, nicht aus einem Prüf-Werkzeug am Ende. Wenn das Fundament stimmt, sind die meisten AA-Kriterien schon erfüllt, bevor jemand testet.
Deshalb beginnt jede Seite mit semantischem HTML: Landmarks wie
header, nav,
main und footer, eine saubere
Überschriften-Hierarchie und echte button- und
a-Elemente statt geklickter div-Attrappen.
Diese Elemente bringen Rolle, Zustand und Tastatur-Bedienung von Haus aus mit — das Fundament, auf dem
unser Frontend aus HTML5, Tailwind und Vanilla JavaScript aufsetzt.
// p-01struktur
Landmarks, Listen, Tabellen und Formular-Labels bilden die Bedeutung im Markup ab. Ein Screenreader liest die Seite so, wie sie gemeint ist — ohne dass wir Bedeutung nachträglich behaupten müssen.
landmarks + headings
// p-02fokus
Kein outline:none ohne Ersatz. Wir setzen sichtbare Fokus-Ringe über :focus-visible mit ≥ 3:1 Kontrast — so sieht jeder Tastatur-Nutzer jederzeit, wo er steht.
:focus-visible ring
// p-03tastatur
Skip-Link, logische Tab-Reihenfolge, bedienbare Menüs und Dialoge mit Fokus-Fang. Wir testen jede Seite einmal komplett ohne Maus — was mit der Tastatur läuft, läuft auch mit Hilfsmitteln.
skip-link + tab-order
// p-04kontrast
Text-, Rahmen- und Signalfarben sind Design-Token mit geprüftem Kontrast — in hellem und dunklem Theme. Neue Komponenten erben die Werte, statt sie neu zu erfinden. Kein Ratespiel im Nachhinein.
farb-token je theme
// p-05skalierung
Schriftgrößen und Abstände in relativen Einheiten, flexible Layouts, Media-Queries auf den vergrößerten Zustand. Bei 200 % Zoom bricht nichts ab und nichts überlappt — der Inhalt fließt nur um.
200 % ohne verlust
// p-06aria
Erst HTML, dann ARIA. Wir greifen zu role, aria-label oder aria-live nur bei eigenen Widgets. Falsches ARIA schadet mehr, als es hilft — die erste Regel von ARIA ist, keins zu benutzen, wenn HTML reicht.
html > aria
// kontrast
unser default: 4,5:1
Kontrast ist das Kriterium, das am häufigsten reißt — meist, weil eine Markenfarbe zu blass gerät. WCAG 2.2 setzt klare Grenzen: 4,5:1 für normalen Fließtext, 3:1 für großen Text (ab 24 px oder 18,66 px fett), für grafische Bedienelemente und für Fokus-Indikatoren. Die höhere Stufe AAA verlangt 7:1.
Wir bauen standardmäßig auf 4,5:1 und prüfen jede Text-Hintergrund-Kombination automatisch beim Build — in beiden Themes. So fällt eine zu blasse Farbe auf, bevor sie live geht, nicht erst im Audit.
// version 2.2
9 neue kriterien · 3 die man merkt
WCAG 2.2 bringt neun neue Erfolgskriterien. Drei davon ändern die tägliche Bauweise spürbar — wir haben sie fest in Layout und Komponenten verdrahtet, damit sie nicht bei jeder neuen Seite neu bedacht werden müssen.
// 2.5.8target size
Bedienelemente sind mindestens 24 × 24 Pixel groß oder haben genug Abstand zueinander. Wir setzen das über Mindest-Trefferflächen in den Button- und Link-Komponenten — auch bei kleinen Icons.
24 × 24 px min.
// 2.4.11focus not obscured
Sticky-Header und Cookie-Banner dürfen das fokussierte Element nicht überdecken. Wir kalkulieren scroll-margin und die Höhe fixierter Leisten ein, damit der Fokus immer im Blick bleibt.
scroll-margin
// 2.4.13focus appearance
Der Fokus-Indikator ist groß und kontraststark genug, um ihn nicht zu übersehen — mindestens so viel Fläche wie ein 2-px-Rahmen und ≥ 3:1 Kontrast. Ein Wert, den unsere Fokus-Ringe zentral erben.
≥ 2 px · ≥ 3:1
// in echten projekten
sprachen & interaktive karten
Barrierefreiheit ist unkompliziert, solange eine Seite aus Text und Bildern besteht. Interessant
wird es bei Mehrsprachigkeit und interaktiven Bausteinen. Bei mehrsprachigen
Websites zahlt sich konsequente Semantik doppelt aus:
ein korrektes lang-Attribut je Sprachfassung, damit Screenreader richtig
aussprechen, und eine Struktur, die über alle Sprachfassungen identisch trägt.
Interaktive Karten sind der zweite Härtefall für WCAG 2.2 — der Kartencanvas allein ist für Tastatur und Screenreader kaum zu greifen. Unsere Antwort: eine bedienbare Liste als gleichwertiger Zugang neben der Karte, sinnvolle Namen für Bedienelemente und ein Fokus, der nie in einer unsichtbaren Falle landet. Wie tief so etwas geprüft wird, steht beim Barrierefreiheits-Audit.
// faq
WCAG 2.2 (Web Content Accessibility Guidelines) ist der internationale W3C-Standard für barrierefreie Webinhalte, seit Oktober 2023 in Kraft. Er ordnet 87 prüfbare Erfolgskriterien vier Prinzipien zu: wahrnehmbar, bedienbar, verständlich und robust. In Deutschland ist die Konformitätsstufe AA der praktische Zielwert — an ihr misst sich auch das BFSG. siteway baut jede Seite standardmäßig gegen diese AA-Kriterien.
Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 und verpflichtet viele private Anbieter — etwa Online-Shops, Banken und Buchungsdienste — zu barrierefreien digitalen Angeboten. Es verweist technisch auf die europäische Norm EN 301 549, die wiederum WCAG 2.1/2.2 auf Stufe AA übernimmt. Praktisch heißt das: Wer BFSG-konform sein muss, baut nach WCAG-AA. siteway setzt diese Kriterien direkt im Markup und CSS um, nicht per nachträglichem Overlay.
WCAG 2.2 auf Stufe AA verlangt für normalen Fließtext ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund. Für großen Text (ab 24 Pixel, oder 18,66 Pixel fett) sowie für grafische Bedienelemente und Fokus-Indikatoren reichen 3:1. Stufe AAA fordert 7:1. siteway legt diese Schwellen als Farb-Token an und prüft sie automatisch — in hellem wie dunklem Theme.
Nur dort, wo semantisches HTML an seine Grenzen stößt. Ein Button ist ein button, ein Link ist ein a — diese Elemente bringen Rolle, Zustand und Tastatur-Bedienung von sich aus mit. ARIA ergänzt erst bei eigenen Widgets wie Tabs, Dialogen oder Live-Regionen. Falsches oder überflüssiges ARIA verschlechtert die Zugänglichkeit oft, statt sie zu verbessern — deshalb gilt bei siteway die Regel: erst HTML, dann ARIA.
WCAG 2.2 ergänzt neun Erfolgskriterien gegenüber 2.1. Für die Umsetzung am wichtigsten: Target Size (Minimum) verlangt Klickflächen von mindestens 24 × 24 Pixeln oder entsprechenden Abstand (2.5.8), Focus Not Obscured sorgt dafür, dass Sticky-Header oder Cookie-Banner das fokussierte Element nicht verdecken (2.4.11), und Focus Appearance schärft, wie deutlich der Tastatur-Fokus sichtbar sein muss. siteway baut diese Kriterien fest in Komponenten und Layout ein.
Ja. WCAG-Erfolgskriterium 1.4.4 verlangt, dass sich Text bis 200 % vergrößern lässt, ohne dass Inhalt oder Funktion verloren gehen. siteway erreicht das mit relativen Einheiten (rem/em) statt fester Pixel, flexiblen Layouts und Media-Queries, die den vergrößerten Text abfangen — so bleibt die Seite auch bei starkem Zoom bedien- und lesbar, statt Text abzuschneiden oder zu überlappen.
// womit das zusammenhängt
leistung, audit & stack
// leistung · buchen
Diese Seite erklärt die Technik — die Leistung setzt sie um: eine barrierefreie Website nach WCAG 2.2 und BFSG, mit Prüfbericht.
zur leistung →
// leistung · prüfen
Bestehende Seite gegen WCAG 2.2 geprüft — mit Tastatur, Screenreader und echten Hilfsmitteln, nicht nur mit einem Scanner.
zum audit →
// stack · frontend
Das Fundament der Zugänglichkeit: semantisches HTML5, Tailwind und Vanilla JavaScript — ohne Framework-Ballast.
zum stack →
// Website, die alle bedienen können?
Projekt anfragen