Zwischenbericht nach dem Monitoring-Zeitraum 2022
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 (externer Link) definiert.
Diese Ergebnisse werten wir aus und informieren alle drei Jahre die EU-Kommission über den Fortschritt der Barrierefreiheit in Österreich.
Der erste Bericht zu Österreichs digitaler Barrierefreiheit wurde 2021 veröffentlicht, der nächste Bericht folgt Ende 2024.
Auf dieser Website zeigen wir zentrale Ergebnisse des Barrierefreiheits-Monitorings von 2022. Es handelt sich um einen Ausschnitt aus den erhobenen Daten. Details zur Methodik, weitere Hintergrundinformationen und die vollständigen Auswertungen werden im Monitoringbericht 2024 veröffentlicht.
Details zu den Monitoring-Checks
Die FFG führt 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. Details zum vereinfachten Test-Vorgang finden Sie hier.
- Eingehende Checks sind umfangreich und überprüfen jedes einzelne – laut Europäischem Standard EN 301 549 geforderte – Barrierefreiheits-Kriterium auf der ausgewählten Seite bzw. der App. Details zum eingehenden Test-Vorgang finden Sie hier.
Trends in den Monitoring-Ergebnissen
Im Vergleich zu den Monitoring-Ergebnissen aus 2021 fallen folgende Punkte auf:
- Es sind nach wie vor dieselben Kriterien, zu denen auf den Websites bzw. in den Apps der öffentlichen Hand Barrierefreiheits-Issues gefunden werden. Änderungen ergeben sich u. a. dadurch, dass 2022 deutlich mehr Apps gecheckt wurden als im ersten Monitoring-Zeitraum.
- Auch 2022 war bei den eingehenden Barrierefreiheits-Checks keine Website oder App vollständig mit den Barrierefreiheitsanforderungen vereinbar. Dafür ist allerdings auch die sehr strenge Auslegung der Konformität verantwortlich – gibt es einen einzelnen Fehler auf einer einzigen Unterseite, gilt der digitale Auftritt „nur“ noch als „teilweise vereinbar“ und nicht mehr als „vollständig vereinbar“.
- Die Ergebnisse der vereinfachten Checks im Jahr 2022 sind vergleichbar mit den Ergebnissen aus 2021: Nach wie vor werden durchschnittlich bei vier der überprüften Kriterien Issues auf den Websites gefunden.
- Der Anteil der Websites und Apps, die eine Barrierefreiheitserklärung veröffentlicht haben, ist 2022 (55 %) im Vergleich zum ersten Monitoring-Zeitraum (54 %) etwa gleich geblieben.
- Insgesamt lassen sich folgende positive Entwicklungen erkennen:
- Betrachtet man nur die Web Content Accessibility Guidelines (WCAG) und zieht die übrigen Kriterien aus EN 301 549 nicht in die Berechnung mit ein, waren 2022 mit 39 % der Websites anteilsmäßig deutlich weniger Websites nicht mit den Barrierefreiheitskriterien vereinbar als im ersten Monitoring-Zeitraum (52 % nicht vereinbar).
- Werden Websites und Apps erneut geprüft, ist der Anteil der digitalen Angebote, die eine Barrierefreiheitserklärung haben, bei diesen höher als bei digitalen Angeboten, die zum ersten Mal gecheckt werden (67 % verfügen über eine Barrierefreiheitserklärung im Vergleich zu 54 % bei den erstmals gecheckten Websites und Apps). Das kann ein Hinweis auf einen Sensibilisierungseffekt des Monitorings sein.
Wie viele Websites und Apps wurden 2022 gecheckt?
- 23 eingehende Checks Websites
- rund 460 Unterseiten
- 253 vereinfachte Checks Websites
- rund 3690 Unterseiten
- 17 eingehende Checks Apps
- rund 280 Screens
In welchem Zeitraum wurden die Checks durchgeführt?
Die Barrierefreiheits-Checks fanden zwischen 7. Februar 2022 und 13. Oktober 2022 statt.
Wie setzt sich die Stichprobe zusammen?
| Bund oder Bundesland | Eingehende Checks Websites | Vereinfachte Checks Websites | Eingehende Checks Apps |
|---|---|---|---|
| Bund | 11 | 126 | 7 |
| Burgenland | 0 | 4 | 0 |
| Kärnten | 1 | 8 | 1 |
| Niederösterreich | 2 | 24 | 1 |
| Oberösterreich | 2 | 21 | 1 |
| Salzburg | 1 | 8 | 1 |
| Steiermark | 2 | 18 | 1 |
| Tirol | 1 | 11 | 1 |
| Vorarlberg | 1 | 6 | 0 |
| Wien | 2 | 27 | 4 |
Verteilung nach Verwaltungsebenen
Verteilung nach Verwaltungsebenen
- Lokal: 20%
- Regional: 30%
- Staatlich: 50%
Verteilung nach Verwaltungsebenen
- Lokal: 20%
- Regional: 30%
- Staatlich: 50%
Rund die Hälfte der gecheckten Websites und Apps lassen sich dem Bund und somit der Verwaltungsebene „staatlich“ zuordnen, die andere Hälfte entfällt auf Bundesländerebene (Verwaltungsebene „regional“) sowie Gemeindeebene (Verwaltungsebene „lokal“).
| Dienstleistungskategorie | Anteil in der Stichprobe |
|---|---|
| Wohnen | 7% |
| Öffentliche Ordnung und Sicherheit | 8% |
| Verkehr | 8% |
| Wirtschaft | 9% |
| Beschäftigung und Steuern | 9% |
| Gesundheit | 9% |
| Soziales | 9% |
| Freizeit und Kultur | 10% |
| Umwelt und Energie | 10% |
| Anderes | 10% |
| Bildung, Wissenschaft und Forschung | 11% |
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“) zu ähnlich großen Anteilen in der Stichprobe enthalten.
Für Apps: Verteilung nach Betriebssystemen und Downloadzahlen
Es wurden 9 Apps des Betriebssystems iOS gecheckt und 8 Apps des Betriebssystems Android. Zusätzlich wurden für die Stichprobenziehung die Downloadzahlen der Apps 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 sind angehalten, auf ihren Websites und in ihren Apps Barrierefreiheitserklärungen zu 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.
Hinweis: Bei der Erhebung der Barrierefreiheitserklärungen wurde deutlich, dass nicht alle Erklärungen aktuell sind. Barrierefreiheitserklärungen müssen zumindest einmal jährlich überprüft und gegebenenfalls aktualisiert werden. Das Datum der letzten Überprüfung wird in der Barrierefreiheitserklärung angegeben.
Anteil Barrierefreiheitserklärungen
Etwas mehr als die Hälfte der gecheckten Websites und Apps (55 %) haben eine Barrierefreiheitserklärung veröffentlicht. 45 % haben keine.
Feedbackmechanismus
Die allermeisten Barrierefreiheitserklärungen (96 %) haben einen Feedback-Kontakt angegeben – eine Kontaktmöglichkeit in der Einrichtung selbst, an die sich Nutzer:innen wenden können, wenn sie auf Barrieren stoßen.
Unverhältnismäßige Belastung
In 44 % der Barrierefreiheitserklärungen ist angegeben, dass aufgrund unverhältnismäßiger Belastung einzelne Barrieren nicht beseitigt werden konnten. Häufig ist hier beispielsweise angeführt, dass für Videos, die über YouTube gehostet werden, keine Audiodeskription bereitgestellt werden könne. In 56 % der Barrierefreiheitserklärungen wird keine unverhältnismäßige Belastung angegeben.
Konformitäts-Status aus den Barrierefreiheitserklärungen
Tabelle: Konformitäts-Status aus den Barrierefreiheitserklärungen
| Vereinbarkeit | Anteil |
|---|---|
| Vollständig vereinbar | 7% |
| Teilweise vereinbar | 66% |
| Nicht vereinbar | 2% |
| Nicht angegeben | 25% |
Tabelle: Konformitäts-Status aus den Barrierefreiheitserklärungen
| Vereinbarkeit | Anteil |
|---|---|
| Vollständig vereinbar | 7% |
| Teilweise vereinbar | 66% |
| Nicht vereinbar | 2% |
| Nicht angegeben | 25% |
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 Aussage, die von den Betreiber:innen der Website bzw. App getätigt wird. „Vollständig vereinbar“ bedeutet: alle Barrierefreiheitskriterien sind ausnahmslos erfüllt. „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 drei Vierteln der Barrierefreiheitserklärungen findet sich eine solche Aussage. Ein Großteil (66 %) gibt an, teilweise mit den Barrierefreiheitsanforderungen vereinbar zu sein. Als vollständig vereinbar bezeichnen sich 7 % der Websites bzw. Apps. Für nicht vereinbar mit den Barrierefreiheitsanforderungen halten sich 2 %.
Ergebnisse der Barrierefreiheits-Checks
Eingehende Checks Websites
Pro gecheckter Website wurden durchschnittlich rund 20 Unterseiten für den Check ausgewählt. Bei der Auswahl der Unterseiten wurde u. a. darauf geachtet, die Hauptzwecke der Websites abzubilden und ganze Prozesse mit aufzunehmen.
Anteile Konformitäts-Status aller eingehend gecheckten Websites
Bei den eingehenden Checks der Websites wurden jeweils rund 92 Kriterien gecheckt. Die Website mit den wenigsten nicht erfüllten Kriterien erfüllt 13 Kriterien nicht. 13 % der Websites erfüllen weniger als 20 Kriterien nicht. Etwa die Hälfte der Websites (52 %) erfüllen mindestens 20, aber weniger als 30 Kriterien nicht. 35 % der Websites erfüllen mehr als 30 Kriterien nicht. Die Website mit den meisten nicht erfüllten Kriterien erfüllt 37 Kriterien nicht. Damit sind alle eingehend gecheckten Websites teilweise mit den Barrierefreiheitsanforderungen vereinbar – sie erfüllen mindestens 50 % der gecheckten Kriterien, aber weniger als 100 %.
Betrachtet man nur die Web Content Accessibility Guidelines (WCAG) (rund 49 gecheckte Kriterien) und zieht die übrigen Kriterien aus EN 301 549 nicht in die Berechnung ein, stellt sich die Vereinbarkeit mit der Auswahl der Kriterien folgendermaßen dar (Konformität mit WCAG):
- Vollständig vereinbar (100 % der WCAG-Kriterien erfüllt): 0 % (keine gecheckte Website)
- Teilweise vereinbar (mind. 50 % der WCAG-Kriterien erfüllt): 61 % der gecheckten Websites
- Nicht vereinbar (unter 50 % der WCAG-Kriterien erfüllt): 39 % der gecheckten Websites
Für die Berechnungen wurden Bewertungen mit „nicht anwendbar“ den Bewertungen mit „erfüllt“ zugerechnet.
Am häufigsten nicht erfüllte Kriterien (Websites)
Tabelle: Am häufigsten nicht erfüllte Kriterien (Websites)
| Kriterium | Nicht erfüllt | Erfüllt | Nicht anwendbar |
|---|---|---|---|
| 3.1.1 Language of Page | 52% | 48% | 0% |
| 2.5.3 Label in Name | 61% | 35% | 4% |
| 2.4.6 Headings and Labels | 61% | 39% | 0% |
| 1.4.5 Images of Text | 61% | 35% | 4% |
| 1.4.13 Content on Hover or Focus | 61% | 9% | 30% |
| 1.3.5 Identify Input Purpose | 61% | 17% | 22% |
| 4.1.1 Parsing | 65% | 35% | 0% |
| 4.1.3 Status Messages | 70% | 4% | 26% |
| 3.3.2 Labels or Instructions | 78% | 13% | 9% |
| 1.4.1 Use of Color | 78% | 22% | 0% |
| 1.4.3 Contrast (Minimum) | 87% | 13% | 0% |
| 1.4.10 Reflow | 87% | 13% | 0% |
| 3.1.2 Language of Parts | 91% | 9% | 0% |
| 2.4.3 Focus Order | 91% | 9% | 0% |
| 2.4.2 Page Titled | 91% | 9% | 0% |
| 1.4.11 Non-text Contrast | 91% | 4% | 4% |
| 1.3.2 Meaningful Sequence | 91% | 9% | 0% |
| 2.4.7 Focus Visible | 96% | 4% | 0% |
| 2.4.4 Link Purpose (In Context) | 96% | 4% | 0% |
| 2.1.1 Keyboard | 96% | 4% | 0% |
| 1.1.1 Non-text Content | 96% | 4% | 0% |
| 4.1.2 Name, Role, Value | 100% | 0% | 0% |
| 1.3.1 Info and Relationships | 100% | 0% | 0% |
Tabelle: Am häufigsten nicht erfüllte Kriterien (Websites)
| Kriterium | Nicht erfüllt | Erfüllt | Nicht anwendbar |
|---|---|---|---|
| 3.1.1 Language of Page | 52% | 48% | 0% |
| 2.5.3 Label in Name | 61% | 35% | 4% |
| 2.4.6 Headings and Labels | 61% | 39% | 0% |
| 1.4.5 Images of Text | 61% | 35% | 4% |
| 1.4.13 Content on Hover or Focus | 61% | 9% | 30% |
| 1.3.5 Identify Input Purpose | 61% | 17% | 22% |
| 4.1.1 Parsing | 65% | 35% | 0% |
| 4.1.3 Status Messages | 70% | 4% | 26% |
| 3.3.2 Labels or Instructions | 78% | 13% | 9% |
| 1.4.1 Use of Color | 78% | 22% | 0% |
| 1.4.3 Contrast (Minimum) | 87% | 13% | 0% |
| 1.4.10 Reflow | 87% | 13% | 0% |
| 3.1.2 Language of Parts | 91% | 9% | 0% |
| 2.4.3 Focus Order | 91% | 9% | 0% |
| 2.4.2 Page Titled | 91% | 9% | 0% |
| 1.4.11 Non-text Contrast | 91% | 4% | 4% |
| 1.3.2 Meaningful Sequence | 91% | 9% | 0% |
| 2.4.7 Focus Visible | 96% | 4% | 0% |
| 2.4.4 Link Purpose (In Context) | 96% | 4% | 0% |
| 2.1.1 Keyboard | 96% | 4% | 0% |
| 1.1.1 Non-text Content | 96% | 4% | 0% |
| 4.1.2 Name, Role, Value | 100% | 0% | 0% |
| 1.3.1 Info and Relationships | 100% | 0% | 0% |
23 Kriterien sind auf über 50 % der Websites nicht erfüllt. Zwei Kriterien – „1.3.1 Info and Relationships“ und „4.1.2 Name, Role Value“ – sind auf allen gecheckten Websites nicht erfüllt. 9 weitere Kriterien sind auf über 90 % der Websites nicht erfüllt.
Eingehende Checks Apps
Pro gecheckter App wurden durchschnittlich rund 17 Screens für den Check ausgewählt. Bei der Auswahl der Screens wurde u. a. darauf geachtet, alle Hauptzwecke der App abzubilden und ganze Prozesse mit aufzunehmen.
Anteile Konformitäts-Status aller eingehend gecheckten Apps
Für die Apps wurden jeweils rund 120 Kriterien gecheckt. Die App mit den wenigsten nicht erfüllten Kriterien erfüllt 9 Kriterien nicht. 10 Apps (knapp 60 % der Apps) erfüllen 10 bis 20 Kriterien nicht. 6 Apps (rund 35 %) erfüllen über 20 Kriterien nicht. Die Apps mit den meisten nicht erfüllten Kriterien erfüllt 35 Kriterien nicht. Damit sind alle eingehend gecheckten Apps teilweise mit den Barrierefreiheitsanforderungen vereinbar – sie erfüllen mindestens 50 % der gecheckten Kriterien, aber weniger als 100 %.
Betrachtet man nur die WCAG und zieht die übrigen Kriterien aus EN 301 549 nicht in die Berechnung mit ein, stellen sich die Anteile folgendermaßen dar (Konformität mit WCAG):
- Vollständig vereinbar (100 % der WCAG-Kriterien erfüllt): 0 % (keine gecheckte App)
- Teilweise vereinbar (mind. 50 % der WCAG-Kriterien erfüllt): 94 % der gecheckten Apps
- Nicht vereinbar (unter 50 % der WCAG-Kriterien erfüllt): eine gecheckte App
Für die Berechnungen wurden Bewertungen mit „nicht anwendbar“ den Bewertungen mit „erfüllt“ zugerechnet.
Am häufigsten nicht erfüllte Kriterien (Apps)
Tabelle: Am häufigsten nicht erfüllte Kriterien (Apps)
| Kriterium | Nicht erfüllt | Erfüllt | Nicht anwendbar |
|---|---|---|---|
| 2.5.3 Label in Name | 53% | 47% | 0% |
| 1.4.11 Non-text Contrast | 53% | 47% | 0% |
| 1.3.2 Meaningful Sequence | 53% | 47% | 0% |
| 1.4.1 Use of Color | 59% | 35% | 6% |
| 1.4.4 Resize text | 71% | 29% | 0% |
| 1.3.4 Orientation | 76% | 24% | 0% |
| 2.4.3 Focus Order | 88% | 12% | 0% |
| 1.4.3 Contrast (Minimum) | 94% | 6% | 0% |
| 1.1.1 Non-text Content | 94% | 6% | 0% |
| 4.1.2 Name, Role, Value | 100% | 0% | 0% |
| 1.3.1 Info and Relationships | 100% | 0% | 0% |
Tabelle: Am häufigsten nicht erfüllte Kriterien (Apps)
| Kriterium | Nicht erfüllt | Erfüllt | Nicht anwendbar |
|---|---|---|---|
| 2.5.3 Label in Name | 53% | 47% | 0% |
| 1.4.11 Non-text Contrast | 53% | 47% | 0% |
| 1.3.2 Meaningful Sequence | 53% | 47% | 0% |
| 1.4.1 Use of Color | 59% | 35% | 6% |
| 1.4.4 Resize text | 71% | 29% | 0% |
| 1.3.4 Orientation | 76% | 24% | 0% |
| 2.4.3 Focus Order | 88% | 12% | 0% |
| 1.4.3 Contrast (Minimum) | 94% | 6% | 0% |
| 1.1.1 Non-text Content | 94% | 6% | 0% |
| 4.1.2 Name, Role, Value | 100% | 0% | 0% |
| 1.3.1 Info and Relationships | 100% | 0% | 0% |
11 Kriterien sind bei über 50 % der Apps nicht erfüllt. Wie bei den Websites sind auch bei den Apps die beiden Kriterien „1.3.1 Info and Relationships“ und „4.1.2 Name, Role, Value“ auf allen Apps nicht erfüllt. Zwei weitere Kriterien – „1.1.1 Non-text Content“ und „1.4.3 Contrast (Minimum)“ – sind auf über 90 % der Apps nicht erfüllt.
Vereinfachte Checks Websites
Für den zweiten Monitoring-Zeitraum wurden 13 WCAG-Kriterien ausgewählt, die mit dem Tool QualWeb (externer Link) überprüft wurden. Die vereinfachten Prüfungen der Stadt Wien wurden mit dem Tool Google Lighthouse (externer Link) für dieselben 13 Kriterien durchgeführt.
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. mit aufzunehmen.
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.
Anteil „nicht erfüllt“ bei den vereinfacht gecheckten Kriterien
Tabelle: Anteil „nicht erfüllt“ bei den vereinfacht gecheckten Kriterien
| Kriterium | Anteil |
|---|---|
| 1.3.4 Orientation | 0% |
| 1.4.12 Text Spacing | 1% |
| 2.4.2 Page Titled | 7% |
| 2.1.1 Keyboard | 9% |
| 3.1.1 Language of Page | 11% |
| 2.5.3 Label in Name | 13% |
| 1.4.4 Resize Text | 19% |
| 4.1.1 Parsing | 42% |
| 1.1.1 Non-text Content | 47% |
| 1.3.1 Info and Relationships | 66% |
| 1.4.3 Contrast (Minimum) | 69% |
| 2.4.4 Link Purpose (In Context) | 71% |
| 4.1.2 Name, Role, Value | 84% |
Tabelle: Anteil „nicht erfüllt“ bei den vereinfacht gecheckten Kriterien
| Kriterium | Anteil |
|---|---|
| 1.3.4 Orientation | 0% |
| 1.4.12 Text Spacing | 1% |
| 2.4.2 Page Titled | 7% |
| 2.1.1 Keyboard | 9% |
| 3.1.1 Language of Page | 11% |
| 2.5.3 Label in Name | 13% |
| 1.4.4 Resize Text | 19% |
| 4.1.1 Parsing | 42% |
| 1.1.1 Non-text Content | 47% |
| 1.3.1 Info and Relationships | 66% |
| 1.4.3 Contrast (Minimum) | 69% |
| 2.4.4 Link Purpose (In Context) | 71% |
| 4.1.2 Name, Role, Value | 84% |
Am häufigsten nicht erfüllt ist das Kriterium „4.1.2 Name, Role, Value“, das von 84 % der Websites nicht erfüllt wird. Es folgen die Kriterien „2.4.4 Link Purpose (In Context)“ und „1.4.3 Contrast (Minimum)“, die von rund 70 % der Websites nicht erfüllt werden. Am besten schneiden die Websites bei den Kriterien „1.3.4 Orientation“ und „1.4.12 Text Spacing“ ab – diese werden von keiner Website bzw. nur von 1 % nicht erfüllt.
Verteilung nach Anzahl nicht erfüllter Kriterien je gecheckter Website
Tabelle: Verteilung nach Anzahl nicht erfüllter Kriterien je gecheckter Website
| Anzahl der nicht erfüllten Kriterien | Anteil der gecheckten Websites |
|---|---|
| 0 | 1% |
| 1 | 4% |
| 2 | 13% |
| 3 | 15% |
| 4 | 20% |
| 5 | 20% |
| 6 | 13% |
| 7 | 8% |
| 8 | 4% |
| 9 | 2% |
| 10 | 0,4% |
| 11 | 0% |
| 12 | 0% |
| 13 | 0% |
Tabelle: Verteilung nach Anzahl nicht erfüllter Kriterien je gecheckter Website
| Anzahl der nicht erfüllten Kriterien | Anteil der gecheckten Websites |
|---|---|
| 0 | 1% |
| 1 | 4% |
| 2 | 13% |
| 3 | 15% |
| 4 | 20% |
| 5 | 20% |
| 6 | 13% |
| 7 | 8% |
| 8 | 4% |
| 9 | 2% |
| 10 | 0,4% |
| 11 | 0% |
| 12 | 0% |
| 13 | 0% |
Auf zwei Websites (0,8 %) wurden zu den gecheckten Kriterien keine Fehler gefunden. Auf 40 % der Websites wurden zu vier oder fünf der 13 gecheckten Kriterien Fehler gefunden. Auf keiner der Websites wurden zu 11 oder mehr der 13 gecheckten Kriterien Fehler gefunden.
Die am häufigsten nicht erfüllten Kriterien
Im Monitoring 2022 wurden für Websites und Apps folgende fünf Kriterien als am häufigsten nicht erfüllt identifiziert – diese sind durchschnittlich auf mindestens 90 % der Websites und Apps nicht erfüllt.
Hinweis: Die Darstellung konzentriert sich auf die häufigsten Barrierefreiheits-Issues – die einzelnen Kriterien werden daher nicht zur Gänze beschrieben. Die weiterführenden Links sind reine Zusatzinformation und stehen nicht in Zusammenhang mit den von der FFG durchgeführten Barrierefreiheits-Checks.
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 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 (h1 bis h6) sollen entsprechend und korrekt verwendet werden.
- Ähnliche/gleichrangige Element, die visuell einer Liste ähneln, sollen auch programmatisch als Listen ausgezeichnet werden, als unordered lists (ul) oder als ordered lists (ol), sowie die Listen-Elemente 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 horizontal als auch vertikal. Komplexere Tabellen können auch mittels scope- und header-Attributen umgesetzt werden. Allerdings sollte hier überlegt werden, ob die Aufteilung einer komplexen Tabelle auf mehrere einfachere Tabellen nicht sinnvoller wäre.
- Formularelemente sollen entweder direkt beschriftet oder mit einem Label korrekt verknüpft sein (siehe dazu auch Kriterium 4.1.2).
- 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 richtige programmatische 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) sollte dem Seitentitel entsprechen, alle anderen Überschriften (h2 bis h6) den visuellen und logischen Aufbau der Website reflektieren. Keine Überschriften-Ebenen dürfen ausgelassen werden. Gleichrangige Überschriften sollen mit der gleichen Ebene ausgezeichnet werden, direkte Kind-Elemente mit einer Ebene darunter, direkte Eltern-Elemente 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. Steuerelemente 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. Zurzeit ist es sogar am besten, beides gleichzeitig zu verwenden, da unterschiedliche Screenreader-Browser-Kombinationen unterschiedliche Annotationsformen beherrschen können. Hier eine Auflistung:
| HTML 5 | ARIA Role |
|---|---|
| <header> | role="banner" |
| <nav> | role="navigation" |
| <main> | role="main" |
| <footer> | role="contentinfo" |
| <aside> | role="complementary" |
| <section> | role="region" |
Weiterführende Informationen
- BITV-Prüfschritt 9.1.3.1a HTML-Strukturelemente für Überschriften (externer Link)
- BITV-Prüfschritt 9.1.3.1b HTML-Strukturelemente für Listen (externer Link)
- BITV-Prüfschritt 9.1.3.1c HTML-Strukturelemente für Zitate (externer Link)
- BITV-Prüfschritt 9.1.3.1d Inhalte gegliedert (externer Link)
- BITV-Prüfschritt 9.1.3.1e Datentabellen richtig aufgebaut (externer Link)
- BITV-Prüfschritt 9.1.3.1f Zuordnung von Tabellenzellen (externer Link)
- BITV-Prüfschritt 9.1.3.1g Kein Strukturmarkup für Layouttabellen (externer Link)
- BITV-Prüfschritt 9.1.3.1h Beschriftung von Formularelementen programmatisch ermittelbar (externer Link)
- WCAG 2.1: Understanding Success Criterion 1.3.1: Info and Relationships (externer Link)
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 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 (h1 bis h6) sollen entsprechend und korrekt verwendet werden.
- Ähnliche/gleichrangige Element, die visuell einer Liste ähneln, sollen auch programmatisch als Listen ausgezeichnet werden, als unordered lists (ul) oder als ordered lists (ol), sowie die Listen-Elemente 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 horizontal als auch vertikal. Komplexere Tabellen können auch mittels scope- und header-Attributen umgesetzt werden. Allerdings sollte hier überlegt werden, ob die Aufteilung einer komplexen Tabelle auf mehrere einfachere Tabellen nicht sinnvoller wäre.
- Formularelemente sollen entweder direkt beschriftet oder mit einem Label korrekt verknüpft sein (siehe dazu auch Kriterium 4.1.2).
- 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 richtige programmatische 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) sollte dem Seitentitel entsprechen, alle anderen Überschriften (h2 bis h6) den visuellen und logischen Aufbau der Website reflektieren. Keine Überschriften-Ebenen dürfen ausgelassen werden. Gleichrangige Überschriften sollen mit der gleichen Ebene ausgezeichnet werden, direkte Kind-Elemente mit einer Ebene darunter, direkte Eltern-Elemente 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. Steuerelemente 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. Zurzeit ist es sogar am besten, beides gleichzeitig zu verwenden, da unterschiedliche Screenreader-Browser-Kombinationen unterschiedliche Annotationsformen beherrschen können. Hier eine Auflistung:
| HTML 5 | ARIA Role |
|---|---|
| <header> | role="banner" |
| <nav> | role="navigation" |
| <main> | role="main" |
| <footer> | role="contentinfo" |
| <aside> | role="complementary" |
| <section> | role="region" |
Weiterführende Informationen
- BITV-Prüfschritt 9.1.3.1a HTML-Strukturelemente für Überschriften (externer Link)
- BITV-Prüfschritt 9.1.3.1b HTML-Strukturelemente für Listen (externer Link)
- BITV-Prüfschritt 9.1.3.1c HTML-Strukturelemente für Zitate (externer Link)
- BITV-Prüfschritt 9.1.3.1d Inhalte gegliedert (externer Link)
- BITV-Prüfschritt 9.1.3.1e Datentabellen richtig aufgebaut (externer Link)
- BITV-Prüfschritt 9.1.3.1f Zuordnung von Tabellenzellen (externer Link)
- BITV-Prüfschritt 9.1.3.1g Kein Strukturmarkup für Layouttabellen (externer Link)
- BITV-Prüfschritt 9.1.3.1h Beschriftung von Formularelementen programmatisch ermittelbar (externer Link)
- WCAG 2.1: Understanding Success Criterion 1.3.1: Info and Relationships (externer Link)
Nicht-Text-Inhalt (WCAG-Kriterium 1.1.1)
Was bedeutet das Kriterium?
Nicht-Text-Inhalte benötigen eine textliche Alternative. Textalternativen sind eine wichtige Möglichkeit, 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 Alternativtext versehen werden.
- Bei Bildern soll der Alternativtext kurz und prägnant die relevante Information wiedergeben, 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 Alternativtexte für informationstragende visuelle Elemente (Grafiken, Bilder, grafische Bedienelemente etc.) angewiesen. Audio-Inhalte benötigen z. B. eine textliche 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 Alternativtext:
Wenn ein Bild oder Logo keinen Alternativtext 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äftiger Alternativtext:
Die Beschreibung soll aussagekräftig, aber trotzdem möglichst kurz und prägnant sein. 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 Porträt 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 Friseursalons, 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 Alternativtext:
Hintergrundbilder 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, einer 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
- BITV-Prüfschritt 9.1.1.1a Alternativtexte für Bedienelemente (externer Link)
- BITV-Prüfschritt 9.1.1.1b Alternativtexte für Grafiken und Objekte (externer Link)
- BITV-Prüfschritt 9.1.1.1c Leere alt-Attribute für Layoutgrafiken (externer Link)
- WCAG 2.1: Understanding Success Criterion 1.1.1: Non-text Content (externer Link)
Nicht-Text-Inhalt (WCAG-Kriterium 1.1.1)
Was bedeutet das Kriterium?
Nicht-Text-Inhalte benötigen eine textliche Alternative. Textalternativen sind eine wichtige Möglichkeit, 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 Alternativtext versehen werden.
- Bei Bildern soll der Alternativtext kurz und prägnant die relevante Information wiedergeben, 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 Alternativtexte für informationstragende visuelle Elemente (Grafiken, Bilder, grafische Bedienelemente etc.) angewiesen. Audio-Inhalte benötigen z. B. eine textliche 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 Alternativtext:
Wenn ein Bild oder Logo keinen Alternativtext 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äftiger Alternativtext:
Die Beschreibung soll aussagekräftig, aber trotzdem möglichst kurz und prägnant sein. 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 Porträt 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 Friseursalons, 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 Alternativtext:
Hintergrundbilder 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, einer 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
- BITV-Prüfschritt 9.1.1.1a Alternativtexte für Bedienelemente (externer Link)
- BITV-Prüfschritt 9.1.1.1b Alternativtexte für Grafiken und Objekte (externer Link)
- BITV-Prüfschritt 9.1.1.1c Leere alt-Attribute für Layoutgrafiken (externer Link)
- WCAG 2.1: Understanding Success Criterion 1.1.1: Non-text Content (externer Link)
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, ihnen wird 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 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?
Control (z. B. Buttons, Eingabefelder etc.) haben keine programmatisch erfassbare Beschriftung (keinen Namen):
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 Labels entweder verlinkt werden (label-Tag und for-Attribut bzw. aria-labelledby) oder direkt definiert werden (aria-label).
Siehe auch: Web Accessibility Tutorials: Labeling Controls (externer Link)
Buttons (und andere Controls) sind nicht als solche ausgezeichnet:
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 auf den korrekten Einsatz von WAI-ARIA achten.
Siehe dazu auch: WAI-ARIA Roles (externer Link)
Link hat keine programmatisch erfassbare Linkbeschriftung (keinen Namen):
Links müssen eine programmatisch erfassbare (textliche) Beschriftung aufweisen, die den Linkzweck angibt. Dies ist vor allem bei Bild- bzw. Icon-Links wichtig, damit für Screenreader-Nutzer:innen kommuniziert wird, wohin diese Links führen. Dabei soll nicht das title-Attribute verwendet werden, das nicht für den Linkzweck, sondern für zusätzliche Information vorgesehen ist. Genutzt werden soll der Link-Text, das ist der Text, den der a-Tag umschließt. Wenn dieser Text visuell nicht sichtbar sein soll, kann er in ein span-Element gekapselt und mittels CSS versteckt werden (nicht „display:none“ verwenden, da dies auch den Text für Screenreader-Nutzer:innen versteckt).
Siehe dazu auch: CSS in Action: Invisible Content Just for Screen Reader Users (externer Link)
Beispiel für einen Icon-Link:
- Icon: FFG-Logo
- Span mit sr-only-Klasse: FFG – Österreichische Forschungsförderungsgesellschaft
- Title: Öffnet ein neues Browser Fenster
IFrame hat keinen Namen (bspw. kein title-Attribut):
IFrames benötigen einen Namen (z. B. mittels title-Attribut), damit ihr Zweck Screenreader-Nutzer:innen kommuniziert wird und diese dann entscheiden können, ob sie zu den Inhalten des iFrames navigieren oder diese überspringen möchten. Der Name soll kurz den Inhalt des iFrames beschreiben. Beispiel: „Youtube Video: Interview mit Frau XYZ“.
Weiterführende Informationen
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, ihnen wird 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 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?
Control (z. B. Buttons, Eingabefelder etc.) haben keine programmatisch erfassbare Beschriftung (keinen Namen):
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 Labels entweder verlinkt werden (label-Tag und for-Attribut bzw. aria-labelledby) oder direkt definiert werden (aria-label).
Siehe auch: Web Accessibility Tutorials: Labeling Controls (externer Link)
Buttons (und andere Controls) sind nicht als solche ausgezeichnet:
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 auf den korrekten Einsatz von WAI-ARIA achten.
Siehe dazu auch: WAI-ARIA Roles (externer Link)
Link hat keine programmatisch erfassbare Linkbeschriftung (keinen Namen):
Links müssen eine programmatisch erfassbare (textliche) Beschriftung aufweisen, die den Linkzweck angibt. Dies ist vor allem bei Bild- bzw. Icon-Links wichtig, damit für Screenreader-Nutzer:innen kommuniziert wird, wohin diese Links führen. Dabei soll nicht das title-Attribute verwendet werden, das nicht für den Linkzweck, sondern für zusätzliche Information vorgesehen ist. Genutzt werden soll der Link-Text, das ist der Text, den der a-Tag umschließt. Wenn dieser Text visuell nicht sichtbar sein soll, kann er in ein span-Element gekapselt und mittels CSS versteckt werden (nicht „display:none“ verwenden, da dies auch den Text für Screenreader-Nutzer:innen versteckt).
Siehe dazu auch: CSS in Action: Invisible Content Just for Screen Reader Users (externer Link)
Beispiel für einen Icon-Link:
- Icon: FFG-Logo
- Span mit sr-only-Klasse: FFG – Österreichische Forschungsförderungsgesellschaft
- Title: Öffnet ein neues Browser Fenster
IFrame hat keinen Namen (bspw. kein title-Attribut):
IFrames benötigen einen Namen (z. B. mittels title-Attribut), damit ihr Zweck Screenreader-Nutzer:innen kommuniziert wird und diese dann entscheiden können, ob sie zu den Inhalten des iFrames navigieren oder diese überspringen möchten. Der Name soll kurz den Inhalt des iFrames beschreiben. Beispiel: „Youtube Video: Interview mit Frau XYZ“.
Weiterführende Informationen
Kontraste von Texten (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 als 18 pt bei normaler Schriftdicke oder kleiner als 14 pt bei fetter Schrift) gilt das Kontrastverhältnis 4,5:1
- für große Schrift (18 pt oder größer bei normaler Schriftdicke oder 14 pt oder größer bei fetter Schrift) gilt das Kontrastverhältnis 3:1
Ausgenommen sind 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 Apps 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. 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
Kontraste von Texten (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 als 18 pt bei normaler Schriftdicke oder kleiner als 14 pt bei fetter Schrift) gilt das Kontrastverhältnis 4,5:1
- für große Schrift (18 pt oder größer bei normaler Schriftdicke oder 14 pt oder größer bei fetter Schrift) gilt das Kontrastverhältnis 3:1
Ausgenommen sind 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 Apps 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. 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
Schlüssige Reihenfolge bei der Tastaturbedienung (WCAG-Kriterium 2.4.3)
Was bedeutet das Kriterium?
Wenn Nutzer:innen eine Website oder App 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 essenziell, dass sie Inhalte in einer sinnvoll nachvollziehbaren Reihenfolge erreichen. Das kann Menschen mit motorischen Behinderungen betreffen oder auch blinde Menschen, die das Web mit Screenreadern und Tastaturnavigation nutzen. Für diese Zielgruppe ist die Fokusreihenfolge beispielsweise beim Ausfüllen eines Online-Formulars essenziell. Für Nutzer:innen, die aufgrund einer Sehbehinderung starke 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 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 Fenster ist geöffnet, aber der 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
Schlüssige Reihenfolge bei der Tastaturbedienung (WCAG-Kriterium 2.4.3)
Was bedeutet das Kriterium?
Wenn Nutzer:innen eine Website oder App 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 essenziell, dass sie Inhalte in einer sinnvoll nachvollziehbaren Reihenfolge erreichen. Das kann Menschen mit motorischen Behinderungen betreffen oder auch blinde Menschen, die das Web mit Screenreadern und Tastaturnavigation nutzen. Für diese Zielgruppe ist die Fokusreihenfolge beispielsweise beim Ausfüllen eines Online-Formulars essenziell. Für Nutzer:innen, die aufgrund einer Sehbehinderung starke 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 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 Fenster ist geöffnet, aber der 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
Die Servicestelle des Bundes zur digitalen Barrierefreiheit
Von Oktober 2021 bis Dezember 2022 wurden 34 Beschwerden von der Servicestelle der FFG bearbeitet, bei denen es sich um digitale Barrieren im Sinne des Web-Zugänglichkeits-Gesetzes handelte (davon entfielen 27 auf das Jahr 2022).
Wie geht es weiter?
Das Monitoring wird weiterhin jährlich durchgeführt. Ende 2024 ist der nächste Bericht über die Ergebnisse des Monitorings an die Europäische Kommission fällig. Darin werden die Monitoring-Zeiträume 2022 bis inklusive 2024 ausführlich dargestellt. Monitoringberichte müssen alle drei Jahre veröffentlicht werden, demnach ist der nächste Monitoringbericht Ende 2027 fällig.