WCAG 2.1: Was ist neu? – Teil 2

Tastaturbefehle (A)

Wenn Websites eigene Tastaturbefehle mit Buchstaben, Ziffern oder anderen Zeichen anbieten, so muss eine der folgenden Bedingungen sein. Diese dienen dazu, Überlappungen mit Tastaturbefehlen für Browser oder technologische Hilfsmittel zu vermeiden.

1. Die User können die Kurztaste deaktivieren.
2. Die User können den Tastaturbefehl modifizieren durch zusätzliche Funktionstasten, wie zum Beispiel STRG, ALT oder CMD.
3. Der Tastaturbefehl ist nur aktiv, wenn das Element gerade den Fokus besitzt.

Dieses Kriterium verbessert die Barrierefreiheit für Menschen, die Spracheingabe nutzen um auf einer Website zu navigieren. Auch für Menschen, die beispielsweise einen Tremor haben und leicht irrtümlich eine falsche Taste drücken, verbessert dieses Kriterium die Accessibility.

Pointer-Gesten (A)

Mit diesem neu in WCAG 2.1 eingeführten Kriterium reagiert die WAI auf neue Bedienungskonzepte auf Touchscreens.

Diese Richtlinie besagt, dass der User Aktionen, die mit komplexten Gesten wie Wischen oder mit mehreren Punkten gleichzeitig ausgeführt werden müssen, auch mit einfacheren Gesten ausführen können muss. Zu solchen einfachen Gesten gehören zum Beispiel Einfachtipps, Doppeltipps und langes Pressen.

Pointer-Eingaben und -Abbruch (A)

Ein Klick mit der Maus oder am Touchscreen sollen keine unbeabsichtige Ereignisse auslösen. Insbesondere bei motorischen Beeinträchtigungen wie Tremor oder in speziellen Situationen wie zum Beispiel im Tram hat dieses Kriterium eine Relevanz.

Um dieses Kriterium zu verstehen, braucht es eine Unterscheidung von Down-Events und Up-Events. Bei Down-Events lösen das alleinige Drücken einer Maustaste oder das alleinige Berühren des Touchscreens eine Aktion aus. Bei Up-Events wird die Aktion erst ausgelöst, wenn der Finger die Maustaste oder den Touchscreen verlässt.

Wenn eine Aktion mit einem Klick ausgelöst werden kann, muss zumindest eine der folgenden Bestimmungen erfüllt sein:

1. Die ausgelösten Funktionen geschehen nicht auf dem Down-Event.
2. Die Funktionalität wird auf dem Up-Event ausgelöst und es ist möglich, sie entweder abzubrechen, bevor das Up-Event stattfindet, oder sie danach rückgängig zu machen.
3. Das Up-Event bricht das ab, was auf dem Down-Event passiert ist.
4. Das Auslösen der Funktionalität auf dem Down-Event darf nur erfolgen, wenn ein wichtiger Grund vorliegt. Triggering die Funktionalität auf dem Down-Event muss aus einem wichtigen Grund erfolgen.

Ein Beispiel für Punkt 2: Wenn du eine Maus verwendest und eine Taste zum Löschen einer Datei auf der Dropbox gedrückt hältst, solltest du in der Lage sein, den Mauszeiger von der Taste wegzubewegen und sie loszulassen, ohne dass etwas passiert.

Sichtbare Beschriftungen (A)

Dieses neue WCAG 2.1 Kriterium verbessert die Bedienung durch Spracheingabe. Damit Links und Schalter mittels Spracheingabe bedient werden können, müssen sie über eine sichtbare Beschriftung verfügen. Diese entspricht dem Namen des Elements.

Das ist einfach zu erreichen, indem du HTML-Elemente wie Anker-Tags und Buttons richtig verwendest und erläuternde Text-Labels schreibst.

Tipp: Wenn du Text durch ein Symbol auf einer Oberflächenkomponente ersetzt, kannst du einen Screenreader trotzdem mit Hilfe des aria-label-Attributes dazu bringen, den Text vorzulesen.

<button aria-label="Search">
    <span class="icon-search"></span>
</button>

Befolgst du dieses Kriterium, verbesserst du die Accessibility für Menschen mit Sehbehinderung, die einen Screenreader verwenden. Zudem verbesserst du auch die Barrierefreiheit für Menschen, die mittels Spracheingabe im Web surfen.

Bewegungsbestätigung (A)

Lösen körperliche Bewegungen des Smartphones oder des Users eine Funktionalität aus, so muss es eine Alternative geben. Wenn ich beispielsweise durch Schütteln meines iPhones eine Aktion rückgängig machen kann, muss das auch mit Maus und Tastatur möglich sein.

Zusätzlich muss ich die Option haben, die Steuerung durch Bewegung meines Gerätes gänzlich zu deaktivieren. Menschen mit chronischem Tremor sollten dadurch vor ständigen unwillkürlichen Eingaben bewahrt werden.

Statusmeldungen (A)

Um dieses Kriterium zu erfolgen, dieser Richtlinie zu folgen, müssen Nutzer, die assistierende Technologien nutzen, eine Mitteilung erhalten, wenn sich Inhalt dynamisch aktualisiert. Die Statusmeldung soll erfolgen, ohne dass der aktualisierte Inhalt einen visuellen Fokus erhält.

Ein Beispiel: Du durchstöberst eine Nachrichten-Website, auf der ein Twitter-Feed eingebettet ist. Es wäre ärgerlich, wenn du jedes Mal, wenn ein neuer Tweet erscheint, automatisch wieder nach oben gescrollt würdest, um den neuen Tweet zu sehen.

Eine gute Lösung solcher Statusmeldungen ist die Verwendung von ARIA-Live-Regionen. Diese drei Code-Ausschnitt erklären, wie es funktioniert:

<div role="status" aria-live="off">
  When this text is updated, 
  users with screen readers 
  will not be notified at all.
</div><div role="status" aria-live="polite">
  When this text is updated, 
  users with screen readers 
  will be notified if they 
  aren't doing anything else.
</div><div role="status" aria-live="assertive">
  When this text is updated,
  users with screen readers 
  will be notified immediately 
  regardless of what they're doing.
</div>