Index

Text und Formatierung

WordPress und die bereitgestellten Themes bieten umfangreiche Möglichkeiten zur Textgestaltung. Erfahren Sie auf den folgenden Seiten, wie Sie Tabellen, Listen und mehr einbinden können. Folgende Elemente stehen Ihnen dabei zur Auswahl:

  • Überschriften (H1 – H6)
  • Absätze
  • ein Standardsatz an Formatierwerkzeugen
  • Bilder, Bildgalerien, Bilder & Text
  • Tabellen
  • Zitationen
  • Links
  • Menüs
  • dynamisch erzeugte Inhalte
  • Inhalte aus Drittsystemen (wie bspw. UnivIS, CRIS, dem Videoportal und anderen)

Diese Elemente können Sie sowohl auf Seiten, als auch Beiträgen einbinden. Wie diese Inhalte dabei aussehen, hängt mit dem jeweiligen Theme und dem zugrunde liegenden Corporate Design zusammen.

Medien

Erfahren Sie auf den folgenden Seiten, wie Sie Bilder in die Mediathek hochladen und diese verwalten, und wie Sie Bilder und Galerien auf Inhaltsseiten einbinden können.

Kurzanleitung zur Verbesserung der digitalen Barrierefreiheit in Dokumenten aus Büroanwendungen

Wenn die Aufgabe besteht, alte Word- und PDF-Dokumente gemäß den Anforderungen der Barrierefreiheit zu korrigieren oder neue Dokumente zu erstellen, sollten folgende Maßnahmen berücksichtigt werden.

Neue Dokumente mit Textverarbeitungssoftware erstellen (MS Word, Libre Office, LaTeX)

Hierauf ist zu achten:

  • Stets Absatz- und Formatvorlagen verwenden (insbesondere „Überschrift 1“ bis „Überschrift 6“)
  • Formatierungen für Aufzählungen und Nummerierungen verwenden
  • Mehrere Leerzeilen und Leerzeichen hintereinander vermeiden.
  • Visuelle Objekte (Bilder, Grafiken, Logos, …), die inhaltlich relevant sind (keine Schmuckbilder), mit Alternativtext versehen
  • Einfache Tabellenstruktur verwenden und einfache Spaltenüberschriften wählen
  • Auf gute Kontraste für Text- und Hintergrundfarben sowie ausreichende Schriftgröße (mindestens 11 Pt) achten.
  • Möglichst aussagekräftige Linktexte verwenden und QuickInfos hinterlegen
  • Einen Titel sowie die Sprache für das Dokument hinterlegen
  • Eine integrierte Überprüfung der Barrierefreiheit wird speziell in MS Word angeboten, allerdings von Version zu Version unterschiedlich gehandhabt.
    Über den Menüpunkt „Hilfe“ lässt sich in MS Word mittels Suchfunktion die Suche nach „Barrierefreiheit überprüfen“ anzeigen und aktivieren.

Altdokumente im PDF-Format

Pragmatischer Umgang mit alten PDF-Dokumenten (ohne Zugriff auf das Word-Original):

Alte PDF-Dokumente, für die kein Original vorhanden ist, werden standardmäßig

  • nicht nachträglich als PDF bearbeitet, um sie barrierefrei anzulegen
  • und nicht nachträglich als Worddokument angelegt, um daraus erneut ein PDF zu erzeugen,
  • diese Vorgehensweise würde großen Aufwand erfordern.

 

Empfohlen wird hier stattdessen

  • alle relevanten Inhalte auszuwählen und zu kopieren, um sie in eine neu angelegte Webseite einzufügen;
  • zusätzlich müssen ggf. Überschriften korrigiert und Bilder/Grafiken mit Beschreibungen oder Alternativtexten versehen werden.
  • Im Word-Original lediglich die Überschriften sowie Bilder und Grafiken anpassen und es anschließend zusätzlich zum (neu erstellten) PDF bereitstellen.
Anmerkung: Da auch PDF-Inhalte durch Dritte weiterverwendet werden können, bietet das PDF-Format gegenüber Word keinen höheren Schreibschutz vor Missbrauch von Inhalten. Die oft verbreitete These, man müsse Inhalte als PDF bereitstellen, um sie vor Manipulation zu schützen, ist falsch.

Umgang mit großen PDF-Dokumenten (erstellt mit Adobe InDesign oder Scribus)

  • Alle Maßnahmen für Dokumente, die mit Textverarbeitungssoftware erstellt wurden, gelten auch hier.
  • Das RRZE empfiehlt andernfalls zur Nachbearbeitung umfangreicher PDF-Dokumente externe Agenturen.

„Web first“

Diese Maxime besagt, dass Dokumente so anzulegen sind, dass sie die Vorgaben zur Barrierefreiheit im Web einhalten; Layoutwünsche, die sich an einer Printveröffentlichung orientieren, sind zu vernachlässigen.

  • Inhalte sind dadurch besser auffindbar (auch durch Suchmaschinen).
  • Inhalte sind auf mobilen Endgeräten besser lesbar, da sich die Ausgabe an die Größe des Bildschirms anpassen lässt.

Weitere Leitfäden und relevante Informationsangebote

Digitale Barrieren melden

Für Webseiten

Social-Media-Kanäle

Erstellung von Dokumenten aus Büroanwendungen (PDF, Office, u.a.)

Erstellung von Vorlesungs- und Lehrmaterialien

Erstellung von multimedialen Produktionen (Videoaufzeichnungen, Podcasts, u.a.)

Weitere Leitfäden und Informationen zur Barrierefreiheit

Rechtliche Anforderungen

Tests der Barrierefreiheit

Dieses Kapitel soll eine schnelle Hilfe und Übersicht zur Prüfung der Barrierefreiheit geben.

Schnelle „Jedermann“-Sichtprüfung

Hinweis: Die in diesem Kapitel aufgeführten Methoden ersetzen keinesfalls einen durch Experten durchgeführten WCAG-Test. Die Methoden sollen nur eine Möglichkeit aufzeigen, damit auch technisch und sachlich nicht vertraute Menschen zu einer schnellen Grundsatzaussage kommen.

Folgende Methoden und Test sind bei dem Besuch einer Seite durchzuführen:

  1. Maus weg!

    Erreiche ich jede Seite? Jede Ebene der Navigation? Sehe ich das aktive Element deutlich und genauso wie wenn ich mit der Maus drüber fahre?

  2. Seite mit dem Handy aufrufen!

    Jeder Inhalt und jede Aktion muss auch mit dem Handy ausführbar sein. Dabei muss die Webseite nicht die selbe Optik haben wie eine Bildschirmseite auf einem großen Monitor. Eine Seite sollte auf einem Smartphone auch bzgl. Reihenfolge und Anordnung von Seitenelementen auf die kleine Auflösung optimiert sein. Zudem lässt sich feststellen, ob sämtliche Elemente auch durch Touch-Bedienung erreichbar sind.

  3. Die Schrift auf 200% vergrößern!

    Ist noch alles nutzbar und erkennbar? Kommt es zur Überlagerung von Inhalten, so dass diese nicht mehr erreicht oder gelesen werden können?

  4. Enthaltene Bilder prüfen.

    Enthält eine Seite Bilder? Sind diese Bilder informativ und sind die Inhalte auch im Text vorhanden? Wird auf das Bild im Text Bezug genommen?

  5. Seite auf einem Drucker im Schwarz-Weiß-Modus ausdrucken.

    Gibt es Inhalte, die nicht les- oder erkennbar sind? Und: Sieht die Seite gedruckt genauso aus, wie auf dem Bildschirm? Ist nach dem Ausdruck noch immer ein Menü vorhanden?

  6. Bewegung, Töne, Videos checken!

    Bewegt sich etwas? Gibt es ein „Carousel“, also einen Bereich in dem Artikel und Bilder von selbst eingeblendet werden. Enthält die Seite sich bewegenden oder wechselnden Content? Wird beim Aufruf der Seite ein Video unaufgefordert abgespielt? Kann ich das Video stoppen – auch ohne Maus?

  7. Tabellen prüfen.

    Zur Prüfung einer vorhandenen Tabelle ist das Browserfenster zu verkleinern oder die Seite mit einem Handy aufzurufen. Lassen sich die Inhalte der Tabelle noch lesen, ohne einen Scrollbalken nach rechts bedienen zu müssen?

Sollte eine oder mehrere der obigen Situationen Probleme aufzeigen, ist die Zugänglichkeit der Seite nicht vollständig gegeben. Es ist in diesem Fall davon auszugehen, dass keine Konformität zur WCAG vorliegt.

Das W3C selbst bietet ebenfalls einen Schnelltest an: Easy Checks – A First Review of Web Accessibility. Dieser ist etwas aufwendiger als oben aufgeführte Punkte und ebenfalls noch keine vollständige Prüfung.

Ein weiterer Schnelltest beschreibt Kerstin Probiesch in ihrem Artikel Schnelltest zur Barrierefreiheit auf Webkrauts.de.

Ebenfalls hilfreich für eine schnelle Überprüfung und zur Vermeidung technischer Fehler ist die Anwendung Accessibility Insights. Diese ermöglicht neben der Prüfung von Webseiten auch die Überprüfung von Software.

Prüfung zur Konformität zur WCAG

Das W3C hat eine eigene Seite zur Evaluierung der Barrierefreiheit eingerichtet: Unter Test & Evaluate erhält man einen Überblick über verschiedene Testmethoden, Werkzeugen und weiterführende Informationen. Hierzu gehört auch eine umfangreiche Sammlung an Werkzeugen, die auf der Seite Web Accessibility Evaluation Tool List angeboten wird. Die Sammlung ist entsprechend der Anforderungen und des zu testenden Angebots sortier- und filterbar.

Eine vollständige Prüfung über die Einhaltung der WCAG kann mit Hilfe der Accessibility Conformance Evaluation Methodology (WCAG-EM) erfolgen. Die WCAG selbst definiert bereits durch die Erfolgskriterien und die Konformitätsbedingungen, wie man einzelne Seiten auf Barrierefreiheit prüft. Was jedoch durch die WCAG nicht geleistet wird, ist eine Wertung der Ergebnisse. So lässt sich ein Webauftritt anhand von einzelnen Punkten aus der WCAG nicht pauschal einordnen. Dies wird durch die Methode geleistet, die durch die WCAG-EM vorgegeben wird. Die WCAG-EM beschreibt das Best-Practice-Vorgehen zur Prüfung von Webangeboten, zur Definition des Testumgangs, der Auswahl von Stichproben und zur Berichterstattung.

Die WCAG-EM besteht aus 5 Teilen:

Schemagrafik zur Auswahl des Umfangs einer Evaluation

  1. Festlegung des Bewertungsumfangs
  2. Sichtung der zu bewertenden Webauftritts
  3. Festlegung eines repräsentativen Seitenauswahl
  4. Prüfung der Seitenauswahl
  5. Erstellung des Gutachtens

Die WCAG-EM bietet Hilfestellung und Empfehlungen zu jedem der genannten Schritte. Eine Zusammenfassung findet sich auch in der Dokumentation von Jan Hellbusch auf der Seite Konformität nach den Web Content Accessibility Guidelines 2.0.

Ein sehr nützliches Hilfsmittel bietet das WCAG-EM Report Tool.

Screenshot WCAG-EM Report Tool

Hierbei handelt es sich um ein Online-Tool in dem alle 5 Schritte abgebildet werden können. Interaktive Eingabefelder und Auswahllisten unterstützen den Prüfer in diesem Werkzeug bei der Evaluation und erlauben es am Ende des Prozesses eine Vorlage für ein Gutachten zu erstellen. Die Vorlage kann in den Formaten HTML oder JSON exportiert, aber auch für die spätere Weiterbearbeitung gespeichert werden.

Nachweis gemäß der Europäischen Norm EN 301 549 V2.1.2

Für Webanwendungen wird Konformität mit den Barrierefreiheitsanforderungen vermutet, sofern und soweit nach Annex C der Europäischen Norm EN 301 549 V2.1.2 die Testkriterien erfüllt sind. Über die WCAG 2.1 mit Level AA hinaus, sind dafür auch allgemeine Kriterien zu erfüllen. Durch die große Schnittmenge werden Tests nach der WCAG-EM die Prüfung nach der EU Norm gut vorbereiten.

Zertifikate

Es gibt Anbieter, welche Zertifikate über eine Prüfung der Barrierefreiheit anbieten. Hierzu muss jedoch bemerkt werden, dass eine Prüfung in allen Fällen nur eine Momentaufnahme sein kann. Ein Prüfergebnis, welches die Konformität einer Webseite gemäß der WCAG 2.1 in der Konformitätsstufe AA belegt, gilt für den Zeitpunkt des Tests. Da größere Webauftritte steten Änderungen und Aktualisierungen unterliegen, ist die Gültigkeit einer Prüfung ebenfalls zeitlich begrenzt. Dieser Einschränkung unterliegt auch ein Prüfergebnis gemäß Annex C der europäischen Norm.

Im Falle einer Barriere, die beim Besuch eines Betroffenen auftritt und dann tatsächlich vorhanden ist, ist ein vorheriges positives Prüfungsergebnis oder ein Zertifikat ohne Bedeutung: Die EU-Richtlinie erfordert in allen Fällen die Behebung der Barriere und das Anbieten eines geeigneten Feedback-Mechanismus.

Die EU-Richtlinie verpflichtet nicht zu einer Zertifizierung. Stattdessen fordert sie allein die Konformität der Webanwendungen gemäß der Europäischen Norm EN 301 549 V2.1.2 auf Basis der WCAG. Da die WCAG mit der WCAG-EM eigene Testverfahren enthalten, sind auch diese zu verwenden. Eigene Prüfverfahren und Zertifikate von einzelnen Anbietern oder von staatlichen Einrichtungen geförderten Projekten werden von der EU-Richtlinie und der WCAG nicht erfasst und sind daher nicht relevant. Die Autoren des Leitfadens empfehlen daher auf den Kauf von Zertifikaten zu verzichten.

Satzungen

Aufgabenbereich und Zielgruppe

Dieser Anwendungsbereich betrifft die Erstellung und Pflege von Satzungen, Prüfungsordnungen, Ordnungen und anderen Dokumenten mit regulatorischen oder dienstrechtlichen Anweisungen.

Diese Art von Dokumenten bedürfen gesonderten Hinweisen und müssen besonderen Ansprüchen genügen. Daher wird diesem Aufgabenbereich ein eigenes Kapitel gewidmet.

Dieses Kapitel wendet sich an folgende Personenkreise:

  • Prüfungsämter
  • Weisungsbefugte Einrichtungen und Abteilungen auf Leitungsebene, die Dokumente für den Geschäftsverkehr erstellen

Grundlagen

Hochschulen gestalten viele ihrer eigenen und staatlichen Aufgaben durch Satzungen oder auch Ordnungen. Anders als der Gesetzgeber, der nur durch Menschenrechte, das Grundgesetz und höherrangiges Recht betrachtet, muss bei Satzungen auch das einfache Recht beachtet werden. Form und Inhalt der Satzungen dürfen daher Menschen mit Behinderung nicht beeinträchtigen. Zudem sind Satzungen durch ihre Bekanntmachung eine allgemein zugängliche Quellen zur Information und müssen daher ungehindert jeder Person zugänglich sein. Aus diesen Grundsätzen folgt, dass die veröffentlichten Dateiformate der Satzungen barrierefrei gestaltet sein müssen.

Umsetzung

Allgemeines zu Satzungen und Prüfungsordnungen

Zu prüfen wäre, ob eine grundsätzliche Barrierefreiheit schon durch den Einsatz der elektronischen Arbeitshilfen „eNorm“ aus dem Projekt des Bundesministerium der Justiz und für Verbraucherschutz „Elektronische Arbeitshilfen und Verkündung“ bei Satzungen genutzt werden kann.

Neue Satzungen und Prüfungsordnungen

Soweit neue Satzungen erstellt werden, kann durch die Nutzung von Formatvorlagen und der Gliederungsmöglichkeiten der zum Verfassen genutzten Büroanwendungen bei Artbezeichnungen, Zählbezeichnungen, Überschriften, Absätzen und deren Untergliederung die Barrierefreiheit umgesetzt werden.

Änderungssatzungen und Änderungen in Prüfungsordnungen

Nur bei umfassender Neugestaltung kann statt einer Änderungssatzung eine vollständige Neubekanntmachung erfolgen. Zur Barrierefreiheit der veröffentlichten Änderungssatzung gilt das gleiche wie für neue Satzungen.

Ordnungen und sonstige Rechtsdokumente

Für Ordnungen und sonstige Rechtsdokumente gilt anders als für Satzungen keine Einschränkung dahingehend, dass bei kleineren Änderungen keine Neuveröffentlichung zulässig ist. Daher bietet es sich an, diese stets im Ganzen neu zu verfassen oder das Vorgängerdokument unmittelbar zu bearbeiten.

Empfehlung

Da die Veröffentlichung anders als die Bekanntmachung für Satzungen nicht konstitutiv ist, kann neben dem Einstellen des neuen oder geänderten Rechtstextes eine redaktionelle Lesefassung angeboten werden. Für diese bietet es sich an, auf eine native Webseite mit Exportmöglichkeiten zu setzen, da über Webanwendungen leichter eine Zugänglichkeit umsetzbar ist.

Soweit für Dokumente oder dateibasierte Formulare keine alternative barrierefreie Webanwendung zu Verfügung steht, sind Dokumente und Formulare barrierefrei zu gestalten gemäß Kapitel 10 der Norm EN 301 549 V1.1.2 (2015-04). In diesem Leitfaden ist jedoch derzeit kein Kapitel für barrierefreie Dateiformate von Büroanwendungen vorgesehen.

Rechtsquellen

Grundgesetz

Völkerrechtliche Vereinbarungen und Verträge

Bundesgesetze

Gemeinsame Geschäftsordnung der Bundesministerien, http://www.verwaltungsvorschriften-im-internet.de/bsvwvbund_21072009_O11313012.htm

  • § 42 Abs. 6 für barrierefreie Gesetzesentwürfe
  • § 62 Abs. 2 für barrierefreie Verordnungsentwürfe

Bayerische Verfassung

Bayerisches Hochschulgesetz

  • Art. 2 Abs. 3 S. 3 und 4
  • Art. 13 Abs. 3 S. 2
  • Verordnung über die Bekanntmachung von Hochschulsatzungen

Vertiefung

Organisatorische und rechtliche Anforderungen

Aufgabenbereich und Zielgruppe

Dieser Anwendungsbereich betrifft die rechtlichen und regulatorischen Aspekte bei dem Betrieb eines Webangebotes.

Dieses Kapitel wendet sich an folgende Personenkreise:

  • CIOs
  • Rechenzentren und Provider
  • Verantwortliche von Webauftritten
  • Verantwortliche Auftragsgeber

Er dient als Ergänzung und Vertiefung des Handlungsleitfadens für IT-Verantwortliche „Barrierefreie Software V1.0“.

Grundlagen

Barrierefreiheit ist kein neues Thema. Da die Exekutive durch das Onlinezugangsgesetz und E-Goverment-Gesetze verpflichtet ist, ihre Leistungen (demnächst) und Informationen auch digital anzubieten, gewinnt die Barrierefreiheit stark an Bedeutung. Verfassungsrechtlich gut begründbar ist es, einen Leistungsanspruch auf Zugänglichkeit von Informationen für benachteiligte Personen anzunehmen (Vgl. Sachs/Bethge GG Art. 5 Rn. 62-63, beck-online zu Art. 5 Abs. 1 2. Halbsatz GG i.V.m. Art. 3 Abs. 1 GG). Die verfassungsrechtliche Grenze dieser Leistung ergibt sich nur aus den verfügbaren Mitteln der handelnden Behörde.

Richtlinie 2016/2016/EU über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen

Mit der Richtlinie 2016/2102/EU der Europäischen Union vom 26. Oktober 2016 über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen ist nun die europäischen Norm EN 301 549 V1.1.2 verbindlich geworden. Für den Bereich Web (Dokumente und Software) – enthält diese Norm alle Level A und Level AA – Erfolgskriterien der WCAG 2.0 als Mindestanforderung. Für Nicht-Webdokumente orientiert sich die Norm an den Richtlinien der WCAG2ICT Task Force.

Vereinfacht kann gesagt werden, dass der Maßstab für Barrierefreiheit im Web die WCAG Standard in der seiner aktuellen Fassung ist. Aktuell liegen die WCAG in der Fassung 2.1 vor. Wird man den Erfolgskriterien von WCAG 2.1 gerecht, erfüllt man auch WCAG 2.0. Mit einer Anpassung der Europäischen Norm auf die Fassung der WCAG 2.1 ist zu rechnen.

Verordnung zur Schaffung barrierefreier Informationstechnik (BITV)

Auf Bundesebene gilt die „Barrierefreie-Informationstechnik-Verordnung“ (BITV). Diese schreibt vor, wie nach dem Behindertengleichstellungsgesetz (BGG) die Träger öffentlicher Gewalt, insbesondere die Bundesbehörden, Barrierefreiheit technisch umsetzen sollen. Viele Landesgesetze und Landesverordnungen verweisen zur Umsetzung der Landesgesetze auf die BITV.

Die BITV wurde zum 21. Mai 2019 auf die Version 2.0 aktualisiert um sie entsprechend der eie auf die Europäische Norm anzupassen.

Bayerisches Gesetz zur Gleichstellung, Integration und Teilhabe von Menschen mit Behinderung

Die einfache gesetzliche Pflicht zur Barrierefreiheit von Webseiten und Programmen folgt in Bayern für staatliche Hochschulen aus Art. 13 BayBGG. Dieser wurde auch bereits an die Richtlinie angepasst und umfasst nun explizit auch mobile Anwendungen. Die Details werden wie bisher in einer Verordnung geregelt. Jedoch waren Apps auch bereits zuvor vom BayBGG erfasst.

Bayerische Barrierefreie Informationstechnik-Verordnung

Die Bayerische Barrierefreie Informationstechnik-Verordnung (BayBITV) setzte in der Fassung von 2006 voraus, dass die Zugangspfade barrierefrei auszugestalten waren. Für bestehende (vor 31.12.2006) waren je nach Zielgruppe Übergangsfristen bis zum 31.12.2010 bzw. 31.12.2013 vorgesehen.

Die Umsetzung gemäß § 2 BayBITV (2006) und § 1 Abs. 1 BayBITV (Stand bis zum 30. September 2018) gibt für Webangebote der staatlichen Hochschulen die Empfehlung, die Barrierefreiheit nach der BITV Anlage in der Stufe Priorität I umzusetzen. Für zentrale Navigations- und Einstiegsangebote ist die Empfehlung, diese gemäß der BITV Anlage in der Stufe Priorität II umzusetzen.

Für den Anwendungsbereich der Richtlinie 2016/2102/EU sind die Empfehlungen der BITV hinfällig. Maßgeblicher Standard für Webanwendungen der Hochschulen ist nun die WCAG über die Europäischen Norm EN 301 549 V1.1.2. Festzustellen ist, dass Hochschulen, die sich bereits vorher an die WCAG orientierten, einen Vorsprung in der Umsetzung der Barrierefreiheit erlangten.

Die Verordnung wurde mit Wirkung zum 1. Oktober 2018 an die Richtlinie 2016/2102/EU angepasst: Am 8. November 2016 wurde die Bayerische Verordnung über die elektronische Verwaltung und die barrierefreie Informationstechnik (Bayerische E-Government-Verordnung – BayEGovV) erlassen, welche die bisherige BayBITV ersetzt.

Für die technischen Anforderungen wird trotz der europäischen Norm auf die Anlage 1 der Barrierefreie Informationstechnik-Verordnung verwiesen. Ob es weiter ein Nebeneinander des deutschen Standards und der europäischen Norm gegeben wird, bleibt abzuwarten. Gemäß fanden die neuen Pflichten aus der BayBITV mit den Änderungen zum 1. Oktober 2018 gemäß § 5a BayBITV mit unterschiedlichen Fristen erst ab dem 1. Oktober 2019 Anwendung. Bis zu diesem Zeitpunkt bestand für die Hochschulen keine rechtliche Verpflichtung nach der BITV Anlage die Barrierefreiheit herzustellen. Im Hinblick auf die Überarbeitung der BITV sollte die Umsetzung an Hochschulen nach der Europäischen Norm EN 301 549 V1.1.2 erfolgen und dabei die WCAG 2.1 miteinbeziehen.

Umsetzung

Die Umsetzung erfordert zum einen die Beachtung formaler Aspekte (Barrierefreiheitserklärung, Feedback-Mechanismus und Umsetzungenfristen) zum anderen inhaltliche Aspekte (Barrierefreiheit der Inhalte durch technische und organisatorische Maßnahmen). Hinzu kommen die Besonderheiten aus der Umsetzung in Bayern. Ergänzend wird die Umsetzung durch Berichtspflichten an die EU-Kommission und leichtere Durchsetzungsmöglichkeiten für betroffene Menschen mit Behinderungen angetrieben.

Barrierefreiheitserklärung gemäß der Richtlinie 2016/2102/EU

Die Richtlinie führt eine Barrierefreiheitserklärung für Webseiten und mobile Anwendungen verpflichtend ein. Der Inhalt der Erklärung wird durch Art. 7 vorgegeben, dessen Inhalt die Kommission in einer Mustererklärung festlegt.

Ein Entwurf einer Mustererklärung für die Erklärung zur Barrierefreiheit ist bereits verfügbar. Die finale Version ist Mitte 2019 zu erwarten.

Als wesentlicher Bestandteil der Erklärung wird die Konformität mit den Barrierefreiheitsanforderungen vermutet, sofern und soweit nach Annex C der Europäischen Norm EN 301 549 V2.1.2 die Testkriterien erfüllt sind. Sofern dies jedoch nicht der Fall ist, ist in der Erklärung darzulegen, welche Kriterien, aus welchen Gründen nicht erfüllt werden konnten. Soweit einzelne Seiten die Konformität zur WCAG nicht erfüllen, ist anzugeben, welche sichere barrierefreie zugängliche Alternative besteht.

Die erforderlichen Alternativen können Leistungen von Kontakt- und Informationsstellen für Studierende mit Behinderung und chronischer Erkrankung oder die Schwerbehindertenvertretung für die Beschäftigten sein.

Bestandsaufnahme und innerorganisatorische Gestaltung

Um auch den Gestaltungsspielraum, den die Richtlinie 2016/2102/EU bietet auszuschöpfen, ist im ersten Schritt eine Bestandsaufnahme der wichtigsten Webseiten, Social-Media-Kanäle und Verwaltungsdokumente durchführen. Erste Schritte erhalten Sie im Kapitel „Test zur Barrierefreiheit“. Optimal bieten Sie für die Mitglieder der Hochschule Veranstaltungen zum Thema Barrierefreiheit an, und setzen ein Gremium zur Begleitung der Umsetzungsprojekte ein und verzahnen Barrierefreiheit in die Schulungsprogramme. Gerade für Webseiten wäre zu prüfen, ob eine höhere Konformität der Inhalte durch einen Freigabeprozess oder zentral organisierte Redaktion erreichbar ist.

Feedback-Mechanismus

Über die konkrete Umsetzung des Feedback-Verfahrens äußert sich die Richtlinie 2016/2102/EU kaum. Aus dem Entwurf der Mustererklärung für die Erklärung zur Barrierefreiheit wird ersichtlich, dass es eine Meldemöglichkeit geben muss und eine verantwortliche Person zu benennen ist. Aus den Erwägungsgründen wird zudem ersichtlich, dass über den Feedback-Mechanismus nicht barrierefreie Informationen, Dienstleistungen oder Dokumente für Betroffene barrierefrei zugänglich gemacht werden sollen. Die Umsetzung in Bayern gemäß § 2 BayBITV verlangt keine Öffentlichkeit für die Beschwerden, ähnlich einer Kommentarfunktion oder einem Diskussionsforum. Eine einfache (barrierefreie) Kontaktmöglichkeit zur Mitteilung von Inhalten, die nicht barrierefrei sind, ist ausreichend.

Die Beantwortung der Anfragen muss innerhalb von sechs Wochen gemäß § 3 Abs. 2 S. 1 BayBITV erfolgen. Bei einer nicht zufriedenstellenden Antwort können Betroffene ein Durchsetzungsverfahren beim Landesamt für Digitalisierung, Breitband und Vermessung einleiten.

EU-Fristen

Die Barrierefreiheit war bereits nach nationalem Recht umzusetzen. Werden jedoch die neuen Fristen aus der Richtlinie 2016/2102/EU nicht eingehalten, liegt neben der verletzten gesetzlichen Pflicht ein Verstoß gegen EU-Recht vor. Aus diesem Grund sind die neuen Fristen von besonderer Relevanz.

  • Alle neuen Dateiformate (PDF u.a.) aus Büroanwendungen müssen ab dem 23.09.2018 barrierefrei sein. Ältere Dateien müssen bis dahin ebenfalls barrierefrei sein, wenn sie für aktive Verwaltungsverfahren benötigt werden. (z.B. Prüfungsordnungen!).  Es wird jedoch gleiche Umsetzungszeitraum dem Medium (wie nachfolgend) entsprechend zugebilligt werden müssen.
  • Webseiten, die ab dem 23.09.2018 veröffentlicht wurden, müssen bis zum 23.09.2019 auf Stufe AA konform zu WCAG 2.0 sein; ältere Webseiten erst zum 23.09.2020.
  • „Intranets/Extranets“ müssen bis zum 23.09.2019 barrierefrei sein.  Ausnahmen gelten für Inhalte die vor dem 23. September 2019 erstellt wurden.
  • Mobile Anwendungen müssen bis zum 23.06.2021 barrierefrei sein.

Barrierefreiheit und ihre Grenzen

Der Handlungsleitfaden für IT-Verantwortliche „Barrierefreie Software V1.0“ gibt den IT-Entscheidern auf den Seiten 9 und 10 umfassenden Empfehlungen, wann gemäß § 1 Abs. 1 BayBITV eine im Einzelfall durch die Einhaltung der Barrierefreiheitsanforderungen eine unverhältnismäßige Belastung besteht.

Vertiefung der Ausnahmen

Ergänzend zum Handlungsleitfaden für IT-Verantwortliche „Barrierefreie Software V1.0“ können die nachfolgenden Passagen bei der Entscheidungsfindung unterstützen. So gewährend die Richtlinie 2016/2102/EU einige Ausnahmen bei bestimmten Arten oder bei bestimmten Alter von Inhalten:

  • Dateiformate von Büroanwendungen, die vor dem 23. September 2018 veröffentlicht wurden, soweit nur dokumentarisch (z.B. Folien zu früheren Veranstaltungen)
  • aufgezeichnete zeitbasierte Medien, die vor dem 23. September 2020 veröffentlicht wurden
  • live übertragene zeitbasierte Medien
  • Online-Karten und Kartendienste, sofern bei Karten für Navigationszwecke wesentliche Informationen in einer barrierefrei zugänglichen Weise digital bereitgestellt werden
  • Inhalte von Dritten, die von der betreffenden öffentlichen Stelle weder finanziert noch entwickelt werden, noch deren Kontrolle unterliegen
  • Reproduktionen von Stücken aus Kulturerbesammlungen, die nicht vollständig barrierefrei zugänglich gemacht werden können
  • Inhalte von Extranets und Intranets, die vor dem 23. September 2019 veröffentlicht wurden

Rückausnahmen

Die Richtlinie 2016/2012 EU hat einen kleineren Anwendungsbereich als das BayBGG. Während die Richtlinie 2016/2102/EU Webseiten und Apps regelt, umfasst das BayBGG Internet- und Intranetauftritte und Internetangebote sowie die von ihnen zur Verfügung gestellten grafischen Programmoberflächen. Soweit die EU-Richtlinie 2016/2012 aber keine Anwendung findet, wie es z.B. für Karten oder digitalisierte Kulturgüter der Fall ist, sind auch diese Ausnahmen barrierefrei anzubieten. Die Grenze bleibt das technisch Machbare.

Verhältnismäßigkeitsausnahme

Durch den größeren Anwendungsbereich kommt der Verhältnismäßigkeit der Umsetzung der Barrierefreiheit eine große Bedeutung zu. Gleichwohl zeigen die Erwägungsgründe der Richtlinie 2016/2012 EU, dass die Zeit von Ausreden vorbei ist. So sollen nicht barrierefreie Inhalte in allen Fällen so barrierearm wie möglich angeboten werden. Die Barrierefreiheit ist auch kein Grund veröffentlichungspflichtige Dokumente nicht zu veröffentlichen, da insoweit die Aufgabenerfüllung Vorrang vor der Barrierefreiheit genießt. Unmissverständlich werden jedoch mangelnde Priorität, Zeit oder Kenntnis als Rechtfertigungsgründe abgelehnt. Ebenso die Nichtentwicklung von Softwaresystemen zur barrierefreien Verwaltung von Inhalten auf Websites und in mobilen Anwendungen. Die Angebote sollen auch bestmöglichst zu assistiven Technologien kompatibel sein. Ebenso sollten Programmierschnittstellen angeboten werden.

In der konkreten Ausgestaltung sieht der Bayerische Gesetzgeber eine schrittweise technische Umstellung der Angebote vor. Dies erspart jedoch nicht die Bestandsaufnahme für jedes Angebot (Webauftritte, Intranets und mobile Anwendungen) hinsichtlich der Barrierefreiheit.

Art. 13 Abs. 1 S. 2 schränkt die Umsetzung auf die technischen, finanziellen, wirtschaftlichen und verwaltungsorganisatorischen Möglichkeiten des jeweiligen Trägers öffentlicher Gewalt ein. Hier können auch die Ausnahmen der Richtlinie 2016/2102/EU wieder hineingelesen werden, wie sie etwa für Karten oder digitalisierte Kulturgüter vorgesehen sind.

Mit Blick auf Art. 5 der Richtlinie 2016/2012 EU wird dies noch etwas spezifischer ausgeführt. Insbesondere in Hinblick auf

  • Größe, Ressourcen und Art der betreffenden öffentlichen Stelle;
  • Die Umsetzungskosten im Vergleich zu den mit einer Umsetzung erzielbaren Vorteilen;
  • Nutzungshäufigkeit der Webseiten und mobilen Anwendungen durch Menschen mit Behinderungen.

Ziel ist, dass durch die Umsetzung der Barrierefreiheit keine übermäßige organisatorische oder finanzielle Last entsteht. Da die Umsetzung von barrierefreiem Webdesign Vorteile mit sich bringt wie

  • responsives Design,
  • Nutzung der Angebote von jedem Endgerät
  • Optimierung der Inhalte für Suchmaschinen

überwiegen die Investitionen die Kosten.

Durchsetzungsmöglichkeiten für Betroffene

Für Öffentliche Stellen unter Verantwortung des Bundes ist die Bundesfachstelle Barrierefreiheit eingerichtet worden. Sie übernimmt die Aufgaben:

  • Zentralen Anlaufstelle für das Schlichtungsverfahren
  • Erstberatung
  • Aufnahme der Überwachungsfunktion (ab 2020)
  • Koordination der Meldungen der Bundesländer
  • Reporting an die EU Kommission

Bayerische Besonderheiten

Behandlung von Schlichtungsverfahren, Überwachungs- und Kontrollfunktion

Für die Durchsetzung und Überwachung ist für Träger öffentlicher Gewalt in Bayern ist das Landesamt für Digitalisierung, Breitband und Vermessung gemäß § 3 BayBITV zuständig.

Das Landesamt überwacht und kontrolliert die Umsetzung und wird Beschwerden von Nutzern nachgehen.

  • Es nimmt Beschwerden über Feedback-Mechanismus an und behandelt diese.
  • Es prüft die Webauftritte der Öffentlichen Stellen bzw. fordert hierzu Berichte ein.
  • Und meldet den Status für den Freistaat Bayern ab Juni 2021 an den Bund.

Bayerische Fristen

Da der einfachgesetzliche Auftrag in Bayern schon seit 2006 besteht, sind die Umsetzungfristen in Bayern angepasst.

Aktuell gelten nach der im Oktober 2018 erneuerten BayBITV 2.0 folgende Fristen für Öffentliche Stellen:

  • Inhalte, die bis zum 30. September 2018 erstellt wurden: bis 30. September 2020
  • Alle danach erstellten Inhalte: bis 30. September 2019
  • Mobile Anwendungen: bis 1. Juli 2021

Es handelt sich dabei um Umsetzungsfristen. Die alten Pflichten (BayBITV1.0) gelten bis zum Zeitpunkt der neuen Umsetzung fort – und waren bereits abgelaufen. Daher beginnt die Umsetzung jetzt und hätte schon beginnen müssen.

Eine Frist zur Bereitstellung einer Barrierefreiheitserklärung wurde in der BayBITV nicht definiert. Daher gilt für diese die Frist der EU Richtlinie: ab dem 21. September 2019 müssen Webangebote der öffentlichen Stellen eine Barrierefreiheitserklärung aufweisen mit Angabe des Standes der Umsetzung der Barrierefreiheit, der Bereitstellung eines Feedback-Mechanismus und der Verlinkung der aufsichtsführenden Stelle (das Landeamt für Digitalisierung).

Entwicklung und Ablauf der Umsetzungsfristen in Bayern seit 2005

Träger Erstellungsdatum des Webangebotes BayBITV 1.0
(2006)		 BayEGovV
(2016)
Staatsverwaltung 31. Dezember 2005 oder älter bis 31. Dezember 2013 bereits abgelaufen
Staatsverwaltung 1. Januar 2006 oder danach bis 31. Dezember 2012 bereits abgelaufen
Staatsverwaltung 30. September 2018 oder älter – bereits abgelaufen (1. Oktober 2020)
Staatsverwaltung 1. Oktober 2018 oder danach – bereits abgelaufen (1. Oktober 2019)
Hochschulen 30. September 2018 oder älter Keine Frist, aber Empfehlung bereits abgelaufen (1. Oktober 2020)
Hochschulen 1. Oktober 2018 oder danach Keine Frist, aber Empfehlung bereits abgelaufen (1. Oktober 2019)
Seiten zur Teilhabe egal bis 31. Dezember 2010 bereits abgelaufen
Apps – Wie Webseiten ab 1. Juli 2021

Für Dateiformate aus Büroanwendungen sind die gleichen Fristen maßgeblich. Intranets/Extranets sind wie Webseiten zu behandeln.

Deutsche Gebärdensprache und Leichte Sprache

Für Neuveröffentlichung ab dem 1. Oktober 2018 sind nach Fristablauf (siehe zuvor) zusätzliche Inhalte gemäß Anlage 2 BITV 2.0 in Deutscher Gebärdensprache und in Leichter Sprache bereitzustellen. Dies umfasst

  • Informationen zum Inhalt
  • Navigationshinweise
  • Hinweise auf weitere Informationen, die in diesem Auftritt entweder in Deutscher Gebärdensprache oder in Leichter Sprache eingestellt sind.

Es bietet sich an, den Auftritt neben Deutsch und Englisch die Sprachversion Deutscher Gebärdensprache und Leichte Sprache anzubieten. Eine Wirtschaftlichkeit Inhalte in dieser Form anzubieten ist abseits der zentrale Navigations- und Einstellungsangebote sehr genau zu prüfen.

Vertragliche Anforderungen bei Auftragsarbeiten

Werden Webseiten nicht hochschulintern, sondern extern entwickelt oder gestaltet, hat die Einrichtung, die einen solchen Auftrag vergibt, neben dem Haushaltsrecht sicherzustellen, dass in der Auftragsdefinition die Einhaltung der EU-Norm zur Barrierefreiheit verbindlich gefordert wird. Dies gilt nicht nur für Programmierarbeiten, sondern auch für gestalterische Leistungen.

Die Schritte zum Auftrag (vereinfachte Darstellung)

  1. Wirtschaftlichkeitsbetrachtung
  2. Konformität zur Europäischen Norm EN 301 549 V2.1.2 – Der Handlungsleitfaden für IT-Verantwortliche „Barrierefreie Software V1.0“ enthält auf Seite 16-18 wertvolle Empfehlungen zu Leistungsanforderung für die Beschaffung. Die Stabsstelle IT-Recht bietet dafür gegen Ende 2018 einen Mustertragvertrag an.
  3. Einhalten des Vergaberechts
    • a) Dokumentation der Entscheidung und des Verfahrens
    • b) Bis € 1000 (ohne Umsatzsteuer) ist eine Direktvergabe möglich
    • c) Bis € 50.000 (ohne Umsatzsteuer) ist bei entsprechender Begründung die Vergabe nach Einholung von drei Angeboten möglich. Ab € 25.000 (ohne Umsatzsteuer) ist eine elektronische Vergabe vorgesehen.
    • d) Bei größeren Aufträgen sollte stets eine Abstimmung mit dem Einkauf erfolgen

Die Schritte nach dem Auftrag

  1. Prüfung des Werkes bei der Abnahme auf seine Barrierefreiheit, ggf. mit Hilfe Ihres Rechenzentrums
  2. Vorbehalten der Abnahme bis zur erfolgreichen Barrierefreiheitsprüfung
  3. Bei fehlender Barrierefreiheit: Setzen einer Frist von ca. zwei Wochen bis einem Monat zur Umsetzung der Barrierefreiheit
  4. Erneute Prüfung auf Barrierefreiheit
  5. Nach Fristablauf Durchsetzung Ihrer Rechte anstreben
    • a) Verlangen eines Vorschusses in Höhe der Kosten für die Herstellung der Barrierefreiheit
    • b) Alternativ den Vertrag auflösen oder teilweise die Vergütung zurückfordern
    • c) Geltendmachen von Schadensersatzansprüchen

Weitere Pflichtangaben auf Webseiten

Da die Webseite um eine Barrierefreiheitskonformitätserklärung zu erweitern ist, lohnt sich in dem Zuge auch einen prüfenden Blick auf Impressum und Datenschutzerklärung zu werfen.

Impressum

Häufige Fehler sind die fehlende Angabe der Rechtsform, fehlende gesetzliche Vertreter oder ein nicht aktualisierter Name der zuständigen Aufsichtsbehörde.

Über ein Webformular stellt die Stabsstelle IT-Recht der bayerischen staatlichen Universitäten und Hochschulen im Rahmen Ihrer Zuständigkeit einen Vorschlag für ein Impressum zur Verfügung.

Datenschutzerklärung

Gerade eigenständige Projektseiten oder Webseiten der Hochschulvereine haben ihr Impressum noch nicht aktualisiert. Häufig werden auch unbedacht nicht passende Textbausteine aus Musterdatenschutzerklärungen eingefügt.

Die Musterdatenschutzerklärung der Stabsstelle IT-Recht der bayerischen staatlichen Universitäten und Hochschulen versucht diese Fehlerquellen zu minimieren und versucht in seinem Umfang die üblichen Anforderungen eines Hochschulinternetauftritts gerecht zu werden.

Handlungsempfehlungen

  • Abhalten einer Auftaktveranstaltung zur Barrierefreiheit
  • Einsetzen eines Gremiums zur Umsetzung
    • Festlegen von Verantwortlichkeiten für die Umsetzung der Barrierefreiheit
    • Prüfung, ob eine Inhaltsfreigabe über eine zentrale Stelle koordiniert werden könnte
    • Auswahl der Webseiten, die gemäß Annex C der Europäischen Norm EN 301 549 V2.1.2 geprüft werden
  • Prüfung führender Systeme und aller neuen
  • Konformität zur Europäischen Norm EN 301 549 V2.1.2 in der Regel als verpflichtendes Kriterium für Beschaffungen festlegen
  • Beständige Information und Sensibilisierung für das Thema
  • Barrierefreiheitserklärung und Feedback-Mechanismus auf Webseite und in mobilen Anwendungen veröffentlichen
  • Etablieren von Schulungsangeboten
  • Regelmäßiger hochschulübergreifender fachlicher Austausch der Wissensträger

Vertiefung

Browser-Add-ons

Beim Entwickeln und Testen von Websites können verschiedene Add-ons eine Hilfe sein.

Der Chrome-Browser von Google hat sich in den letzten Jahren zum meistgenutzten Browser weltweit entwickelt. Auf dem Gebiet der Webentwicklung lag dies unter anderem an der im Vergleich zu Firefox besseren Unterstützung mit Hilfe von nativen Entwickler-Tools, aber auch an der besseren Unterstützung von Webstandards. (Siehe hierzu u.a. die Plattform CanIuse.com). Mit dem neuen Firefox Quantum kann sich diese Situation wieder ändern, aber aktuell ist bei Webentwicklern der Chrome-Browser nach wie vor der am häufigsten verwendete Browser. Unabhängig davon muss jeder Entwickler dennoch weitere Browser auf seinen Arbeitsplatzgeräten oder virtuellen Umgebungen haben. Neue Webauftritte sollten im Idealfall stets mit mindestens drei verschiedenen Browsern auf mindestens zwei verschiedenen Betriebssystemen getestet werden.

Die folgende Liste der Add-ons basiert auf dem aktuellen Chrome-Browser. Ähnliche oder auch dieselben Add-ons gibt es jedoch auch für die anderen Browser.

Name Beschreibung Link
ColorA11y Dieses Add-on prüft, ob bei einer Website die verwendeten Farben für Texte und Hintergründe den WCAG 2.0 Anforderungen Genüge tun. Download
ColorZilla Dieses Add-on erlaubt das „Entnehmen“ von Farbwerten aus einer aktuellen Website („Color Picker“) und bietet andere hilfreiche Informationen zur Farbauswahl an. Download
Full Page Screenshot Für Protokoll- und Testzwecke oder die Diskussion von Bestandteilen einer Website ist ein Screencapture-Werkzeug unumgänglich. Dieses Add-on erlaubt sowohl das Erstellen von Screenshots einer ganzen Seite als auch das gezielte Selektieren von Ausschnitten. Die jeweiligen Bilder können als Datei gespeichert werden. Download
headingsMap Anzeige der Überschriftenhierarchie einer Webseite. Diese Anzeige ist besonders wichtig, um zu erkennen, ob die Navigation innerhalb einer Seite plausibel und logisch strukturiert ist. Auch dies wird zur Einhaltung der WCAG-Bedingungen gefordert. Download
IP-Domain-Markierungsfahne Dieses einfache Plugin ermittelt auf Basis bekannter IP-Adressebereiche die für die aktuell aufgerufene Domain jeweils wahrscheinlich passende Länderfahne. Download
Semantic Inspector Moderne Websites geben über die HTML-Semantik hinaus mit Hilfe von strukturierten Elementen (vgl. auch schema.org) Aussagen darüber, aus welcher Art von Inhalten eine Seite und deren Bestandteile besteht. Insbesondere Suchmaschinen und UserAgents nutzen diese Formate, um Informationen aus Webseiten auszulesen und entsprechend weiterzuverabeiten. Der Semantic Inspector macht diese Inhalte sichtbar und bietet damit gleichzeitig ein Testtool an, ob die selbst eingestellten strukturierten Elemente korrekt waren. Download
WAVE Evaluation Tool Dieses Tool ermöglicht einen automatisierten WCAG-Test der gerade besuchten Website. Die Ergebnisse sind hinreichend nutzbar für Tests und Entwicklung. Zu beachten ist jedoch, dass dieses Testtool, wie auch andere WCAG-Testtools auch viele „False Positives“ meldet – also Dinge als Fehler markiert, die sich bei einer genaueren Prüfung als korrekt erweisen. Download
Web Developer Dieses Add-on ergänzt die Toolbar um einen Button mit hilfreichen Informationen zur Website. So beispielsweise die semantische und topographische Gestaltung der Webseite. Auch werden weitere Links angeboten, mit denen man die W3C-Validation oder andere Werkzeuge bequem aufrufen kann. Download

Üblicherweise sind weitere Add-ons vorhanden, wie beispielsweise das uBlock Origin Add-on, welches effektiv Werbung unsichtbar macht bzw. das Laden dieser unterdrückt oder uMatrix oder NoScript, die (in Kombination mit uBlock Origin) ebenfalls gute und datenschutzorientierte Add-ons zur digitalen Selbstverteidigung gegen Tracking und durch Werbung eingeschleuste Schadsoftware ist.

Entwicklung und Design

Aufgabenbereich und Zielgruppe

Dieser Anwendungsbereich betrifft die Entwicklung und das Webdesign von Webangeboten, Webauftritten und Apps. Teil der Entwicklung ist auch die Umsetzung und Bereitstellung von Templates und Musterseiten, die von Autoren verwendet werden. Auch automatisch erstellte Ausgaben werden durch diese Zielgruppe definiert.

Dieses Kapitel wendet sich an folgende Personenkreise:

  • Webdesigner
  • Webentwickler

Grundlagen

Die Entwicklung von Webangeboten, Webauftritten und Apps ist abhängig von der jeweiligen Arbeitsweise der Beteiligten, von definierten Workflows und Prozessen und von vorgegebenen Frameworks. Der Leitfaden kann keine Empfehlungen zur Arbeitsorganisation und zum idealen Ablauf eines Webprojektes geben. Dies würde den Rahmen des Leitfadens deutlich sprengen. Daher werden hier nur die wichtigsten Problemfelder bei der Entwicklung und Bereitstellung von Webangeboten, Webauftritten und Apps angesprochen und für eine tiefergehende Beschäftigung auf relevante Webseiten verwiesen.

Ein umfangreiches Tutorial für die Entwicklung und Gestaltung von Webangeboten und Webauftritten bietet das Web Accessibility Tutorial des W3C. Dieses sollte sowohl bei Neuentwicklungen als auch bei der Korrektur vorhandener Webangebote als Grundlage und Nachschlagewerk genommen werden. Das Tutorial erläutert, wie Teile von Webangeboten erstellt werden können, um sowohl die Konformität zu den WCAG sicherzustellen, als auch die Benutzererfahrung für alle Nutzer einer Seite zu erhöhen. Es gliedert sich in folgende Teile:

Weiterhin wurden für Designer und Entwickler die folgenden Empfehlungen und Hinweise zusammengefasst:

Eine weitere hilfreiche Quelle ist die Standards-Seite des W3C: Die Plattform enthält ein umfangreiches Nachschlagewerk zur Entwicklung von Webangeboten, Webauftritten, Apps, aber auch von Schnittstellen, strukturierten Daten und Kommunikationsprotokollen.

Umsetzung

Die wesentlichen Grundlagen und Beispiele zur Umsetzung werden in den oben genannten Tutorials behandelt. Hier folgen daher lediglich Umsetzungshilfen, die obige Tutorials ergänzen oder Sonderfälle betreffen.

Strukturierte Daten

Hinweis: Die Umsetzung von strukturierten Daten ist derzeit für die Umsetzung der Barrierefreiheit nicht erforderlich. Gleichwohl kommt es zu positiven Auswirkungen in der Form, dass die Webseite durch Software besser analysiert werden kann. Dies führt unter anderem zu einer besseren Auffindbarkeit mit Hilfe von Suchmaschinen und somit wiederum dazu, dass Menschen die Inhalte besser finden, bevor sie die Seite überhaupt besuchen.

Strukturierte Daten erlauben es, die Semantik von HTML mit Hilfe standardisierter Anweisungen zu erweitern. HTML erlaubt zwar die Auszeichnung von Überschriften, Absätzen und Bildern, definiert jedoch keine Aussagen über den Inhalt. Menschen können anhand von Kontext und Inhalt erkennen, worum es geht. Diese Möglichkeit hat Software (abseits von Machine Learning) jedoch nicht. Die in der WAI-ARIA 1.1 durch die W3C definierte Spezifikation kann dieses Problem auch nicht lösen. Die ARIA erlaubt zwar die Auszeichnung von Strukturen, Bedienelementen und Inhaltstypen einer Webseite, sie macht aber keine Aussagen zur inhaltlichen Bedeutung.

Schemagrafik zur Erkennung von Inhalten, Quelle: RDFa 1.1 Spezifikation

Das Schema aus der Beschreibung des W3C zur Spezifikation RDFa 1.1 beschreibt das Problem: Auf der linken Seite ist das zu sehen, was die Browsersoftware sieht: Zwei Überschriften, einen mit <em> markierten Text und darunter ein Absatz. Gefolgt von eine Linkliste.

Ein Mensch hingegen interpretiert es als einen Artikel mit einer Hauptüberschrift, einer kleineren Überschrift zur Angabe des Autors, einer Datumsangabe und darauf folgend den eigentlichen Artikel, gefolgt von einer Tagclound und einem Link zu Copyright-Informationen.

Suchmaschinen und spezialisierte Softwareprodukte werten strukturierte Daten auf Webseiten aus und liefern diese dann in geeigneter Weise an Menschen aus.

So zum Beispiel:

  • durch die Anreicherung der Ergebnisliste einer Suche mit Öffnungszeiten, Terminen, lokaler Suche, hervorgehobenen Links;
  • durch Auslesen von aktuellen Terminen aus Webseiten und Weiterverwendung dieser in anderen Anwendungen;
  • durch die automatische Erkennung von Telefonnummern auf Webseiten und Verknüpfung dieser mit der Anruffunktion auf mobilen Devices.

Bei der Suche in Google wird beispielsweise bei der Suche nach der Universität Erlangen unterhalb eines Treffers auch eine Auswahlliste an Öffnungszeiten gezeigt.

Anzeige der Öffnungszeiten von Teilen der Universität bei der Ausgabe einer Suche mit Google

Und bei der Suche nach der LMU wird für diese im Infopanel eine Liste der kommenden Veranstaltungen angeboten.

Anzeige der kommenden Veranstaltungen der LMU

Der Nebeneffekt dieser Anzeigen ist, dass der Benutzer der Suchmaschine ohne Umweg über die Startseite der jeweilige Webseite gleich zu dem jeweiligen Angebot springen kann.

In HTML geschieht die Auszeichnung dieser Inhalte durch die Attribute itemscope und itemprop.

Beispiel Termin mit strukturierten Daten

Ohne strukturierte Daten würde eine Terminangabe in HTML so aussehen:

<div class="event">
	  <h2>Webkongress Erlangen</h2>
	  <em>12. September 2018, 9:00 Uhr</em>
	  Department Mathematik 
	  <address>  
			Cauerstraße 11
			91058 Erlangen
	  </address>
</div>

Mit Anwendung der Schema.org-Beschreibung zu Terminen wird hieraus folgendes:

<div class="event" itemscope itemtype="http://schema.org/Event">
	  <h2>Webkongress Erlangen</h2>
	  <em itemprop="startDate" content="2018-09-12T09:00">
	      12. September 2018, 9:00 Uhr
	  </em>
	  <div class="event-venue" itemprop="location" 
	        itemscope itemtype="http://schema.org/Place">
		    <span itemprop="name">	Department Mathematik </span>
		    <address itemprop="address" 
		             itemscope itemtype="http://schema.org/PostalAddress">  
			 	<span itemprop="streetAddress">Cauerstraße 11</span>
				<span itemprop="postalCode">91058</span> 
				<span itemprop="addressLocality">Erlangen</span>
		  	</address>
	   </div>
 </div>

Dieser HTML-Code kann von einer Software ausgelesen und interpretiert werden. Dabei spielt dann auch die individuelle Schreibweise bei der Datumsangabe keine Rolle mehr, da die standardisierte Form im Attribut content="2018-09-12T09:00" angegeben wurde.

Auf der Seite schema.org findet sich eine Übersicht der gebräuchlichsten Inhaltstypen mit Beispielen für deren Anwendung. Um zu prüfen, ob die Angaben korrekt waren, kann das Testtool von Google aber auch die Browsererweiterung Semantic Inspector (siehe unten) verwendet werde.

Vertiefung

Bereitstellung und Pflege von Inhalten

Aufgabenbereich und Zielgruppe

Dieser Anwendungsbereich betrifft die Erstellung und Pflege von Inhalten auf Webauftritten von Hochschulen, deren Einrichtungen, Lehrstühlen, Projekten und anderen Informationsseiten.

Dieses Kapitel wendet sich an folgende Personenkreise:

  • Redakteure
  • Autoren
  • Fotoredakteure
  • sonstige Bearbeiter von Inhalten

Es wird davon ausgegangen, dass Webangebote in diesen Bereichen über ein geeignetes Content-Management-System verwaltet werden, das über Eingabeverfahren mit Hilfe von einem WYSIWYG- oder zumindest Text-Editor verfügt, in dem einfache HTML-Anweisungen eingegeben werden können.

Abgrenzung: Die Programmierung von CMS oder die optische und technische Gestaltung der Ausgaben über HTML, CSS und JavaScript ist nicht Teil dieses Kapitels.

Grundlagen

Mit Inhalten sind all die Informationen gemeint, die vom Leser wahrgenommen werden müssen. Zur Darstellung und Strukturierung der Inhalte wird auf Webseiten die Strukturierungssprache HTML verwendet. Mit dieser kann die Bedeutung eindeutig definiert werden, wozu auch nur wenige, leicht zu merkendende Elemente notwendig sind: Nämlich die Elemente für Überschriften, Absätze, Bilder, Listenelemente, Zitate und Tabellen. In HTML nutzt man den Begriff der Semantik.

Wichtig hierbei ist die Semantik einzuhalten: Überschriften, die nicht mittels verfügbarer HTML-Elementen als solche gekennzeichnet sind, sind keine Überschriften. Der klassische Fehler vieler Autoren besteht oft darin, dass keine Überschriften gesetzt wurden, sondern eine Textzeile schlicht mit Fettdruck und einer größeren Schrift optisch hervorgehoben wurde. Semantisch sind solche Texte jedoch keine Überschriften und werden daher auch nicht als solche interpretiert: Screenreader können diese nicht von normalem Text unterscheiden und auch die Analyse von Suchmaschinen wird den Inhalt dieser Zeile nicht als hervorhebenswerte Überschrift einstufen. Der Fettdruck und die Schriftgröße werden lediglich als optische Darstellung interpretiert; eine automatische Erkennung einer Überschrift geschieht nicht. Diese Interpretation findet allein im Auge des Autors statt.

Ein weiterer häufiger Fehler ist es, eine Semantik falsch zu verwenden mit dem Ziel eine optische Darstellung zu erlangen. So zum Beispiel verwenden einige Autoren gern Überschriften, um einen in ihren Augen wichtigen Text hervorzuheben. Ebenso häufig ist der Fehler, eine Überschrift einer bestimmten Ebene nur deswegen zu verwenden, weil sie dem Autor in der jeweiligen Größe besser gefällt als die Überschrift in ihrer korrekten Ebene. Oder es werden Tabellen verwendet, um eine rein optische Ausrichtung des Textes zu erlangen.

Auf Webseiten, aber auch auf Flyern und anderen Print-Produkten, erfolgt häufig eine optische Verschönerung durch sogenannte Schmuckgrafiken. Mit diesem Verständnis kann man solche Grafiken von Schemagrafiken, Auswertungen oder anderen Grafiken unterscheiden: Schmuckgrafiken können jederzeit ausgetauscht oder weggelassen werden, während inhaltsvermittelnde Grafiken ein nicht wegzulassender Bestandteil der Seite sind.

Wird eine optische Hervorhebung von Texten gewünscht ist, dürfen hierzu keine Strukturelemente, die für die inhaltliche Kennzeichnung vorgesehen sind, verwendet werden. Sollen ein Absatz oder einzelne Worte optisch hervorgehoben werden sollen, ist es Aufgabe des Webdesigns, eine entsprechende Funktionalität bereitzustellen. Viele Webdesigns enthalten bereits entsprechende Funktionalitäten für optionale Boxen, Spaltensatz, Hinweismarken oder Buttons. Sind eine entsprechende Dokumentation oder ein Styleguide vorhanden sein, sollten diese konsultiert werden.

Umsetzung

Überschriften und Überschriftenhierarchien

Inhalte beginnen üblicherweise mit einer Überschrift, gefolgt von einem oder mehren Absätzen. Beim Schreiben von längeren Texten ist eine logische Überschriftenhierarchie wichtig:

Die erste Überschrift im Dokument ist eine Überschrift der Ebene 1. Ist der Text hierarchisch gegliedert, folgt ein Absatz mit einer Überschrift der Ebene 2. Besteht dieses Kapitel aus weiteren hierarchisch untergeordneten Kapitel folgen hier die Überschriften der Ebene 3 und so weiter.

In HTML wird die Überschrift der ersten Ebene mit <h1> deklariert, die zweite Ebene mit <h2>, die dritte mit <h3> und so weiter bis zur sechsten Ebene. Hat ein CMS einen WYSIWYG-Editor wie den populären TinyMCE-Editor, werden die Überschriften als Absatzvorlagen angeboten. Diese werden nach der Eingabe in dem Editor in die entsprechende HTML-Variante gesetzt.

Ansicht der Überschriften in einem CMS mit dem TinyMCE Editor

Bei einigen CMS und Redaktionssystemen wurde die Überschrift der ersten Ebene aus den Absatzvorlagen entfernt, wie es auch das obige Bild zeigt. Grund ist, dass viele Webseiten in der Ausgabe den Titel der Seite als erste Überschrift ausgeben.

Überschriftenauszeichnungen sind nur in ihrer logischen Struktur zu nutzen und nicht als Hilfsmittel zur optischen Formatierung der Texte. Wie eine Überschrift einer beliebigen Ebene optisch auf einem Browser, in einem Office-Dokument oder einem Ausdruck aussieht, ist Sache des Corporate Designs oder der zugrundeliegenden Dokumentenvorlage. Wenn die optische Darstellung nicht passend erscheint, ist nicht die Überschriftenhierarchie zu ändern, sondern das Corporate Design bzw. die Dokumentenvorlage. Als Redakteur oder Autor einer Webseite oder eines Dokumentes sollte man sich jedoch grundsätzlich nicht um die optische Gestaltung der Inhalte kümmern und daher auch nicht versuchen, diese zu beeinflussen. Entdeckt man Mängel in der vorgegebenen Vorlage, sollte man diese an die zuständigen Designer oder Entwickler melden; die Fehler können dann an zentraler Stelle behoben werden und die Fehlerbehebung wirkt sich positiv auch auf solche Stellen aus, die bisher unentdeckt blieben und nicht gemeldet wurden.

Logische Überschriftenhierarchien sind von hoher Bedeutung bei der barrierefreien Umsetzung von Webseiten und Dokumenten: Die Überschriften sind für Screenreader-Software ein unverzichtbares Mittel, um innerhalb der Seite zu navigieren. Die Software erkennt Überschriften anhand der korrekten HTML-Markierung und bietet dem (blinden) Leser der Seite die Möglichkeit an, von Kapitel zu Kapitel zu springen. Sind die Kapitel jedoch nicht mit Überschriften versehen, funktioniert dies nicht. Im Falle von Überschriften der falschen Hierarchieebene wird diese hingegen einem anderen Kontext zugeordnet.

Barrierefreie Webseiten setzen die Überschriftenhierarchie nicht nur für den Inhaltsbereich um, sondern gliedern auch alle anderen Bestandteile der Webseite in einer passenden Hierarchie. Mit einem Browser-Add-on, wie HeadingsMap, kann man sich die Überschriftenhierarchie einer Webseite gesondert anzeigen lassen.

Beispiels einer HeadingsMap

Neben Screenreader nutzen auch Suchmaschinen Überschriften und deren logische Abfolge zur Einordnung von Inhalten. Wenn Sie also Wert darauf legen, dass eine Information besser gefunden wird, sollten Sie auf eine hierarchische Gliederung des Inhalts achten.

Verpflichtende Erfolgskriterien

Optionale Erfolgskriterien

Absätze und andere Textbereiche

Beim Schreiben von Text für Webseiten gelten generell dieselben Regeln wie auch bei jeder anderen Publikation oder wissenschaftlichen Arbeit: Der Text muss für die jeweilige Zielgruppe klar strukturiert werden, frei von Rechtsschreibfehlern und verständlich sein. Dabei sollte man jedoch nicht davon ausgehen, dass der Leser der Webseite denselben Kenntnisstand hat, wie der Autor. Abkürzungen, interne Begriffe und Codewörter, die im Umfeld des Autors oder in Projekten alltäglich verwendet werden, müssen für andere nicht bekannt sein. Zudem können dieselben Abkürzungen je nach Umfeld und Kontext auch verschiedene Bedeutungen haben. Bei einem längeren Text bietet es sich zudem an, im ersten Absatz eine kurze Zusammenfassung oder eine Einführung zu schreiben.

Wenngleich Aspekte der Textverständlichkeit wie Abkürzungen, Lese-Niveau, Verzicht bzw. Erläutern ungewöhnlicher Wörter und Verwenden von Zwischenüberschriften von den WCAG erst auf Stufe AAA erfasst werden, fördert es stets sowohl die Barrierefreiheit als auch die Usability, wenn Redakteure diese Aspekte nicht aus den Augen verlieren.

Jan Eric Hellbusch schreibt zur Verständlichkeit:

Textverstehen ist ein aktiver Prozess und eine Interaktion zwischen Text und Leser. Texte sind für unterschiedliche Leser unterschiedlich leicht verstehbar. Dies hat sowohl mit den Interessen und dem Vorwissen des Lesers zu tun, als auch mit dessen individuellen Fähigkeiten. Aufgrund der unterschiedlichen Voraussetzungen können Texte nicht für alle Leser gleichermaßen verständlich gemacht werden. Dennoch können Voraussetzungen geschaffen werden, die zur Textverständlichkeit beitragen und die Zugänglichkeit der Inhalte auf der Verständlichkeitsebene fördern. Hierzu zählen redaktionelle Aspekte wie die Verwendung geläufiger Begriffe oder kurzer Sätze und gestalterische Maßnahmen wie das Vermeiden von Blocksatz und die Berücksichtigung von relativen Schriftgrößen und höheren Zeilenabständen. Auch die Verwendung von Zwischenüberschriften gehört zu den Anforderungen der Verständlichkeit.

Sprache

Ein Text wird üblicherweise in nur einer Sprache geschrieben. Auch wenn die Sprache für einen sehenden Leser offensichtlich ist, muss die Sprache der Webseite im Quellcode der Seite angegeben sein. Dies gilt insbesondere dann, wenn Textteile auf einer Seite einer andere Sprache nutzen, als der Rest der Seite.

Für die Definition der Sprache einer gesamten Seite ist bei modernen Webauftritten das jeweilige CMS zuständig. Je nach Einstellung des Webauftritts wird dabei vorgegeben, welches die Hauptsprache des Webauftritts und damit auch der Inhalte ist. Als Autor oder Redakteur kann man diese globale Einstellung normalerweise nicht ändern. Unter Umständen bieten manche CMS-Installationen jedoch die Option an, die Sprache einer einzelnen Inhaltsseite gesondert anzugeben:

Seitensprache ändern

Auch wenn die Angabe der Sprache für einen sehenden Leser unnötig erscheint, ist sie dennoch von großer Bedeutung:

  • Screenreader lesen den Text vor. Damit der Text jedoch in der richtigen Sprache und in der korrekten Aussprache vorgelesen werden kann, muss die Screenreader-Software auch erkennen können, um welche Sprache es sich handelt. Eine automatische Erkennung ist zwar nicht unmöglich, sie ist jedoch nicht zuverlässig. Dies macht sich vor allem dann bemerkbar, wenn die Hauptsprache des Webauftritts ebenfalls angegeben wurde und sich von der Sprache des Textabschnitts unterscheidet.
  • Neben Menschen besuchen auch Suchmaschinen und Inhaltsaggregatoren die Webseiten. Auch diese versuchen den Inhalt zu interpretieren und verwenden zur Einordnung und Erkennung von Keywords und Synonymen die angegebene Sprache. Ist die Sprache nicht oder falsch angegeben, kann der Inhalt falsch zugeordnet werden, was in der Praxis bedeuten kann, dass die Seite in der Ergebnisliste einer Suchmaschine an einer schlechten Position aufgelistet wird.

Gibt das CMS oder dessen Bearbeitungswerkzeuge keine Optionen vor, um die Sprache der Inhaltsbereiche anzugeben, ist diese mittels HTML zu setzen. Hierzu eignet sich das Attribut lang="" welches in dem HTML-Element angegeben wird, das den Text mit der Sprache umgibt. Handelt es sich nur um einen Absatz, kann man das <p> Element nutzen, handelt es sich um ein längeres Zitat, verwendet man das <blockquote> Element.

Beispiel mit zwei Absätzen. Der erste gibt keine Sprachdefinition an. Der zweite Absatz setzt die Sprache auf Englisch:

   <p>
      Dies ist ein Absatz ohne Sprachdeklaration. Es wird die Sprache 
      verwendet, die vom CMS bzw. dem Webseitentemplate im Kopfteil
      der Seite angegeben wurde.
   </p>
   <p lang="en">
      This is an english paragraph.
   </p>

Sollte sich der Textbereich über mehrere Kapitel und Absätze erstrecken, setzt man die Sprachdefinition nicht für jedem einzelnen Absatz neu, sondern verwendet das Element <div> um alle darin liegenden Absätze zu deklarieren:

   <h1>Text in einer deutschsprachigen Seite mit englischen Absätzen</h1>
   <p>
      Dies ist ein Absatz ohne Sprachdeklaration. Es wird die Sprache 
      verwendet, die vom CMS bzw. dem Webseitentemplate im Kopfteil 
      der Seite angegeben wurde.
   </p>
   <div lang="en">
       <h2>Chapter One</h2>
       <p>
           This is an english paragraph in chapter one.
       </p> 

       <h2>Chapter Two</h2>
       <p>
           This is the first paragraph in chapter two.
       </p> 
       <p>
           This is the second paragraph in chapter two.
       </p>
   </div>

Abkürzungen

Für Abkürzungen sollte Folgendes beachtet werden:

  • Abkürzungen sollten beim ersten Auftreten im Text ausgeschrieben werden. Dies gilt besonders bei längeren Namen von Einrichtungen oder Titeln. Dabei wird zunächst der Name ausgeschrieben, gefolgt von der Abkürzung in runden Klammern. Beispiel: Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU).
  • Eine Ausnahme gibt es bei solchen Abkürzungen, die in der kurzen Form bereits Teil der Alltagssprache, in ihrer ausgeschriebenen Form hingegen weitgehend unbekannt sind. So zum Beispiel die Abkürzungen „DSL“ oder „WLAN“. Die ausgeschriebenen Formen dieser Abkürzungen („Digital Subscriber Line“ und „Wireless Local Area Network„) sind oft nicht gängig, während die Bedeutung der kurzen Form für jeden Leser klar ist.
  • Sollte bei der Ausschreibung der Abkürzung ein Sprachwechsel erfolgen, muss diese über geeignete HTML-Anweisungen im Code deklariert werden. Hierzu eignet sich das Attribut lang="" .
Beispiele:

Bei der Ausschreibung von DSL sähe der entsprechende HTML-Code daher so aus:

   <span lang="en">Digital Subscriber Line</span>

Wird die Abkürzung nicht ausgeschrieben, wird das <abbr>-Element verwendet um sie als solche zu deklarieren:

<abbr title="zum Beispiel">z.B.</abbr>

Kommt es zudem zu einem Sprachwechsel, wird das Attribut lang="" ergänzt; Als Inhalt des Attributs wird der jeweilige Code der Sprache der Abkürzung verwendet:

<abbr title="World Wide Web" lang="en">WWW<abbr>

Verpflichtende Erfolgskriterien

Optionale Erfolgskriterien

Vertiefung

Bilder und Schemagrafiken

Mit Hilfe von Bildern und Schemagrafiken können viele Informationen an den Leser übermittelt werden: Inhaltliche Informationen und Daten, aber auch Stimmungen. Im letzteren Fall wird oft von sogenannten Schmuckgrafiken oder von dekorativen Elementen gesprochen: Die Bilder tragen keinen eigentlichen Inhalt, sondern dienen dazu, die Webseite für einen sehenden Leser oder für den Ausdruck optisch ansprechend zu gestalten. Würde man diese Bilder weglassen, würde der Leser keine Information vermissen.

Dem gegenüber stehen Bilder und Schemagrafiken, die tatsächlich Informationen enthalten. Würde man diese Bilder ausblenden, würden wesentliche Informationen fehlen oder gar die gesamte Seite inhaltsleer sein.

Für die Barrierefreiheit ist es wichtig, dass Bilder und Schemagrafiken entweder im Text erklärt werden, so dass man auch ohne diese auskommt, oder dass die Bilder über eine geeignete Textalternative verfügen. Die Textalternative muss die gesamte vom Bild übermittelte Information enthalten.

Die Art der Textalternative ist dabei abhängig von der Art des Bildes:

  • Handelt es sich um eine Schmuckgrafik, sollte keine Textalternative angegeben werden. Screenreader sollen diese Bilder ignorieren; Eine Beschreibung ist daher wegzulassen.
  • Handelt es sich um die Illustration eines im Text beschriebenen Sachverhaltes, ist lediglich eine kurze Textbeschreibung notwendig.
  • Handelt es sich bei dem Bild um ein informatives Bild, welches nicht im Text beschrieben wird, ist eine ausführliche Textalternative für das Bild zu hinterlegen.
  • Handelt es sich bei dem Bild um ein aktives Element um auf eine andere Webseite zu verlinken oder als grafischer Button eine Aktion auszulösen, ist nicht das Bild inhaltlich zu beschreiben, sondern das Linkziel oder das was passiert, wenn man auf das Bild klickt.

Um eine Textalternative eines Bildes anzugeben, verwendet man im HTML-Element <img> das Attribut alt="". Das Attribut title="" hingegen wird nur verwendet, um den Titel des Bildes anzugeben. Unterstützt das CMS des Webauftritts auch Bildunterschriften, sind auch diese anzugeben, sofern das Bild keine Schmuckgrafik ist.

Beispiele:

  1. Auf einer Seite wird der Versuchsaufbau eines physikalischen Experiments erläutert. Hierzu wird ein Bild angegeben. 
    <img alt="Im Experiment wird der Laserstrahl durch einen Doppelspalt 
          gelenkt. Die Spalte haben einen Durchmesser von 0,085 mm 
          und einen Abstand voneinander von 0,6 mm. Dahinter findet 
          sich im Abstand von 2 Metern ein Schirm. Auf diesem kann
          man bei Einschaltung des Lasern ein Wellenmuster erkennen." 
     title="Versuchsaufbau Doppelspaltexperiment" src="(BILD-URL)">

    Für einen sehenden Menschen wird die Information im Bild gegeben. Kann man hingegen das Bild nicht sehen, kann man den Versuchsaufbau anhand der Beschreibung im alt-Attribut nachvollziehen. Der Titel allein hätte nicht gereicht, um den Versuchsaufbau zu erläutern.

  2. Bei einem dekorativen Bild wird das Attribut alt="" leer gelassen: 
    <img alt="" src="(BILD-URL)">
  3. Bei einem grafischen Link wird hingegen das Linkziel beschrieben und nicht mehr das Bild: 
    <a href="https://www.fau.de">
    <img alt="Zum Webauftritt der FAU" src="(LOGO-URL)">
</a>

Verpflichtende Erfolgskriterien

Vertiefung

Links

Abseits von den Menüs und Navigationskonzepten einer Website werden auch Links im Inhaltsbereich von Seiten gesetzt. Auch wenn das eigentliche Setzen von Links nicht schwierig ist, können einige Fehler gemacht werden, die negative Auswirkungen auf Barrierefreiheit, Verständnis und auch Findbarkeit haben.

Folgende Eigenschaften muss jeder Link erfüllen:

  • Ein Link sollte grundsätzlich immer klar und deutlich machen, was den Leser erwartet, wenn er diesen auswählt. Und zwar schon vor dem „Klick“ und auch vor einem Mouseover.
  • Das Ziel eines Links muss stets klar erkennbar sein. Mit der Konformitätsstufe AA reicht hier auch die Betrachtung des Kontextes in dem sich der Link befindet. So ist ein Link mit dem Linktext „Download“ durchaus legitim, sofern dies im Kontext einer Liste mit eigenen Überschriften statt findet.
  • Soll auch die Konformitätsstufe AAA erreicht werden, muss ein Link für sich allein genommen verständlich sein. So muss er auch dann, wenn er allein und ohne umgebenden Text ausgegeben wird, noch immer das Ziel und seinen Zweck klar beschreiben.

Verlinkt man auf eine andere Webseite, ist der Linktext optimalerweise der Titel der verlinkten Webseite. Verlinkt man auf ein Dokument, so eignet sich der Titel der Dokuments oder eine Kurzfassung. Keinesfalls sollte man als Linktext jedoch Handlungsanweisungen verwenden. Ein Klassiker bei fehlerhaften Umsetzungen ist ein Link wie dieser: „Klicken Sie hier“ . Das Wort „hier“ für sich allein genommen sagt nichts darüber aus, was passiert oder wohin man gelangt, wenn man tatsächlich auf den Link klickt. Stattdessen sollte an solchen Stellen besser so formuliert werden: „Rufen Sie die Online-Broschüre zum Thema ABC auf.„. Der eigentliche Link wäre dann auf den Worten „Online-Broschüre zum Thema ABC„. Dies ist ohne den Text davor auch für sich allein verständlich und der Leser wird wissen, was ihn beim Klick auf den Link erwartet.

In normalen Textbereichen wird ein Link mit den HTML-Element <a> gesetzt:

Rufen Sie die <a href="(URL)">Online-Broschüre zum Thema ABC</a> auf.

Bei Nutzung eines WYSIWYG-Editors reicht es oft, den entsprechenden Text zu selektieren und dann in einem erscheinenden Fenster die Zieladresse einzugeben oder aus einer Liste vorhandener Seiten auszuwählen.

Screenshot des Modals zum Einfügen eines neues neuen Links im Visuellen Editor von WordPress

Weitere Attribute

Zu beachten ist, dass im Fall einfacher Links auf Dokumente keine weiteren Angaben oder Attribute notwendig sind. Auch die Angabe, welche dafür sorgt, dass ein Link in einem neuen Fenster oder Tab geöffnet wird, sollte vermieden werden. Man kann nicht davon ausgehen, dass das Öffnen eines neuen Fensters für Links von jedem Leser erwünscht ist. Tatsächlich sorgt das Öffnen eines neuen Fensters auch zu einigen Nachteilen bei den Lesern der Seite: Die „Zurück“-Funktion des Browser funktioniert für das neue Fenster nicht mehr und der Rechner wird möglicherweise durch viele neue Fenster stärker belastet. Wurde die Seite zudem mit einem Smartphone aufgerufen, wird das neue Fenster üblicherweise das vorherige komplett überlagern. Ob ein neues Fenster oder ein Tab geöffnet wird, sollte daher grundsätzlich dem Leser selbst überlassen bleiben, der hierfür die dafür gedachten Werkzeuge seines Browsers nutzen kann.

Auf manchen Webseiten sieht man, dass Links zusätzlich mit einem title="" -Attribut versehen wurden. Dies sollte man ebenfalls nur in besonderen Ausnahmefällen tun. Das Attribut sollte nur dann verwendet werden, wenn der Linktext nicht gleich dem tatsächlichen Titel des aufzurufenden Dokumentes ist. Screenreader werden bei einem Link üblicherweise sowohl den Titel, sofern vorhanden, als auch den Linktext vorlesen. Sind Linktext und Titel dagegen gleich, werden Menschen mit Screenreader daher denselben Text unnötigerweise zweimal anhören müssen.

Verpflichtende Erfolgskriterien

Optionale Erfolgskriterien

Tabellen

Für die Nutzung von Tabellen gilt eine feste Regel: Tabellen dürfen nur für tabellarische Daten genutzt werden. Tabellen sind nicht dazu gedacht, Texte und Bilder auszurichten oder die Seite zu layouten. Es gilt auch hier das oben Genannte: Wenn eine besondere optische Darstellung benötigt wird, so ist es Aufgabe des Designs und der Technik, entsprechende Funktionalitäten bereitzustellen. Wird beispielsweise eine Ausrichtung des Inhaltes in zwei oder mehr Spalten gewünscht, wird dies bei modernen Websites oft durch eigene Anweisungen geleistet. So verfügen Websites, die auf dem populären Bootstrap-Framework beruhen, über eine umfangreiche Klassenbibliothek um Inhaltsbereiche in bis zu 12 Spalten aufzutrennen. Eine Tabelle erweist sich bei der Nutzung als Gestaltungswerkzeug spätestens bei dem Aufruf der Seite mit dem Smartphone als untauglich: So werden dann Inhalte nicht mehr erkennbar und es kommt zu horizontalen Scrollbalken. Wird hingegen ein vorgegebenes Grid-System verwendet, werden die Spalten serialisiert und in korrekter Reihenfolge übereinander positioniert.

Bei der Nutzung von Datentabellen ist den jeweiligen Zellen eine Überschrift zuzuordnen. Dies erfolgt mit Hilfe des Elements <th>. Die eigentlichen Zellen mit Daten werden dagegen mit dem Element <td> gekennzeichnet. Die Zeilen werden durch das Element <tr> ausgezeichnet.

Eine einfache Datentabelle ist in HTML wie folgt aufgebaut:

<table>
  <caption> Tabellenüberschrift </caption>
  <tr>
    <th> Überschrift Spalte 1 </th>
    <th> Überschrift Spalte 2 </th>
  </tr>
  <tr>
    <td> Datenzelle </td>
    <td> Datenzelle </td>
  </tr>
</table>

Je nach Komplexität der Datentabelle ist es sinnvoll, weitere Überschriften und Beziehungen von Zellen zueinander zu definieren. Die Anleitung des W3C zu Tabellen bietet eine ausführliche Erläuterung mit Beispielen zum korrekten Gebrauch und Einsatz.

Gängige WYSWIYG-Editoren, wie der TinyMCE-Editor, verfügen über Hilfsmittel um Tabellen auch ohne Kenntnisse von HTML zu erstellen.

Screenshot des Table-Wizards in TinyMCE

Hier erfolgt die Bedienung ähnlich zu der in Microsoft Office.

Verpflichtende Erfolgskriterien

Vertiefung

Listen

Nummerierte Aufzählungen und Listen werden auf Webseiten mit eigenen HTML-Elementen deklariert. Wie bei Überschriften und Absätzen ist bei Listen die Einhaltung dieser Semantik wichtig, damit Aufzählungselemente und Listenpunkte von Screenreader erkannt werden können.

Im Redaktionsalltag sind im wesentlichen zwei Formen von Listen in Gebrauch: Unsortierte und nummerierte Listen. (Es gibt noch eine dritte Form: Definitionslisten; Diese werden jedoch nur selten verwendet).

Eine einfache unsortierte Liste wird in HTML wie folgt aufgebaut:

<ul>
  <li> Unnummeriertes Listenelement </li>
  <li> Unnummeriertes Listenelement </li>
</ul>

Die sortierte Liste unterscheidet sich hiervon nur durch die Verwendung des Elements <ol> anstelle von <ul>:

<ol>
  <li> Nummeriertes Listenelement 1 </li>
  <li> Nummeriertes Listenelement 2 </li>
</ol>

In den Listenelementen können eigene Überschriften, Absätze, weitere Listen oder andere Elemente gesetzt werden. So kann eine Liste auch eine untergeordnete Liste enthalten.

Gängige WYSIWYG-Editoren wie der TinyMCE unterstützen Listen durch eigene Bedienelemente:

Screenshot des Modals zum Einfügen eines neues neuen Links im Visuellen Editor von WordPress

Zu beachten ist auch hier, wie oben bereits bei den Überschriften und den Tabellen erwähnt: Listen dienen nicht der optischen Gestaltung beliebiger Texte oder zur Einrückung derselben. Sie haben den Zweck, eine Liste auszuzeichnen. Umgekehrt bedeutet das: Wer eine Liste auf einer Seite angeben möchte, der muss dazu auch die Listenelemente verwenden — und nicht etwa Absätze aus einzelnen Zeilen, die mit einer Zahl beginnen und einem erzwungen Umbruch enden.

Eine korrekt ausgezeichnete Liste wird im Gegensatz zu Absatzzeilen von Screenreader und Analysesoftware als zusammenhängende Liste erkannt. Zusätzlich wird eine Liste auch bei der Darstellung auf mobilen Endgeräten mit kleinem Display korrekt umbrochen.

Die Optik der unnummerierten Listen und das Zahlenformat der nummerierten Listen wird durch das zugrundeliegende Design bestimmt. Zwar lassen sich in HTML die Zahlenformate über das list-style-type Attribut vorgeben, dies sollte man jedoch nur in Ausnahmefällen nutzen, da üblicherweise das Webdesign die Nutzung ohne weitere Attribute als Standard betrachtet.

Verpflichtende Erfolgskriterien

Vertiefung

Zitate

Um längere Zitate darzustellen, verwendet man das <blockquote>-Element. Die optische Form dieser Darstellung wird wie gewohnt von dem zugrundeliegenden Webdesign bestimmt. Üblicherweise wird ein Zitat jedoch optisch hervorgehoben, indem es links und rechts eingerückt wird und Schriftart und -stil verändert wird.

<blockquote>
  <p>
   Der Universität ist vorbehalten, was nur der Mensch durch und durch in
   sich finden kann, die Einsicht in die reine Wissenschaft.
  </p>
</blockquote>

Das <blockquote>-Element umrandet darin befindliche Absätze.

Soll zusätzlich ein Zitatgeber oder eine Quelle genannt werden, kann dies mit Hilfe des <cite> Elements vorgenommen werden. Dies darf dann jedoch nicht im eigentlichen Zitat-Absatz stehen, sondern muss hiervon getrennt sein (beispielsweise mit einem <footer>-Element).

<blockquote>
  <p>
      Der Universität ist vorbehalten, was nur der Mensch durch und durch 
      in sich finden kann, die Einsicht in die reine Wissenschaft.
  </p>
  <footer>
     <cite>Wilhelm von Humboldt (1767 - 1835)</cite>
  </footer>
</blockquote>

Liegt dem gesamten Zitat eine externe Quelle zugrunde, kann diese mit einem Attribut im <blockquote>-Element ergänzt werden, nämlich mit cite="(URL)". (Bedauerlicherweise hat das Attribut denselben Namen wie das Element; Es handelt sich aber dennoch um unterschiedliche Dinge).

<blockquote cite="https://de.wikiquote.org/wiki/Albert_Einstein">
  <p>
      Ich habe keine besondere Begabung, sondern bin nur leidenschaftlich 
      neugierig.
  </p>
  <footer>
     <cite>Albert Einstein</cite>
  </footer>
</blockquote>

Falls die Zitate kürzer ausfallen und keinen langen Text beinhalten, kann man auch das <cite>-Element innerhalb eines Absatzes nutzen:

<p>
    <cite>
    Woran erkennt man barrierefreies Internet? 
    - Gar nicht! Das ist ja gerade das Gute!
    </cite>
</p>

Verpflichtende Erfolgskriterien

Vertiefung

Embeddings

Immer mehr moderne Webseiten ergänzen textuelle Informationen mit multimedialen Inhalten, die von darauf spezialisierten Portalen kommen.

Dies können zum Beispiel Bildergalerien, Videos, Tonmitschnitte, Karten, Vortragsfolien aber auch interaktive Bedienoberflächen sein. Beispielsweise werden viele Online-Kurse und Tutorials in Form kurzer Videos auf der Plattform YouTube abgelegt und Vortragsfolien finden sich oft auf dem Portal SlideShare. Auf sehr vielen Webauftritten finden sich unter der Beschreibung des Kontakts auch eingebundene Karten von OpenStreetMap oder Google Maps.

Von einem Embedding wird gesprochen, wenn ein Inhalt von einem dieser Portale in die eigene Webseite integriert wird. So wird beispielsweise ein Video von YouTube im Inhaltsbereich der Seite gezeigt.

Auch wenn viele CMS inzwischen die Bereitstellung und Wiedergabe entsprechender Dateien beherrschen, sind die Portale aufgrund ihrer Spezialisierung in der spezifischen Bereitstellung des Contents jedem CMS technisch und funktionell überlegen. Es ist daher nicht verwunderlich, wenn auch große Websites für die Bereitstellung von Videos oder Karten auf die entsprechenden Portale oder eigenständige Softwarelösungen außerhalb des CMS ausweichen.

Die meisten Inhaltsportale und auch die meisten CMS unterstützen das Embedding mit Hilfe entsprechender Funktionalitäten, mit deren Hilfe externer Content einfach in die eigene Webseite „embedded“ werden kann.

So bietet YouTube beispielsweise unter dem Link Teilen die Funktion zum Einbetten an. Dieses öffnet ein neues Fenster in dem man einen HTML-Code angeboten bekommt, welchen man in seine eigene Webseite integrieren kann:

Embedding eines Videos von YouTube

Moderne CMS nutzen zudem vermehrt die oEmbed-Schnittstelle . Mit dieser ist es für den Autor einer Seite nicht mehr nötig, irgendeinen HTML-Code auf der Portalseite zu suchen und ihn dann einzubinden. Stattdessen reicht es, die URL des Videos oder der Information auf dem Portal aus der Adresszeile des Browsers zu nehmen und in den Editor zu kopieren.

Embedding über URL - Codeansicht des Editors

Dies passiert im CMS WordPress sogar schon im WYSIWYG-Editor:

Embedding über URL - WYSIWYG-Ansicht

Im Kontext der Barrierefreiheit ist Embedding umstritten: Die Betreiber einer Seite und erst recht nicht die Redakteure haben Einfluss auf die Barrierefreiheit des Embeddings. Es bleibt in vielen Fällen nur die Wahl: Wenn man die Information einer fremden und nicht barrierefreien Quelle einbindet, hilft man einer großen Zahl an Personen. Lässt man die Einbindung hingegen weg, da sie nicht vollständig barrierefrei ist, hat niemand einen Vorteil.

Große Portale kennen diese Problematik auch und versuchen bereits von sich aus, den Content eines Embeddings barrierefrei zu liefern. So werden die Embeddings inzwischen mit Techniken ausgeliefert, die eine Zugänglichkeit für assistive Technologien unterstützen. Videos werden beispielsweise automatisch mit Audiotranskriptionen versehen und von Vortragsfolien wird eine Textfassung bereitgestellt. Dies geschieht bei den betreffenden Portalen weitgehend automatisch, ist jedoch auch abhängig von der Sorgfalt der Personen, welche die Informationen hochgeladen haben und dort die Möglichkeit hatten, entsprechende notwendige Informationen zu ergänzen.

Empfehlungen für den Einsatz von Embeddings

Der Autor einer Seite kann sich bei einem Embedding nicht sicher sein, ob dieses tatsächlich barrierefrei geliefert wird oder nicht. Daher sollte hier eine Lösung ähnlich wie der bei dem Einsatz von Bildern vorgenommen werden. Um den Konformitätsanforderungen der WCAG Genüge zu tun, ist zudem deutlich zu machen, dass der angezeigte Inhalt von einer Drittquelle kommt.

Daher:

  • Sofern das Embedding zwingend notwendige Informationen enthält, die der Leser der Webseite erfahren muss, sollten diese Informationen zusätzlich in Textform bereitgestellt werden.
  • An geeigneter Stelle vor oder nach dem Embedding wird auf die Quelle hingewiesen. Hierbei sollte bestenfalls das Quellportal (z.B. der YouTube-Kanal ) und der Titel sichtbar sein. Eine gesonderte Verlinkung sollte ebenfalls vorgenommen werden, so dass man hierfür nicht auf das Embedding selbst angewiesen ist.

Verpflichtende Erfolgskriterien

Autoren von Webseiten, die aufgrund von externen, nicht kontrollierbaren Inhalten nicht konform sein können, müssen eine Erklärung partieller Konformität anbieten. Bei einer Prüfung der Seite gemäß den Richtlinien der WCAG würde dies bedeuten, dass man die Seite nur ohne das Embedding prüft und die eingebundenen Teile als solche deutlich erkennbar macht. Das kann zum Beispiel dadurch geschehen, dass man den Inhalt, wie oben empfohlen, als zusätzlichen Text beschreibt.

Wichtig ist hierbei, dass der Leser der Seite deutlich erkennen kann, dass der Inhalt aus einer Drittquelle kommt.

Rechtlicher Hinweis

Die EU-Richtlinie schränkt in Artikel 1, Absatz 4d) und 4e) die Umsetzung der WCAG in einigen Anwendungsbereichen ein. Dieser Teil der Richtlinie wurde jedoch bei der Umsetzung der Gesetzgebung von einigen Bundesländern nicht übernommen. Somit entfällt die Einschränkung und es gilt daher das, was in der WCAG zur Umsetzung der Konformität definiert wurde.

Vertiefung