BFSG, BaFG, BehiG: Barrierefreiheit für Arzt-Websites in DACH

Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG), in Österreich das Barrierefreiheitsgesetz (BaFG). Beide setzen die EU-Richtlinie 2019/882 (European Accessibility Act, EAA) um. Die Schweiz arbeitet an einer Teilrevision des Behindertengleichstellungsgesetzes (BehiG), Inkrafttreten geplant für den 01.01.2027.

Für Arzt-Websites stellt sich damit eine Frage, die in keiner Praxis-Software-Demo auftaucht: Falle ich mit meiner Website unter die Pflicht, und wenn ja, was muss ich technisch wirklich umsetzen. Dieser Beitrag sortiert die drei Gesetze nebeneinander, zeigt was unter “elektronischen Geschäftsverkehr” fällt, welche Test-Tools du brauchst und wo die rechtliche Lage 2026 noch unklar ist.

Für die jeweiligen Landesdetails verlinke ich am Ende des Artikels die drei Country-Posts: BFSG für Arztpraxen Deutschland, BaFG für Arztpraxen Österreich und BehiG-Revision Schweiz 2027.

DACH-Vergleich auf einen Blick

Land	Gesetz	Stichtag	WCAG	Max. Strafe
Deutschland	BFSG	seit 28.06.2025	2.1 AA	bis 100.000 €
Österreich	BaFG	seit 28.06.2025	2.1 AA	bis 80.000 €
Schweiz	BehiG-Teilrevision	geplant 01.01.2027	2.2 AA	in Klärung
EU-Quelle	EAA (Richtlinie 2019/882)	28.06.2025	2.1 AA	je Mitgliedstaat

Gesetzes-Bezeichnungen ausgeschrieben: Barrierefreiheitsstärkungsgesetz (DE), Barrierefreiheitsgesetz (AT, BGBl. I Nr. 76/2023), Behindertengleichstellungsgesetz (CH, Teilrevision im parlamentarischen Prozess), European Accessibility Act (EU).

Zuständige Behörden: In Deutschland die Marktüberwachungsstelle der Länder für Barrierefreiheit (MLBF) mit Sitz in Magdeburg, in Österreich das Sozialministeriumservice, in der Schweiz mit Inkrafttreten der Revision zu klären.

Drei Beobachtungen, die in der Tabelle nicht stehen, aber praxisrelevant sind:

1. Die Schweiz wird strenger. WCAG 2.2 ist die neuere Version, sie verlangt zusätzliche Erfolgskriterien wie eindeutige Fokus-Sichtbarkeit, größere Touch-Targets, klare Drag-Gesten. Wer 2025 in DE oder AT auf 2.1 AA baut, sollte den Sprung auf 2.2 mit einplanen.
2. Schweizer Praxen mit EU-Kunden sind bereits jetzt unter EU-Recht. Wenn deine Website Patient:innen aus Deutschland oder Österreich gezielt anspricht (DE-Suche-Optimierung, deutsche Buchungs-Formulare), fällt sie unter BFSG/EAA, unabhängig vom Sitz.
3. Die Strafen sind das eine, Abmahnungen das andere. Praktischer wird vermutlich nicht das Bußgeld, sondern die Abmahnung durch Mitbewerber oder Verbraucherschutzverbände. Die Rechtslage dazu ist 2026 noch nicht final geklärt, Parallelen zur DSGVO sprechen aber für Zulässigkeit.

Was ist “elektronischer Geschäftsverkehr”

Der zentrale Begriff in BFSG und BaFG ist “Dienstleistung im elektronischen Geschäftsverkehr”. § 2 Nr. 26 BFSG definiert das so:

Digitale Dienste über Websites oder Apps, die zum Abschluss eines Verbrauchervertrags dienen, elektronisch und auf individuellen Wunsch eines Verbrauchers erbracht werden.

Explizit als Beispiele genannt: Online-Shops, Hotelbuchungen, Terminbuchungs-Tools. Explizit ausgenommen: reine B2B-Angebote und reine Info-Websites ohne Transaktions-Funktion.

Für eine Arzt-Praxis heißt das im Kern:

• Praxis-Website mit Online-Terminbuchung (eigener Buchungs-Bereich, Doctolib-Iframe, 4myhealth-Integration, Calendly-Embed): elektronischer Geschäftsverkehr, BFSG-pflichtig.
• Reine Visitenkarten-Site ohne Buchung (Praxis-Info, Anfahrt, Sprechzeiten, Telefonnummer): kein elektronischer Geschäftsverkehr, nicht pflichtig.
• Externe Link-Lösung (Button “Termin bei 4myhealth buchen” verlinkt extern): rechtlich unklar, Tendenz aber zu “nicht pflichtig”, weil der Vertragsschluss extern stattfindet.

Diese Trennung ist nicht offiziell rechtssicher geklärt. Die Bundesfachstelle Barrierefreiheit und Quellen wie DocLeads und DigitalPraxis.at gehen davon aus, dass jede Online-Buchungsmöglichkeit in den Bereich fällt. Andere Quellen wie die Kanzlei Plutte sehen die Frage, ob externe Embeds oder reine Links als “Vertragsschluss auf der eigenen Site” zählen, als ungeklärt.

Kleinstunternehmens-Ausnahme

Eine Erleichterung gibt es: § 2 Nr. 17 BFSG (und identisch im BaFG) definiert eine Kleinstunternehmens-Ausnahme. Befreit von der Pflicht ist, wer:

• weniger als 10 Mitarbeiter:innen beschäftigt und
• entweder weniger als 2 Mio € Jahresumsatz oder eine Bilanzsumme unter 2 Mio € hat

Die meisten Solo-Praxen und kleinen Gemeinschaftspraxen fallen technisch unter diese Schwelle. Aber: die Ausnahme greift nur für die Service-Pflicht, nicht für Produkte. Und Online-Buchung wird als Service gewertet. Hier wird die Rechtslage konkret uneinheitlich:

• Position A (Bundesfachstelle, DocLeads, DigitalPraxis.at): Online-Buchung ist elektronischer Geschäftsverkehr und damit ein Service. Auch eine Solo-Praxis fällt drunter, wenn sie Online-Buchung anbietet.
• Position B (DocRelations, Kanzlei Plutte): Reine Info-Site ohne Vertragsschluss-Funktion bleibt ausgenommen, Online-Buchung über externes Tool (Iframe versus Link) noch ungeklärt.

Was bei dieser Gegenüberstellung zu beachten ist: Die Quellen, die Position A (Pflicht) am deutlichsten vertreten, sind überwiegend Praxismarketing-Agenturen, die BFSG-Compliance als Dienstleistung anbieten. DocLeads und DigitalPraxis.at fallen in diese Kategorie. Die Bundesfachstelle Barrierefreiheit ist als öffentliche Stelle neutral, aber tendenziell weit auslegend. Position B kommt teilweise von Anwälten (Kanzlei Plutte, IT-Recht-Schwerpunkt), die nicht von einer Compliance-Pflicht-Auslegung profitieren, sondern eher davon, dass Mandant:innen eine zweite Meinung einholen. Das spricht nicht automatisch dafür, dass eine Position richtiger ist als die andere, aber es lohnt sich, die Interessen-Lage der Quellen mitzulesen. Wer letztgültige Sicherheit für die eigene Praxis braucht, holt sich anwaltlichen Rat.

Pragmatisch heißt das: Wenn du in einer Solo-Praxis oder kleinen Gemeinschaftspraxis arbeitest und Online-Buchung anbietest, kannst du dich nicht zuverlässig auf die Kleinstunternehmens-Ausnahme verlassen. Die Umsetzung der WCAG 2.1 AA ist ohnehin in der Regel kein großer Aufwand bei einer Praxis-Website mit überschaubarem Umfang, und du holst dir SEO-, UX- und AI-Discovery-Vorteile ohne Mehraufwand.

Keine Übergangsfrist für Websites

Eine wichtige Klarstellung: § 38 BFSG (und § 36 BaFG) regeln Übergangsfristen, aber für Websites und E-Commerce gibt es keine. Sofort ab 28.06.2025 gilt die Pflicht.

Bereich	Übergangsfrist
Websites und E-Commerce	keine, sofort ab 28.06.2025
Dienstleistungen mit bestehenden Produkten	bis 27.06.2030
Bestehende Verträge	max. 5 Jahre nach 28.06.2025
Selbstbedienungsterminals	bis 28.06.2040 (max. 20 Jahre Lebenszyklus)

In der Recherche bin ich auf eine Quelle gestoßen, die von einem “Bestandsschutz bis 28.05.2030 für Websites” sprach. Das stimmt so nicht. § 38 BFSG sieht für Websites und E-Commerce explizit keine Übergangsfrist vor. Wer das in einem Blog-Post oder einer Beratung liest, sollte den Punkt im Originalgesetzestext (bfsg-gesetz.de) prüfen, bevor er sich darauf verlässt.

WCAG 2.1 Level AA: die 4 Prinzipien

Der Standard, an dem sich BFSG und BaFG orientieren, sind die Web Content Accessibility Guidelines 2.1 Level AA. Vier Prinzipien (POUR) bilden den Kern:

Prinzip	Bedeutung	Konkrete Umsetzung
Perceivable (Wahrnehmbar)	Inhalte müssen für alle Sinne zugänglich sein	Alt-Texte für Bilder, Untertitel für Videos, ausreichender Farbkontrast
Operable (Bedienbar)	Funktionen müssen ohne Maus benutzbar sein	Tastatur-Navigation, sichtbarer Focus-Indikator, kein erzwungenes Time-Limit
Understandable (Verständlich)	Inhalte und Bedienung müssen klar sein	Einfache Sprache, konsistente Navigation, klare Fehlermeldungen in Forms
Robust (Robust)	Funktioniert mit assistiven Technologien	Semantisches HTML, valides Markup, ARIA-Labels für Icons

In der Praxis bedeutet das für eine Arzt-Website mehrere konkrete Anforderungen:

• Farbkontrast mindestens 4.5:1 für Body-Text, 3:1 für Large Text (ab 18pt oder 14pt bold). Klassischer Stolperstein bei Sage-Farben oder hellen Grautönen für Body-Copy.
• Alt-Texte für alle inhaltlich relevanten Bilder (Ärzte-Foto, Praxis-Bilder, Geräte). Dekorative Bilder bekommen alt="", damit Screenreader sie überspringen.
• Tastatur-Navigation muss durch alle interaktiven Elemente führen, mit sichtbarem Focus. Tab-Reihenfolge logisch, kein versteckter Focus-Indikator.
• Skalierbarkeit bis 200 Prozent Zoom ohne Funktionsverlust. Klassischer Fehler: fixe Pixel-Werte, die bei Zoom aus dem Viewport fallen.
• Forms mit echten <label>-Verknüpfungen, Fehlermeldungen direkt am Feld, kein reines placeholder-Vertrauen.
• HTML-Lang-Attribut gesetzt (<html lang="de">). Screenreader brauchen das für korrekte Aussprache.
• Skip-Link “Zum Hauptinhalt springen” am Seitenanfang, damit Screenreader-Nutzer:innen die Navigation überspringen können.
• Touch-Targets auf Mobile mindestens 44 mal 44 Pixel, kein horizontales Scrollen.

Für die Schweiz ab 2027 kommen mit WCAG 2.2 zusätzliche Punkte dazu: konsistente Hilfe-Positionierung, klare Drag-Alternativen, sichtbarer Focus mindestens 2 Pixel, keine Accessibility-Komplexität versteckt hinter Cookie-Bannern.

Test-Tools: was du selbst prüfen kannst

Du musst kein WCAG-Auditor sein, um die wichtigsten Lücken zu finden. Die folgenden Tools sind kostenlos und für eine Praxis-Website in einer halben Stunde durchgemacht:

Tool	URL	Was es prüft
WAVE	wave.webaim.org	Komplette WCAG-Analyse, Screenreader-Simulation, Kontrast-Check, ARIA-Validierung
Lighthouse Accessibility	Chrome DevTools (F12 → Lighthouse)	Audit mit Score von 0 bis 100, klare Liste der Fehler
axe DevTools	Browser-Extension (Chrome, Firefox)	WCAG-Issues live in der Seite, gut für Entwickler:innen
Contrast Checker	contrastchecker.com	Einzelne Farb-Kombis prüfen (Body-Text-Farbe versus Hintergrund)
Funkify	funkify.org	Disability-Simulator (Screenreader, Dyslexie, motorische Einschränkung)

Mein Workflow für eine Bestandsaufnahme: Lighthouse Accessibility auf die Startseite und die Buchungs-Seite, danach WAVE für die gleichen URLs. Lighthouse gibt einen schnellen Score (alles unter 95 hat fast immer Lücken), WAVE zeigt die konkreten Fehler mit Markierungen in der Seite. Zusammen findet man in 15 bis 20 Minuten die größten Probleme.

Drei Unsicherheiten, die ich offen benenne

Bei der Recherche bin ich auf drei Punkte gestoßen, an denen die Rechtslage 2026 noch nicht eindeutig ist. Wer mit Mandanten oder eigener Praxis hierauf trifft, sollte sie kennen:

1. Iframe versus Link bei Buchungs-Tools. Wenn du Doctolib, Jameda oder 4myhealth per Iframe einbettest, ist die Verantwortung für Barrierefreiheit theoretisch beim Anbieter. Eine Stand-2026-Analyse von DocRelations merkt an, dass die meisten Anbieter WCAG 2.1 AA noch nicht garantiert dokumentieren. Externer Link statt Iframe verlagert die Verantwortung sauberer.
2. Kleinstunternehmens-Ausnahme bei Online-Buchung. Wie oben beschrieben streiten Quellen, ob Online-Buchung den Solo-Praxis-Schutz aufhebt. Pragmatisch: WCAG 2.1 AA umsetzen, dann ist die Frage akademisch.
3. Abmahnungs-Risiko durch Mitbewerber und Verbraucherverbände. Rechtlich noch nicht final geklärt, aber Parallelen zur DSGVO sprechen für Zulässigkeit. Wer abwartet, riskiert das erste Abmahn-Schreiben einer Praxis nebenan oder eines Verbraucherschutzverbandes.

Das ist die ehrliche Recherche-Lage Mai 2026. Wer in einem Blog-Post oder einer Praxis-Marketing-Beratung pauschale Sätze wie “Solo-Praxen sind ausgenommen” oder “Iframe-Buchungs-Tools sind kein Problem” hört, sollte zurückfragen, auf welche Quelle sich das stützt.

Was bedeutet das für dich konkret

Drei Szenarien, drei Empfehlungen:

Praxis-Website mit Online-Buchung (Doctolib, Jameda, 4myhealth, Calendly, eigene Lösung): WCAG 2.1 AA umsetzen ist nicht optional. Lighthouse Accessibility Score über 95, WAVE ohne Errors, manueller Tab-Test durchführen. Für die Schweiz gleich auf 2.2 AA bauen, dann sparst du dir den Update-Schritt 2027. Mein Tipp für Tracking-Setups: Cookie-Banner ist klassischer WCAG-Brecher, weil er oft als Vollbild-Wand kommt und Skip-Links blockiert. Saubere Implementierung via Bottom-Bar statt Modal-Overlay.

Reine Info-Website ohne Buchung: Technisch nicht pflichtig, aber WCAG 2.1 AA bringt SEO- und AI-Discovery-Vorteile (klare semantische Struktur ist gleich gute Vorbereitung für AI-Tools wie ChatGPT, Perplexity, Gemini). Plus: deine Patient:innen werden älter, motorische und visuelle Einschränkungen nehmen zu. Pragmatisch ist Barrierefreiheit Patientennähe.

Du planst einen Relaunch: Beste Gelegenheit. WCAG 2.1 AA als Anforderung in den Brief schreiben, Lighthouse-Score und WAVE-Audit als Abnahmekriterien. In einem modernen, schlanken Build-Setup sind die Basics (Skip-Link, lang-Attribut, semantisches HTML, Focus-Sichtbarkeit) Default. Ein moderner technischer Stack zwingt dich nicht zu Barrierefreiheit, aber er stellt sie viel weniger im Weg als ein WordPress-Theme mit 20 Plugins, die alle eigene Markup-Eigenheiten haben.

Wer beim Tracking-Setup ohnehin auf Consent Mode v2 und sauberes Tracking wechselt, kann den Barrierefreiheits-Check im gleichen Projekt mitnehmen. Beides sind 2026 keine optionalen Extras mehr.

Für die Werberecht-Frage bei Praxis-Werbung verlinke ich die zwei Begleit-Artikel: HWG für Ärzte in Deutschland und ÄrzteG für Ärzte in Österreich. Wer in Deutschland zusätzlich die KI-Kennzeichnungspflicht 2026 auf dem Schirm haben sollte: das ist die dritte Compliance-Baustelle für Praxis-Websites neben Werberecht und BFSG.

Wer das Setup für Google Ads in einer Praxis sucht: Google Ads für Ärzte ist meine Service-Seite mit dem konkreten Projekt-Format.

FAQ

Falle ich als Solo-Praxis unter das BFSG?

Wahrscheinlich ja, wenn du Online-Buchung anbietest. Die Kleinstunternehmens-Ausnahme greift theoretisch (weniger als 10 MA, weniger als 2 Mio € Umsatz oder Bilanzsumme), aber Online-Buchung gilt als Service im elektronischen Geschäftsverkehr. Die Rechtslage ist uneinheitlich, pragmatisch ist die Umsetzung der WCAG 2.1 AA auf einer Praxis-Website überschaubar.

Reicht es, wenn ich Doctolib oder Jameda einbette?

Die Verantwortung für Barrierefreiheit des Buchungs-Tools liegt beim Anbieter. Aber: deine eigene Website (alles drumherum) muss WCAG 2.1 AA erfüllen. Und ob ein Iframe-Embed das Buchungs-Tool zu deiner Verantwortung macht, ist rechtlich nicht final geklärt. Sauberer ist ein externer Link statt Iframe, das verlagert die Verantwortung eindeutig.

Was kostet eine BFSG-Konformität bei einer neuen Praxis-Website?

Bei einem Neubau oder Relaunch sind die Mehrkosten bei einem kompetenten Webdesigner gering, oft im niedrigen 4-stelligen Bereich, weil die Basics (semantisches HTML, Kontrast, Skip-Link, Forms) ohnehin Standard sein sollten. Teurer wird es bei einer bestehenden Site, die nachträglich umgebaut werden muss, vor allem wenn ein altes WordPress-Theme oder Drag-and-Drop-Builder darunter liegt.

Wann genau gilt die Pflicht in der Schweiz?

Geplant ist das Inkrafttreten der BehiG-Teilrevision für den 01.01.2027. Die Vorlage ist (Stand Mai 2026) noch im parlamentarischen Prozess, Details können sich ändern. Bis zur Revision sind private Unternehmen in der Schweiz nicht pflichtig, mit zwei Ausnahmen: zivilrechtliche Inanspruchnahme bei Diskriminierung ist möglich, und Schweizer Praxen mit aktiver EU-Akquise fallen seit 28.06.2025 unter BFSG/EAA.

Was passiert bei einem Verstoß konkret?

In Deutschland sieht § 37 BFSG ein gestuftes Vorgehen vor: Erst eine Nachbesserungs-Aufforderung durch die MLBF (Marktüberwachungsstelle der Länder für Barrierefreiheit, Sitz Magdeburg), dann ein Bußgeld bis 100.000 €, in schweren Fällen ein Verkaufsverbot oder Website-Abschaltung. Praktisch viel wahrscheinlicher: eine Abmahnung durch Mitbewerber oder Verbraucherverbände, die Anwaltskosten oder eine Unterlassungserklärung nach sich zieht.

Welches Test-Tool ist das wichtigste?

Lighthouse Accessibility in den Chrome DevTools für den schnellen Score (alles unter 95 hat Lücken), plus WAVE für die konkrete Fehlerliste. Beides kostenlos, zusammen in 15 bis 20 Minuten pro Seite durchgemacht. Wer es genauer braucht, ergänzt axe DevTools als Browser-Extension.

Deine nächsten Schritte

1. Bestandsaufnahme mit Lighthouse Accessibility und WAVE auf der Startseite und der Buchungs-Seite. Score und Fehler-Anzahl notieren.
2. Kritische Lücken priorisieren: Farbkontrast, Forms ohne Labels, fehlende Alt-Texte, fehlender Skip-Link, fehlendes lang-Attribut sind die häufigsten Findings.
3. Bei Relaunch oder Neubau: WCAG 2.1 AA als Anforderung in den Brief schreiben. Für die Schweiz gleich 2.2 AA.
4. Cookie-Banner und Buchungs-Tool prüfen, das sind die häufigsten Brecher der Tab-Navigation und Screenreader-Erfahrung.

Wer einen Audit des kompletten Tracking- und Werbe-Setups einer Praxis braucht (Barrierefreiheit wird im Rahmen eingeordnet, nicht selbst umgesetzt), fängt am besten mit einem kostenlosen Erstgespräch an.

→ 20-Min-Erstgespräch für Praxen buchen

---

Disclaimer: Dieser Artikel ist keine Rechtsberatung. Bei rechtlich relevanten Entscheidungen, insbesondere zur Frage, ob deine Praxis konkret unter das Gesetz fällt, solltest du eine Anwältin oder einen Anwalt mit Schwerpunkt IT-Recht oder Medizinrecht konsultieren. Die hier dargestellten Informationen entsprechen meinem Recherche-Stand vom 12.05.2026 und können sich durch neue Rechtsprechung oder Gesetzes-Updates ändern.