Barrierefreiheit, BFSG und WCAG 2.1: Umsetzung der neuen Normen

Auf Webseiten öffentlicher Stellen bereits seit einiger Zeit geltender Standard, soll der barrierefreie Zugang zu Webseiten nun für deutlich mehr Webseiten, insbesondere auch im privaten Sektor, verpflichtend werden. In diesem Rahmen erhalten die „Web Content Accessibility Guidelines 2.1“ (WCAG) der „Web Accessibility Initiative“ (WAI) erhebliche Bedeutung. Eine kurze Vorstellung des Standards.

Gesetzlicher Rahmen

Bereits seit längerer Zeit statuiert das BGG Anforderungen an die Zugänglichkeit von Internetauftritten öffentlicher Stellen. Durch die Richtlinie (EU) 2019/882 hat die EU eine Ausdehnung auch auf Teile des privaten Sektors angestoßen. Die Richtlinie wurde in Deutschland durch das „Gesetz zur Umsetzung der Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen“ (BFSG) in nationales Recht umgesetzt. Details soll eine Verordnung des Bundesministeriums für Arbeit und Soziales regeln. Die dort geplante „Verordnung über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen nach dem Barrierefreiheitsstärkungsgesetz“ ist jedoch – ebenso wie das BFSG – teils schwer verständlich und systematisch nicht zwingend geglückt. Die Verordnung verweist (nach aktuellem Entwurf) für Detailfragen selbst wiederum auf die Webseite der Bundesfachstelle für Barrierefreiheit. Dort heißt es:

„Als Grundlage dienen die Web Content Accessibility Guidelines 2.1 (WCAG 2.1), auf denen auch die Barrierefreie-Informationstechnik-Verordnung fußt.“

Bundesfachstelle für Barrierefreiheit

Weitere Informationen über die Reichweite des neuen Gesetzes und die möglichen Folgen einer mangelhaften Umsetzung durch Betroffene hat Sebastian Laoutoumai hier übersichtlich zusammengefasst.

Was genau meint WCAG 2.1?

Das World Wide Web Consortium (W3C) hat mit den „Richtlinien für die Zugänglichkeit von Web-Inhalten“ (WCAG) ein Grundlagenwerk geschaffen, das darauf abzielt, die immer wichtiger werdenden Inhalte des Internets für mehr Menschen zugänglich und damit nutzbar zu machen. Davon sollen insbesondere Menschen mit Behinderungen profitieren, die Befolgung der Richtlinien soll aber auch generell zur Verbesserung der Nutzerfreundlichkeit führen. Ziel ist dabei aber nicht, individuellen Bedürfnissen vollständig zu entsprechen.

Es ist wichtig zu verstehen, dass die WCAG technologieagnostisch sind. Soll heißen: Sie geben keine bestimmte Technologie für deren Umsetzung vor und hegen hierfür auch keine Präferenz. Die Richtlinien sind also abstrakt gehalten und überlassen die Umsetzung in technische Lösungen nachgeordneten Ebenen.

Welches System steckt hinter den WCAG?

Das System basiert auf mehreren Ebenen:

  1. Prinzipien („Principles“)
  2. Richtlinien („Guidelines“)
  3. Erfolgskriterien („Success Criteria“)
  4. Informativ: Technologien

Die Prinzipien werden von den Richtlinien ausgestaltet, während die Erfolgskriterien eine Möglichkeit an die Hand geben, die erfolgreiche Umsetzung zu testen.

Die lediglich informativ genannten Techniken sollen bei der Umsetzung helfen, ohne dass sie normativ sind.

Welche Prinzipien müssen Webseiten nach dem BFSG also erfüllen?

Es bietet sich an, sich mit den folgenden Prinzipien vertraut zu machen und sie fortan bei der Entwicklung und Gestaltung von Webinhalten präsent zu haben.

  1. Wahrnehmbarkeit
    Inhalte und Bedienelemente müssen so gestaltet sein, dass sie die Nutzer wahrnehmen können.
  2. Bedienbarkeit
    Alle UI-Elemente müssen (auch für Menschen mit Einschränkungen) bedienbar sein.
  3. Verständlichkeit
    Inhalte und Bedienelemente müssen so gestaltet werden, dass sie verständlich sind.
  4. Robustheit
    Webinhalte müssen so gestaltet werden, dass sie von möglichst vielen User-Agents insbesondere auch durch Unterstützungstechnologie interpretiert werden können.

Technische Umsetzung: WAI-ARIA

Hinter dem weiteren Akronym ARIA verbirgt sich die Bezeichnung „Accessible Rich Internet Applications (Suite)“. Durch die Nutzung der hier definierten zusätzlichen Attribute für Elemente auf Webseiten soll deren Funktion, Struktur und Bedienung auch für Menschen erschlossen werden, die beeinträchtigt sind.

So lassen sich etwa die Funktionen von Bedienelementen hinterlegen, Inhaltsbereiche abgrenzen oder der Status bestimmter Aktionselemente darstellen.

Das klingt zunächst sehr abstrakt. Wie so oft hilft es aber auch hier, einmal die Rolle einer beeinträchtigten Person einzunehmen. Fügen Sie doch Ihrem Browser zu Testzwecken einfach einen Screenreader hinzu, um zu erfahren, wie sich die Webseite für Menschen darstellt, die auf solche Assistenzen angewiesen sind.

Einige Beispiele:

ARIA Beispiel 1

Zunächst ein einfaches Beispiel über die Erweiterung von HTML-Tags mit ARIA-Attributen.

Gehen wir einmal von einer denkbar einfachen Navigation als Seitenleiste aus. Davon benötigen wir in unserem Beispiel zwei Stück. Eine für Inhalte (etwa andere Blogbeiträge) und eine für die Nutzerinteraktion.

Diese erstellen wir als einfache ungeordnete Liste mit Links:

Zwei einfache Navigationsleisten

<h5>Weitere Beiträge</h5>
<ul>
	<li><a title="Ein erster Beitrag" href="/erster-beitrag/">Erster Beitrag</a></li>
	<li><a title="Ein zweiter Beitrag" href="/zweiter-beitrag/">Zweiter Beitrag</a></li>
</ul>
<h5>Aktionen</h5>
<ul>
	<li><a title="Beitrag bearbeiten" href="/pages/1/bearbeiten/">Beitrag bearbeiten</a></li>
	<li><a title="Beitrag löschen" href="/pages/1/löschen/">Beitrag löschen</a></li>
</ul>

Das oben genannte Beispiel mag nicht schön sein, es würde aber funktionieren. Für einen Screenreader stellt sich das jedoch nicht als "Navigationsleiste" dar, sondern als eine schlichte Liste. Mit ARIA-Attributen können Sie die Funktion vermitteln:

Zwei einfache Navigationsleisten - mit ARIA-Attributen

<div role="navigation" aria-label="Navigation zu weiteren Beiträgen">
	<h5>Weitere Beiträge</h5>
	<ul>
		<li><a title="Ein erster Beitrag" href="/erster-beitrag/" aria-label="Öffnen Sie: Erster Beitrag, ein Artikel von Max Mustermann">Erster Beitrag</a></li>
		<li><a title="Ein zweiter Beitrag" href="/zweiter-beitrag/" aria-label="Öffnen Sie: Zweiter Beitrag, ein Artikel von Ute Musterfrau">Zweiter Beitrag</a></li>
	</ul>
</div>

<div role="navigation" aria-label="Navigation für Aktionen zu diesem Beitrag">
	<h5>Aktionen</h5>
	<ul>
		<li><a title="Beitrag bearbeiten" href="/pages/1/bearbeiten/" aria-label="Klicken Sie hier, um den Beitrag zu bearbeiten.">Beitrag bearbeiten</a></li>
		<li><a title="Beitrag löschen" href="/pages/1/löschen/" aria-label="Klicken Sie hier, um den Beitrag zu löschen.">Beitrag löschen</a></li>
	</ul>
</div>

Wie Sie sehen, haben wir unserem Menü lediglich eine Role mit einem ARIA-Label zugewiesen, das das jeweilige Menü beschreibt. Weiter haben wir dem jeweiligen Link noch ein ARIA-Label hinzugefügt. Diese kleinen Änderungen können bei der Verwendung einen Screenreaders zu ganz erheblichen Verbesserungen führen.

ARIA Beispiel 2

Bootstrap ist eines der bekanntesten Frontend-CSS-Frameworks. Eine sehr nützliche Komponente ist dabei das sogenannte „Modal“. Es handelt sich dabei um ein Dialogfenster, das bei Bedarf (etwa einem Klick) erscheint. Es ist – in der Regel – vorher nicht sichtbar, auch wenn der Text oft im HTML bereits vorhanden ist. Für Menschen, die diesen optischen Umstand nicht wahrnehmen können, ist es also wichtig, dass Informationen hinterlegt werden, welche die Rolle, den Status und die Funktionsweise eines solchen Dokuments definieren.

Werfen wir nun einen Blick in die Bootstrap Dokumentation zu Modals, die ARIA-Attribute bereits teilweise implementiert:

Bootstrap Modal Dokumentation mit ARIA-Attributen

<!-- Button trigger modal -->
<button type="button" class="btn btn-primary" data-toggle="modal" data-target="#exampleModal">
  Launch demo modal
</button>

<!-- Modal -->
<div class="modal fade" id="exampleModal" tabindex="-1" role="dialog" aria-labelledby="exampleModalLabel" aria-hidden="true">
  <div class="modal-dialog" role="document">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title" id="exampleModalLabel">Modal title</h5>
        <button type="button" class="close" data-dismiss="modal" aria-label="Close">
          <span aria-hidden="true">&times;</span>
        </button>
      </div>
      <div class="modal-body">
        ...
      </div>
      <div class="modal-footer">
        <button type="button" class="btn btn-secondary" data-dismiss="modal">Close</button>
        <button type="button" class="btn btn-primary">Save changes</button>
      </div>
    </div>
  </div>
</div>

Wir sehen, dass für das Modal-Element ein „Tabindex" definiert wurde, eine Rolle („Dialog“), ein Label (hier ein Verweis auf die Überschrift in dem Modal als „Modal title“) und ein Zustand, nämlich „verborgen“. Weiter wurde dem inneren Teil die Rolle als „Dokument“ zugewiesen; ein ARIA-Label erklärt die Rolle des „Close-Buttons“.

Auf diese Weise werden Bedienelemente einer Webseite, deren Bedienung sonst ein optisches Verständnis voraussetzt, für einen deutlich größeren Personenkreis nutzbar.

Weitere Informationen

Die detaillierte Beschreibung aller Möglichkeiten dieser Technik würde den Rahmen dieses Artikels zweifellos sprengen. Eine gute Beschreibung und Dokumentation findet sich für ARIA, SCR und CSS-Techniken hier.

Fazit

Die Barrierefreiheit im immer wichtiger werdenden Internet ist ein Thema mit großer Bedeutung für eine signifikante Bevölkerungsgruppe. Die Einführung verbindlicher Standards ist daher grundsätzlich zu begrüßen. Aufgrund der Kaskadenverweise innerhalb des Bundesgesetzes und der Abstraktheit der weiteren Standards sollten sich Verantwortliche frühzeitig mit der Umsetzung der neuen Regelungen beschäftigen.


Die hier dargestellten Informationen sind keine Rechtsberatung und erheben keinen Anspruch auf Vollständigkeit und Richtigkeit!

Veröffentlicht in den folgenden Kategorien