Barrierefreiheit: Was das neue Gesetz für Ihre Website bedeutet.

Am 28. Juni 2025 ist das Barrierefreiheitsgesetz (BaFG) in Kraft getreten – die österreichische Umsetzung der EU-weiten Richtlinie European Accessibility Act. Die meisten Betriebe, mit denen wir sprechen, haben davon nichts mitbekommen. Kein großer Stichtag in den Nachrichten, keine Welle an Abmahnungen am nächsten Tag. Trotzdem ist die Frage seither nicht mehr rein akademisch: Muss meine Website eigentlich barrierefrei sein?

Was das Barrierefreiheitsgesetz überhaupt regelt

Das BaFG setzt die EU-Richtlinie European Accessibility Act in österreichisches Recht um. Es legt EU-weit einheitliche Barrierefreiheitsanforderungen für bestimmte, im Gesetz namentlich genannte Produkte und Dienstleistungen fest – unter anderem E-Commerce, E-Banking, E-Ticketing, E-Books und bestimmte Kommunikationsdienste. Als praktischer technischer Maßstab dient dabei der Standard WCAG 2.1 auf Konformitätsstufe AA – derselbe Standard, den öffentliche Stellen in Österreich schon länger einhalten müssen.

Wen es betrifft – und wen nicht

Wichtig: Das Gesetz gilt nicht pauschal für jede Website. Es greift dort, wo eine der ausdrücklich genannten Dienstleistungen erbracht wird – ein Online-Shop mit direktem Verkauf an Verbraucher ist der häufigste Fall. Bei Dienstleistungen gibt es zusätzlich eine Ausnahme für Kleinstunternehmen: Wer weniger als 10 Personen beschäftigt und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme hat, ist von dieser Pflicht befreit – bei Produkten gilt diese Ausnahme allerdings nicht. Ob die eigene Website konkret betroffen ist, hängt also von Branche, Größe und Geschäftsmodell ab; im Zweifel lohnt sich eine kurze rechtliche Abklärung, bevor man sich auf eine Ausnahme verlässt.

Und selbst wer formal ausgenommen ist: Ein erheblicher Teil der Bevölkerung ist auf barrierefreie Websites angewiesen oder profitiert zumindest davon – nicht nur Menschen mit dauerhafter Behinderung, sondern auch, wer gerade schlecht sieht, einen gebrochenen Arm hat, oder unterwegs nur mit einer Hand tippt.

Was WCAG 2.1 AA in der Praxis bedeutet

Der Standard klingt abstrakt, die Anforderungen dahinter sind es nicht. Die häufigsten Punkte, an denen Websites in der Praxis scheitern:

• Bilder ohne aussagekräftigen Alt-Text, sodass Screenreader nichts vorzulesen haben
• Farbkontraste unter 4,5:1 zwischen Text und Hintergrund, kaum lesbar bei Sehschwäche
• Elemente, die sich nur mit der Maus bedienen lassen, nicht mit der Tastatur
• Fehlender oder unsichtbarer Fokus-Rahmen, sodass bei Bedienung mit der Tastatur nicht sichtbar ist, wo man gerade steht
• Formulare ohne verknüpfte Labels, sodass unklar bleibt, welches Feld wofür ist
• Überschriften, die nur optisch größer sind statt als echtes <h2> oder <h3> ausgezeichnet

Keiner dieser Punkte ist für sich aufwendig zu beheben. Zusammen machen sie aber den Unterschied zwischen einer Website, die für einen Teil des Publikums tatsächlich benutzbar ist, und einer, die nur für alle benutzbar wirkt, die selbst keine Einschränkung haben.

Ein erster Check dauert zehn Minuten

Bevor eine Agentur oder ein Audit ins Spiel kommt, lässt sich vieles selbst grob abschätzen. Der Lighthouse-Report in den Chrome-Entwicklertools hat einen eigenen Accessibility-Score und listet die häufigsten Probleme direkt mit Fundstelle im Code. Wer testen will, wie sich die Seite ohne Maus anfühlt, tabbt sich einfach mit der Tab-Taste durch die Navigation – landet der Fokus dabei irgendwo unsichtbar oder in falscher Reihenfolge, ist das ein Warnsignal. Und ein kurzer Blick auf Formularfelder reicht oft schon: Lässt sich jedes Feld per Klick auf sein Label fokussieren, ist zumindest die Grundstruktur da. Das ersetzt kein vollständiges Audit, gibt aber in wenigen Minuten ein ehrliches erstes Bild.

Warum das mehr ist als eine Pflicht

Barrierefreiheit und technisches SEO überschneiden sich mehr, als man denkt. Alt-Texte helfen nicht nur Screenreadern, sondern auch der Google-Bildersuche. Eine saubere Überschriften-Hierarchie hilft nicht nur Menschen, die mit der Tastatur navigieren, sondern auch Suchmaschinen-Crawlern, den Aufbau einer Seite zu verstehen. Semantisches HTML – ein echter <button> statt eines klickbaren <div>, ein echtes <nav> statt eines beliebigen Containers mit Links – ist in beiden Fällen dieselbe Grundarbeit, nur mit zwei unterschiedlichen Zielgruppen. Das deckt sich mit einem Punkt aus unserem Beitrag Warum wir kein WordPress verwenden: handgeschriebener, semantischer Code ist von Anfang an einfacher barrierefrei zu halten als eine Seite, die aus generischen Page-Builder-Blöcken zusammengesetzt ist – dort landet oft ein <div> mit Klick-Handler, wo eigentlich ein <button> hingehört.

Wie wir das bei saweb umsetzen

Wir bauen Barrierefreiheit nicht als nachträgliches Audit ein, sondern von Anfang an in die Struktur: einen "Zum Inhalt springen"-Link am Seitenanfang, der bei Bedienung mit der Tastatur als Erstes erreichbar ist; Animationen, die sich über prefers-reduced-motion abschalten lassen, für alle, denen Bewegung auf dem Bildschirm Probleme bereitet – auch diese Website läuft so; Formulare mit echten, verknüpften Labels statt nur Platzhaltertext. Das ist kein zusätzliches Paket, das wir separat verkaufen, sondern Teil dessen, was eine sauber gebaute Website für uns bedeutet. Mehr zu unserem Ansatz auf der Webentwicklung-Seite.

Unsicher, ob und wie das BaFG Ihre Website betrifft, oder wo Ihre Seite bei WCAG 2.1 AA aktuell steht? Im kostenlosen Erstgespräch schauen wir uns das konkret an.