Qualitative Auswertungen

Barrierefreiheitskriterien, die bei Websites und Apps insgesamt besonders häufig nicht erfüllt wurden, welche Fehler das sind, warum sie als Barrieren eingestuft werden und wie sie behoben werden können

Die am häufigsten nicht erfüllten Kriterien

Aus den quantitativen Auswertungen zu den einzelnen WCAG-Kriterien geht hervor, welche Kriterien besonders häufig erfüllt beziehungsweise nicht erfüllt werden. Über alle Monitoringzeiträume hinweg gibt es 4 Kriterien, die jedes Mal unter den am häufigsten nicht erfüllten sind:

  • Info und Beziehungen (WCAG-Kriterium 1.3.1)
  • Nicht-Text-Inhalt (WCAG-Kriterium 1.1.1)
  • Name, Rolle, Wert (WCAG-Kriterium 4.1.2)
  • Kontraste von Texten (WCAG-Kriterium 1.4.3)

Welche Kriterien seit dem ersten Monitoringzeitraum 2020/2021 als besonders häufig nicht erfüllt identifiziert wurden, ist auf der Seite „Die häufigsten Fehler“ auf digitalbarrierefrei.at (externer Link) beschrieben.

Monitoringzeitraum

Im Monitoringzeitraum 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 für 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 Website und ihrer Elemente angewiesen, um die Website und ihre Inhalte nachvollziehen zu können. Ist die Überschriften-Struktur nicht richtig ausgezeichnet, ist der Aufbau und die Gliederung einer Website 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:

Vereinfachte Darstellung des Aufbaus einer typischen WebSeite, mit schriftlich bezeichneten aria-Regionen. Oben 'banner', mittig dreigeteilt von links nach rechts 'navigation', 'main' (mit 'article', 'application' und 'section') und 'complementary' (mit 'form'). Unten 'contentinfo'.

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

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äftigen 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

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 Forschungs­förderungs­gesellschaft
  • 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 (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

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
https://monitoringbericht2024.digitalbarrierefrei.at/ergebnisse/qualitative-auswertungen