// p-01perceivable
Wahrnehmbar.
Inhalte müssen für alle Sinne zugänglich sein: Alternativtexte für Bilder, Untertitel für Videos, Kontraste von mindestens 4,5:1 für Text — und nichts, das nur über Farbe kommuniziert.
alt-texte + kontraste
// svc-08 · barrierefreiheit
Eine barrierefreie Website heißt bei siteway: bedienbar per Tastatur, lesbar für Screenreader, Kontraste nach WCAG 2.2 — und konform mit dem BFSG, das seit dem 28. Juni 2025 gilt. Geprüft wird mit echten Hilfsmitteln, nicht nur mit Tools. Heraus kommt ein WCAG-Prüfbericht, den du vorzeigen kannst.
// definition
Eine barrierefreie Website können alle Menschen nutzen — unabhängig von Sehvermögen, Gehör, Motorik oder Hilfsmitteln wie Screenreadern. Der Maßstab dafür sind die Web Content Accessibility Guidelines (WCAG) 2.2 in der Konformitätsstufe AA. Seit dem 28. Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz (BFSG) genau das von vielen Unternehmen auch rechtlich.
In der Praxis heißt das: Jede Funktion geht ohne Maus. Bilder haben Alternativtexte, Videos Untertitel. Kontraste liegen bei mindestens 4,5:1, die Seite verträgt 200 % Zoom ohne Funktionsverlust. Und die Struktur ist so sauber, dass ein Screenreader sie versteht — dieselbe Struktur, von der auch SEO & GEO profitieren.
// gesetz
keine übergangsfrist mehr · das gesetz gilt
Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 — den European Accessibility Act — in deutsches Recht um. Es gilt seit dem 28. Juni 2025 und verpflichtet Unternehmen, die Produkte oder Dienstleistungen für Verbraucher digital anbieten: Online-Shops, Buchungsstrecken, Kontakt- und Bestellformulare — kurz: elektronischer Geschäftsverkehr. Ausgenommen sind nur Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens 2 Mio. € Jahresumsatz.
Verstöße sind kein Kavaliersdelikt: Die Marktüberwachungsbehörden der Länder können Bußgelder bis 100.000 € verhängen, Mitbewerber können abmahnen. Aber die Pflicht ist nur die halbe Rechnung — barrierefreie Seiten sind für alle besser bedienbar, erreichen mehr Menschen und bringen die saubere Struktur gleich mit, die Google und KI-Systeme belohnen. Wir bauen sie deshalb nicht als Pflichtübung, sondern als Qualitätsmerkmal.
// wcag 2.2 · pour
wahrnehmbar · bedienbar · verständlich · robust
Die WCAG 2.2 ordnen alle Anforderungen vier Prinzipien zu — im Standard „POUR" genannt. Wer sie kennt, versteht jede einzelne Maßnahme. Wir prüfen und bauen entlang genau dieser vier Achsen, auf Konformitätsstufe AA.
// p-01perceivable
Inhalte müssen für alle Sinne zugänglich sein: Alternativtexte für Bilder, Untertitel für Videos, Kontraste von mindestens 4,5:1 für Text — und nichts, das nur über Farbe kommuniziert.
alt-texte + kontraste
// p-02operable
Jede Funktion geht ohne Maus: vollständige Tastaturbedienung, sichtbarer Fokus in logischer Reihenfolge, Skip-Links, ausreichend große Klickziele — und keine Zeitlimits, die Nutzer aussperren.
tastatur + fokus
// p-03understandable
Klare Sprache, konsistente Navigation, Formulare mit Labels und Fehlermeldungen, die sagen, was zu tun ist. Niemand soll raten müssen, was ein Feld erwartet oder warum ein Absenden scheitert.
sprache + formulare
// p-04robust
Sauberes, valides Markup, das Browser und Hilfsmittel zuverlässig interpretieren: semantische HTML-Elemente, korrekte Landmarks, ARIA nur dort, wo HTML allein nicht reicht.
html + aria
// leistung · 6 bausteine
vom audit bis zum prüfbericht
Sechs Bausteine, ein Ergebnis: eine Website, die WCAG 2.2 AA erfüllt und das BFSG einhält — nachgewiesen im Prüfbericht statt behauptet im Angebot. Ob Neubau oder Nachrüstung einer bestehenden Seite: Die Bausteine sind dieselben, nur der Startpunkt unterscheidet sich.
// b-01audit
Bestandsaufnahme nach WCAG 2.2: Tastatur, Screenreader, Kontraste, Fokus. Jeder Befund mit Fundstelle und Schweregrad — auch einzeln buchbar als Audit a-15.
output: a11y-befund
// b-02struktur
Überschriften-Hierarchie, Landmarks, native Elemente statt Div-Suppe. ARIA setzen wir gezielt ein — nur dort, wo HTML allein nicht reicht, denn falsches ARIA ist schlimmer als keins.
output: markup
// b-03bedienung
Jede Funktion ohne Maus erreichbar: logische Tab-Reihenfolge, sichtbarer Fokusring, Skip-Links, bedienbare Menüs und Dialoge. Wer nur die Tastatur hat, kommt überall hin.
output: fokus-pfade
// b-04design
Kontrastverhältnisse von mindestens 4,5:1 für Text, skalierbare Schriften, Zoom bis 200 % ohne Funktionsverlust. Das fließt direkt in die Design-Tokens — nicht als Korrektur hinterher.
output: kontrast-report
// b-05inhalte
Alternativtexte für Bilder, Untertitel für Videos, Formulare mit Labels, klaren Fehlermeldungen und ohne Zeitdruck. Die Stellen, an denen die meisten Anfragen verloren gehen.
output: alt-texte + labels
// b-06nachweis
Manuelle Tests mit Screenreader und Tastatur plus automatisierte Checks. Am Ende steht ein Prüfbericht mit allen Kriterien, Ergebnissen und Restpunkten — dein Nachweis gegenüber Behörden und Kunden.
output: wcag-prüfbericht
// prüfung
tools finden fehler · menschen finden barrieren
Automatische Tools wie axe oder Lighthouse finden nur einen Teil der Barrieren — fehlende Alt-Texte ja, eine unverständliche Fokus-Reihenfolge nein. Ob eine Seite wirklich benutzbar ist, zeigt sich erst mit den Hilfsmitteln, die Betroffene tatsächlich verwenden. Deshalb prüfen wir vierfach:
// t-01screenreader
Wir hören die Seite mit NVDA und VoiceOver: Werden Überschriften, Links und Formularfelder korrekt angesagt? Ergibt die Lesereihenfolge Sinn? Was ein Screenreader falsch vorliest, ist für blinde Nutzer unsichtbar.
nvda · voiceover
// t-02tastatur
Maus abgesteckt, einmal komplett durch die Seite: Navigation, Formulare, Dialoge, Suche. Jeder Punkt, an dem der Fokus hängen bleibt oder verschwindet, kommt als Befund in den Bericht.
tab · enter · esc
// t-03sehen
200 % Zoom ohne horizontales Scrollen, Kontrast-Messung gegen die 4,5:1-Schwelle, Check auf reine Farb-Kommunikation. Getestet in beiden Farbschemata — hell und dunkel.
zoom 200% · 4,5:1
// t-04automatisiert
axe und Lighthouse laufen zusätzlich — als Regressionsschutz in der CI/CD-Pipeline. So bleibt barrierefrei, was einmal barrierefrei war, auch nach dem nächsten Feature.
axe · lighthouse · ci
// ablauf · 5 schritte
jeder schritt ein ergebnis · ein prüfbericht am ende
// schritt 01 · audit
Wir prüfen die Seite nach WCAG 2.2 — mit Tastatur, Screenreader und Kontrast-Messung. Jede Barriere mit Fundstelle, Kriterium und Schweregrad.
output: a11y-befund
// schritt 02 · plan
Blocker zuerst: Was Nutzer komplett aussperrt, kommt vor Schönheitsfehlern. Du bekommst einen Maßnahmenplan mit Aufwänden — und einen Festpreis für die Umsetzung.
output: maßnahmenplan
// schritt 03 · umsetzung
Markup, Fokus-Führung, Kontraste, Alt-Texte, Formulare — direkt in den Templates deines CMS, ob TYPO3, WordPress oder Statamic. Kein Overlay, keine Symptombehandlung.
output: fixes
// schritt 04 · test
Kompletter Durchlauf mit Screenreader, Tastatur und Zoom — plus automatisierte Checks als Regressionsschutz für die Zukunft.
output: testprotokoll
// schritt 05 · nachweis ● ergebnis
Du bekommst den WCAG-Prüfbericht mit allen Kriterien und Ergebnissen — auf Wunsch inklusive Barrierefreiheitserklärung und Feedback-Mechanismus für deine Website.
output: wcag-prüfbericht
// faq
Eine barrierefreie Website können alle Menschen nutzen — unabhängig von Sehvermögen, Gehör, Motorik oder Hilfsmitteln wie Screenreadern. Der Maßstab dafür sind die Web Content Accessibility Guidelines (WCAG) 2.2 in der Konformitätsstufe AA: bedienbar per Tastatur, ausreichende Kontraste, Alternativtexte und eine Struktur, die Vorlese-Software versteht.
Seit dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) Unternehmen, die Produkte oder Dienstleistungen für Verbraucher digital anbieten — vor allem Online-Shops und Websites mit elektronischem Geschäftsverkehr wie Buchung, Bestellung oder Vertragsabschluss. Ausgenommen sind Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz. Öffentliche Stellen sind über BITV und EU-Recht schon länger verpflichtet.
Die Marktüberwachungsbehörden der Länder kontrollieren die Einhaltung und können Bußgelder bis 100.000 Euro verhängen. Dazu kommen Abmahnungen durch Mitbewerber und Verbände — und im Ernstfall die Anordnung, das Angebot einzustellen, bis es barrierefrei ist.
Die WCAG 2.2 sind der internationale Standard für barrierefreie Webinhalte, veröffentlicht vom W3C. Sie kennen drei Stufen: A (Minimum), AA (Standard) und AAA (erweitert). Stufe AA ist der übliche rechtliche Maßstab — sie verlangt unter anderem Kontrastverhältnisse von mindestens 4,5:1 für Text, vollständige Tastaturbedienung und sichtbaren Fokus. Auch die EN 301 549, auf die sich das BFSG stützt, baut auf den WCAG auf.
Nein. Overlays legen eine Werkzeugleiste über die Seite, beheben aber die Barrieren im Code nicht: fehlende Alternativtexte, kaputte Tastaturnavigation oder unverständliche Formulare bleiben bestehen. Barrierefreiheit entsteht im Markup, nicht in einem nachgeladenen Skript. Deshalb bauen wir sie direkt in Struktur, Design und Templates ein.
Ja, in den meisten Fällen. Am Anfang steht ein Barrierefreiheits-Audit: Wir prüfen die Seite nach WCAG 2.2 mit Tastatur, Screenreader und Kontrast-Checks und priorisieren die Befunde nach Schwere. Danach entscheidest du, ob wir nachbessern oder ob sich — bei sehr altem Unterbau — ein Relaunch mehr lohnt.
Festpreis nach Briefing. Der Aufwand hängt davon ab, ob Barrierefreiheit von Anfang an mitgebaut wird — dann kostet sie kaum extra — oder ob eine bestehende Seite nachgerüstet wird. Das Audit ist einzeln buchbar und liefert die Grundlage für ein verbindliches Angebot.
// verwandte leistungen
alle leistungen im überblick
// svc-02 · design
Kontraste, Fokus-Zustände und Schriftgrößen entstehen im Design — nicht als Korrektur danach.
weiterlesen →
// svc-03 · code
Semantisches Markup ist das Fundament jeder barrierefreien Website — wir bauen es von Anfang an so.
weiterlesen →
// svc-09 · betrieb
Barrierefrei bleiben: automatisierte Checks und Reviews sichern den Stand auch nach Updates und neuen Inhalten.
weiterlesen →
// Website barrierefrei machen?
Briefing starten