Redaktion

Eine barrierefreie Website oder App ist technisch so gestaltet, dass sie alle Menschen gut nutzen können. Insbesondere für Menschen mit dauerhaften oder temporären Behinderungen ist digitale Barrierefreiheit von großer Bedeutung. Barrieren können beispielsweise fehlende alternative Bildbeschreibungen, eine unlogische Überschriftenstruktur oder zu geringe Farbkontrastwerte sein.

Die Web Content Accessibility Guidelines (WCAG) definieren klare Anforderungen, die dabei helfen, Barrieren zu vermeiden. Welche Barrierefreiheitskriterien genau erfüllt werden müssen, finden Sie hier aufgelistet.

Diese Anleitung soll Web-Redakteur:innen dabei unterstützen, Inhalte im Sinne der Barrierefreiheitskriterien barrierefrei zu gestalten und online einzupflegen.

Zur Erklärung der Zusammenhänge sind in diesem Leitfaden auch einige technische Aspekte angeführt, obwohl diese ausschließlich von Entwickler:innen zu bearbeiten sind. Bei technischen Unklarheiten empfehlen wir den Redakteur:innen, auf jeden Fall Kontakt mit den jeweils verantwortlichen Entwickler:innen aufzunehmen.

Welche Aspekte sind für digitale Barrierefreiheit wesentlich?

Information wird über eine barrierefreie Website oder App aufgrund der individuellen Usability-Einstellungen uneingeschränkt zugänglich. Damit dies gewährleistet ist, sollten mehrere Aspekte berücksichtigt werden.

Technische Aspekte

Basis für digitale Barrierefreiheit ist, dass die eingesetzten Technologien wie Content-Management-Systeme (beispielsweise WordPress, Joomla, TYPO3 usw.), Apps, PDFs etc. den technischen Standards entsprechen.

Frontend- und Backend-Entwickler:innen sind dafür verantwortlich, dass der generierte Code den Standards entspricht und die Inhalte von Redakteur:innen auch barrierefrei eingegeben werden können.

Die technischen Standards beinhalten eine Reihe von WCAG-Erfolgskriterien (Success Criteria) sowie erweiterte, in dem Zusammenhang relevante Standards wie beispielsweise PDF/UA (Regelwerk für PDF-Dokumente).

Den Web Content Accessibility Guidelines liegen zudem vier Prinzipien zugrunde:

• Wahrnehmbar: Informationen können ohne Probleme aufgenommen werden, z. B. verfügen Farbwerte über ausreichend Kontrast.
• Bedienbar: Beispielsweise ist Navigieren durch die Website mittels Tastatur – ohne Computermaus – möglich und es besteht genügend Zeit für die Informationsaufnahme.
• Verständlich: Die Benutzung der Schnittstelle soll verständlich sein, z.B. durch Erklärungen bei Formularfeldern.
• Robust: Fehlerfreiheit in der technischen Umsetzung schafft Kompatibilität mit assistierenden Technologien.

Hier finden Sie Näheres zur barrierefreien Entwicklung von Websites und Apps.

Grafische und konzeptionelle Aspekte

Je früher digitale Barrierefreiheit in der Projektplanung mitgedacht wird, desto besser. Dadurch lässt sich eventuelles aufwendiges und kostenintensives Nacharbeiten vermeiden.

Konzeptionell könnte beispielsweise geklärt werden, wie die Struktur der Applikation aufgebaut ist, ob die Anwendung linearisierbar ist (macht die Lesereihenfolge der Elemente Sinn?).

Weiters ist empfehlenswert, bereits in der Designphase digitale Barrierefreiheit und User Experience für unterschiedliche Nutzer:innen-Gruppen mitzudenken. In diesem Arbeitsschritt kann bereits festgelegt werden, wie Skiplinks, Tab Focus (Style, wenn ein Element Fokus erhält) oder weitere assistierende Elemente aussehen.

Farbe und Kontrast

Auch die Umsetzbarkeit (Feasibility) der grafischen Entwürfe in Hinblick auf digitale Barrierefreiheit ist wichtig, vor allem die Wahl eines passenden Farbschemas, das ausreichend Kontrast für „Text“- und „Nicht-Text“-Elemente (beispielsweise Buttons) bietet.

Entsprechender Kontrast ist wesentlich, damit der Text gut lesbar ist. Der Kontrast zwischen Text und Hintergrundfarbe muss daher ausreichend sein. Gemäß der Mindestanforderung sollte das Kontrastverhältnis jedenfalls 4,5:1 sein.

Bei Nichterfüllung braucht es gegebenenfalls im Corporate Design eine Ergänzung barrierefreier Farben. Für die Prüfung bestehender Farbwerte bzw. eines korrekten Kontrastverhältnisses gibt es viele unterschiedliche Tools.

Tipp: Ein hilfreiches Online-Werkzeug dafür ist der Kontrast-Checker von WebAIM (externer Link).

Nachfolgend finden sich einige Beispiele für Text mit ausreichend Kontrast:

Ein nicht ausreichendes Kontrastverhältnis entsteht meist dann, wenn eine zu helle Textfarbe verwendet wird – zu sehen im nachfolgenden Beispiel.

Zusätzlich zum Kontrast ist es wichtig, dass Informationen nicht nur durch Farbe kommuniziert werden, da diese von Nutzer:innen mit einer Farbenfehlsichtigkeit womöglich nicht wahrgenommen werden können.

Erfolgskriterium 1.4.1 „Use of Color“ (Level A) (externer Link): Farbe wird nicht als einziges visuelles Mittel zur Informationsvermittlung, zum Hinweis auf eine Aktion, zum Auslösen einer Reaktion oder zur Unterscheidung eines visuellen Elements verwendet.

Wenn bei einem Formular verpflichtend auszufüllende Felder beispielsweise nur durch eine rote Umrandung gekennzeichnet sind, ist das für viele Menschen nicht wahrnehmbar. Zusätzlich könnte ein textueller Hinweis oder ein Symbol angezeigt werden, damit diese Information für alle ersichtlich ist.

Redaktionelle Aspekte

Einige wesentliche Anforderungen an digitale Barrierefreiheit wie Klarheit und Struktur sind nur durch die Redaktion selbst erfüllbar. Formulierungen sollten beispielsweise aussagekräftig und verständlich sein. Verschachtelte Sätze und Abkürzungen sollen vermieden werden. Tabellarische Darstellungen sollen übersichtlich aufbereitet werden.

Die angesprochenen Aspekte werden in den nachfolgenden Kapiteln im Detail erklärt.

Welche strukturellen Vorbereitungen sind nötig?

Textliche Inhalte ohne Gliederung oder Formatierung sind häufig schwerer lesbar und erfassbar. Elemente wie Überschriften, Absätze, Listen, Tabellen und Zitate strukturieren einen Text und erleichtern dessen Aufnahme sowie die Wiedergabe durch assistierende Technologien.

Für eine übersichtliche und barrierefreie Strukturierung sind insbesondere die folgenden Punkte wichtig:

Überschriften

Überschriften sind dann barrierefrei, wenn diese hierarchisch korrekt auf einer Seite verwendet werden. Im Idealfall gibt es eine Hauptüberschrift <h1>, die als Beschreibung der jeweiligen Seite dient. Danach folgen Zwischenüberschriften wie <h2> und weitere Überschriften. In HTML stehen insgesamt sechs Überschriftenebenen zur Verfügung (<h1> bis <h6>).

Im Detail nachzulesen sind die Vorgaben zum Erfolgskriterium „Heading and Labels“ auf der Website der Web Accessibility Initiative (WAI) (externer Link).

Eine gute Überschriftenstruktur ermöglicht nicht nur sehenden Personen ein schnelleres Erfassen der Hauptthemen einer Seite. Auch blinde Personen sowie Personen mit einer Sehbehinderung „screenen“ häufig schnell den Seiteninhalt, indem sie sich die Überschriften vorlesen lassen oder von Überschrift zu Überschrift springen, um einen ersten inhaltlichen Überblick zu erhalten.

Gut erfassbare Überschriften sollten klar und aussagekräftig formuliert sein. Nutzer:innen erhalten dadurch informative Anhaltspunkte, welche konkreten Inhalte darunter zu finden sind.

Beispiel einer hierarchisch korrekten Überschriftenstruktur:

Folgende Punkte sollten bei der Erarbeitung einer korrekten Überschriften-Hierarchie beachtet werden:

• Die <h1> muss nicht zwangsläufig die erste Überschrift sein. Es können davor Überschriften anderer Ebenen vorkommen. (Siehe Beispiel 2 im Headings Tutorial von W3C (externer Link)).
• Im besten Fall wird auf jeder Seite eine <h1> verwendet.
• Die Verwendung mehrerer <h1> sollte eher vermieden werden. Wenn dennoch mehrere <h1> benötigt werden, ist auf strukturelle und inhaltliche Sinnhaftigkeit zu achten. Wie Überschriften von Nutzer:innen wahrgenommen werden, zeigt die Screen Reader User Survey #7 von WebAIM (externer Link).
• Es ist auch möglich, die Überschrift <h1> dem Titel der Seite anzupassen, erforderlich ist es jedoch nicht.
• Ist aus Designgründen keine visuelle Überschrift gewünscht, lässt sich trotzdem eine sr-only-Überschrift einfügen, damit Nutzer:innen von Sprachausgaben den Bereich ansteuern können. Diese Überschrift ist dann nur für Screenreader sichtbar. Damit ist es möglich, Inhalte visuell zu verstecken, aber trotzdem bleiben sie für Screenreader ansteuerbar.

Listen

Listen dienen zur Darstellung von Aufzählungen, Verzeichnissen und Strukturen. Redaktionell erlaubt fast jeder „What You See Is What You Get (WYSIWYG)“-Editor das Einfügen verschiedener Arten von Listen. Beim Erstellen von Listen ist es daher empfehlenswert, die jeweiligen Methoden des CMS/WYSIWYG-Editors zu verwenden.

Tipp: Listen eignen sich gut, um Inhalte barrierefrei zu strukturieren, aber nur, wenn diese nicht zu tief verschachtelt werden (maximal drei Hierarchie-Ebenen). Ansonsten wird der Inhalt für Nutzer:innen, die diesen nicht visuell wahrnehmen können, unübersichtlich.

Weiterführende Informationen zum Erfolgskriterium „Listen“ finden sich auf der Website der Web Accessibility Initiative (WAI) (externer Link).

In HTML gibt es mehrere Arten von Listen:

• Geordnete Liste (<ol><li></li></ol>)
• Ungeordnete Liste (<ul><li></li></ul>)
• Definitionsliste (<dl><dt></dt><dd></dd><dd></dd></dl>)

Der Klassiker unter den Listen ist die ungeordnete Liste, die in der Regel als Auflistung mit „Bullet Points“ dargestellt wird. Diese Liste wird redaktionell verwendet, um einzelne, inhaltlich zusammenhängende Informationen zu präsentieren.

• Beispiel ungeordnete Liste (z. B. Suchmaschinen)
  • Google
  • Bing
  • DuckDuckGo

Die geordnete Liste kommt zum Einsatz, wenn die Reihenfolge der gelisteten Information wesentlich ist.

• Beispiel geordnete Liste (z. B. Verbreitung von Suchmaschinen)
  1. Google
  2. Bing
  3. DuckDuckGo

Die Definitionsliste wird häufig verwendet, um Begriffe mit erklärenden Beschreibungen in Zusammenhang zu bringen, etwa in einem Glossar.

• Beispiel Definitionsliste (z. B. Beschreibung von Begriffen)

  WCAG (dt)
      Web Content Accessibility Guideline (dd)
      Zugänglichkeitsrichtlinien für Webinhalte (dd)

  WAI (dt)
      Web Accessibility Initiative (dd)

Tabellen

Tabellen dienen der übersichtlichen Darstellung von Daten. In vielen WYSIWYG-Editoren können Tabellen ähnlich wie in Word eingefügt werden.

Für einen korrekten Tabellenaufbau sind folgende Punkte wichtig:

• Die erste Tabellenzeile sollte immer mit dem Element <th> ausgezeichnet werden und die dazugehörige Spalte beschreiben.
• Für das Einfügen der Tabellenüberschrift wird das Caption-Element genutzt.
• Die inhaltliche Struktur einer Tabelle sollte einfach und klar gehalten werden – komplexe Tabellen-Verschachtelungen daher vermieden oder die Inhalte zur besseren Erfassbarkeit auf mehrere Tabellen aufgeteilt werden.
• Leere und verbundene Zellen sollten vermieden werden.

Tipp: Einfach strukturierte Tabellen können zumeist problemlos über WYSIWYG-Editoren erstellt werden. Sollte ein komplexerer Tabellenaufbau notwendig werden, bieten die Informationen des Tables Tutorial der Website der Web Accessibility Initiative (WAI) (externer Link) eine gute Hilfestellung.

Beispiel einer einfach strukturierten Tabelle:

HTML Code der Beispiel-Tabelle:

Zitate

Damit Zitate von Sprachausgaben erkannt werden können, sollen die passenden HTML-Elemente eingesetzt werden. Assistierende Technologien können den Nutzer:innen dann die Information geben, wo ein Zitat beginnt und wo es endet.

Die Kennzeichnung eines Zitats zeigt auf, dass der Inhalt anderen Autor:innen zugeschrieben wird. Zitate können als Inline-Zitate oder als Textblöcke gekennzeichnet werden.

Tipp: Für das Zitieren ist jedenfalls die Textblock-Variante zu bevorzugen.

Beispielcode eines Textblock-Zitates:

Darstellung des Beispielcodes des Textblock-Zitates:

Das Folgende ist ein Auszug aus der Geschichte meines Lebens von Helen Keller

Schon in den Tagen, bevor meine Lehrerin kam, tastete ich mich an den quadratischen, steifen Buchsbaumhecken entlang und entdeckte …

Im Tutorial-Bereich „Quotes“ der Web Accessibility Initiative (WAI) (externer Link) finden sich ergänzende Beispiele einer korrekten Zitat-Auszeichnung.

Wie werden Links richtig definiert?

Links sind dann barrierefrei, wenn sie für sich allein aussagekräftig sind. Nutzer:innen, die den Inhalt nicht visuell wahrnehmen, tabben auf einer Website häufig von Link zu Link. Kommt der Tab-Fokus auf einen Link, sollte das Linkziel durch den Linktext klar erkennbar sein.

In den WCAG ist die Verwendung von Links unter anderem in folgendem Punkt erklärt:

2.4.4 Linkzweck im Kontext (Level A) (externer Link): Der Zweck jedes Links kann durch den Linktext allein oder durch den Linktext zusammen mit seinem durch Software bestimmten Link-Kontext definiert werden – außer bei Verlinkungen, in denen der Zweck des Links mehrdeutig für Nutzer:innen im Allgemeinen wäre.

Links wie beispielsweise „Informationen zu WCAG finden Sie hier“ oder „Mehr zur WCAG“ sind nicht zu empfehlen. Besser wäre hier, WCAG mit in den Link zu nehmen, beispielsweise in Form von „Informationen zu den WCAG“. Sogenannte „sprechende Links“ erklären den Linkzweck und sind für sich aussagekräftig, wenn sie von assistierenden Technologien vorgelesen werden.

Um Benutzer:innen mobiler Geräte entgegenzukommen, ist es auf Websites empfehlenswert, Telefonnummern und E-Mail-Adressen als solche zu kennzeichnen. Bei Verlinkungen sollten daher die richtigen Attribute verwendet werden – und zwar „tel“ bei Telefonnummern und „mailto“ bei E-Mail-Adressen. Dadurch werden diese von Hardware-Geräten erkannt und die dazugehörige Applikation wie zum Beispiel das Telefonbuch oder das Mailprogramm aufgerufen.

Beispielcode einer korrekten Verlinkung für Telefonnummer und E-Mail-Adresse:

Die Schreibweise des Linktextes für Telefonnummern orientiert sich an der im Corporate Wording definierten Vorgehensweise.

Weitere hilfreiche Tipps für die Definition von Links:

• Externe Links in einem neuen Fenster (target="_blank") mit dem Titelattribut des Link-Elements (title="Link in neuem Fenster") kennzeichnen.
• Bei Verlinkung auf Dateien im Linktext oder wiederum im Titelattribut des Link-Elements (title="PDF, 20 KB") das Format darstellen (oder generell eine Info, dass es sich um eine Datei handelt).
• Bei Verwendung von zusammengehörigen Bildern und Text, die das gleiche Linkziel haben – etwa bei Teasern, etc. – einen einzelnen gemeinsamen Link um die Elemente setzen anstatt mehrerer einzelner Links. Ergänzende Informationen finden sich dazu in den WCAG Techniques der Web Accessibility Initiative (WAI) (externer Link).
• Wird ein Bild verlinkt (ohne weiteren Linktext), jedenfalls das Linkziel in der alternativen Bildbeschreibung angeben (oder zum Beispiel im Titelattribut des Links) – damit klar ist, wohin man gelangt, wenn man den Link aktiviert.
• Bei der Linkbezeichnung über eine Seite hinweg möglichst konsistent mit dem Linkziel sein. Zwei gleichlautende Links mit unterschiedlichen Linkzielen sind nach Möglichkeit zu vermeiden. Umgekehrt sind auch zwei unterschiedlich lautende Links mit gleichem Linkziel nicht ideal.

Welche sprachlichen Kriterien sind zu beachten?

Klare und aussagekräftige Formulierungen sind wesentliche Merkmale, um Inhalte zugänglich zu machen. Hier finden Sie eine kurze Darstellung, welche Möglichkeiten es gibt, die digitale Barrierefreiheit durch Sprache zu verbessern.

Je nach Zielgruppe der Website kann überlegt werden, die Inhalte in „einfacher Sprache“ oder zusätzlich in „leichter Sprache“ anzubieten. Die Richtlinie der Europäischen Kommission über den barrierefreien Zugang zu Websites und Apps öffentlicher Stellen schreibt „einfache“ oder „leichte Sprache“ allerdings nicht vor, da es sich hierbei um ein AAA-Kriterium der WCAG handelt.

Einfache Sprache

„Einfache Sprache“ ist eine sprachlich vereinfachte Version der Standardsprache oder Fachsprache. Der Sprachstil ist einfacher, klarer und verständlicher. Dieser Stil wird bei einigen Websites – beispielsweise bei öffentlichen Stellen – als Standard der Inhaltsdarstellung verwendet. Dieser Stil richtet sich an weite Teile der Bevölkerung und weniger an spezifische Zielgruppen.

In den WCAG ist die Verwendung von einfacher Sprache vor allem in folgendem Erfolgskriterium beschrieben:

3.1.5 Leseniveau (Level AAA) (externer Link): Wenn der Text nach der Entfernung von Eigennamen und Titeln Lesefähigkeiten voraussetzt, die über das Niveau der niedrigen, sekundären Schulbildung hinausgehen, dann braucht es ergänzenden Inhalt oder eine Version, die keine über die niedrige, sekundäre Schulbildung hinausgehenden Lesefähigkeiten verlangt.

Dieser Punkt der WCAG kann auf mehrere Arten erfüllt werden, etwa durch die „Bereitstellung einer gesprochenen Version des Textes“ (also beispielsweise eines Vorlese-Services) oder eben durch die Bereitstellung des Textes in einer einfacheren Sprache. Für weiterführende Informationen siehe die Techniques der Web Accessibility Initiative (WAI) für das Verfassen eines Textes in „einfacher Sprache“ (externer Link).

Leichte Sprache

Es handelt sich um eine besonders geregelte „einfache Sprache“. Sie richtet sich an Menschen, die aus unterschiedlichen Gründen über eine geringe Kompetenz in der deutschen Sprache verfügen. „Leichte Sprache“ richtet sich somit an Personen einer klar definierten Zielgruppe, etwa Menschen mit Lernbehinderung, Personen mit nicht-deutscher Muttersprache, einer niedrigen Lesekompetenz etc. Sie kann als vereinfachte Form der „einfachen Sprache“ gesehen werden.

Verwendet werden häufig sehr kurze Sätze und Illustrationen, komplizierte Wörter oder Satzstellungen werden vermieden. In der Praxis wird bei einigen Websites über einen „Leseniveau-Wechsler“ die „leichte Sprache“ zusätzlich zur Standardsprache angeboten.

Um das Verfassen von Texten in „leichter Sprache“ zu erlernen, werden von unterschiedlichen Institutionen oder Agenturen Kurse angeboten. Es werden auch Übersetzungsservices angeboten.

Sprachbezogene WCAG-Kriterien

In den WCAG-Richtlinien finden sich weitere auf die Sprache bezogene Kriterien, deren Umsetzung die digitale Barrierefreiheit verbessern:

• Sprachwechsel (3.1.2 Language of Parts – Level AA) (externer Link)
  Wenn es einen Wechsel in der Sprache des Inhalts gibt, die betreffenden fremdsprachigen Passagen mit lang= auszeichnen. Damit wird der Inhalt von Sprachausgaben (z. B. Screenreadern) mit der richtigen Betonung wiedergegeben.
  Beispiel: <span lang="en">English Content</span>
• Abkürzungen (3.1.4 Abbreviations – Level AAA) (externer Link)
  Wenn Abkürzungen im Inhalt verwendet werden, dann beispielsweise textlich oder über das Element <abbr title=""> definieren. Damit wird der Inhalt verständlicher.
  Beispiel textlich: FFG (Öster­reich­ische Forschungs­förderungs­gesellschaft)
  Beispiel abbr: <abbr title="Österreichische Forschungsförderungsgesellschaft">FFG</abbr>
• Sensorische Informationen (1.3.3 Sensory Characteristics – Level A) (externer Link)
  Angabe von sensorischen Informationen im Inhalt vermeiden, wie zum Beispiel: „Klicken Sie auf den grünen Kreis“. Besser eine ergänzende oder neutrale Formulierung wählen, um Personen nicht auszuschließen bzw. um eine für alle verständliche Erklärung anzubieten. Eine ergänzende Formulierung zum obigen Beispiel könnte sein: „Klicken Sie auf den grünen Kreis mit der Bezeichnung ‚Abschicken‘“.

Bilder

Eine wichtige Anforderung an die Barrierefreiheit ist die inhaltliche Beschreibung von Bildern und anderen „Nicht-Text-Elementen“. Dieser sogenannte Alternativtext wird Nutzer:innen, die Bilder nicht visuell wahrnehmen können, über eine Sprachausgabe vorgelesen.

Die Verwendung von Alternativtexten ist zudem empfehlenswert, da diese von Suchmaschinen interpretiert werden können und somit zu besseren SEO-Ergebnissen führen.

In den WCAG ist die Verwendung von Bildern und weiteren „Nicht-Text-Inhalten“ vor allem in folgendem Punkt geregelt:

Nicht-Text-Inhalt (Level A) (externer Link): Alle Nicht-Text-Inhalte, die Nutzer:innen gezeigt werden, haben eine Textalternative, die denselben Zweck erfüllt – also die Informationen, die mit den Nicht-Text-Inhalten vermittelt werden sollen, in Textform transportiert. Erläuternde Informationen zu diesem Erfolgskriterium finden sich auf der Website der Web Accessibility Initiative (WAI) (externer Link).

Viele „Nicht-Text-Elemente“ im Sinne von Interaktionselementen werden in Anwendungen häufig über das Rahmen-CMS verwaltet (Icons, Pfeile, Buttons etc.). Auf diese Funktionen haben Redakteur:innen jedoch häufig keinen Zugriff.

Bilder im Inhaltsbereich einer Web-Anwendung können zumeist schon redaktionell beschrieben werden. Technisch wird dies über das „alt Attribut“ (Alternativtext) des Bildelements (<img src="bild1.jpg" alt="bildbeschreibung" ... >) oder den weiteren Fließtext auf der Seite festgelegt.

Redaktionelle Hinweise für die Vorbereitung und Verwendung eines Alternativtextes:

• Der Alternativtext ist das möglichst genaue Äquivalent zum Inhalt bzw. zur Information, die das Bild transportieren soll.
• Die alternative Bildschreibung sollte möglichst kurz und prägnant sein. Wenn eine Beschreibung mehr Textlänge benötigt, wird diese besser in den Fließtext der betreffenden Seite verlegt.
• Der Alternativtext wird kontextabhängig eingesetzt. Dieser kann sich somit bei ein- und demselben Bild unterscheiden (siehe nachfolgendes Beispiel unter Unterschiedlicher Kontext).
• Es braucht keine Einleitung der Bildbeschreibung wie „Bild:“ oder „Foto:“. Diese Information erkennen assistierende Technologien automatisch.

Technische Hinweise für die Vorbereitung und Verwendung eines Alternativtextes:

• Das Alternativattribut (alt=) eines Bildes (<img>) muss immer zugewiesen sein.
• Bei Bildern, die zu rein dekorativen Zwecken eingesetzt werden (Schmuckbildern), ist das Alternativattribut leer (alt=""). Damit wird es von Sprachausgaben automatisch übersprungen.
• Wenn im Bild Text vorkommt, wird dieser Text auch im Alternativtext angegeben. Sofern möglich, ist Textinformation in Bildern zu vermeiden, da Text in Bildern schlecht wahrnehmbar sein kann (weil er z. B. schwieriger vergrößert dargestellt werden kann).
• Bei Font Icons ist (wenn im jeweiligen Projekt redaktionell möglich) darauf zu achten, ob diese dekorativen oder informativen Inhalt haben. Je nachdem, ob Erstes oder Zweites zutrifft, wird das Font Icon mittels aria-hidden ausgeblendet und/oder mittels sr-only-Text (Style, um Text nur für Sprachausgaben darzustellen) ergänzt. Ergänzende Informationen dazu finden sich auf der Website von Font Awesome (externer Link).
• Redundanzen (mit Titelattribut und Kontexttext) sind zu vermeiden. Im folgenden Beispiel würde der Beschreibungstext, je nach assistierender Technologie, bis zu dreimal gelesen werden: <img src="bild.jpg" alt="Bildbeschreibung" title="Bildbeschreibung"/><p>Bildbeschreibung</p>
  In diesem Fall sollte idealerweise nur das Alternativattribut oder die Beschreibung im Fließtext bleiben.
• Wenn Bilder verlinkt werden, wird auf das Linkziel des Links verwiesen und nicht der Inhalt des Bildes selbst beschrieben. Dieser Schritt kann beispielsweise auch im Titelattribut des Linkelements durchgeführt werden.

Tipp für komplexere Bilder wie Infografiken oder Diagramme:

• Diese brauchen in der Regel auch einen beschreibenden Alternativtext. Hier kommt es besonders auf die technologischen Rahmenbedingungen der Anwendung an. Redaktionell könnte beispielsweise eine äquivalente alternative Darstellung zu Infografik/Diagramm als Text auf der Seite eingebunden werden. Ergänzende Informationen dazu finden sich auf der WCAG-Infoseite unter 5.2.1 Conformance Level (externer Link).

Beispiel: Unterschiedlicher Kontext

Der Alternativtext wird kontextabhängig eingesetzt. Bei ein und demselben Bild ist eine inhaltlich unterschiedliche Verwendung möglich.

• Das obige Symbolbild könnte sich auf einer Mitarbeiter:innenseite einer Unternehmenswebsite befinden und den Alternativtext alt="Thomas Mustermann" haben. Dieser Alternativtext wäre für die Verwendung angemessen. Wenn der Name des Mitarbeiters auch zusätzlich zum Bild als Text verfügbar ist, könnte auch ein leerer Alternativtext (alt="") passend sein, um Redundanzen zu vermeiden.
• Sollte das gleiche Bild hingegen auf einer Website für Mode vorkommen, braucht es einen Alternativtext mit Informationen zum Styling der Person – also die Beschreibung des Outfits, der Haare etc. Ist eine längere Beschreibung nötig, dann wäre es besser, die alternative Bildbeschreibung im Fließtext der betreffenden Seite vorzunehmen. Im Alternativattribut reicht in diesem Fall dann ein kurzer Text wie beispielsweise: alt="Mann mit schulterlangen Haaren und Strickpullover".

Beispiel: Beschreibung von komplexen Bildern oder grafischen Elementen

Beim Einsatz von komplexen Bildern wie beispielsweise Charts oder Organigrammen ist es zumeist nicht zielführend, die gesamte Beschreibung des Bildes im Alternativattribut zu platzieren.

• Hier wäre eine kurze Beschreibung im Bild vorzuziehen wie beispielsweise „Liniendiagramm XXX der Städte Wien, Linz, Graz und Salzburg“. Die ausführliche inhaltliche Beschreibung sollte wiederum im Fließtext der betreffenden Seite (oder in einer verlinkten anderen Seite) platziert werden.
• Bei einem Diagramm ist es eine gute inhaltliche Alternative, eine semantisch korrekte Tabelle (siehe Kapitel Tabellen) der Daten des Diagramms anzubieten.

Beispiel einer Tabelle als inhaltliche Alternative:

Audio

Bei der Gestaltung von Audioinhalten sollten folgende Punkte berücksichtigt werden:

• Die Qualität der Tonspur sollte so hoch wie möglich sein. Hintergrundgeräusche sollten vermieden werden.
• Es ist empfehlenswert, Menschen genügend Zeit zu geben, Informationen zu verarbeiten. Daher sollten ausreichend Pausen in der inhaltlichen Struktur eingehalten werden.
• Vermeiden Sie Akronyme und Redewendungen bei der Konzeption von Audioinhalten. So können beispielsweise Ausdrücke wie „die Messlatte hochlegen“ von manchen Menschen mit kognitiven Behinderungen wörtlich interpretiert werden und verwirrend sein.
• Ergänzende Informationen dazu finden sich auf der entsprechenden WCAG-Infoseite betreffend Audio Content (externer Link) und in der Anleitung Multimedia-Inhalte.

Video

Bei der Produktion von Videos ist auf folgende Punkte zu achten:

• Um bei betroffenen Personen Krampfanfälle zu verhindern, gilt als Grundsatz, Aufnahmen und Animationen zu vermeiden, bei denen Blinken oder Blitzen (mehr als dreimal innerhalb einer Sekunde) vorkommen.
• Manche Menschen nutzen Mundbewegungen, um gesprochene Sprache besser zu verstehen. Achten Sie daher bei Videoaufnahmen bestmöglich darauf, das Gesicht der Sprecher:innen gut sichtbar zu zeigen und zu beleuchten.
• Untertitel (1.2.2 Video Captions – Level A) (externer Link)
  Aufgezeichnete Videos benötigen Untertitel, die der Audiospur des Videos entsprechen. Bei manchen Videoanbietern (wie z. B. YouTube) ist die Erstellung von Untertiteln relativ einfach möglich.
  Weiterführende Informationen finden sich in der Anleitung Multimedia-Inhalte.
• Video Transkript (1.2.3 Audio Description or Media Alternative – Level A (externer Link)) bzw. Audiodeskription (1.2.5 Audio Description – Prerecorded – Level AA (externer Link))
  Für relevante rein visuelle Videoinhalte eine Audiodeskription oder ein Transkript bereitstellen.
  Um alle inhaltlich relevanten visuellen Informationen aus einem Video auch über einen zusätzlichen Kanal zu vermitteln, kann darauf geachtet werden, dass diese auch im Sprecher:innen-Text wiedergegeben werden. Dann ist unter Umständen keine zusätzliche Audiodeskription nötig. Falls das Video generell eine Alternative für einen vorhandenen Text ist und als solche gekennzeichnet ist, ist keine Audiodeskription nötig.
  Weiterführende Informationen finden sich in der Anleitung Multimedia-Inhalte.
• Ergänzende Informationen dazu finden sich auf der entsprechenden WCAG-Infoseite betreffend Video Content (externer Link) und in der Anleitung Multimedia-Inhalte.

Wie kann digitale Barrierefreiheit geprüft werden?

Automatisierte Tools und Evaluierungstools

Automatisierte Tools können nicht alle Barrierefreiheits-Probleme erkennen. Sie helfen aber dabei, mit geringem Aufwand auf automatisiert erkennbare Fehler aufmerksam zu werden.

Warum braucht es eine Barriere­freiheits­erklärung?

Auf allen Websites und Apps des Bundes und der ihm zuordenbaren Einrichtungen und der Bundesländer muss eine Barrierefreiheitserklärung veröffentlicht werden.

Generell ist zu empfehlen, bei allen Anwendungen Barrierefreiheitserklärungen aufzubereiten. Dadurch bietet sich ein guter Überblick über den Status der Zugänglichkeit einer Website.

Diese Erklärung soll detailliert, umfassend und klar sein. Wichtig sind auch eine regelmäßige, zumindest einmal jährliche Überprüfung und Aktualisierung.

Inhaltliche Bestandteile der Erklärung sind:

• Stand der Vereinbarkeit mit den Anforderungen
• Nicht barrierefreie Inhalte (sofern vorhanden)
• Angaben zur Erstellung der Barrierefreiheitserklärung
• Feedback und Kontaktangaben
• Durchsetzungsverfahren

Teil der Barrierefreiheitserklärung ist die Möglichkeit einer Kontaktaufnahme. Dies ist hilfreich, um Feedback zu erhalten und dadurch die Anwendungen stetig verbessern zu können.

Tipp: Als Hilfestellung gibt es Vorlagen für eine Mustererklärung in Deutsch und eine Mustererklärung in Englisch.

Wichtig für die Veröffentlichung der Erklärung:

Veröffentlicht werden muss die Barrierefreiheitserklärung über die Startseite einer Website und zusätzlich über jede Unterseite. Dies kann beispielsweise über einen Link in einer statischen Kopf- oder Fußzeile erfolgen.

Bei Apps ist die Barrierefreiheitserklärung auf der Website des Rechtsträgers, der diese entwickelt oder deren Entwicklung beauftragt hat, zu veröffentlichen. Als Alternative kann die Erklärung auch im Zuge des Downloads der Apps abgerufen werden.

Die gesetzlichen Grundlagen einer Barrierefreiheitserklärung sowie weitere Details finden sich als Informationssammlung unter „Barrierefreiheitserklärung“.