Ist Ihre Website barrierefrei?

Was verlangen BaFG (AT) und BFSG (DE)?

Seit dem 28. Juni 2025 müssen in Österreich (Barrierefreiheitsgesetz, BaFG) und in Deutschland (Barrierefreiheitsstärkungsgesetz, BFSG) bestimmte Produkte und Dienstleistungen für Verbraucher barrierefrei sein. Bei Websites betrifft das vor allem Online-Shops und Buchungen, also „Dienstleistungen im elektronischen Geschäftsverkehr“. Kleinstunternehmen, die Dienstleistungen erbringen, sind davon ausgenommen.

Die folgende Übersicht ist eine technische Einordnung am Gesetzestext, keine Rechtsberatung.

Ausgenommen sind unter anderem Inhalte Dritter, die das Unternehmen weder finanziert noch kontrolliert, Archive, die nach dem Stichtag nicht mehr geändert werden, sowie vor dem Stichtag veröffentlichte Videos und Büro-Dokumente (§ 2 Abs. 3 BaFG). Reine Informationsseiten ohne Bestell- oder Buchungsmöglichkeit fallen laut Wirtschaftskammer Österreich nicht unter das BaFG; ob ein Kontaktformular allein genügt, ist laut WKO strittig.

Einen bestimmten technischen Standard nennt das BaFG nicht. Wer harmonisierte europäische Normen einhält, für den gilt die Vermutung, dass die Anforderungen erfüllt sind (§ 5). Die WKO nennt als Maßstab die Norm EN 301 549, die sich laut EU-Kommission stark auf die WCAG 2.1 stützt, und empfiehlt, die aktuelle Fassung WCAG 2.2 zu verwenden.

Was lässt sich automatisch prüfen – und was nicht?

Automatische Prüfungen finden technische Lücken wie fehlende Alt-Texte, unbeschriftete Formularfelder oder ein gesperrtes Zoomen. Ob eine Website wirklich barrierefrei ist, kann laut W3C kein Werkzeug allein feststellen; dafür braucht es menschliche Beurteilung.

Das prüft Auffindig im HTML

• Viewport und Zoom-Sperre, Sprache der Seite
• Alt-Attribute bei Bildern und Alt-Texte, die wie Dateinamen aussehen
• Beschriftung von Formularfeldern und Namen von Schaltflächen
• Hauptbereich <main> und Sprunglink
• doppelte IDs, positive tabindex-Werte, versteckte Fokusziele
• Titel von eingebetteten Inhalten (iframes)

Das braucht einen Menschen oder eine Darstellung im Browser

• Farbkontrast: mindestens 4,5:1 für normalen Text (WCAG 1.4.3)
• vollständige Bedienung per Tastatur und ein sichtbarer Fokus
• Darstellung bei starker Vergrößerung: Inhalte müssen bei 320 CSS-Pixel Breite ohne seitliches Scrollen lesbar sein (WCAG 1.4.10)
• ob ein Alt-Text das Bild sinnvoll beschreibt und Texte verständlich sind
• Untertitel und Audiodeskription bei Videos

Werkzeuge können zudem falsche oder irreführende Ergebnisse liefern. Nutzen Sie den Bericht von Auffindig deshalb als Vorab-Prüfung und testen Sie wichtige Abläufe – etwa Bestellung oder Terminbuchung – selbst mit der Tastatur und einem Screenreader (Bildschirmvorleseprogramm).

Wie stelle ich Sprache, Zoom und Viewport richtig ein?

Drei Angaben im HTML-Grundgerüst erledigen das: lang="de-AT" am html-Element, ein Viewport-Tag mit width=device-width und keine Zoom-Sperre. Ohne Sprachangabe können Screenreader nicht die richtigen Ausspracheregeln laden, und eine Zoom-Sperre hindert Menschen mit Sehschwäche am Vergrößern.

<html>
<meta name="viewport" content="width=device-width, maximum-scale=1, user-scalable=no">

<html lang="de-AT">
<meta name="viewport" content="width=device-width, initial-scale=1">

• Sprache: Der Wert folgt dem Standard BCP 47: de oder mit Region de-AT, getrennt durch einen Bindestrich. de_AT oder german sind ungültig. Die Sprache der Seite muss technisch erkennbar sein (WCAG 3.1.1, Stufe A).
• Viewport: Ohne Viewport-Tag stellen Mobilbrowser die Seite in einer breiteren, virtuellen Ansicht dar und verkleinern sie. Da Google überwiegend die Mobilversion einer Website indexiert, ist das auch für die Suche wichtig.
• Zoom: Text muss sich laut WCAG 1.4.4 ohne Hilfsmittel auf 200 % vergrößern lassen; MDN empfiehlt, fünffaches Zoomen zu ermöglichen. Entfernen Sie daher user-scalable=no und Werte für maximum-scale unter 5.

Wie schreibe ich gute Alt-Texte?

Ein Alt-Text beschreibt kurz und sachlich, was ein Bild an dieser Stelle aussagt. Dekorative Bilder erhalten ein leeres alt="", verlinkte Bilder einen Text, der das Ziel oder die Funktion nennt.

Fehlt das alt-Attribut ganz, lesen manche Screenreader stattdessen den Dateinamen vor. Ebenso wertlos sind Alt-Texte wie IMG_4711.jpg oder „bild1“. Alt-Texte verlangt WCAG 1.1.1 (Stufe A); auch Google wertet sie beim Indexieren aus. Auffindig meldet zusätzlich sehr lange Alt-Texte über 125 Zeichen und denselben Alt-Text auf drei oder mehr verschiedenen Bildern.

Wie beschrifte ich Formulare und Schaltflächen?

Jedes Eingabefeld braucht eine sichtbare, verknüpfte Beschriftung (<label>), jede Schaltfläche einen erkennbaren Namen – auch reine Symbol-Schaltflächen wie Menü, Suche oder Slider-Pfeile. Ein Platzhalter im Feld (Attribut placeholder) ersetzt keine Beschriftung: Screenreader lesen ihn standardmäßig nicht vor, und er verschwindet beim Tippen.

<input type="email" placeholder="E-Mail-Adresse">
<button type="button"><svg …></svg></button>

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email">

<button type="button" aria-label="Menü öffnen" aria-expanded="false">
  <svg aria-hidden="true" …></svg>
</button>

Das for-Attribut des Labels muss genau der id des Feldes entsprechen. Lässt sich keine sichtbare Beschriftung unterbringen, helfen aria-label oder aria-labelledby – laut W3C aber nur, wenn der Zweck des Feldes aus dem Umfeld klar ist. Bei Schaltflächen hilft zusätzlich sichtbarer Text, denn nicht jeder kennt die Bedeutung eines Symbols. Die zugrunde liegenden Kriterien sind WCAG 3.3.2 (Beschriftungen) und 4.1.2 (Name, Rolle, Wert).

Wie helfen Landmarks, Sprunglink und Fokus?

Ein <main>-Bereich und ein Sprunglink „Zum Inhalt springen“ ganz am Anfang erlauben Tastatur- und Screenreader-Nutzern, die wiederkehrende Navigation zu überspringen. Die Reihenfolge, in der die Tabulatortaste durch die Seite führt, sollte der Lesereihenfolge folgen.

<body>
  <a href="#inhalt">Zum Inhalt springen</a>
  <header>…</header>
  <main id="inhalt">…</main>
</body>

• Landmarks: <main>, <nav>, <header> und <footer> markieren Bereiche, zu denen assistive Technologien direkt springen. Pro Seite darf es nur ein sichtbares <main> geben. Sprunglink und Landmarks sind anerkannte Techniken für WCAG 2.4.1.
• tabindex: Verwenden Sie nur 0 und -1. Positive Werte ändern die Reihenfolge und machen die Bedienung per Tastatur schwierig.
• Versteckte Fokusziele: aria-hidden="true" darf nicht auf fokussierbaren Elementen oder deren Eltern stehen. Für ausgeblendete Menüs oder Dialoge eignet sich das Attribut inert: Es nimmt Inhalte aus der Tab-Reihenfolge und blendet sie für assistive Technologien aus.
• Eindeutige IDs: Eine id muss im ganzen Dokument einmalig sein. Doppelte IDs brechen die Verknüpfung von Labels, ARIA-Verweisen und Sprunglinks – etwa, wenn ein Menü für Mobil und Desktop zweimal im HTML steht.
• iframes: Eingebettete Karten oder Videos brauchen ein title-Attribut, etwa title="Karte: Anfahrt zur Apotheke". Sonst müssen Screenreader-Nutzer erst hineinnavigieren, um den Inhalt zu erkennen.

Ob der Fokus sichtbar ist (WCAG 2.4.7) und nicht von einer fixierten Kopfzeile verdeckt wird (WCAG 2.4.11), lässt sich nur im Browser prüfen: Gehen Sie die Seite einmal nur mit der Tabulatortaste durch.

Brauche ich eine Erklärung zur Barrierefreiheit?

Eine „Erklärung zur Barrierefreiheit“ schreibt in Österreich das Web-Zugänglichkeits-Gesetz (WZG) für Websites und Apps des Bundes vor (§ 4 WZG). Unternehmen, die unter das BaFG fallen, müssen stattdessen in ihren AGB oder einem ähnlichen Dokument angeben, wie ihre Dienstleistung die Barrierefreiheitsanforderungen erfüllt (§ 14 Abs. 2 und Anlage 3 BaFG).

Diese Informationen umfassen laut Anlage 3 BaFG gegebenenfalls zumindest:

• eine allgemeine Beschreibung der Dienstleistung in barrierefreiem Format,
• die Erläuterungen, die zum Verständnis der Durchführung nötig sind,
• eine Beschreibung, wie die Dienstleistung die Anforderungen aus Anlage 1 erfüllt.

Der Dienstleister muss diese Informationen der Allgemeinheit schriftlich und mündlich bereitstellen, auch in barrierefreier Form, und für die Dauer des Angebots aufbewahren (§ 14 Abs. 2 BaFG). In Deutschland verlangt § 14 BFSG ebenfalls Informationen nach Anlage 3, die für die Allgemeinheit barrierefrei zugänglich sein müssen.

Auch ohne Pflicht schafft eine freiwillige Erklärung Vertrauen: Ziel und Stand der Umsetzung, bekannte Einschränkungen, Datum und Art der Prüfung sowie ein Kontakt für Rückmeldungen. Ein Beispiel ist unsere eigene Erklärung zur Barrierefreiheit. Ob Ihr Angebot unter das BaFG oder BFSG fällt, klären im Zweifel die Wirtschaftskammer oder eine Rechtsberatung.