Zwischenbericht nach dem Monitoring-Zeitraum 2025
Worum geht es?
Im Auftrag des Bundes checken wir – als Monitoring-Stelle – jährlich, stichprobenartig Websites und Apps der öffentlichen Hand auf ihre digitale Barrierefreiheit. Unsere Aufgaben sind im Web-Zugänglichkeits-Gesetz definiert. Auch die Monitoringstellen in den Bundesländern überprüfen jährlich die online Angebote der öffentlichen Hand im jeweiligen Bundesland auf digitale Barrierefreiheit, basierend auf 9 entsprechenden Landesgesetzen.
Alle Ergebnisse dieser Checks werten wir für ganz Österreich aus und informieren alle drei Jahre die EU-Kommission über den Fortschritt der Barrierefreiheit in Österreich.
Der letzte umfassende Bericht über Österreichs digitale Barrierefreiheit (externer Link) wurde 2024 veröffentlicht, der nächste folgt 2027.
Im aktuellen Zwischenbericht zeigen wir zentrale Ergebnisse des Barrierefreiheits-Monitorings des Jahres 2025. Es handelt sich um einen Ausschnitt aus den erhobenen Daten. Details zur Methodik, weitere Hintergrundinformationen und die vollständigen Auswertungen werden im Monitoring-Bericht 2027 veröffentlicht.
Details zu den Monitoring-Checks
Die FFG und alle Bundesländer führen zwei Arten von Monitoring-Checks der digitalen Auftritte von öffentlichen Einrichtungen durch:
- Vereinfachte Checks sind voll-automatisiert. Ein Accessibility-Prüfprogramm läuft über einzelne Seiten, die zuvor definiert wurden. Mehr Details zum vereinfachten Test-Vorgang finden Sie hier.
- Eingehende Checks sind umfangreich und überprüfen jedes einzelne – laut Europäischem Standard EN 301 549 (externer Link) geforderte – Barrierefreiheits-Kriterium auf der ausgewählten Website bzw. in der App. Mehr Details zum eingehenden Test-Vorgang finden Sie hier.
Das Wichtigste auf einen Blick
Barrierefreiheitserklärungen:
- Der Anteil der gecheckten Websites und Apps, die eine Barrierefreiheitserklärung veröffentlicht haben, ist 2025 (64 %) im Vergleich zu 2024 (57 %) gestiegen.
- Erstmals erhoben wurde, ob die Barrierefreiheitserklärungen aktuell sind: Knapp 70 % der Erklärungen hatten kein aktuelles Datum angegeben, obwohl eine jährliche Überprüfung vorgesehen ist.
- Auch neu erhoben wurde, ob die Barrierefreiheitserklärungen alle verpflichtenden Inhalte enthalten – das ist bei 73 % der Erklärungen der Fall.
Eingehende Checks Websites:
- Alle gecheckten Websites sind teilweise vereinbar mit den Barrierefreiheitsanforderungen (insgesamt 92 Kriterien). Keine Website ist vollständig vereinbar oder nicht vereinbar mit den Barrierefreiheitsanforderungen. Vollständig vereinbar bedeutet, dass alle Barrierefreiheitskriterien ausnahmslos erfüllt sind. Teilweise vereinbar bedeutet, dass mindestens die Hälfte der Barrierefreiheitskriterien erfüllt sind. Nicht vereinbar heißt, dass mehr als die Hälfte der Barrierefreiheitskriterien nicht erfüllt sind.
- Betrachtet man nur die WCAG-Kriterien (Web Content Accessibility Guidelines (externer Link); hier: WCAG 2.1, Level AA; 49 Kriterien), sind 87 % der Websites teilweise vereinbar mit den Anforderungen, 13 % nicht vereinbar und keine vollständig vereinbar. Im Mittel sind pro Website 18 WCAG-Kriterien nicht erfüllt. Das ist eine leichte Verbesserung zu 2024 (durchschnittlich 20 WCAG-Kriterien nicht erfüllt). Allerdings waren 2024 nur 9 % der Websites nicht mit den WCAG-Kriterien vereinbar.
- Generell zeigt sich durchschnittlich eine leichte Verbesserung im Vergleich zu 2024, aber es gibt auch vereinzelt mehr Websites mit sehr vielen Issues.
Eingehende Checks Apps:
- Alle gecheckten Apps sind teilweise vereinbar mit den Barrierefreiheitsanforderungen (insgesamt 120 Kriterien). Keine App ist vollständig vereinbar oder nicht vereinbar mit den Barrierefreiheitsanforderungen.
- Betrachtet man nur die WCAG-Kriterien (45 Kriterien), sind auch hier alle Apps teilweise vereinbar. Im Mittel sind pro App 13 WCAG-Kriterien nicht erfüllt. Das ist eine leichte Verbesserung zu 2024 (durchschnittlich 15 WCAG-Kriterien nicht erfüllt). 2024 waren noch 13 % der Apps nicht vereinbar mit den WCAG-Kriterien.
Generell ist im Vergleich festzustellen, dass die geprüften Apps 2025 mehr WCAG-Kriterien erfüllten als 2024.
Vereinfachte Checks Websites:
- 5 % der Websites zeigen zu den geprüften 14 WCAG-Kriterien keine Fehler. Rund 40 % weisen zu 4 bis 5 der geprüften Kriterien Fehler auf.
- Im Vergleich zu 2024 zeigt sich in den Ergebnissen der vereinfachten Checks ein sehr ähnliches Bild mit nur leichten Verschiebungen.
Die häufigsten Fehler:
Es sind größtenteils dieselben Kriterien wie 2024, zu denen auf den Websites bzw. in den Apps der öffentlichen Hand besonders häufig Barrierefreiheits-Issues gefunden werden. Zu folgenden WCAG-Kriterien finden sich bei mindestens rund 80 % der geprüften Websites und Apps Issues:
- Name, Role, Value (WCAG-Kriterium 4.1.2)
- Info and Relationships (WCAG-Kriterium 1.3.1)
- Focus Order (WCAG-Kriterium 2.4.3)
- Non-text Content (WCAG-Kriterium 1.1.1)
- Focus Visible (WCAG-Kriterium 2.4.7)
- Contrast (Minimum) (WCAG-Kriterium 1.4.3)
- Keyboard (WCAG-Kriterium 2.1.1)
- Link Purpose (In Context) (WCAG-Kriterium 2.4.4)
Konkrete, häufig gefundene Fehler werden im Bericht beschrieben. Im Vergleich zu den bisherigen Monitoringzeiträumen ist das Kriterium „2.4.4 Link Purpose (In Context)“ neu hinzugekommen. „2.1.1 Keyboard“ war zuletzt 2023 unter den am häufigsten nicht erfüllten Kriterien. Im Vergleich zu 2024 sind zwei Kriterien weggefallen: „1.4.11 Non-text-Contrast“ und „4.1.3 Status Messages“.
Wie viele Websites und Apps wurden 2025 gecheckt?
- 23 eingehende Checks Websites
- rund 440 Unterseiten
- 349 vereinfachte Checks Websites
- rund 5400 Unterseiten
- 16 eingehende Checks Apps
- rund 200 Screens
In welchem Zeitraum wurden die Checks durchgeführt?
Die Barrierefreiheits-Checks fanden zwischen 17. Februar 2025 und 16. Oktober 2025 statt.
Wie setzt sich die Stichprobe zusammen?
Verteilung nach Bund bzw. Bundesländern
| Bund oder Bundesland | Eingehende Checks Websites | Vereinfachte Checks Websites | Eingehende Checks Apps |
|---|---|---|---|
| Bund | 11 | 174 | 8 |
| Burgenland | 0 | 6 | 0 |
| Kärnten | 1 | 11 | 1 |
| Niederösterreich | 2 | 33 | 1 |
| Oberösterreich | 2 | 29 | 1 |
| Salzburg | 1 | 11 | 1 |
| Steiermark | 2 | 24 | 1 |
| Tirol | 1 | 15 | 1 |
| Vorarlberg | 1 | 8 | 0 |
| Wien | 2 | 38 | 2 |
Verteilung nach Verwaltungsebenen
Die Hälfte der gecheckten Websites und mobilen Anwendungen lässt sich dem Bund und somit der Verwaltungsebene „staatlich“ zuordnen, die andere Hälfte entfällt auf die Bundesländer-Ebene (Verwaltungsebene „regional“) sowie die Gemeinde-Ebene (Verwaltungsebene „lokal“).
- Lokal: 20 %
- Regional: 30 %
- Staatlich: 50 %
Verteilung nach Dienstleistungskategorien
| Dienstleistungskategorie | Anteil in der Stichprobe |
|---|---|
| Wohnen | 7 % |
| Öffentliche Ordnung und Sicherheit | 8 % |
| Beschäftigung und Steuern | 8 % |
| Verkehr | 8 % |
| Wirtschaft | 9 % |
| Gesundheit | 9 % |
| Soziales | 9 % |
| Freizeit und Kultur | 10 % |
| Anderes | 10 % |
| Umwelt und Energie | 11 % |
| Bildung, Wissenschaft und Forschung | 12 % |
Die Stichprobe ist vielfältig. Es werden inhaltlich viele unterschiedliche Themen von den Websites repräsentiert. Es sind zehn unterschiedliche Dienstleistungskategorien (und zusätzlich die Kategorie „Anderes“) in der Stichprobe enthalten. Die Kategorie „Bildung, Wissenschaft und Forschung“ ist am stärksten repräsentiert, die Kategorie „Wohnen“ am geringsten. Es wird eine gleiche Verteilung aller Dienstleistungskategorien in der Stichprobe angestrebt. Da es unterschiedlich viele Websites zu den Dienstleistungskategorien gibt, kann es sein, dass manche stärker vertreten sind als andere. Zusätzlich werden bevorzugt Websites in die Stichprobe aufgenommen, die noch nie im Rahmen des Monitorings überprüft wurden.
Für Apps: Verteilung nach Betriebssystemen & Downloadzahlen
Es wurden 8 mobile Anwendungen des Betriebssystems iOS gecheckt und 8 mobile Anwendungen des Betriebssystems Android.
Zusätzlich wurden für die Stichprobenziehung die Downloadzahlen der mobilen Anwendungen berücksichtigt und Apps, die öfter heruntergeladen wurden, bevorzugt in die Stichprobe aufgenommen (Downloadzahlen laut Google Play Store).
Ergebnisse der Erhebung zu Barrierefreiheitserklärungen
Öffentliche Stellen müssen auf ihren Websites und in ihren Apps eine Barrierefreiheitserklärung veröffentlichen. Diese Erklärung informiert detailliert, umfassend und klar in einem barrierefrei zugänglichen Format über die digitale Barrierefreiheit des jeweiligen Angebots. Auf unserer Website gibt es alle relevanten Informationen zur Barrierefreiheitserklärung zum Nachlesen.
Im Rahmen des Monitorings haben wir einige Daten in Zusammenhang mit den Barrierefreiheitserklärungen erhoben und ausgewertet.
Anteil Barrierefreiheitserklärungen
Fast zwei Drittel der gecheckten Websites und Apps (64 %) hatten eine Barrierefreiheitserklärung veröffentlicht, 36 % hatten keine.
Aktualität Barrierefreiheitserklärungen
Barrierefreiheitserklärungen müssen zumindest einmal jährlich überprüft und gegebenenfalls aktualisiert werden (siehe dazu die Angaben im einleitenden Absatz im Durchführungsbeschluss (EU) 2018/1523 der Kommission (externer Link)). Das Datum der letzten Überprüfung wird in der Barrierefreiheitserklärung angegeben. 31 % der Barrierefreiheitserklärungen hatten ein aktuelles Datum angegeben, 69 % hatten kein aktuelles Datum angegeben.
Vollständigkeit der verpflichtenden Inhalte
Die Barrierefreiheitserklärungen müssen sich an ein bestimmtes Schema halten – es gibt einige Inhalte, die in allen Barrierefreiheitserklärungen vorkommen müssen. Grundlage dafür ist die Mustererklärung der Europäischen Kommission (Durchführungsbeschluss (EU) 2018/1523) (externer Link). Hier finden Sie unsere Mustererklärung für Websites und Apps, die dem Bund zugeordnet werden können.
73 % der Barrierefreiheitserklärungen hatten die verpflichtenden Inhalte vollständig angegeben, bei 27 % der Barrierefreiheitserklärungen fehlten verpflichtende Inhalte.
Feedbackmechanismus
Die allermeisten Barrierefreiheitserklärungen (99 %) haben einen Feedback-Kontakt angegeben – eine Kontaktmöglichkeit, an die sich Nutzer:innen wenden können, wenn sie auf Barrieren stoßen.
Unverhältnismäßige Belastung
In 52,5 % der Barrierefreiheitserklärungen war angegeben, dass aufgrund unverhältnismäßiger Belastung einzelne Barrieren nicht beseitigt werden konnten. Häufig war hier beispielsweise angeführt, dass für Videos, die über YouTube gehostet werden, keine Audiodeskription bereitgestellt werden könne. Darüber hinaus wurde mehrfach angegeben, dass PDF-Dokumente nicht standardmäßig barrierefrei veröffentlicht werden könnten. In 47,5 % der Barrierefreiheitserklärungen wurde keine unverhältnismäßige Belastung angegeben.
Konformitäts-Status aus den Barrierefreiheitserklärungen
Tabelle: Konformitäts-Status aus den Barrierefreiheitserklärungen
| Angabe zum Konformitäts-Status | Anteil |
|---|---|
| Vollständig vereinbar | 8 % |
| Teilweise vereinbar | 76 % |
| Nicht vereinbar | 0,4 % |
| Nicht angegeben | 16 % |
Ein Abschnitt in der Barrierefreiheitserklärung beschreibt, ob die jeweilige Website oder App vollständig, teilweise oder nicht mit den Barrierefreiheitsanforderungen vereinbar ist. Es handelt sich dabei um eine Einschätzung, die von den Betreiber:innen der Website bzw. App getätigt wird.
Vollständig vereinbar bedeutet, dass alle Barrierefreiheitskriterien ausnahmslos erfüllt sind. Teilweise vereinbar bedeutet, dass mindestens die Hälfte der Barrierefreiheitskriterien erfüllt sind. Nicht vereinbar heißt, dass mehr als die Hälfte der Barrierefreiheitskriterien nicht erfüllt sind.
In knapp 85 % der Barrierefreiheitserklärungen fand sich eine solche Aussage zur Konformität. Ein Großteil (76 %) gab an, teilweise mit den Barrierefreiheitsanforderungen vereinbar zu sein. Als vollständig vereinbar bezeichneten sich rund 8 % der Websites bzw. Apps. Für nicht vereinbar mit den Barrierefreiheitsanforderungen hielten sich 0,4 %.
Ergebnisse der Barrierefreiheits-Checks
Eingehende Checks Websites
Pro gecheckter Website wurden durchschnittlich rund 19 Unterseiten für den Check ausgewählt. Bei der Auswahl der Unterseiten wurde unter anderem darauf geachtet, die Hauptzwecke der Websites abzubilden und ganze Prozesse mit aufzunehmen.
Anteile Konformitätsstatus aller eingehend gecheckten Websites
Bei den eingehenden Checks der Websites wurden jeweils rund 92 Kriterien gecheckt. Durchschnittlich erfüllten die Websites 21 Kriterien nicht. Die Website mit den wenigsten nicht erfüllten Kriterien erfüllte 8 Kriterien nicht. 43 % der Websites erfüllten weniger als 20 Kriterien nicht. 39 % der Websites erfüllten ab 20 bis weniger als 30 Kriterien nicht. 17 % der Websites erfüllten 30 oder mehr Kriterien nicht. Die Website mit den meisten nicht erfüllten Kriterien erfüllte 36 Kriterien nicht. Damit waren alle eingehend gecheckten Websites teilweise mit den Barrierefreiheitsanforderungen vereinbar – sie erfüllten mindestens 50 % der gecheckten Kriterien aber weniger als 100 %.
Betrachtet man nur die Web Content Accessibility Guidelines (WCAG) (externer Link) (hier: WCAG 2.1, Level AA; 49 gecheckte Kriterien) und bezieht die übrigen Kriterien aus EN 301 549 nicht ein, stellt sich die Vereinbarkeit folgendermaßen dar (Konformität mit WCAG):
- Vollständig vereinbar (100 % der WCAG-Kriterien erfüllt): keine der gecheckten Websites
- Teilweise vereinbar (mind. 50 % der WCAG-Kriterien erfüllt): 87 % der gecheckten Websites
- Nicht vereinbar (unter 50 % der WCAG-Kriterien erfüllt): 13 % der gecheckten Websites
Für die Berechnungen wurden Bewertungen mit „nicht anwendbar“ den Bewertungen mit „erfüllt“ zugerechnet.
Im Mittel erfüllten die Websites 18 WCAG-Kriterien nicht.
Monitoringergebnis nach Anzahl nicht erfüllter WCAG-Kriterien
| Anzahl nicht erfüllter Kriterien | Anteil der Websites | Anzahl Websites |
|---|---|---|
| 0 bis 5 | 0 % | 0 |
| 6 bis 10 | 13 % | 3 |
| 11 bis 15 | 26 % | 6 |
| 16 bis 20 | 26 % | 6 |
| 21 bis 25 | 22 % | 5 |
| 26 bis 30 | 9 % | 2 |
| 31 bis 35 | 4 % | 1 |
| 36 bis 40 | 0 % | 0 |
| 41 bis 45 | 0 % | 0 |
| 46 bis 49 | 0 % | 0 |
Vergleich Monitoringergebnis nach Anzahl nicht erfüllter WCAG-Kriterien 2024 und 2025
Tabelle: Vergleich Monitoringergebnis nach Anzahl nicht erfüllter WCAG-Kriterien 2024 und 2025
| Anzahl nicht erfüllter Kriterien | Anteil der Websites 2024 | Anteil der Websites 2025 |
|---|---|---|
| 0 bis 5 | 0 % | 0 % |
| 6 bis 10 | 0 % | 13 % |
| 11 bis 15 | 22 % | 26 % |
| 16 bis 20 | 35 % | 26 % |
| 21 bis 25 | 35 % | 22 % |
| 26 bis 30 | 9 % | 9 % |
| 31 bis 35 | 0 % | 4 % |
| 36 bis 40 | 0 % | 0 % |
| 41 bis 45 | 0 % | 0 % |
| 46 bis 49 | 0 % | 0 % |
Im Vergleich mit den Monitoringergebnissen aus dem Jahr 2024 zeigt sich: Mehr Websites erfüllten weniger WCAG-Kriterien nicht – während 2024 keine Website weniger als 11 WCAG-Kriterien nicht erfüllt hat, waren es 2025 13 % der Websites, die 6 bis 10 Kriterien nicht erfüllt haben. Jedoch gibt es nach wie vor gleich viele Websites, die 26 bis 30 Kriterien nicht erfüllt haben und auch eine, die 31 oder mehr Kriterien nicht erfüllte, was 2024 nicht der Fall war.
Am häufigsten nicht erfüllte Kriterien
Tabelle: Am häufigsten nicht erfüllte Kriterien
| Kriterium | Nicht erfüllt | Erfüllt | Nicht anwendbar |
|---|---|---|---|
| 3.1.2 Language of Parts | 52 % | 17 % | 30 % |
| 2.5.3 Label in Name | 52 % | 43 % | 4 % |
| 1.4.11 Non-text Contrast | 52 % | 48 % | 0 % |
| 1.2.5 Audio Description (Prerecorded) | 57 % | 0 % | 43 % |
| 3.3.2 Labels or Instructions | 57 % | 39 % | 4 % |
| 1.3.2 Meaningful Sequence | 57 % | 43 % | 0 % |
| 1.4.10 Reflow | 61 % | 39 % | 0 % |
| 2.4.2 Page Titled | 65 % | 35 % | 0 % |
| 2.4.7 Focus Visible | 83 % | 17 % | 0 % |
| 2.1.1 Keyboard | 87 % | 13 % | 0 % |
| 2.4.3 Focus Order | 87 % | 13 % | 0 % |
| 2.4.4 Link Purpose (In Context) | 91 % | 9 % | 0 % |
| 1.4.3 Contrast (Minimum) | 91 % | 9 % | 0 % |
| 4.1.2 Name, Role, Value | 96 % | 4 % | 0 % |
| 1.1.1 Non-text Content | 96 % | 4 % | 0 % |
| 1.3.1 Info and Relationships | 100 % | 0 % | 0 % |
16 Kriterien waren auf über 50 % der Websites nicht erfüllt. Ein Kriterium – „1.3.1 Info and Relationships“ – war auf allen gecheckten Websites nicht erfüllt. 4 weitere Kriterien waren auf über 90 % der Websites nicht erfüllt: „1.1.1 Non-text Content“, „4.1.2 Name, Role, Value“, „1.4.3 Contrast (Minimum)“ und „2.4.4 Link Purpose (In Context)“.
Vergleich am häufigsten nicht erfüllte Kriterien 2024 und 2025
| Kriterium | 2024: Anteil „nicht erfüllt“ | 2025: Anteil „nicht erfüllt“ | Veränderung des „nicht erfüllt“-Anteils 2025 verglichen mit 2025 (in Prozentpunkten) |
|---|---|---|---|
| 2.4.2 Page Titled | 100 % | 65 % | -35 |
| 3.1.2 Language of Parts | 87 % | 52 % | -35 |
| 1.3.2 Meaningful Sequence | 91 % | 57 % | -34 |
| 1.4.11 Non-text Contrast | 74 % | 52 % | -22 |
| 1.1.1 Non-text Content | 100 % | 96 % | -4 |
| 4.1.2 Name, Role, Value | 100 % | 96 % | -4 |
| 3.3.2 Labels or Instructions | 57 % | 57 % | +/-0 |
| 2.4.3 Focus Order | 87 % | 87 % | +/-0 |
| 1.3.1 Info and Relationships | 100 % | 100 % | +/-0 |
| 2.4.7 Focus Visible | 78 % | 83 % | +5 |
| 1.4.3 Contrast (Minimum) | 83 % | 91 % | +8 |
| 2.1.1 Keyboard | 74 % | 87 % | +13 |
| 2.5.3 Label in Name | 35 % | 52 % | +17 |
| 2.4.4 Link Purpose (In Context) | 74 % | 91 % | +17 |
| 1.2.5 Audio Description (Prerecorded) | 35 % | 57 % | +22 |
Betrachtet man die Entwicklung der 2025 am häufigsten nicht erfüllten Kriterien zeigt sich: Bei 7 WCAG-Kriterien ist eine positive Entwicklung zu verzeichnen. Bei diesen ist der „nicht erfüllt“-Anteil verglichen mit 2024 zurückgegangen. Am deutlichsten war das bei den Kriterien „2.4.2 Page Titled“, „3.1.2 Language of Parts“ und „1.3.2 Meaningful Sequence“: Bei diesen hat sich der „nicht erfüllt“-Anteil um 35 bzw. 34 Prozentpunkte reduziert.
Bei 9 WCAG-Kriterien lässt sich keine positive Entwicklung feststellen. Bei diesen ist der „nicht erfüllt“-Anteil verglichen mit 2024 gestiegen oder unverändert geblieben. Am negativsten haben sich die Kriterien „1.2.5 Audio Description (Prerecorded)“, „2.4.4 Link Purpose (In Context)“ und „2.3.5 Label in Name“ entwickelt: Hier ist der „nicht erfüllt“-Anteil um 22 bzw. 17 Prozentpunkte gestiegen.
Entwicklung der WCAG-Kriterien, die auf über 90 % der Websites nicht erfüllt sind
| Anzahl Kriterien / Monitoringzeitraum | 2020/2021 | 2022 | 2023 | 2024 | 2025 |
|---|---|---|---|---|---|
| Anzahl Kriterien | 14 | 11 | 8 | 5 | 5 |
Wie 2024 waren es auch 2025 5 WCAG-Kriterien, die auf über 90 % der Websites nicht erfüllt waren. Über alle bisherigen Monitoringzeiträume hinweg lässt sich ein positiver Trend feststellen, der 2025 stagniert hat.
Eingehende Checks Apps
Pro gecheckter App wurden durchschnittlich rund 13 Screens für den Check ausgewählt. Bei der Auswahl der Screens wurde unter anderem darauf geachtet, alle Hauptzwecke der App abzubilden und ganze Prozesse mit aufzunehmen.
Anteile Konformitätsstatus aller eingehend gecheckten Apps
Für die Apps wurden jeweils rund 120 Kriterien gecheckt. Durchschnittlich erfüllten die Apps 19 Kriterien nicht. Die mobile Anwendung mit den wenigsten nicht erfüllten Kriterien erfüllte 5 Kriterien nicht. Eine weitere App erfüllte mit 6 nicht erfüllten Kriterien auch unter 10 Kriterien nicht. 56 % der Apps (9 Apps) erfüllten 10 bis 20 Kriterien nicht. 5 Apps (31 %) erfüllten über 20 Kriterien nicht. Die Apps mit den meisten nicht erfüllten Kriterien erfüllten 32 Kriterien nicht. Damit waren alle eingehend gecheckten mobilen Anwendungen teilweise mit den Barrierefreiheitsanforderungen vereinbar – sie erfüllten mindestens 50 % der gecheckten Kriterien aber weniger als 100 %.
Betrachtet man nur die 45 gecheckten WCAG und bezieht die übrigen Kriterien aus EN 301 549 nicht ein, stellen sich die Anteile folgendermaßen dar (Konformität mit WCAG):
- Vollständig vereinbar (100 % der WCAG-Kriterien erfüllt): keine der gecheckten Apps
- Teilweise vereinbar (mind. 50 % der WCAG-Kriterien erfüllt): 100 % der gecheckten Apps
- Nicht vereinbar (unter 50 % der WCAG-Kriterien erfüllt): keine der gecheckten Apps
Für die Berechnungen wurden Bewertungen mit „nicht anwendbar“ den Bewertungen mit „erfüllt“ zugerechnet.
Im Mittel erfüllten die Apps 13 WCAG-Kriterien nicht.
Monitoringergebnis nach Anzahl nicht erfüllter WCAG-Kriterien
| Anzahl nicht erfüllter Kriterien | Anteil der Apps | Anzahl Apps |
|---|---|---|
| 0 bis 5 | 6 % | 1 |
| 6 bis 10 | 31 % | 5 |
| 11 bis 15 | 31 % | 5 |
| 16 bis 20 | 25 % | 4 |
| 21 bis 25 | 6 % | 1 |
| 26 bis 30 | 0 % | 0 |
| 31 bis 35 | 0 % | 0 |
| 36 bis 40 | 0 % | 0 |
| 41 bis 45 | 0 % | 0 |
Vergleich Monitoringergebnis nach Anzahl nicht erfüllter WCAG-Kriterien 2024 und 2025
Tabelle: Vergleich Monitoringergebnis nach Anzahl nicht erfüllter WCAG-Kriterien 2024 und 2025
| Anzahl nicht erfüllter Kriterien | Anteil der Apps 2024 | Anteil der Apps 2025 |
|---|---|---|
| 0 bis 5 | 0 % | 6 % |
| 6 bis 10 | 13 % | 31 % |
| 11 bis 15 | 40 % | 31 % |
| 16 bis 20 | 33 % | 25 % |
| 21 bis 25 | 13 % | 6 % |
| 26 bis 30 | 0 % | 0 % |
| 31 bis 35 | 0 % | 0 % |
| 36 bis 40 | 0 % | 0 % |
| 41 bis 45 | 0 % | 0 % |
Am häufigsten nicht erfüllte Kriterien
Tabelle: Am häufigsten nicht erfüllte Kriterien
| Kriterium | Nicht erfüllt | Erfüllt |
|---|---|---|
| 1.4.1 Use of Color | 50 % | 50 % |
| 2.4.4 Link Purpose (In Context) | 56 % | 44 % |
| 1.4.11 Non-text Contrast | 56 % | 44 % |
| 2.1.1 Keyboard | 63 % | 38 % |
| 1.4.3 Contrast (Minimum) | 63 % | 38 % |
| 1.3.4 Orientation | 63 % | 38 % |
| 4.1.3 Status Messages | 69 % | 31 % |
| 2.4.7 Focus Visible | 75 % | 25 % |
| 1.4.4 Resize text | 81 % | 19 % |
| 1.1.1 Non-text Content | 81 % | 19 % |
| 1.3.1 Info and Relationships | 94 % | 6 % |
| 4.1.2 Name, Role, Value | 100 % | 0 % |
| 2.4.3 Focus Order | 100 % | 0 % |
| Kriterium | 2024: Anteil „nicht erfüllt“ | 2025: Anteil „nicht erfüllt“ | Veränderung des „nicht erfüllt“-Anteils 2025 verglichen mit 2025 (in Prozentpunkten) |
|---|---|---|---|
| 1.4.11 Non-text Contrast | 80 % | 56 % | -24 |
| 1.1.1 Non-text Content | 100 % | 81 % | -19 |
| 4.1.3 Status Messages | 80 % | 69 % | -11 |
| 1.4.1 Use of Color | 60 % | 50 % | -10 |
| 1.4.3 Contrast (Minimum) | 73 % | 63 % | -10 |
| 1.3.1 Info and Relationships | 100 % | 94 % | -6 |
| 1.3.4 Orientation | 67 % | 63 % | -4 |
| 1.4.4 Resize text | 80 % | 81 % | +1 |
| 2.4.7 Focus Visible | 73 % | 75 % | +2 |
| 2.4.4 Link Purpose (In Context) | 53 % | 56 % | +3 |
| 4.1.2 Name, Role, Value | 93 % | 100 % | +7 |
| 2.4.3 Focus Order | 73 % | 100 % | +27 |
Betrachtet man die Entwicklung der 2025 am häufigsten nicht erfüllten Kriterien zeigt sich: Bei 8 WCAG-Kriterien ist eine positive Entwicklung zu verzeichnen. Bei diesen ist der „nicht erfüllt“-Anteil verglichen mit 2024 zurückgegangen. Am besten haben sich die Kriterien „1.4.11 Non-text Contrast“ und „1.1.1 Non-text Content“ entwickelt: Bei diesen hat sich der „nicht erfüllt“-Anteil um 24 bzw. 19 Prozentpunkte reduziert.
Bei 5 WCAG-Kriterien lässt sich keine positive Entwicklung feststellen. Bei diesen ist der „nicht erfüllt“-Anteil verglichen mit 2024 gestiegen. Am negativsten hat sich das Kriterium „2.4.3 Focus Order“ entwickelt: Hier ist der „nicht erfüllt“-Anteil um 27 Prozentpunkte gestiegen.
Entwicklung der WCAG-Kriterien, die auf über 90 % der Apps nicht erfüllt sind
| Anzahl Kriterien / Monitoringzeitraum | 2022 | 2023 | 2024 | 2025 |
|---|---|---|---|---|
| Anzahl Kriterien | 4 | 3 | 3 | 3 |
Wie 2023 und 2024 waren es auch 2025 3 WCAG-Kriterien, die auf über 90 % der Websites nicht erfüllt waren.
Vereinfachte Checks Websites
Für den Monitoring-Zeitraum 2025 wurden 14 WCAG-Kriterien ausgewählt, die mit dem Tool QualWeb (externer Link) überprüft wurden. Für die vereinfachten Prüfungen der Steiermark wurden zusätzlich auch Bookmarklets (Images, Headings, Tabindex, Textabstände, Autocomplete Attribute Favlet) genutzt, sowie teilweise manuelle Nachprüfungen der automatisierten Checks vorgenommen. Für die vereinfachten Prüfungen von Tirol wurde zusätzlich zu QualWeb auch die WAVE-Chrome Extension genutzt und JAWS sowie das Tool Fusion 2025 eingesetzt.
Pro gecheckter Website wurden durchschnittlich rund 15 Unterseiten für den Check ausgewählt. Bei der Auswahl der Unterseiten wurde darauf geachtet, möglichst viele unterschiedliche Funktionalitäten, Inhaltstypen etc. mitaufzunehmen.
Vereinfachte Checks können nicht alle Barrierefreiheits-Issues aufzeigen. Das kann nur ein eingehender manueller Check leisten. Es kann auch nicht festgestellt werden, ob Websites die Barrierefreiheitskriterien zur Gänze erfüllen. Es können aber Issues zu den gecheckten Kriterien gefunden werden.
Verteilung Anzahl nicht erfüllter Kriterien je gecheckter Website
| Anzahl nicht erfüllter Kriterien | Anteil der Websites | Anzahl der Websites |
|---|---|---|
| 0 | 5 % | 17 |
| 1 | 10,9 % | 38 |
| 2 | 11,2 % | 39 |
| 3 | 18,9 % | 66 |
| 4 | 18,6 % | 65 |
| 5 | 17 % | 58 |
| 6 | 7 % | 26 |
| 7 | 5 % | 16 |
| 8 | 3 % | 10 |
| 9 | 1,4 % | 5 |
| 10 | 0,3 % | 1 |
| 11 | 1,1 % | 4 |
| 12 | 0,9 % | 3 |
| 13 | 0,3 % | 1 |
| 14 | 0 % | 0 |
Auf 17 Websites (5 %) wurden zu den gecheckten Kriterien keine Fehler gefunden. Auf insgesamt rund 40 % der Websites wurden zu vier oder fünf der 14 gecheckten Kriterien Fehler gefunden. Auf insgesamt 9 Websites wurden zu 10 bis 13 der 14 gecheckten Kriterien Fehler gefunden.
Vergleich Monitoringergebnis nach Anzahl nicht erfüllter WCAG-Kriterien 2024 und 2025
Im Vergleich zum Monitoringzeitraum 2024 zeigt sich 2025 ein ähnliches Bild. Es gibt keine nennenswerten Veränderungen.
Anmerkung: 2024 wurden nur 13 WCAG-Kriterien geprüft (siehe Monitoringbericht 2022-2024 (externer Link)), 2025 waren es 14 WCAG-Kriterien.
Verteilung nicht erfüllte Kriterien aller vereinfacht gecheckten Websites
Tabelle: Anteil "nicht erfüllt" bei den für die vereinfachte Prüfung gecheckten Kriterien
| WCAG-Kriterium | Anteil "nicht erfüllt" |
|---|---|
| 1.4.12 Text Spacing | 1 % |
| 1.3.4 Orientation | 3 % |
| 3.1.2 Language of Parts | 7 % |
| 2.4.2 Page Titled | 8 % |
| 1.3.5 Identify Input Purpose | 8 % |
| 3.1.1 Language of Page | 8 % |
| 1.4.4 Resize Text | 15 % |
| 2.1.1 Keyboard | 17 % |
| 2.5.3 Label in Name | 30 % |
| 1.1.1 Non-text Content | 39 % |
| 1.3.1 Info and Relationships | 39 % |
| 2.4.4 Link Purpose (In Context) | 61 % |
| 1.4.3 Contrast (Minimum) | 74 % |
| 4.1.2 Name, Role, Value | 79 % |
Am häufigsten nicht erfüllt war das Kriterium „4.1.2 Name, Role, Value“, welches von 79 % der Websites nicht erfüllt wurde. Es folgt das Kriterium „1.4.3 Contrast (Minimum)“, welches von 74 % der Websites nicht erfüllt wurde. „2.4.4 Link Purpose (In Context)“ folgt mit einem „nicht erfüllt“-Anteil von 61 %. Am besten schnitten die Websites bei den Kriterien „1.4.12 Text Spacing“ und „1.3.4 Orientation“ ab – diese wurden nur von 1 % bzw. 3 % der Websites nicht erfüllt.
Die am häufigsten nicht erfüllten Kriterien und qualitative Auswertung der gefundenen Barrieren
Jährlich werten wir aus, welche Barrierefreiheitskriterien bei Websites und Apps am häufigsten nicht erfüllt werden. Wir sehen uns an, welche Kriterien auf durchschnittlich rund 80 % der Websites und Apps nicht erfüllt werden. Zu diesen Kriterien führen wir auch eine qualitative Auswertung der konkret dokumentierten Barrierefreiheits-Issues durch. Im Monitoring 2025 wurden für Websites und Apps acht Kriterien am häufigsten als nicht erfüllt festgestellt:
| Kriterium | Anteil "nicht erfüllt" |
|---|---|
| 4.1.2 Name, Role, Value | 98 % |
| 1.3.1 Info and Relationships | 98 % |
| 2.4.3 Focus Order | 92 % |
| 1.1.1 Non-text Content | 90 % |
| 2.4.7 Focus Visible | 80 % |
| 1.4.3 Contrast (Minimum) | 80 % |
| 2.1.1 Keyboard | 77 % |
| 2.4.4 Link Purpose (In Context) | 77 % |
Im Folgenden dargestellt ist, was die einzelnen Kriterien bedeuten, warum sie wichtig sind und für welche Zielgruppen sie besonders relevant sind. Außerdem sind die häufigsten konkreten Barrieren beschrieben, die 2025 in Zusammenhang mit diesen Kriterien dokumentiert wurden. Die einzelnen Kriterien werden jedoch nicht vollständig erklärt. Der Schwerpunkt liegt auf den Verbesserungs-Möglichkeiten für die Barrierefreiheit von Websites. Die weiterführenden Links sind nur zusätzliche Informationen. Sie haben keinen Zusammenhang mit den von den Monitoringstellen durchgeführten Monitoring-Checks.
Name, Rolle, Wert (WCAG-Kriterium 4.1.2)
Was bedeutet das Kriterium?
Interaktive Elemente sollen programmatisch ermittelbare Namen, Rollen und Werte (falls anwendbar, z. B.: bei einer Checkbox „ausgewählt“ oder „nicht ausgewählt“) haben.
Warum und für wen ist das Kriterium wichtig?
Standard-HTML-Bedienelemente wie zum Beispiel Links oder Buttons haben einen Namen und eine Rolle. Manche Bedienelemente haben auch Werte bzw. Zustände wie Eingabefelder oder Checkboxes. Diese Eigenschaften sind per Screenreader für blinde Personen zugänglich – das heißt, es wird ihnen kommuniziert, was sie mit dem Bedienelement machen können. Ein Beispiel: Eine Checkbox in einem Formular hat den Namen „Ich möchte den Newsletter abonnieren“. Die Rolle ist, dass es eine Checkbox ist. Der Wert ist „unchecked“, wenn es noch nicht ausgewählt ist. Ist der Wert „checked“ bedeutet das, dass die Checkbox ausgewählt ist.
Bei Standard-HTML-Elementen werden diese Infos automatisch für Screenreader mitgeliefert. Falls nicht dafür vorgesehene Elemente (– wie das div- oder das span-Element) mithilfe von JavaScript und CSS umfunktioniert werden, um das Aussehen und die Funktion von Bedienelementen nachzuahmen, müssen diese mit WAI-ARIA (externer Link) angereichert werden, damit diese Eigenschaften auch für Screenreader-Nutzer:innen zugänglich sind. Dies betrifft auch Komponenten wie Tabpanels, Akkordeons, Schieberegler etc. Für blinde Nutzer:innen ist die Funktion dieser Elemente sonst nicht nachvollziehbar. Wenn die Zustände bzw. Werte ebenfalls nicht zur Verfügung stehen, sind diese auch nicht bedienbar.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Controls (z. B. Buttons, Eingabefelder etc.) haben keine oder eine unzureichende programmatisch erfassbare Beschriftung (fehlender Accessible Name):
Ohne entsprechende Beschriftungen wird die Funktion von Bedienelementen für Screenreader-Nutzer:innen nicht entsprechend kommuniziert. Hier sind – abhängig vom jeweiligen Control-Typ – Labels zu erwähnen. Dabei können bei den meisten Controls entweder Labels verlinkt werden (label-Tag und for-Attribut bzw. aria-labelledby) oder auch Labels direkt definiert werden (aria-label).
Siehe auch: Web Accessibility Tutorials: Labeling Controls (externer Link)
Buttons (und andere Controls) sind nicht als solche ausgezeichnet (fehlende oder falsche semantische Rollen):
Das tritt auf, wenn ungeeignete HTML-Elemente (bspw. div- oder span-Elemente) als Controls eingesetzt werden. Um dies zu vermeiden, sollten möglichst die für die entsprechenden Controls vorgesehenen semantischen HTML-Elemente (wie bspw. button etc.) genutzt werden. Falls dies nicht möglich ist, mit ARIA-roles nachbessern und die Funktion darüber definieren. Dabei ist auf den korrekten Einsatz von WAI-ARIA zu achten.
Siehe dazu auch: WAI-ARIA Roles (externer Link)
Nicht übermittelte Zustände (fehlende Werte):
ARIA-Attribute (externer Link) wie
aria‑expanded(eingeklappt oder ausgeklappt),aria‑pressed(für Toggle-Buttons: gedrückt, nicht gedrückt etc.),aria‑current(um das aktuelle Element einer Gruppe verwandter Elemente zu kennzeichnen),aria‑selected(kennzeichnet die ausgewählten Elemente in Widgets mit Einzel- oder Mehrfachauswahl),aria‑checked(zeigt den „ausgewählten“ Status von Kontrollkästchen etc. an)
fehlen oder werden falsch gesetzt (z. B. bei einem ausgeklappten Element bleibt aria-expanded="false" im geöffneten Zustand).
Name-Rolle-Wert inkonsistent oder unvollständig / ARIA‑Attribute auf falschen Elementen:
Wenn ARIA-Attribute inkonsistent oder falsch platziert sind, erhalten assistierende Technologien wie Screenreader unvollständige oder widersprüchliche Informationen. Typische Beispiele:
- aria‑label auf generischen
div/spanohne passenderole - ARIA‑Attribute falsch eingesetzt bei Elementen, bei denen diese nicht erlaubt sind
- komplexe Komponenten (carousel, tabs, combobox, listbox, accordion) werden mit
divs nachgebaut und mit ARIA angereichert, aber ohne z. B. komplette Patterns des ARIA Authoring Practices Guide (APG) (externer Link) umzusetzen, wodurch Name, Rolle und Wert nicht vollständig vermittelt werden
Weiterführende Informationen
Info und Beziehungen (WCAG-Kriterium 1.3.1)
Was bedeutet das Kriterium?
Informationen und Strukturen auf Websites beziehungsweise Beziehungen zwischen Elementen auf Websites sollen nicht nur visuell verständlich sein, sondern müssen auch programmatisch richtig ausgezeichnet werden und bestimmt werden können. Die wichtigsten Aspekte hier sind:
- Die Überschriften-Hierarchie soll richtig ausgezeichnet werden: Die Website soll nicht nur visuell strukturiert und mit CSS visuell hierarchisiert werden, sondern die HTML-Überschriften-Ebenen (
h1bish6) sollen entsprechend und korrekt verwendet werden. - Ähnliche/gleichrangige Elemente, die visuell einer Liste ähneln, sollen auch programmatisch als Listen ausgezeichnet werden, als unordered lists (
ul) oder als ordered lists (ol) sowie die Listen-Elementen darin (li). Dies gilt sowohl für vertikal angeordnete Elemente als auch horizontal angeordnete Elemente (kommt z. B. häufig in Navigationsleisten vor) - Tabellen sollen auch programmatisch als solche ausgezeichnet werden. Wichtig ist hier die Verwendung von Table-Headers (
th) sowohl für horizontale als auch für vertikale Table-Headers. Komplexere Tabellen können auch mittelsscope- undheader-Attributen umgesetzt werden. Allerdings sollte hier überlegt werden, ob nicht die Aufteilung einer komplexen Tabelle auf mehrere einfachere Tabellen sinnvoller sein könnte. - Formularelemente sollen entweder direkt beschriftet oder mit einem Label korrekt verknüpft sein (siehe dazu auch Kriterium 4.1.2 Name, Rolle, Wert).
- Regionen der Website sollen ausgezeichnet werden, entweder mit den entsprechenden HTML5-Tags oder mit dem
role-Attribut.
Warum und für wen ist das Kriterium wichtig?
Blinde Nutzer:innen sind auf eine programmatisch richtige Auszeichnung der Webseite und ihrer Elemente angewiesen, um die Webseite und ihre Inhalte nachvollziehen zu können. Ist die Überschriften-Struktur nicht richtig ausgezeichnet, ist der Aufbau und die Gliederung einer Webseite kaum verständlich. Gleiches gilt für Listen. Sind Tabellen nicht richtig ausgezeichnet und Eingabefelder oder Steuerelemente nicht richtig beschriftet, sind diese de facto unzugänglich.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Überschriften-Hierarchie ist nicht korrekt aufgebaut oder fehlt:
Generell soll die programmatisch bestimmbare Überschriften-Hierarchie (h1 bis h6) der visuellen und logischen entsprechen. Die Hauptüberschrift (h1) kann z. B. dem Seitentitel entsprechen, alle anderen Überschriften (h2 bis h6) den visuellen und logischen Aufbau der Website reflektieren. Keine Überschriften-Ebenen sollen ausgelassen werden. Gleichrangige Überschriften sollen mit der gleichen Ebene ausgezeichnet werden. Direkte Kind-Elemente mit einer Ebene darunter, direkte Eltern-Element mit einer Ebene darüber.
Strukturierung ist visuell vorhanden aber nicht ausgezeichnet:
Neben Überschriften, sind häufig Listen, Absätze oder Tabellen visuell als solche erkenntlich, aber nicht korrekt ausgezeichnet. Damit steht diese Strukturinformation assistierenden Technologien nicht zur Verfügung.
Labels für Eingabefelder bzw. Steuerelement sind nicht korrekt ausgezeichnet, sind nicht als solche identifiziert oder Labels und Elemente sind nicht entsprechend miteinander im Quelltext verbunden:
Die korrekte Umsetzung garantiert, dass der Zweck der Eingabefelder bzw. Steuerelemente für blinde Nutzer:innen nachvollziehbar ist.
Regionen der Websites sind nicht ausgezeichnet:
Sehr häufig verwendet und besonders hilfreich sind Navigations-Regionen, Main, Header und Footer. Damit werden Orientierung und Navigation auf der Website erleichtert. Hier kann entweder HTML5 oder auch das ARIA role-Attribut verwendet werden. Eine Umsetzung via HTML5 (Tags wie z. B.: header, nav, main, footer, aside, section) ist zu bevorzugen. ARIA soll nur in Ausnahmefällen eingesetzt werden. Bedacht werden sollte: Wenn mehrere Navigations-Regionen vorhanden sind, insbesondere wenn sich diese in derselben übergeordneten Region befinden, sollten diese Navigations-Regionen einen kurzen, aussagekräftigen Namen mittels aria-labelledby oder aria-label erhalten, siehe auch Labeling Regions (externer Link).
Nicht oder falsch getaggte PDF-Dokumente:
Zu Problemen führen PDFs ohne oder mit nur unzureichende Tag-Struktur (fehlende Überschriften, Listen, Tabellen). Ein Extrembeispiel sind PDFs aus Scans, diese vermitteln gar keine Strukturinformationen.
Weiterführende Informationen
- WCAG: Understanding Success Criterion 1.3.1: Info and Relationships (externer Link)
- BIK-BITV-Prüfschritt 9.1.3.1a HTML-Strukturelemente für Überschriften (externer Link)
- BIK-BITV-Prüfschritt 9.1.3.1b HTML-Strukturelemente für Listen (externer Link)
- BIK-BITV-Prüfschritt 9.1.3.1c HTML-Strukturelemente für Zitate (externer Link)
- BIK-BITV-Prüfschritt 9.1.3.1d Inhalt gegliedert (externer Link)
- BIK-BITV-Prüfschritt 9.1.3.1e Datentabellen richtig aufgebaut (externer Link)
- BIK-BITV-Prüfschritt 9.1.3.1f Zuordnung von Tabellenzellen (externer Link)
- BIK-BITV-Prüfschritt 9.1.3.1g Kein Strukturmarkup für Layouttabellen (externer Link)
- BIK-BITV- Prüfschritt 9.1.3.1h Beschriftung von Formularelementen programmatisch ermittelbar (externer Link)
Schlüssige Reihenfolge bei der Tastaturbedienung (WCAG-Kriterium 2.4.3)
Was bedeutet das Kriterium?
Wenn Nutzer:innen eine Website oder mobile Anwendung mit der Tastatur nutzen, muss die Reihenfolge, in der sie Informationen (Links, Formularelemente etc.) mittels Tabulator-Taste der Reihe nach erreichen, schlüssig und nachvollziehbar sein.
Warum und für wen ist das Kriterium wichtig?
Für Nutzer:innen, die der Reihe nach mit der Tastatur navigieren und keine Maus verwenden, ist es essentiell, dass sie Inhalte in einer sinnvoll nachvollziehbaren Reihenfolge erreichen. Das kann Menschen mit motorischen Behinderungen betreffen oder auch blinde Menschen, die das Web u. a. mit Screenreadern und Tastaturnavigation nutzen. Für diese Zielgruppe ist die Fokusreihenfolge beispielsweise beim Ausfüllen eines Online-Formulars essentiell. Für Nutzer:innen, die aufgrund einer Sehbehinderung große Vergrößerungen nutzen, ist es ebenfalls wichtig, dass der Fokus bei der Navigation nicht an eine unerwartete Stelle springt.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Verdeckte Inhalte werden fokussiert:
Inhalte, die von einem Overlay (bspw. Menü) überdeckt und daher nicht sichtbar sind, können trotzdem mit der Tastatur angesteuert werden.
Deaktivierte Schaltflächen oder Elemente, die keine Funktion (mehr) haben und visuell ausgeblendet sind, kommen in der Fokusreihenfolge vor. Diese sollten auch aus der Fokusreihenfolge entfernt werden.
Fokus ist an einer nicht-erwartbaren Stelle:
Der Fokus wird an eine Stelle gesetzt, die nicht erwartbar ist, z. B.:
- Der Fokus wird beim Aufruf einer Seite auf ein interaktives Element weiter unten auf der Seite gesetzt. Der Fokus sollte in den meisten Fällen am Beginn der Seite sein, da sonst der Überblick für Screenreader-Nutzer:innen erschwert wird bzw. Tastatur-Nutzer:innen umständlich navigieren müssen.
- Der Fokus wird beim Schließen eines Dialogs nicht wieder auf den Auslöser des Dialogs gesetzt, sondern an eine andere Stelle der Seite. Hier ist insbesondere für Screenreader-Nutzer:innen sehr schwer nachzuvollziehen, wo sie sich auf der Seite befinden.
- Beim Aktivieren eines Skip-Links oder Inhaltsverzeichnis-Links wird nur der visuelle Viewport zum aufgerufenen Inhalt verschoben. Der Fokus verbleibt beim ursprünglich aktivierten Link und es ist insbesondere für Screenreader-Nutzer:innen nicht nachvollziehbar, was passiert ist. Der Fokus sollte programmatisch auf das Zielelement gesetzt werden.
Reihenfolge der fokussierten Elemente ist nicht sinnvoll:
Beim ersten Besuch einer Website erscheint z. B. ein Cookie-Dialog oder Cookie-Banner. Dieser sollte den Fokus als erstes erhalten, damit die Nutzer:innen ihre Cookie-Einstellungen tätigen können. In vielen Fällen springt der Fokus erst am Ende der Seiteninhalte zum Cookie-Dialog oder -Banner, da der Dialog im Quelltext der Website am Ende steht.
Oder es kommen Schaltflächen vor dem zugehörigen Inhalt, beispielsweise ein „Suchen“-Button vor der Eingabemöglichkeit diverser Suchoptionen. Der Button sollte erst nach den Optionen kommen.
Dialog oder Modal ist geöffnet, aber Fokus liegt nicht darauf:
Ein Eingabefenster öffnet sich, aber der Fokus liegt noch außerhalb des Fensters. Für Screenreader-Nutzer:innen ist schwer nachvollziehbar, dass hier Inhalte im geöffneten Fenster verfügbar sind.
Weiterführende Informationen
Nicht-Text-Inhalt (WCAG-Kriterium 1.1.1)
Was bedeutet das Kriterium?
Nicht-Text-Inhalte benötigen eine textuelle Alternative. Textalternativen sind ein wichtiger Weg, Informationen für alle zur Verfügung zu stellen, da sie für unterschiedliche Sinne wiedergegeben werden können (z. B. visuell, akustisch oder taktil). Grafische Elemente sollen bspw. mit einem Alternativ-Text versehen werden.
- Bei Bildern soll der Alternativ-Text kurz und prägnant die relevante Information enthalten, die mit diesem Bild vermittelt werden soll.
- Bei Logos soll der Name der Firma oder Einrichtung angegeben werden.
- Bei Links soll der Linkzweck – also, wohin der Link führt – angegeben werden.
- Bei rein dekorativen Elementen, die keine Information für Nutzer:innen transportieren, sollen diese so gestaltet sein, dass sie von assistierenden Technologien ignoriert werden. Bei einem leeren Alternativ-Text (
alt="") ist für Screenreader z. B. klar, dass das Element übersprungen werden kann.
Warum und für wen ist das Kriterium wichtig?
Blinde Nutzer:innen sind bspw. auf Alternativ-Texte für informationstragende visuelle Elemente (Grafiken, Bilder, grafische Bedienelemente etc.) angewiesen. Audio-Inhalte benötigen z. B. eine textuelle Alternative für gehörlose Nutzer:innen. Damit erhalten alle Nutzer:innen möglichst dieselben Informationen zu Nicht-Text-Elementen.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Ein Bild oder Logo hat keinen Alternativ-Text:
Wenn ein Bild oder Logo keinen Alternativ-Text aufweist, kann dieser mit alt="Beschreibung des Bildes" hinzugefügt werden. Dekorative Bilder können z. B. mit alt="" für assistierende Technologien als ignorierbar gekennzeichnet werden.
Ein Bild oder Logo hat keinen aussagekräftigen Alternativ-Text:
Die Beschreibung soll aussagekräftig, aber trotzdem möglichst kurz und prägnant formuliert werden. Es soll nur die Information vermittelt werden, die im aktuellen Kontext wichtig ist. D. h. es müssen nicht rein visuelle Details auf dem Bild beschrieben werden, sondern die Grundaussage des Bildes bzw. die durch das Bild transportierte Information.
Zum Beispiel: Ein Portrait-Foto einer Frau mittleren Alters mit schwarzen Haaren und roter Brille:
- Im Kontext eines „Steckbriefes“ in der About-Seite eines Unternehmens wäre der Name und die Position wahrscheinlich passend.
- Im Kontext einer Website eines Friseur-Salons auf der das Foto einen Haarschnitt anpreist, ist der Name der Person irrelevant, vielmehr sollte die Frisur näher beschrieben werden.
Bei Bildern oder Icons, die als Links dienen, soll vorrangig der Linkzweck beschrieben werden, damit eindeutig ist, wohin man gelangt, wenn der Link ausgewählt wird.
Ein dekoratives Bild hat einen nicht-leeren Alternativ-Text:
Hintergrund-Bilder oder andere Bilder, die einen rein dekorativen Zweck haben (z. B. ein Artikel mit einem generischen Stock-Image, das für sich genommen keine Aussagekraft hat, mit einem Titel, Beschreibung und einem Link darunter), sollen für assistierende Technologien als ignorierbar gekennzeichnet werden (bspw. mit einem leeren Alternativ-Text). Dies erhöht die Usability für Screenreader-Nutzer:innen und verhindert, dass unnötige oder redundante Informationen kommuniziert werden.
Weiterführende Informationen
- WCAG: Understanding Success Criterion 1.1.1: Non-text Content (externer Link)
- BIK-BITV-Prüfschritt 9.1.1.1a Alternativtexte für Bedienelemente (externer Link)
- BIK-BITV-Prüfschritt 9.1.1.1b Alternativtexte für Grafiken und Objekte (externer Link)
- BIK-BITV-Prüfschritt 9.1.1.1c Leere alt-Attribute für Layoutgrafiken (externer Link)
- BIK-BITV-Prüfschritt 9.1.1.1d Alternativen für CAPTCHAs (externer Link)
Fokus sichtbar (WCAG-Kriterium 2.4.7)
Was bedeutet das Kriterium?
Wenn Nutzer:innen eine Website oder mobile Anwendung mit der Tastatur nutzen, dann muss der Tastaturfokus sichtbar sein – also, welches Element gerade ausgewählt ist.
Warum und für wen ist das Kriterium wichtig?
Der Zweck des Kriteriums ist, Nutzer:innen zu ermöglichen, zu erkennen, welches Element gerade den Tastaturfokus hat. Das betrifft Tastatur-Nutzer:innen, die sehen können. Auch bei eingeschränkter Aufmerksamkeit oder eingeschränktem Kurzzeitgedächtnis ist es hilfreich, jederzeit feststellen zu können, welches Element gerade fokussiert ist.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Kein sichtbarer Fokus vorhanden:
Werden interaktive Elemente mit der Tastatur angesteuert, gibt es keinerlei visuellen Indikator, dass ein Element fokussiert wurde. Es muss ein sichtbarer Hinweis (z.B. zumindest der Standard Fokus-Rahmen des Browsers) vorhanden sein.
Fokus-Rahmen hat einen zu geringen Kontrast zum Hintergrund:
In vielen Fällen ist ein Fokus-Rahmen vorhanden, welcher sich aber zu wenig vom Hintergrund abhebt. Damit der Fokus gut erkennbar ist, muss der Fokus-Indikator von angrenzenden Elementen deutlich unterscheidbar sein. Der Kontrast muss mindestens 3:1 sein.
Fokussierter Status hat zu wenig Kontrast zu unfokussiertem Status:
In einigen Fällen wird der Fokus durch unterschiedlich gestaltete Status angezeigt – beispielsweise wird ein Button in einer anderen Farbe angezeigt, wenn er mit der Tastatur erreicht wird. Damit dieser Fokus gut erkennbar ist, müssen fokussierter und unfokussierter Status einen Kontrast von mindestens 3:1 haben bzw. dürfen sich die Status nicht nur durch eine andere Farbe unterscheiden. (Siehe auch WCAG-Kriterien "1.4.11 Non-text Contrast" und "1.4.1 Use of Color". Besonders hilfreich ist die Darstellung zu "Relationship with Focus Visible" im Text "Understanding Success Criterion 1.4.11 Non-text Contrast" (externer Link)).
Weiterführende Informationen
Kontraste von Texten (Minimum) (WCAG-Kriterium 1.4.3)
Was bedeutet das Kriterium?
Alle Texte auf der Website sollen ausreichende Kontrastwerte zum jeweiligen Hintergrund haben:
- für normale Schrift (kleiner 18pt normale Schriftdicke oder kleiner 14pt wenn fett) gilt das Kontrastverhältnis 4,5:1
- für große Schrift (18pt oder größer bei normaler Schriftdicke oder 14pt oder größer bei fett) gilt das Kontrastverhältnis 3:1
Ausgenommen sind nur Logos (keine anderen Icons), die Texte enthalten.
Warum und für wen ist das Kriterium wichtig?
Ein ausreichender Kontrast ist wichtig für Menschen mit unterschiedlichen Sehbehinderungen, inklusive Farbenblindheit und Farbschwäche. Auch für Nutzer:innen, die Websites oder mobile Anwendungen in suboptimalen Lichtbedingungen aufrufen – z. B. am Smartphone im direkten Sonnenlicht – stellt ein entsprechendes Kontrastverhältnis zwischen Text und Hintergrund die Benutzbarkeit sicher.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Kontrastwerte sind zu niedrig:
Niedrige Kontrastwerte können mithilfe von Tools leicht erkannt werden, z. B. mit dem Colour Contrast Analyser (externer Link) oder mit Contrast Report (externer Link). Schriftfarbe und/oder Hintergrundfarbe können angepasst werden, um das entsprechende Kontrastverhältnis von 4,5:1 bzw. 3:1 zu erreichen.
Weiterführende Informationen
Tastatur (WCAG-Kriterium 2.1.1)
Was bedeutet das Kriterium?
Die Funktionalitäten von Websites und mobilen Anwendungen müssen mit der Tastatur benutzbar sein (ohne Computer-Maus).
Warum und für wen ist das Kriterium wichtig?
Das Kriterium stellt sicher, dass Inhalte von blinden Menschen oder Menschen mit eingeschränktem Sehvermögen (die keine Computer-Mäuse verwenden können) und Menschen, die alternative Tastaturen oder Tastaturemulatoren (z. B. Spracheingabesoftware, Sip-and-Puff-Software, Bildschirmtastaturen etc.) nutzen, bedient werden können. Das betrifft bspw. auch viele Menschen mit motorischen Behinderungen.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Interaktive Elemente (Buttons, Links etc.) sind nicht mit der Tastatur ansteuerbar:
Wird versucht, interaktive Elemente mit der Tastatur anzusteuern, ist das nicht möglich. Beispielsweise, wenn diese Elemente aus der Tab-Reihenfolge entfernt wurden.
Interaktive Elemente (Buttons, Links etc.) sind nicht mit der Tastatur bedienbar:
Interaktive Elemente können mit der Tastatur erreicht werden, eine Bedienung ist dann aber nicht möglich. Beispielsweise kann ein Button nicht aktiviert werden oder ein Untermenü eines Navigationsmenüs nicht ausgewählt werden. Ein Grund dafür können fehlende Tastatur-Event Handler sein.
Links und Formularelemente in PDF-Dokumenten sind nicht mit der Tastatur ansteuerbar:
PDFs müssen korrekt getaggt sein, um die Tastaturbedienbarkeit von Links, Formularelementen etc. sicherzustellen.
Weiterführende Informationen
Linkzweck (im Kontext) (WCAG-Kriterium 2.4.4)
Was bedeutet das Kriterium?
Für Nutzer:innen muss sofort erkennbar sein, welchen Zweck ein Link auf einer Website oder in einer App erfüllt und welches Ergebnis beim Aufrufen des Links zu erwarten ist. Der Zweck sollte entweder direkt aus dem Linktext hervorgehen oder aus dem Linktext zusammen mit dem programmatisch erfassbaren Kontext (z. B. Text, der sich im selben Absatz, Listenelement oder in derselben Tabellenzelle wie der Link befindet) klar werden.
Es kann Situationen geben, in denen der Zweck eines Links bewusst unbekannt oder verschleiert bleiben soll. Beispielsweise könnte ein Spiel Links enthalten, die lediglich als Tür 1, Tür 2 und Tür 3 bezeichnet werden. Dieser Linktext wäre ausreichend, da die Links dazu dienen, Spannung bei allen Nutzer:innen zu erzeugen.
Best Practice: Links mit demselben Ziel sollten denselben Linktext verwenden; Links mit unterschiedlichen Zielen sollten sich auch im Linktext unterscheiden.
Warum und für wen ist das Kriterium wichtig?
Ziel dieses Kriteriums ist, Nutzer:innen den Zweck jedes Links eindeutig zu vermitteln, damit sie leicht entscheiden können, ob sie ihm folgen möchten. Wo immer möglich, soll der Zweck direkt aus dem Linktext hervorgehen.
Screenreader können beispielsweise eine Liste aller auf einer Unterseite vorhandenen Links anzeigen und die Nutzer:innen können durch diese Liste navigieren. Wenn der Zweck durch den Linktext gleich unmissverständlich vermittelt wird, ist das sehr hilfreich.
Auch für Nutzer:innen mit motorischen Behinderungen ist es nützlich, den Linkzweck direkt erfassen zu können, ohne den Link aufrufen zu müssen. Dadurch können viele Tastendrücke vermieden werden.
Darüber hinaus ist es für Menschen mit kognitiven Behinderungen hilfreich, Linkzwecke klar vermittelt zu bekommen, damit sie nicht desorientiert werden, wenn sie auf unterschiedliche Weisen zu Inhalten gelangen, an denen sie kein Interesse haben.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Links haben keinen (aussagekräftigen) Linktext:
- Kein programmatisch ermittelbaren Linktext vorhanden (für assistierende Technologien ist keine Information darüber vorhanden, wohin der Link führt)
- Es sind nur unaussagekräftige Linktexte vorhanden, die den Zweck nicht ausreichend beschreiben oder verwirrend sind (z. B. Pfeile zum Weiterblättern haben den Linktext „kleiner“ und „größer“; Links werden nur mit den Worten „hier“ oder „mehr“ beschrieben; Linktexte bestehen aus vollständig ausgeschriebenen URLs, die keine Information über den Zweck vermitteln)
Verlinkte Bilder/Icons haben keinen aussagekräftigen Linktext:
- Linktexte beschreiben nicht den Zweck des Links (z. B. Linktext „Logoschriftzug“ bei einem verlinkten Logo – stattdessen sollte klar vermittelt werden, dass man über den Link die Startseite der Einrichtung erreicht, deren Logo abgebildet ist; generell Linktexte, die beschreiben, was auf dem Bild/Icon zu sehen ist anstatt zu beschreiben, wohin man gelangt, wenn man den Link aufruft)
- Verlinkte Icons haben keine Beschriftung und damit keinen aussagekräftigen Linktext
Weiterführende Informationen
Infos aus den Beschwerdestellen zur digitalen Barrierefreiheit
Von Januar 2025 bis Dezember 2025 wurden in den Service- bzw. Beschwerdestellen des Bundes und der Bundesländer folgende Anzahl an Beschwerden bearbeitet, bei denen es sich um digitale Barrieren im Sinne der Web Accessibility Directive gehandelt hat:
- Bund: 19 Beschwerden
- Burgenland: 0 Beschwerden
- Kärnten: 3 Beschwerden
- Niederösterreich: 0 Beschwerden
- Oberösterreich: 0 Beschwerden
- Salzburg: 0 Beschwerden
- Steiermark: 0 Beschwerden
- Tirol: 1 Beschwerde
- Vorarlberg: 0 Beschwerden
- Wien: 1 Beschwerde
Wie geht es weiter?
Das Monitoring wird weiterhin jährlich durchgeführt. Ende 2027 ist der nächste Bericht über die Ergebnisse des Monitorings an die Europäische Kommission fällig. Darin wird die Österreichische Forschungsförderungsgesellschaft (FFG) die Monitoring-Zeiträume 2025 bis inklusive 2027 ausführlich darstellen. Danach wird alle drei Jahre ein Bericht verfasst, als nächstes dann demnach Ende 2030.