Website Barrierefreiheit (WCAG): Leitfaden 2026

Website Barrierefreiheit (WCAG): Der komplette Leitfaden 2026

Barrierefreiheit im Web ist kein optionales Nice-to-have mehr – es ist eine rechtliche Pflicht, eine ethische Verantwortung und ein handfester Business-Vorteil. In Österreich leben rund 1,4 Millionen Menschen mit einer Behinderung, europaweit sind es über 87 Millionen. Dazu kommen Millionen älterer Nutzer und Menschen mit temporären Einschränkungen. Eine barrierefreie Website erreicht all diese Menschen – und bietet gleichzeitig eine bessere Nutzererfahrung für jeden einzelnen Besucher.

Bei GoldenWing setzen wir seit über 3 Jahren barrierefreie Websites um und kennen die Herausforderungen, die gesetzlichen Anforderungen und die praktischen Lösungen. In diesem umfassenden Leitfaden erfahren Sie alles, was Sie 2026 über Website-Barrierefreiheit wissen müssen.

Was ist Website-Barrierefreiheit?

Website-Barrierefreiheit (Web Accessibility) bedeutet, dass eine Website so gestaltet und entwickelt ist, dass sie von allen Menschen genutzt werden kann – unabhängig von körperlichen, sensorischen oder kognitiven Fähigkeiten. Das umfasst Menschen mit:

• Sehbehinderungen: Blindheit, Sehschwäche, Farbenblindheit
• Hörbehinderungen: Gehörlosigkeit, Schwerhörigkeit
• Motorischen Einschränkungen: Eingeschränkte Feinmotorik, Lähmungen, Tremor
• Kognitiven Einschränkungen: Lernbehinderungen, ADHS, Autismus, Demenz
• Temporären Einschränkungen: Gebrochener Arm, Augenentzündung, laute Umgebung
• Situativen Einschränkungen: Sonneneinstrahlung auf dem Bildschirm, Einhandbedienung im Bus

Der Curb-Cut-Effekt

In der Stadtplanung gibt es den „Curb-Cut-Effekt": Bordsteinabsenkungen wurden für Rollstuhlfahrer eingeführt, werden aber von Eltern mit Kinderwagen, Lieferanten mit Rollwagen und Radfahrern gleichermaßen genutzt. Genau das passiert auch im Web: Barrierefreie Websites sind für ALLE besser nutzbar.

Klare Überschriftenstrukturen helfen nicht nur Screenreader-Nutzern, sondern auch eiligen Lesern. Gute Kontraste erleichtern das Lesen bei Sonneneinstrahlung. Tastatur-Navigation ist auch für Power-User schneller als die Maus. Barrierefreiheit ist kein Sonderfall – es ist gutes Webdesign.

Gesetzliche Anforderungen: EU, Österreich und DACH

Die gesetzlichen Anforderungen an barrierefreie Websites haben sich in den letzten Jahren massiv verschärft. Unternehmen, die jetzt nicht handeln, riskieren Abmahnungen und empfindliche Strafen.

European Accessibility Act (EAA)

Der European Accessibility Act (Richtlinie (EU) 2019/882) ist seit dem 28. Juni 2025 in allen EU-Mitgliedstaaten verbindlich. Er verpflichtet Unternehmen, die digitale Produkte und Dienstleistungen anbieten, zur Barrierefreiheit. Betroffen sind unter anderem:

• E-Commerce-Websites und Online-Shops
• Bankdienstleistungen und Finanzprodukte
• Telekommunikationsdienste
• E-Books und E-Reader
• Personenbeförderungsdienste
• Produkte mit digitalem Interface

Wichtig: Der EAA betrifft nicht nur große Konzerne. Auch KMU ab 10 Mitarbeitern oder 2 Millionen Euro Jahresumsatz fallen unter die Regelung. Kleinstunternehmen sind ausgenommen, sollten Barrierefreiheit aber trotzdem ernst nehmen.

Österreichisches Recht: Web-Zugänglichkeits-Gesetz (WZG)

In Österreich gilt zusätzlich das Web-Zugänglichkeits-Gesetz (WZG), das die EU-Richtlinie 2016/2102 umsetzt. Es verpflichtet alle öffentlichen Stellen zu barrierefreien Websites und Apps nach WCAG 2.1 Level AA. Das umfasst:

• Bundes-, Landes- und Gemeindebehörden
• Öffentliche Unternehmen (z. B. ÖBB, Wiener Linien)
• Von öffentlichen Stellen finanzierte Einrichtungen
• Alle Websites und mobilen Anwendungen dieser Stellen

Sanktionen: Beschwerden können bei der zuständigen Schlichtungsstelle eingebracht werden. Bei Verstößen drohen verwaltungsrechtliche Strafen.

Deutschland: Barrierefreiheitsstärkungsgesetz (BFSG)

Das deutsche BFSG setzt den EAA um und gilt seit dem 28. Juni 2025. Es erweitert die Pflicht zur Barrierefreiheit erstmals auf die Privatwirtschaft. Besonders relevant für österreichische Unternehmen, die auch in Deutschland verkaufen: Online-Shops und digitale Dienstleistungen müssen WCAG 2.1 Level AA erfüllen.

Konsequenzen bei Nicht-Einhaltung

• Abmahnungen: Verbraucherschutzverbände und Betroffene können klagen
• Bußgelder: Bis zu 100.000 € in Deutschland, ähnliche Höhen in Österreich
• Reputationsschaden: Öffentliche Kritik durch Behindertenverbände und Medien
• Wettbewerbsnachteil: Öffentliche Auftraggeber verlangen zunehmend Barrierefreiheitsnachweise
• Umsatzverlust: 15–20 % der Bevölkerung mit Behinderungen als potenzielle Kunden ausschließen

WCAG 2.2: Der aktuelle Standard

Die Web Content Accessibility Guidelines (WCAG) sind der international anerkannte Standard für barrierefreie Websites, entwickelt vom World Wide Web Consortium (W3C). Die aktuelle Version WCAG 2.2 wurde im Oktober 2023 veröffentlicht und bringt 9 neue Erfolgskriterien.

Die drei Konformitätsstufen

Level A (Minimum): Grundlegende Barrierefreiheit. Wenn diese Kriterien nicht erfüllt werden, sind bestimmte Nutzergruppen komplett ausgesperrt. Beispiele: Alternativtexte für Bilder, Tastaturzugänglichkeit, keine ausschließlich farbbasierte Information.

Level AA (Empfohlen und rechtlich gefordert): Der Standard, den Gesetze wie das WZG und der EAA fordern. Umfasst Level A plus zusätzliche Anforderungen wie ausreichende Kontraste (4,5:1), Textskalierung bis 200 % und konsistente Navigation.

Level AAA (Optimal): Der höchste Standard. In der Praxis ist eine vollständige AAA-Konformität für gesamte Websites kaum erreichbar, aber einzelne Kriterien sollten wo möglich umgesetzt werden. Beispiele: Kontrastsverhältnis 7:1, Gebärdensprachvideos, erweiterte Audiobeschreibungen.

Neue Kriterien in WCAG 2.2

WCAG 2.2 bringt wichtige Ergänzungen:

• 2.4.11 Focus Not Obscured (Minimum): Der Fokus-Indikator eines Elements darf nicht vollständig verdeckt werden (z. B. durch Sticky Header).
• 2.4.12 Focus Not Obscured (Enhanced): Der Fokus-Indikator darf überhaupt nicht verdeckt werden.
• 2.4.13 Focus Appearance: Der Fokus-Indikator muss eine bestimmte Mindestgröße und einen Mindestkontrast haben.
• 2.5.7 Dragging Movements: Funktionen, die Zieh-Bewegungen erfordern, müssen auch ohne Ziehen bedienbar sein.
• 2.5.8 Target Size (Minimum): Interaktive Elemente müssen mindestens 24×24 CSS-Pixel groß sein.
• 3.2.6 Consistent Help: Hilfemechanismen müssen konsistent platziert sein.
• 3.3.7 Redundant Entry: Bereits eingegebene Informationen dürfen nicht erneut abgefragt werden.
• 3.3.8 Accessible Authentication (Minimum): Authentifizierung darf keine kognitiven Funktionstests erfordern.
• 3.3.9 Accessible Authentication (Enhanced): Erweiterte Anforderungen an barrierefreie Authentifizierung.

Die 4 POUR-Prinzipien der Barrierefreiheit

WCAG basiert auf vier fundamentalen Prinzipien, die als POUR bekannt sind. Jedes Erfolgskriterium ordnet sich einem dieser Prinzipien unter.

1. Perceivable (Wahrnehmbar)

Informationen und Benutzeroberflächenkomponenten müssen so präsentiert werden, dass sie von allen Nutzern wahrgenommen werden können. Ein blinder Nutzer kann Bilder nicht sehen – also braucht er Alternativtexte. Ein gehörloser Nutzer kann Audio nicht hören – also braucht er Untertitel.

Kernforderungen:

• Alternativtexte für alle nicht-textuellen Inhalte (Bilder, Icons, Grafiken)
• Untertitel und Transkripte für Audio- und Videoinhalte
• Inhalte in verschiedener Weise darstellbar (z. B. ohne Verlust von Information bei Vergrößerung)
• Ausreichende Kontraste zwischen Text und Hintergrund
• Text nicht als Bild verwenden (außer bei Logos)

2. Operable (Bedienbar)

Alle Navigationselemente und Interaktionsmöglichkeiten müssen von allen Nutzern bedienbar sein. Wer keine Maus verwenden kann, muss die Website vollständig per Tastatur bedienen können. Wer mehr Zeit braucht, darf nicht durch Zeitlimits ausgesperrt werden.

Kernforderungen:

• Vollständige Tastaturzugänglichkeit (Tab, Enter, Escape, Pfeiltasten)
• Kein Tastatur-Trap (Nutzer darf nicht in einem Element „gefangen" werden)
• Ausreichend Zeit für Interaktionen (Timer pausierbar oder verlängerbar)
• Keine Inhalte, die Anfälle auslösen (keine Blitzeffekte über 3 Hz)
• Klare, konsistente Navigation und Orientierung
• Sichtbarer Fokus-Indikator bei Tastaturnavigation

3. Understandable (Verständlich)

Informationen und die Bedienung der Benutzeroberfläche müssen verständlich sein. Die Sprache muss klar sein, die Navigation vorhersehbar und Fehler müssen vermieden oder verständlich erklärt werden.

Kernforderungen:

• Sprache der Seite im HTML definiert (lang="de")
• Fremdsprachige Passagen markiert
• Navigation konsistent über alle Seiten hinweg
• Formularfelder beschriftet und Fehlermeldungen verständlich
• Hilfe und Fehlervermeidung bei Eingaben

4. Robust (Robust)

Inhalte müssen so robust sein, dass sie von verschiedenen User Agents (Browsern, Screenreadern, alternativen Eingabegeräten) zuverlässig interpretiert werden können.

Kernforderungen:

• Valides HTML (korrekte Verschachtelung, eindeutige IDs)
• ARIA-Rollen und -Attribute korrekt eingesetzt
• Status-Nachrichten programmatisch verfügbar
• Kompatibilität mit aktuellen und zukünftigen Technologien

Praktische Umsetzung: Schritt für Schritt

Theorie ist wichtig, aber die Praxis entscheidet. In diesem Abschnitt zeigen wir Ihnen konkret, wie Sie die wichtigsten Barrierefreiheitsanforderungen umsetzen. Eine barrierefreie Website beginnt beim UX-Design und setzt sich in der Entwicklung fort.

Kontraste und Farben

Der häufigste Barrierefreiheitsfehler: Zu geringe Kontraste. Laut WebAIM-Studie haben 83 % aller Websites Kontrastprobleme. Die WCAG-Anforderungen:

Tools für Kontrastprüfung:

• WebAIM Contrast Checker (online)
• Colour Contrast Analyser (Desktop-App)
• Chrome DevTools (Accessibility Inspector)

Praktische Tipps:

• Verwenden Sie nie Farbe als einziges Unterscheidungsmerkmal (z. B. rote Fehlermeldungen zusätzlich mit Icon oder Text kennzeichnen)
• Platzhaltertext in Formularen hat oft zu wenig Kontrast – setzen Sie auf sichtbare Labels
• Dunkelmodus anbieten, aber ebenfalls auf Kontraste achten
• Links innerhalb von Fließtext nicht nur durch Farbe, sondern auch durch Unterstreichung kennzeichnen

Alternativtexte für Bilder

Jedes Bild braucht einen Alt-Text – aber nicht jeder Alt-Text muss beschreibend sein:

Informative Bilder: Alt-Text beschreibt den Inhalt und Zweck. „Diagramm zeigt 35 % Umsatzwachstum im Q3 2025" statt „Diagramm" oder „chart.png".

Dekorative Bilder: Leerer Alt-Text (alt=""), damit Screenreader das Bild überspringen. Gilt für Hintergrundmuster, Trennlinien, rein dekorative Elemente.

Funktionale Bilder (Links, Buttons): Alt-Text beschreibt die Funktion, nicht das Bild. „Zur Startseite" statt „Logo" für ein verlinktes Logo.

Komplexe Bilder (Diagramme, Infografiken): Kurzer Alt-Text plus ausführliche Beschreibung im umgebenden Text oder über aria-describedby.

SVG-Icons: Verwenden Sie aria-label oder title innerhalb des SVG-Elements. Dekorative Icons mit aria-hidden="true" ausblenden.

Tastaturzugänglichkeit

Viele Nutzer können keine Maus verwenden und navigieren ausschließlich per Tastatur. Testen Sie Ihre Website, indem Sie die Maus weglegen und nur mit der Tastatur navigieren:

Grundlegende Tastatursteuerung:

• Tab: Zum nächsten interaktiven Element springen
• Shift+Tab: Zum vorherigen Element
• Enter: Link oder Button aktivieren
• Leertaste: Checkbox togglen, Button aktivieren
• Pfeiltasten: Innerhalb von Menüs, Tabs, Radio Buttons navigieren
• Escape: Modal/Dropdown schließen

Fokus-Management:

• Jedes interaktive Element muss einen sichtbaren Fokus-Indikator haben
• Die Tab-Reihenfolge muss logisch sein (folgt dem DOM, nicht dem visuellen Layout)
• Bei Modals muss der Fokus im Modal gefangen werden (Focus Trap)
• Nach dem Schließen eines Modals muss der Fokus zum auslösenden Element zurückkehren

Häufige Probleme:

• Custom-Dropdowns ohne Tastatursteuerung
• Slider/Karussells nicht mit Pfeiltasten bedienbar
• Hamburger-Menüs, die per Tastatur nicht geöffnet werden können
• Fokus springt nach Modal-Schließung an den Seitenanfang
• Outline entfernt (outline: none) ohne Alternative

ARIA richtig einsetzen

ARIA (Accessible Rich Internet Applications) erweitert HTML um Attribute, die die Zugänglichkeit dynamischer Inhalte verbessern. Aber Vorsicht: Falsch eingesetztes ARIA schadet mehr als es nützt.

Die erste Regel von ARIA: Verwenden Sie kein ARIA, wenn ein natives HTML-Element den gleichen Zweck erfüllt. Ein button-Element braucht kein role="button". Ein nav-Element braucht kein role="navigation".

Wichtige ARIA-Attribute:

• aria-label: Beschriftung für Elemente ohne sichtbaren Text (z. B. Icon-Buttons)
• aria-labelledby: Verknüpft ein Element mit einem anderen Element als Beschriftung
• aria-describedby: Zusätzliche Beschreibung (z. B. Formular-Hilfetexte)
• aria-hidden="true": Versteckt dekorative Elemente vor Screenreadern
• aria-expanded: Zeigt an, ob ein aufklappbares Element offen oder geschlossen ist
• aria-live: Definiert Live-Regionen, die bei Änderungen vorgelesen werden
• role: Definiert die Rolle eines Elements (z. B. role="alert", role="tabpanel")

Beispiel – barrierefreies Akkordeon:

<h3>
  <button aria-expanded="false" aria-controls="section1">
    Abschnitt 1
  </button>
</h3>
<div id="section1" role="region" hidden>
  <p>Inhalt von Abschnitt 1</p>
</div>

Formulare barrierefrei gestalten

Formulare sind oft die größte Hürde für Nutzer mit Behinderungen. Barrierefreie Formulare erfordern:

Labels: Jedes Eingabefeld braucht ein sichtbares, programmatisch verknüpftes Label (label for="id"). Placeholder-Text ist KEIN Ersatz für Labels.

Fehlermeldungen: Fehler müssen klar beschrieben werden (nicht nur „Fehler in Feld 3", sondern „Bitte geben Sie eine gültige E-Mail-Adresse ein"). Fehlermeldungen müssen programmatisch mit dem Feld verknüpft sein (aria-describedby).

Gruppen: Zusammengehörige Felder mit fieldset und legend gruppieren (z. B. Adressfelder, Radio Buttons).

Validierung: Client-seitige Validierung mit aria-invalid und aria-describedby. Fehlerzusammenfassung am Anfang des Formulars mit Links zu den fehlerhaften Feldern.

Autocomplete: Das autocomplete-Attribut verwenden, damit Browser und Passwort-Manager Felder automatisch ausfüllen können.

Responsive Design und Barrierefreiheit

Barrierefreiheit und Responsive Design ergänzen sich perfekt. Wichtige Punkte im Zusammenhang mit Core Web Vitals und Performance:

• Text muss bis 200 % vergrößerbar sein ohne horizontales Scrollen
• Touch-Targets müssen mindestens 44×44 px groß sein (WCAG empfiehlt 48×48 px)
• Abstände zwischen Touch-Targets beachten (min. 8 px)
• Inhalte dürfen bei Zoom und Vergrößerung nicht abgeschnitten oder überlagert werden
• Media Queries für prefers-reduced-motion und prefers-color-scheme unterstützen

Testing-Tools für Barrierefreiheit

Barrierefreiheit kann nicht allein durch automatisierte Tools sichergestellt werden – aber sie sind ein wichtiger Startpunkt. Nutzen Sie auch unseren Website-Design-Analyzer als ersten Check.

Automatisierte Testing-Tools

Manuelle Tests

Automatisierte Tools finden nur ca. 30 % der Barrierefreiheitsprobleme. Folgende manuelle Tests sind unverzichtbar:

Tastatur-Test: Navigieren Sie Ihre gesamte Website nur mit der Tastatur. Können Sie alle Funktionen erreichen und bedienen? Ist der Fokus-Indikator immer sichtbar? Gibt es Tastatur-Traps?

Screenreader-Test: Testen Sie mit NVDA (Windows, kostenlos), VoiceOver (macOS/iOS, integriert) oder JAWS (Windows, kommerziell). Werden alle Inhalte korrekt vorgelesen? Sind Bilder beschrieben? Sind Formulare bedienbar?

Zoom-Test: Vergrößern Sie die Seite auf 200 % und 400 %. Ist alles lesbar? Überlappen sich Elemente? Verschwindet Content?

Kognitive Tests: Ist die Sprache verständlich? Sind Anweisungen klar? Kann man Fehler leicht korrigieren? Ist die Navigation konsistent?

Nutzertests mit Menschen mit Behinderungen

Die aussagekräftigste Testmethode: Laden Sie Menschen mit verschiedenen Behinderungen ein, Ihre Website zu testen. Organisationen wie MAIN (Medienarbeit Integrativ) in Österreich vermitteln Tester mit Behinderungen. Diese Tests decken Probleme auf, die kein automatisiertes Tool und kein Entwickler ohne Behinderung finden kann.

Barrierefreiheit und SEO: Die perfekte Synergie

Barrierefreiheit und Suchmaschinenoptimierung sind natürliche Verbündete. Viele Accessibility-Maßnahmen verbessern gleichzeitig das Google-Ranking. Warum? Weil Suchmaschinen-Bots Websites ähnlich wie Screenreader „lesen" – sie können keine Bilder sehen, keine Videos anschauen und kein JavaScript interpretieren (oder nur eingeschränkt).

Überschneidungen zwischen Accessibility und SEO

Konkrete Vorteile

Niedrigere Absprungrate: Barrierefreie Websites sind benutzerfreundlicher. Nutzer finden schneller, was sie suchen, und bleiben länger. Google wertet das als positives Nutzersignal.

Größere Zielgruppe: 15–20 % der Bevölkerung haben eine Behinderung. Eine barrierefreie Website spricht diese Zielgruppe an und generiert mehr Traffic, mehr Conversions und mehr Umsatz.

Bessere technische Qualität: Valides HTML, korrekte Heading-Hierarchie und semantisches Markup sind sowohl für Accessibility als auch für SEO essenziell.

Voice Search: Barrierefreie Websites sind besser für Voice Search optimiert, da sie klare, strukturierte Inhalte bieten, die Sprachassistenten interpretieren können.

Häufige Fehler bei der Umsetzung

Aus unserer Erfahrung bei GoldenWing sehen wir diese Fehler immer wieder – selbst bei Websites, die „barrierefrei" sein sollen:

Top 10 Barrierefreiheits-Fehler

1. Fehlende oder nichtssagende Alt-Texte: „Bild1.jpg" oder „DSC_4023" sind keine Alt-Texte. Ebenso wenig hilfreich: Alt-Texte, die nur das Keyword wiederholen, ohne das Bild zu beschreiben.

2. Zu geringe Kontraste: Besonders bei modernem, minimalistischem Design mit hellen Grautönen auf weißem Hintergrund. Design und Barrierefreiheit sind kein Widerspruch – sie erfordern nur bewusstes Design.

3. Fehlende Tastaturzugänglichkeit: Custom-Komponenten (Dropdown-Menüs, Tabs, Modals) ohne Tastatursteuerung. Besonders häufig bei JavaScript-Frameworks, die native HTML-Elemente durch Divs und Spans ersetzen.

4. Outline entfernt: CSS outline: none auf :focus ohne Alternative. Der Fokus-Indikator ist für Tastaturnutzer essenziell. Entfernen Sie ihn nie, ohne einen gleichwertigen Ersatz zu bieten.

5. Automatisch abspielende Medien: Videos und Audio, die automatisch starten, sind nicht nur nervig, sondern für Screenreader-Nutzer besonders problematisch.

6. PDFs nicht barrierefrei: Die Website kann perfekt barrierefrei sein – wenn die verlinkten PDFs es nicht sind, bleibt eine erhebliche Barriere.

7. CAPTCHAs ohne Alternative: Herkömmliche CAPTCHAs sind für viele Nutzer unbedienbar. Verwenden Sie barrierefreie Alternativen wie hCaptcha Accessibility oder unsichtbare CAPTCHAs.

8. Dynamische Inhalte ohne ARIA-Live-Regions: Warenkorb-Updates, Fehlermeldungen und Ladehinweise werden von Screenreadern nicht angekündigt, wenn aria-live fehlt.

9. Fehlende Skip-Links: Tastaturnutzer müssen bei jeder Seite durch die gesamte Navigation tabben, bevor sie zum Hauptinhalt gelangen. Ein „Skip to main content"-Link löst das Problem.

10. Sprache nicht definiert: Das lang-Attribut im HTML fehlt, wodurch Screenreader die falsche Aussprache verwenden.

Kosten und Aufwand

Eine häufige Frage: Was kostet Barrierefreiheit? Die Antwort hängt stark davon ab, ob Sie eine bestehende Website nachrüsten oder eine neue Website von Anfang an barrierefrei entwickeln.

Neue Website barrierefrei entwickeln

Mehrkosten gegenüber einer nicht-barrierefreien Website: 10–20 %. Der Aufwand liegt hauptsächlich in der Planung, der semantischen Entwicklung und dem Testing. Wenn Barrierefreiheit von Anfang an mitgedacht wird, ist der Mehraufwand überschaubar.

Bestehende Website nachrüsten

Kosten: 20–50 % der ursprünglichen Entwicklungskosten. Nachrüsten ist immer teurer als Neuentwicklung, weil bestehender Code umgeschrieben, Designs angepasst und Content überarbeitet werden muss. Ein Accessibility-Audit identifiziert die kritischsten Barrieren als Ausgangspunkt.

Laufende Kosten

• Regelmäßige Audits: 1–2x jährlich, 1.500–5.000 €
• Content-Erstellung: Alt-Texte, Untertitel, barrierefreie PDFs – laufender Aufwand
• Schulung: Mitarbeiter in Redaktion, Design und Entwicklung schulen
• Monitoring-Tools: 100–500 €/Monat für automatisierte Überwachung

ROI von Barrierefreiheit

Die Investition in Barrierefreiheit zahlt sich aus:

• 15–20 % größere Zielgruppe (Menschen mit Behinderungen)
• Besseres SEO-Ranking (siehe Synergien oben)
• Niedrigere Absprungrate (bessere Nutzererfahrung)
• Rechtssicherheit (Vermeidung von Bußgeldern und Abmahnungen)
• Positives Markenimage (gesellschaftliche Verantwortung)

Checkliste: Barrierefreie Website

Diese Checkliste fasst die wichtigsten Punkte zusammen:

Wahrnehmbar:

• Alle Bilder haben beschreibende Alt-Texte
• Videos haben Untertitel und/oder Transkripte
• Kontraste erfüllen WCAG AA (4,5:1 für normalen Text)
• Farbe ist nie das einzige Unterscheidungsmerkmal
• Text ist bis 200 % vergrößerbar

Bedienbar:

• Alle Funktionen sind per Tastatur erreichbar
• Fokus-Indikatoren sind sichtbar
• Skip-Links sind vorhanden
• Keine Tastatur-Traps
• Zeitlimits sind anpassbar

Verständlich:

• Seitensprache ist definiert (lang="de")
• Navigation ist konsistent
• Formulare haben sichtbare Labels und verständliche Fehlermeldungen
• Inhalte sind klar und verständlich geschrieben

Robust:

• HTML ist valide
• ARIA wird korrekt eingesetzt
• Website funktioniert mit aktuellen Screenreadern
• Dynamische Inhalte verwenden aria-live

Wenn Sie Unterstützung bei der barrierefreien Gestaltung Ihrer Website benötigen, kontaktieren Sie unser Team. GoldenWing bietet Barrierefreiheits-Audits, Schulungen und die Umsetzung barrierefreier Websites aus einer Hand.

Häufig gestellte Fragen (FAQ)

Muss meine Website barrierefrei sein?

Seit Juni 2025 verpflichtet der European Accessibility Act (EAA) viele privatwirtschaftliche Unternehmen zur Barrierefreiheit ihrer digitalen Angebote. Betroffen sind insbesondere E-Commerce, Finanzdienstleistungen und Telekommunikation – ausgenommen sind nur Kleinstunternehmen mit weniger als 10 Mitarbeitern UND unter 2 Millionen Euro Jahresumsatz. Öffentliche Stellen in Österreich sind bereits seit dem WZG verpflichtet. Auch wenn Sie rechtlich nicht verpflichtet sind, lohnt sich Barrierefreiheit wirtschaftlich und ethisch.

Was kostet ein Barrierefreiheits-Audit?

Ein professionelles WCAG-2.2-Audit kostet je nach Umfang der Website zwischen 1.500 und 8.000 Euro. Ein Basis-Audit für eine Unternehmenswebsite mit 10–30 Seiten liegt typischerweise bei 2.000–3.500 Euro und umfasst automatisierte Tests, manuelle Prüfung und einen detaillierten Maßnahmenkatalog mit Priorisierung. Bei GoldenWing bieten wir Audits ab 2.500 Euro an.

Reicht ein automatisiertes Test-Tool für Barrierefreiheit?

Nein, automatisierte Tools wie axe oder WAVE finden nur ca. 30 % der Barrierefreiheitsprobleme. Sie erkennen zwar fehlende Alt-Texte oder Kontrastfehler, können aber nicht beurteilen, ob ein Alt-Text sinnvoll ist, ob die Tab-Reihenfolge logisch ist oder ob ein Screenreader-Nutzer den Kontext versteht. Automatisierte Tests sind ein wichtiger Startpunkt, aber manuelle Tests und idealerweise Nutzertests mit Menschen mit Behinderungen sind unverzichtbar.

Ist Barrierefreiheit ein einmaliges Projekt oder ein laufender Prozess?

Barrierefreiheit ist ein laufender Prozess. Jeder neue Content (Bilder, Videos, PDFs), jedes Design-Update und jede neue Funktion muss auf Barrierefreiheit geprüft werden. Wir empfehlen regelmäßige Audits (mindestens jährlich), automatisierte Monitoring-Tools für kontinuierliche Überwachung und Schulungen für alle Mitarbeiter, die Inhalte erstellen oder die Website weiterentwickeln.

Schadet Barrierefreiheit dem Design?

Ein weit verbreiteter Mythos. Barrierefreiheit und ansprechendes Design schließen sich nicht aus – im Gegenteil. Viele der erfolgreichsten Websites (Apple, BBC, GOV.UK) sind Vorzeigebeispiele für barrierefreies UND ästhetisches Design. Der Schlüssel liegt in bewusstem Design: Ausreichende Kontraste, klare Typografie und durchdachte Interaktionsmuster verbessern das Design für alle Nutzer, nicht nur für Menschen mit Behinderungen.

Wie lange dauert es, eine bestehende Website barrierefrei zu machen?

Das hängt vom Ausgangszustand und der Komplexität ab. Für eine typische Unternehmenswebsite mit 20–50 Seiten planen Sie 4–8 Wochen für ein Audit plus Umsetzung der kritischen Maßnahmen. Eine vollständige WCAG-AA-Konformität kann bei komplexen Websites mit vielen interaktiven Elementen 2–4 Monate dauern. Wir empfehlen einen phasierten Ansatz: Erst die kritischsten Barrieren beseitigen (Level A), dann schrittweise auf Level AA erweitern.

ARIA-Attribute richtig einsetzen: Praxisleitfaden

ARIA (Accessible Rich Internet Applications) ist ein maaechtiges Werkzeug, um Webanwendungen fuer Screenreader und andere assistive Technologien zugaenglich zu machen. Doch ARIA wird haeufig falsch eingesetzt -- was die Barrierefreiheit eher verschlechtert als verbessert.

Die goldene Regel: Kein ARIA ist besser als falsches ARIA

Bevor Sie ARIA-Attribute einsetzen, pruefen Sie immer, ob ein natives HTML-Element die gleiche Funktion erfuellt. Ein '<button>' ist immer besser als ein '<div role="button">'. Native Elemente bringen Tastaturzugaenglichkeit, Fokus-Management und Screenreader-Unterstuetzung automatisch mit.

Die wichtigsten ARIA-Rollen fuer moderne Websites

Landmark-Rollen strukturieren Ihre Seite fuer Screenreader-Nutzer:

• 'role="banner"' -- entspricht '<header>', der Kopfbereich der Seite
• 'role="navigation"' -- entspricht '<nav>', Navigationsbereiche
• 'role="main"' -- entspricht '<main>', der Hauptinhalt
• 'role="contentinfo"' -- entspricht '<footer>', der Fussbereich
• 'role="complementary"' -- entspricht '<aside>', ergaenzende Inhalte

Hinweis: Wenn Sie semantische HTML5-Elemente verwenden, sind diese Rollen redundant. Setzen Sie sie nur ein, wenn Sie aus technischen Gruenden keine semantischen Elemente nutzen koennen.

ARIA-States und Properties in der Praxis

aria-expanded: Fuer aufklappbare Menues, Akkordeons und Dropdowns:

• Setzen Sie 'aria-expanded="false"' im geschlossenen Zustand
• Aendern Sie auf 'aria-expanded="true"' beim Oeffnen
• Verbinden Sie das steuernde Element mit dem gesteuerten Bereich via 'aria-controls'

aria-live: Fuer dynamische Inhaltsaenderungen (Benachrichtigungen, Statusmeldungen):

• 'aria-live="polite"' -- Aenderung wird angekuendigt, wenn der Nutzer inaktiv ist (Standard fuer die meisten Faelle)
• 'aria-live="assertive"' -- Aenderung wird sofort angekuendigt (nur fuer kritische Meldungen wie Fehlermeldungen)

aria-label und aria-labelledby: Fuer Elemente, die keinen sichtbaren Text haben:

• 'aria-label="Hauptnavigation schliessen"' fuer Icon-Buttons
• 'aria-labelledby="section-heading"' um ein Element mit einer sichtbaren Ueberschrift zu verknuepfen

Haeufige ARIA-Fehler und ihre Korrektur

• Redundante Rollen: '<nav role="navigation">' ist doppelt gemoppelt. Verwenden Sie einfach '<nav>'
• Fehlende Tastaturzugaenglichkeit: 'role="button"' auf einem '<div>' macht es nicht automatisch per Tastatur bedienbar. Sie muessen 'tabindex="0"' und Keyboard-Event-Handler hinzufuegen
• aria-hidden="true" auf sichtbaren Inhalten: Versteckt Inhalte vor Screenreadern, obwohl sie sichtbar sind
• Fehlende Live-Regions: Dynamische Fehlermeldungen in Formularen ohne 'aria-live' werden von Screenreadern nicht erkannt

Testing-Workflow fuer ARIA-Implementierungen

1. Automatisiertes Testing: axe DevTools oder Lighthouse identifizieren grundlegende ARIA-Fehler
2. Screenreader-Test: Testen Sie mit NVDA (Windows, kostenlos) oder VoiceOver (macOS, vorinstalliert)
3. Tastatur-Navigation: Pruefen Sie jeden interaktiven Bereich nur mit der Tastatur
4. Browser-DevTools: Die Accessibility-Panels in Chrome und Firefox zeigen den berechneten ARIA-Baum

Barrierefreie Formulare und Interaktive Elemente

Formulare sind einer der kritischsten Bereiche fuer die Barrierefreiheit. In Oesterreich nutzen rund 18 % der Bevoelkerung assistive Technologien -- das sind potenzielle Kunden, die Sie durch unzugaengliche Formulare verlieren.

Grundregeln fuer barrierefreie Formulare

Labels und Eingabefelder korrekt verknuepfen:

Jedes Eingabefeld benoetigt ein eindeutig zugeordnetes Label. Die Verknuepfung erfolgt ueber das 'for'-Attribut am Label und die entsprechende 'id' am Eingabefeld. Placeholder-Text ist kein Ersatz fuer ein Label -- er verschwindet bei der Eingabe und bietet keine zuverlaessige Beschriftung.

Fehlermeldungen zugaenglich gestalten:

• Fehlermeldungen muessen programmatisch mit dem fehlerhaften Feld verknuepft sein (via 'aria-describedby')
• Verwenden Sie 'aria-invalid="true"' bei fehlerhaften Feldern
• Platzieren Sie Fehlermeldungen vor oder neben dem Feld, nicht nur am Anfang des Formulars
• Setzen Sie den Fokus auf die erste Fehlermeldung nach dem Absenden

Feldgruppen logisch strukturieren:

• Verwenden Sie '<fieldset>' und '<legend>' fuer zusammengehoerige Felder (z.B. Adressdaten, Zahlungsinformationen)
• Radio Buttons und Checkboxes gehoeren immer in eine Feldgruppe

Barrierefreie Custom-Komponenten

Dropdown-Menues / Select-Alternativen:

• Verwenden Sie moeglichst das native '<select>'-Element
• Bei Custom-Dropdowns: Implementieren Sie die vollstaendige WAI-ARIA Combobox-Spezifikation
• Tastatursteuerung: Pfeiltasten zum Navigieren, Enter zum Auswaehlen, Escape zum Schliessen

Datepicker:

• Native '<input type="date">' ist die barrierefreieste Option
• Custom-Datepicker muessen vollstaendig per Tastatur bedienbar sein
• Bieten Sie immer eine manuelle Texteingabe als Alternative an

Slider / Range-Inputs:

• Verwenden Sie '<input type="range">' wo moeglich
• Bei Custom-Slidern: 'role="slider"', 'aria-valuemin', 'aria-valuemax', 'aria-valuenow' und 'aria-valuetext' implementieren

Multi-Step-Formulare barrierefrei gestalten

Fuer laengere Formulare (z.B. Checkout-Prozesse) gelten zusaetzliche Anforderungen:

• Fortschrittsanzeige: Verwenden Sie 'aria-current="step"' fuer den aktuellen Schritt
• Schritt-Navigation: Ermoeaglichen Sie die Rueckkehr zu vorherigen Schritten per Tastatur
• Eingaben erhalten: Bereits ausgefuellte Felder muessen beim Zuruecknavigieren erhalten bleiben
• Zusammenfassung: Bieten Sie vor dem finalen Absenden eine barrierefreie Zusammenfassung aller Eingaben

Barrierefreiheit fuer E-Commerce: Online-Shops zugaenglich machen

Ab dem 28. Juni 2025 tritt das Barrierefreiheitsstaerkungsgesetz (BaFG) in Oesterreich in Kraft, das die EU-Richtlinie European Accessibility Act (EAA) umsetzt. Online-Shops sind davon direkt betroffen.

Gesetzliche Anforderungen fuer oesterreichische Online-Shops

Das BaFG gilt fuer alle Unternehmen ausser Kleinstunternehmen (weniger als 10 Mitarbeiter und weniger als EUR 2 Mio. Jahresumsatz). Betroffene Online-Shops muessen:

• Die WCAG 2.1 Konformitaetsstufe AA einhalten
• Ein Barrierefreiheits-Statement veroeffentlichen
• Einen Feedback-Mechanismus fuer Barrierefreiheitsprobleme bereitstellen
• Bei Verstoessen drohen Verwaltungsstrafen bis zu EUR 80.000

Kritische Bereiche im E-Commerce

Produktseiten:

• Alle Produktbilder benoetigen aussagekraeftige Alt-Texte (nicht nur "Produktbild", sondern "Blaues Herren-Poloshirt, Groesse M, aus Bio-Baumwolle")
• Groessen- und Farb-Selektoren muessen per Tastatur bedienbar sein
• Preisinformationen duerfen nicht nur visuell (z.B. durchgestrichener Preis) kommuniziert werden

Warenkorb und Checkout:

• Mengenaeaenderungen und Loeschfunktionen muessen per Tastatur und Screenreader bedienbar sein
• Statusmeldungen ("Artikel wurde hinzugefuegt") als 'aria-live'-Regionen implementieren
• Zahlungsformulare muessen vollstaendig barrierefrei sein -- inklusive Kreditkarten-Eingabefelder

Filternavigation:

• Facettenfilter muessen per Tastatur bedienbar sein
• Filteraenderungen muessen dynamisch angekuendigt werden ('aria-live')
• Die Anzahl der Ergebnisse muss nach Filterung kommuniziert werden

Suche:

• Autocomplete-Vorschlaege muessen per Tastatur navigierbar sein
• Suchergebnisse muessen als Live-Region angekuendigt werden
• "Keine Ergebnisse"-Meldungen muessen von Screenreadern erfasst werden

Barrierefreiheits-Audit fuer bestehende Shops

Fuehren Sie ein strukturiertes Audit in vier Phasen durch:

1. Automatisiertes Scanning: Tools wie axe, WAVE oder Lighthouse identifizieren ca. 30-40 % aller Barrierefreiheitsprobleme
2. Manuelles Testing: Tastatur-Navigation durch alle kritischen User Flows (Suche, Produktauswahl, Warenkorb, Checkout)
3. Assistive-Technology-Testing: Screenreader-Tests mit NVDA/VoiceOver und Vergroesserungssoftware
4. Nutzer-Testing: Tests mit Betroffenen -- mindestens 3-5 Personen mit unterschiedlichen Behinderungen

ROI barrierefreier Online-Shops

Barrierefreiheit ist nicht nur gesetzliche Pflicht, sondern auch wirtschaftlich sinnvoll:

• 15-20 % der Bevoelkerung haben eine Form von Behinderung -- eine erhebliche Kundengruppe
• Barrierefreie Shops erzielen im Durchschnitt 12 % hoehere Conversion Rates (bessere Usability fuer alle)
• SEO-Vorteile: Barrierefreie Websites ranken tendenziell besser (sauberes Markup, Alt-Texte, semantisches HTML)
• Reduziertes Rechtsrisiko: Vermeidung von Abmahnungen und Verwaltungsstrafen

Barrierefreiheits-Statement erstellen und pflegen

Ein Barrierefreiheits-Statement (Accessibility Statement) ist ab Juni 2025 fuer die meisten oesterreichischen Websites und Online-Shops verpflichtend. Es dokumentiert den aktuellen Stand der Barrierefreiheit und zeigt Ihren Nutzern, dass Sie das Thema ernst nehmen.

Gesetzliche Grundlage und Anforderungen

Das Barrierefreiheitsstaerkungsgesetz (BaFG) und das Web-Zugaenglichkeits-Gesetz (WZG) in Oesterreich verpflichten Unternehmen zur Veroeffentlichung eines Barrierefreiheits-Statements. Dieses muss:

• Auf jeder Website auffindbar sein (idealerweise im Footer verlinkt)
• In einfacher Sprache verfasst sein
• Regelmaessig aktualisiert werden (mindestens jaehrlich)
• Kontaktinformationen fuer Feedback enthalten

Pflichtinhalte eines Barrierefreiheits-Statements

1. Geltungsbereich:

Beschreiben Sie, fuer welche Website(s) oder App(s) das Statement gilt. Geben Sie die genauen URLs an.

2. Konformitaetsstatus:

Waehlen Sie eine der folgenden Formulierungen:

• "Vollstaendig konform" -- alle WCAG 2.1 AA-Kriterien werden erfuellt
• "Teilweise konform" -- die meisten, aber nicht alle Kriterien werden erfuellt
• "Nicht konform" -- wesentliche Kriterien werden nicht erfuellt

In der Praxis sind die meisten Websites "teilweise konform". Seien Sie hier ehrlich -- ein transparentes Statement ist besser als ein falsches.

3. Bekannte Einschraenkungen:

Listen Sie konkret auf, welche Bereiche nicht vollstaendig barrierefrei sind:

• "Videos enthalten derzeit keine Untertitel (Korrektur geplant bis Q3 2026)"
• "Der Datepicker in der Buchungsfunktion ist nicht vollstaendig per Tastatur bedienbar"
• "PDF-Dokumente aus dem Zeitraum vor 2024 sind nicht barrierefrei aufbereitet"

4. Feedback-Mechanismus:

Stellen Sie einen klaren Kommunikationsweg bereit:

• Dedizierte E-Mail-Adresse (z.B. barrierefreiheit@firma.at)
• Kontaktformular (das selbst barrierefrei sein muss)
• Telefonnummer als Alternative

5. Durchsetzungsverfahren:

Verweisen Sie auf die zustaendige Stelle in Oesterreich: die Oesterreichische Forschungsfoerderungsgesellschaft (FFG) als Beschwerdestelle fuer digitale Barrierefreiheit.

Vorlage fuer ein Barrierefreiheits-Statement

Verwenden Sie den Generator der EU-Kommission als Ausgangspunkt und passen Sie ihn an Ihre spezifische Situation an. Die W3C bietet ebenfalls eine ausfuehrliche Vorlage unter der WAI-Website.

Pflege und Aktualisierung

• Nach jedem Website-Relaunch: Statement komplett ueberarbeiten
• Quartalsweise: Bekannte Einschraenkungen aktualisieren
• Nach Barrierefreiheits-Audits: Ergebnisse und Massnahmen dokumentieren
• Bei Nutzerfeedback: Gemeldete Probleme aufnehmen und Behebungszeitraum angeben

Best Practices aus dem DACH-Raum

Vorbildliche Barrierefreiheits-Statements finden Sie bei:

• oesterreich.gv.at: Sehr detailliert mit konkreten Massnahmen und Zeitplaenen
• Deutsche Bahn (bahn.de): Transparente Kommunikation bekannter Einschraenkungen
• Wiener Linien (wienerlinien.at): Klare Struktur mit Kontaktmoeglichkeiten

Orientieren Sie sich an diesen Vorbildern und passen Sie den Detailgrad an die Groesse und Komplexitaet Ihrer Website an. Ein gut gepflegtes Barrierefreiheits-Statement signalisiert Professionalitaet und Verantwortungsbewusstsein -- Werte, die auch Ihre sehenden und hoerenden Kunden zu schaetzen wissen.

ARIA-Attribute richtig einsetzen: Praxisleitfaden

ARIA (Accessible Rich Internet Applications) ist ein maaechtiges Werkzeug, um Webanwendungen fuer Screenreader und andere assistive Technologien zugaenglich zu machen. Doch ARIA wird haeufig falsch eingesetzt -- was die Barrierefreiheit eher verschlechtert als verbessert.

Die goldene Regel: Kein ARIA ist besser als falsches ARIA

Bevor Sie ARIA-Attribute einsetzen, pruefen Sie immer, ob ein natives HTML-Element die gleiche Funktion erfuellt. Ein '<button>' ist immer besser als ein '<div role="button">'. Native Elemente bringen Tastaturzugaenglichkeit, Fokus-Management und Screenreader-Unterstuetzung automatisch mit.

Die wichtigsten ARIA-Rollen fuer moderne Websites

Landmark-Rollen strukturieren Ihre Seite fuer Screenreader-Nutzer:

• 'role="banner"' -- entspricht '<header>', der Kopfbereich der Seite
• 'role="navigation"' -- entspricht '<nav>', Navigationsbereiche
• 'role="main"' -- entspricht '<main>', der Hauptinhalt
• 'role="contentinfo"' -- entspricht '<footer>', der Fussbereich
• 'role="complementary"' -- entspricht '<aside>', ergaenzende Inhalte

Hinweis: Wenn Sie semantische HTML5-Elemente verwenden, sind diese Rollen redundant. Setzen Sie sie nur ein, wenn Sie aus technischen Gruenden keine semantischen Elemente nutzen koennen.

ARIA-States und Properties in der Praxis

aria-expanded: Fuer aufklappbare Menues, Akkordeons und Dropdowns:

• Setzen Sie 'aria-expanded="false"' im geschlossenen Zustand
• Aendern Sie auf 'aria-expanded="true"' beim Oeffnen
• Verbinden Sie das steuernde Element mit dem gesteuerten Bereich via 'aria-controls'

aria-live: Fuer dynamische Inhaltsaenderungen (Benachrichtigungen, Statusmeldungen):

• 'aria-live="polite"' -- Aenderung wird angekuendigt, wenn der Nutzer inaktiv ist (Standard fuer die meisten Faelle)
• 'aria-live="assertive"' -- Aenderung wird sofort angekuendigt (nur fuer kritische Meldungen wie Fehlermeldungen)

aria-label und aria-labelledby: Fuer Elemente, die keinen sichtbaren Text haben:

• 'aria-label="Hauptnavigation schliessen"' fuer Icon-Buttons
• 'aria-labelledby="section-heading"' um ein Element mit einer sichtbaren Ueberschrift zu verknuepfen

Haeufige ARIA-Fehler und ihre Korrektur

• Redundante Rollen: '<nav role="navigation">' ist doppelt gemoppelt. Verwenden Sie einfach '<nav>'
• Fehlende Tastaturzugaenglichkeit: 'role="button"' auf einem '<div>' macht es nicht automatisch per Tastatur bedienbar. Sie muessen 'tabindex="0"' und Keyboard-Event-Handler hinzufuegen
• aria-hidden="true" auf sichtbaren Inhalten: Versteckt Inhalte vor Screenreadern, obwohl sie sichtbar sind
• Fehlende Live-Regions: Dynamische Fehlermeldungen in Formularen ohne 'aria-live' werden von Screenreadern nicht erkannt

Testing-Workflow fuer ARIA-Implementierungen

1. Automatisiertes Testing: axe DevTools oder Lighthouse identifizieren grundlegende ARIA-Fehler
2. Screenreader-Test: Testen Sie mit NVDA (Windows, kostenlos) oder VoiceOver (macOS, vorinstalliert)
3. Tastatur-Navigation: Pruefen Sie jeden interaktiven Bereich nur mit der Tastatur
4. Browser-DevTools: Die Accessibility-Panels in Chrome und Firefox zeigen den berechneten ARIA-Baum

Barrierefreie Formulare und Interaktive Elemente

Formulare sind einer der kritischsten Bereiche fuer die Barrierefreiheit. In Oesterreich nutzen rund 18 % der Bevoelkerung assistive Technologien -- das sind potenzielle Kunden, die Sie durch unzugaengliche Formulare verlieren.

Grundregeln fuer barrierefreie Formulare

Labels und Eingabefelder korrekt verknuepfen:

Jedes Eingabefeld benoetigt ein eindeutig zugeordnetes Label. Die Verknuepfung erfolgt ueber das 'for'-Attribut am Label und die entsprechende 'id' am Eingabefeld. Placeholder-Text ist kein Ersatz fuer ein Label -- er verschwindet bei der Eingabe und bietet keine zuverlaessige Beschriftung.

Fehlermeldungen zugaenglich gestalten:

• Fehlermeldungen muessen programmatisch mit dem fehlerhaften Feld verknuepft sein (via 'aria-describedby')
• Verwenden Sie 'aria-invalid="true"' bei fehlerhaften Feldern
• Platzieren Sie Fehlermeldungen vor oder neben dem Feld, nicht nur am Anfang des Formulars
• Setzen Sie den Fokus auf die erste Fehlermeldung nach dem Absenden

Feldgruppen logisch strukturieren:

• Verwenden Sie '<fieldset>' und '<legend>' fuer zusammengehoerige Felder (z.B. Adressdaten, Zahlungsinformationen)
• Radio Buttons und Checkboxes gehoeren immer in eine Feldgruppe

Barrierefreie Custom-Komponenten

Dropdown-Menues / Select-Alternativen:

• Verwenden Sie moeglichst das native '<select>'-Element
• Bei Custom-Dropdowns: Implementieren Sie die vollstaendige WAI-ARIA Combobox-Spezifikation
• Tastatursteuerung: Pfeiltasten zum Navigieren, Enter zum Auswaehlen, Escape zum Schliessen

Datepicker:

• Native '<input type="date">' ist die barrierefreieste Option
• Custom-Datepicker muessen vollstaendig per Tastatur bedienbar sein
• Bieten Sie immer eine manuelle Texteingabe als Alternative an

Slider / Range-Inputs:

• Verwenden Sie '<input type="range">' wo moeglich
• Bei Custom-Slidern: 'role="slider"', 'aria-valuemin', 'aria-valuemax', 'aria-valuenow' und 'aria-valuetext' implementieren

Multi-Step-Formulare barrierefrei gestalten

Fuer laengere Formulare (z.B. Checkout-Prozesse) gelten zusaetzliche Anforderungen:

• Fortschrittsanzeige: Verwenden Sie 'aria-current="step"' fuer den aktuellen Schritt
• Schritt-Navigation: Ermoeaglichen Sie die Rueckkehr zu vorherigen Schritten per Tastatur
• Eingaben erhalten: Bereits ausgefuellte Felder muessen beim Zuruecknavigieren erhalten bleiben
• Zusammenfassung: Bieten Sie vor dem finalen Absenden eine barrierefreie Zusammenfassung aller Eingaben

Barrierefreiheit fuer E-Commerce: Online-Shops zugaenglich machen

Ab dem 28. Juni 2025 tritt das Barrierefreiheitsstaerkungsgesetz (BaFG) in Oesterreich in Kraft, das die EU-Richtlinie European Accessibility Act (EAA) umsetzt. Online-Shops sind davon direkt betroffen.

Gesetzliche Anforderungen fuer oesterreichische Online-Shops

Das BaFG gilt fuer alle Unternehmen ausser Kleinstunternehmen (weniger als 10 Mitarbeiter und weniger als EUR 2 Mio. Jahresumsatz). Betroffene Online-Shops muessen:

• Die WCAG 2.1 Konformitaetsstufe AA einhalten
• Ein Barrierefreiheits-Statement veroeffentlichen
• Einen Feedback-Mechanismus fuer Barrierefreiheitsprobleme bereitstellen
• Bei Verstoessen drohen Verwaltungsstrafen bis zu EUR 80.000

Kritische Bereiche im E-Commerce

Produktseiten:

• Alle Produktbilder benoetigen aussagekraeftige Alt-Texte (nicht nur "Produktbild", sondern "Blaues Herren-Poloshirt, Groesse M, aus Bio-Baumwolle")
• Groessen- und Farb-Selektoren muessen per Tastatur bedienbar sein
• Preisinformationen duerfen nicht nur visuell (z.B. durchgestrichener Preis) kommuniziert werden

Warenkorb und Checkout:

• Mengenaeaenderungen und Loeschfunktionen muessen per Tastatur und Screenreader bedienbar sein
• Statusmeldungen ("Artikel wurde hinzugefuegt") als 'aria-live'-Regionen implementieren
• Zahlungsformulare muessen vollstaendig barrierefrei sein -- inklusive Kreditkarten-Eingabefelder

Filternavigation:

• Facettenfilter muessen per Tastatur bedienbar sein
• Filteraenderungen muessen dynamisch angekuendigt werden ('aria-live')
• Die Anzahl der Ergebnisse muss nach Filterung kommuniziert werden

Suche:

• Autocomplete-Vorschlaege muessen per Tastatur navigierbar sein
• Suchergebnisse muessen als Live-Region angekuendigt werden
• "Keine Ergebnisse"-Meldungen muessen von Screenreadern erfasst werden

Barrierefreiheits-Audit fuer bestehende Shops

Fuehren Sie ein strukturiertes Audit in vier Phasen durch:

1. Automatisiertes Scanning: Tools wie axe, WAVE oder Lighthouse identifizieren ca. 30-40 % aller Barrierefreiheitsprobleme
2. Manuelles Testing: Tastatur-Navigation durch alle kritischen User Flows (Suche, Produktauswahl, Warenkorb, Checkout)
3. Assistive-Technology-Testing: Screenreader-Tests mit NVDA/VoiceOver und Vergroesserungssoftware
4. Nutzer-Testing: Tests mit Betroffenen -- mindestens 3-5 Personen mit unterschiedlichen Behinderungen

ROI barrierefreier Online-Shops

Barrierefreiheit ist nicht nur gesetzliche Pflicht, sondern auch wirtschaftlich sinnvoll:

• 15-20 % der Bevoelkerung haben eine Form von Behinderung -- eine erhebliche Kundengruppe
• Barrierefreie Shops erzielen im Durchschnitt 12 % hoehere Conversion Rates (bessere Usability fuer alle)
• SEO-Vorteile: Barrierefreie Websites ranken tendenziell besser (sauberes Markup, Alt-Texte, semantisches HTML)
• Reduziertes Rechtsrisiko: Vermeidung von Abmahnungen und Verwaltungsstrafen

Barrierefreiheits-Statement erstellen und pflegen

Ein Barrierefreiheits-Statement (Accessibility Statement) ist ab Juni 2025 fuer die meisten oesterreichischen Websites und Online-Shops verpflichtend. Es dokumentiert den aktuellen Stand der Barrierefreiheit und zeigt Ihren Nutzern, dass Sie das Thema ernst nehmen.

Gesetzliche Grundlage und Anforderungen

Das Barrierefreiheitsstaerkungsgesetz (BaFG) und das Web-Zugaenglichkeits-Gesetz (WZG) in Oesterreich verpflichten Unternehmen zur Veroeffentlichung eines Barrierefreiheits-Statements. Dieses muss:

• Auf jeder Website auffindbar sein (idealerweise im Footer verlinkt)
• In einfacher Sprache verfasst sein
• Regelmaessig aktualisiert werden (mindestens jaehrlich)
• Kontaktinformationen fuer Feedback enthalten

Pflichtinhalte eines Barrierefreiheits-Statements

1. Geltungsbereich:

Beschreiben Sie, fuer welche Website(s) oder App(s) das Statement gilt. Geben Sie die genauen URLs an.

2. Konformitaetsstatus:

Waehlen Sie eine der folgenden Formulierungen:

• "Vollstaendig konform" -- alle WCAG 2.1 AA-Kriterien werden erfuellt
• "Teilweise konform" -- die meisten, aber nicht alle Kriterien werden erfuellt
• "Nicht konform" -- wesentliche Kriterien werden nicht erfuellt

In der Praxis sind die meisten Websites "teilweise konform". Seien Sie hier ehrlich -- ein transparentes Statement ist besser als ein falsches.

3. Bekannte Einschraenkungen:

Listen Sie konkret auf, welche Bereiche nicht vollstaendig barrierefrei sind:

• "Videos enthalten derzeit keine Untertitel (Korrektur geplant bis Q3 2026)"
• "Der Datepicker in der Buchungsfunktion ist nicht vollstaendig per Tastatur bedienbar"
• "PDF-Dokumente aus dem Zeitraum vor 2024 sind nicht barrierefrei aufbereitet"

4. Feedback-Mechanismus:

Stellen Sie einen klaren Kommunikationsweg bereit:

• Dedizierte E-Mail-Adresse (z.B. barrierefreiheit@firma.at)
• Kontaktformular (das selbst barrierefrei sein muss)
• Telefonnummer als Alternative

5. Durchsetzungsverfahren:

Verweisen Sie auf die zustaendige Stelle in Oesterreich: die Oesterreichische Forschungsfoerderungsgesellschaft (FFG) als Beschwerdestelle fuer digitale Barrierefreiheit.

Vorlage fuer ein Barrierefreiheits-Statement

Verwenden Sie den Generator der EU-Kommission als Ausgangspunkt und passen Sie ihn an Ihre spezifische Situation an. Die W3C bietet ebenfalls eine ausfuehrliche Vorlage unter der WAI-Website.

Pflege und Aktualisierung

• Nach jedem Website-Relaunch: Statement komplett ueberarbeiten
• Quartalsweise: Bekannte Einschraenkungen aktualisieren
• Nach Barrierefreiheits-Audits: Ergebnisse und Massnahmen dokumentieren
• Bei Nutzerfeedback: Gemeldete Probleme aufnehmen und Behebungszeitraum angeben

Best Practices aus dem DACH-Raum

Vorbildliche Barrierefreiheits-Statements finden Sie bei:

• oesterreich.gv.at: Sehr detailliert mit konkreten Massnahmen und Zeitplaenen
• Deutsche Bahn (bahn.de): Transparente Kommunikation bekannter Einschraenkungen
• Wiener Linien (wienerlinien.at): Klare Struktur mit Kontaktmoeglichkeiten

Orientieren Sie sich an diesen Vorbildern und passen Sie den Detailgrad an die Groesse und Komplexitaet Ihrer Website an. Ein gut gepflegtes Barrierefreiheits-Statement signalisiert Professionalitaet und Verantwortungsbewusstsein -- Werte, die auch Ihre sehenden und hoerenden Kunden zu schaetzen wissen.

Barrierefreiheit im Redesign: Bestehende Websites nachrüsten

Viele österreichische Unternehmen stehen vor der Herausforderung, eine bestehende Website barrierefrei zu machen, ohne das gesamte Projekt von Grund auf neu aufzusetzen. Mit dem Barrierefreiheitsstärkungsgesetz (BaFG), das ab Juni 2025 greift, ist die Nachrüstung für zahlreiche Betriebe keine Option mehr, sondern eine gesetzliche Pflicht. Die gute Nachricht: Ein systematisches Vorgehen macht die Nachrüstung planbar und wirtschaftlich umsetzbar.

Bestandsaufnahme: Wo steht Ihre Website aktuell?

Bevor Sie mit der Nachrüstung beginnen, benötigen Sie eine ehrliche Analyse des Ist-Zustands. Nutzen Sie eine Kombination aus automatisierten und manuellen Tests:

• Automatisierte Scans mit Tools wie axe DevTools, WAVE oder Lighthouse decken circa 30–40 Prozent aller Barrieren auf – vor allem fehlende Alt-Texte, mangelnde Farbkontraste und fehlerhafte ARIA-Attribute
• Manuelle Tastaturnavigation: Navigieren Sie Ihre gesamte Website ausschließlich mit der Tastatur. Können Sie jedes interaktive Element erreichen? Ist der Fokus stets sichtbar?
• Screenreader-Tests: Lassen Sie Ihre Seiten mit VoiceOver (macOS/iOS) oder NVDA (Windows) vorlesen. Ergibt die vorgelesene Reihenfolge Sinn? Werden Bilder und Formulare korrekt beschrieben?
• Content-Audit: Prüfen Sie Texte auf Verständlichkeit, Überschriftenstruktur und die korrekte Auszeichnung von Sprache

Dokumentieren Sie jede gefundene Barriere in einer strukturierten Liste mit Schweregrad (kritisch, schwerwiegend, moderat, gering), betroffener Seitentyp und WCAG-Erfolgskriterium. Diese Liste wird Ihr Fahrplan für die Nachrüstung.

Priorisierung: Die richtige Reihenfolge der Maßnahmen

Nicht alle Barrieren haben die gleiche Dringlichkeit. Priorisieren Sie nach dem Impact-Effort-Prinzip:

Sofort umsetzen (Quick Wins mit hohem Impact):

• Fehlende Alt-Texte für Bilder ergänzen – das betrifft oft hunderte Bilder und ist dennoch relativ schnell umsetzbar
• Farbkontraste anpassen – häufig reichen kleine Anpassungen in der CSS-Datei
• Fehlende Formularlabels hinzufügen – technisch simpel, aber enorm wichtig für Screenreader-Nutzer
• Skip-Navigation-Links einbauen – eine einzelne Komponente, die allen Tastaturnutzern hilft

Mittelfristig umsetzen (moderate Komplexität):

• Überschriftenhierarchie korrigieren – erfordert Anpassungen in Templates und bestehendem Content
• ARIA-Landmarks und Rollen korrekt setzen – braucht technisches Verständnis, verbessert die Seitenstruktur massiv
• Fokusmanagement bei dynamischen Inhalten (Modals, Akkordeons, Tabs) überarbeiten – JavaScript-Anpassungen erforderlich
• Responsive Verhalten für Zoom bis 200 Prozent sicherstellen

Langfristig planen (hoher Aufwand):

• Komplette Neugestaltung von interaktiven Komponenten wie Custom-Dropdowns, Datepickern oder Karussells
• Video- und Audio-Inhalte mit Untertiteln und Transkripten versehen
• PDF-Dokumente barrierefrei aufbereiten oder durch HTML-Alternativen ersetzen
• Komplexe Datenvisualisierungen zugänglich machen

Technische Nachrüstung: Schritt für Schritt

Bei der technischen Umsetzung hat sich ein komponentenbasierter Ansatz bewährt. Statt Seite für Seite durchzugehen, identifizieren Sie die wiederverwendeten Komponenten Ihrer Website und machen diese einzeln barrierefrei:

Header und Navigation: Die Navigation ist das meistgenutzte Element Ihrer Website. Stellen Sie sicher, dass das Menü per Tastatur bedienbar ist, Untermenüs mit Escape geschlossen werden können und der aktuelle Seitenbereich mit `aria-current="page"` markiert ist. Bei mobilen Hamburger-Menüs muss der Fokus beim Öffnen in das Menü springen und beim Schließen zum Auslöser zurückkehren.

Formulare und Kontaktseiten: Jedes Eingabefeld benötigt ein programmatisch verknüpftes Label. Fehlermeldungen müssen sowohl visuell als auch für Screenreader erkennbar sein – nutzen Sie `aria-describedby` für Fehlertexte und `aria-invalid="true"` für fehlerhafte Felder. Pflichtfelder kennzeichnen Sie nicht nur mit einem Sternchen, sondern auch mit `aria-required="true"`.

Content-Bereiche: Stellen Sie sicher, dass alle Überschriften eine logische Hierarchie bilden (H1 → H2 → H3, ohne Sprünge). Listen verwenden die korrekten HTML-Elemente (`ul`, `ol`, `dl`). Links sind aussagekräftig beschriftet – ‘Mehr erfahren" ohne Kontext ist für Screenreader-Nutzer unbrauchbar.

CMS-Anpassungen für redaktionelle Barrierefreiheit

Die technische Nachrüstung ist nur die halbe Miete. Damit auch zukünftiger Content barrierefrei bleibt, müssen Sie Ihr Content-Management-System anpassen:

• Alt-Text als Pflichtfeld konfigurieren – kein Bild-Upload ohne Alternativtext
• Überschriften-Templates vordefinieren, die eine korrekte Hierarchie erzwingen
• Redaktionsleitfaden erstellen mit klaren Vorgaben für Linkbeschriftungen, Tabellenaufbau und Dokumentenformate
• Automatische Prüfungen im CMS integrieren, die Kontrastverletzungen oder fehlende Labels vor der Veröffentlichung melden

Kosten und Zeitrahmen realistisch planen

Für eine typische österreichische Unternehmenswebsite mit 30–80 Seiten sollten Sie mit folgendem Aufwand rechnen:

• Audit und Bestandsaufnahme: 2–4 Arbeitstage
• Quick Wins umsetzen: 3–5 Arbeitstage
• Komponentenbasierte Nachrüstung: 10–20 Arbeitstage, abhängig von der Komplexität
• Content-Nachbearbeitung: 5–10 Arbeitstage (stark abhängig vom Umfang)
• Testing und Feinschliff: 3–5 Arbeitstage

Insgesamt bewegen sich die Kosten für eine professionelle Nachrüstung zwischen 5.000 und 25.000 Euro – deutlich günstiger als ein komplettes Redesign, das schnell das Drei- bis Fünffache kosten kann. Entscheidend ist, dass Sie die Nachrüstung nicht als einmalige Maßnahme betrachten, sondern als fortlaufenden Prozess in Ihre Qualitätssicherung integrieren.

Fazit: Barrierefreiheit ist kein Hindernis, sondern eine Chance

Website-Barrierefreiheit nach WCAG 2.2 ist 2026 keine Kür mehr, sondern Pflicht – rechtlich, wirtschaftlich und ethisch. Unternehmen, die jetzt investieren, profitieren von einer größeren Zielgruppe, besserem SEO, niedrigeren Absprungraten und einem positiven Markenimage. Die Kosten sind überschaubar, der Return on Investment messbar.

GoldenWing unterstützt österreichische Unternehmen seit über 3 Jahren auf dem Weg zur barrierefreien Website. Von der Erstanalyse über die Konzeption bis zur technischen Umsetzung und laufenden Wartung bieten wir alles aus einer Hand. Kontaktieren Sie uns für ein unverbindliches Erstgespräch und erfahren Sie, wie barrierefrei Ihre Website aktuell ist.