Häufig nicht erfüllte Barrierefreiheitskriterien

                        
Infografik: Digitale Barrierefreiheit: die häufigsten Fehler vermeiden (PDF)

Im Rahmen unserer regelmäßigen Monitoring-Checks öffentlicher Websites konnten die am häufigsten nicht erfüllten Barrierefreiheitskriterien identifiziert werden. Auf dieser Seite gehen wir näher auf diese Kriterien und die dazu gefundenen Barrieren ein. Wir:

  • stellen die am häufigsten nicht erfüllten WCAG-Kriterien dar,
  • stellen dar, warum und für wen die betroffenen Kriterien wichtig sind,
  • beschreiben, was konkret die häufigsten Barrieren waren, die gefunden wurden,
  • beschreiben, wie diese Barrieren behoben bzw. vermieden werden können und
  • stellen Quellen vor, bei denen weiterführende Informationen gefunden werden können.

Die Darstellung konzentriert sich auf die häufigsten Fehler – die einzelnen Kriterien werden daher nicht zur Gänze beschrieben. Der Fokus liegt auf den identifizierten Ansatzpunkten zur Verbesserung der Barrierefreiheit der Websites.

Die weiterführenden Links sind reine Zusatzinformation und stehen nicht in Zusammenhang mit den von der FFG durchgeführten Monitoring-Checks.

Details zu den häufigsten Fehlern

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äftiger 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-Bild 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

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-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 mittels scope- und header-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).
  • 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-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. 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

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 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, welche 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. 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

Website-Titel (WCAG-Kriterium 2.4.2)

Was bedeutet das Kriterium?

Websites sollen einen sprechenden und verständlichen Titel aufweisen. Dieser soll die Website (Domain) verständlich beschreiben. Auch sollte daran erkennbar sein, auf welcher Unterseite der Domain sich Website-Nutzer:innen gerade befinden.

Titel müssen bei Dokumenten ebenfalls richtig ausgezeichnet werden.

Warum und für wen ist das Kriterium wichtig?

Aussagekräftige Titel für jede Unterseite - erstellt via title-Tag - sind für alle Nutzer:innen wichtig. Sie ermöglichen eine Identifikation der Unterseite, ohne dass deren tatsächlicher Inhalt gelesen oder interpretiert werden muss. Der Titel identifiziert bspw. einzelne geöffnete Tabs im Browser und sollte den Nutzern:innen ermöglichen, jenes Tab aufzurufen, welches sie tatsächlich ansteuern möchten. Werden die Website und die Unterseite im Titel kommuniziert, ist in den meisten Fällen eine eindeutige Identifikation zwischen unterschiedlichen Websites (z. B. Kontakt-Unterseite unterschiedlicher Firmen) und innerhalb einer Website (z. B. Kontakt-Unterseite und Datenschutzerklärungs-Unterseite) sichergestellt.

Bei der Erstellung von Lesezeichen ist ein richtig ausgezeichneter Website-Titel ebenfalls eine große Hilfe, da der Titel automatisch für die Beschriftung des Lesezeichens vorgeschlagen wird.

Bei Dokumenten müssen Titel ebenfalls vorhanden sein. Dies ist vor allem für Screenreader-Nutzer:innen wichtig, da bei mehreren geöffneten (und minimierten) Dokumenten das gewünschte zielsicher ausgewählt werden kann, ohne dass in den Inhalt gesprungen werden muss, um herauszufinden worum es in dem Dokument geht.

Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?

Der Titel einer Website ist nicht (richtig) ausgezeichnet:

Häufig ist der Titel bei Unterseiten von Websites nicht aussagekräftig genug. Eine gute Herangehensweise ist, mittels title-Tag im HTML-Head sowohl den Titel der Unterseite als auch der gesamten Website anzugeben.

  • Z. B. für die Startseite der Stadt Salzburg: „Stadt Salzburg“, oder ev. „Stadt Salzburg - Startseite“
  • Und für die Unterseite Kontakt: „Stadt Salzburg - Kontakt“

Der Titel in einem (PDF)-Dokument ist nicht richtig ausgezeichnet:

Der Titel sollte grundsätzlich schon vor dem Generieren des PDFs richtig im Original-Dokument ausgezeichnet werden. Bei Verwendung eines PDF-Konverters wird dieser dann im Regelfall auch auf das PDF richtig angewendet. Es kann aber auch nachträglich der PDF-Titel ergänzt oder geändert werden z. B. mit Adobe Acrobat.

Weiterführende Informationen

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

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. 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 vom Hintergrund 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 unterschiedliche 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 unterschiedlich genug sein. Der Kontrast muss mindestens 3:1 betragen.

Weiterführende Informationen

Sprache einzelner Abschnitte (WCAG-Kriterium 3.1.2)

Was bedeutet das Kriterium?

Nicht nur die Hauptsprache der Website soll ausgezeichnet sein, sondern auch Teile und in manchen Fällen einzelne Wörter der Seite, die eine davon abweichende Sprache aufweisen. Dies funktioniert mittels lang-Attribut und kann auf alle Elemente angewendet werden.

Das betrifft nicht nur Elemente, die direkt Text darstellen können (z. B. div, p, span), sondern auch z. B. Image-Buttons die ein nicht-sichtbares aria-label aufweisen.

Sehr häufig verwendete Fremdwörter werden aber auch von Screenreadern meist erkannt (z. B.: Copyright, Homepage, E-Mail) und müssen nicht extra ausgezeichnet werden. Um sicher zu gehen, kann das mit einem Screenreader getestet werden.

Warum und für wen ist das Kriterium wichtig?

Screenreader verwenden oft Sprachsynthese (Text-to-Speech), um Text für Nutzer:innen hörbar zu machen. Damit der Text verständlich ausgesprochen werden kann, ist es wichtig, dass die Sprache sowohl für die Website selbst, als auch für anderssprachige Elemente richtig ausgezeichnet ist. Sonst kann es passieren, dass Wörter unverständlich ausgesprochen werden (z. B. englische Begriff mit deutscher Aussprache), oder dass durch die falsche Aussprache die Bedeutung missverstanden wird.

Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?

Die Sprache von anderssprachigen Abschnitten ist nicht richtig ausgezeichnet:

Elemente mit anderssprachigem Text, egal ob sichtbar oder nicht (z. B. Image-Button mit aria-label für Screenreader-Nutzer:innen) sollen per lang-Attribut ausgezeichnet werden. Der Wert soll ein korrekter Sprach-Code sein (z. B. "de" oder "en").               
Siehe auch: HTML Language Code Reference

Häufig sind fälschlicherweise anderssprachige Begriffe zu finden - in so einem Fall sollten der Text oder die Beschriftung in die Hauptsprache übersetzt werden, um ein konsistente und korrekte Darstellung zu garantieren.

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, 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 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 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

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

Link hat keine programmatisch erfassbare Linkbeschriftung (keinen Namen):

Links müssen eine programmatisch erfassbare (textuelle) 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, welches 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 werden 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

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 an Screenreader-Nutzer:innen kommuniziert wird und diese dann entscheiden können, ob sie zu den Inhalten des iFrames navigieren möchten oder diese überspringen möchten. Der Name soll kurz den Inhalt des iFrames beschreiben. Beispiel: „Youtube Video: Interview mit Frau XYZ“.

Weiterführende Informationen

Für eine Übersicht aller zu erfüllenden Kriterien klicken Sie hier.

Wissenswertes und Fakten
Digitales zugänglich machen
Service für Nutzer:innen
Leistungen der FFG