Wie führt man eine Barrierefreiheitsprüfung durch?

Ein Eindruck davon zu bekommen, wie zugänglich Ihr Modul, Theme oder Ihre Website ist, kann eine überwältigende Aufgabe sein. Wenn Sie neu im Bereich Barrierefreiheit sind, kann das Thema selbst verwirrend sein, und Sie wissen nicht, wo Sie anfangen sollen. Die Anpassung an die vielfältigen Fähigkeiten erfordert, dass eine entsprechend vielfältige Reihe von Aspekten berücksichtigt wird. In dieser Dokumentation haben wir die notwendigen Überlegungen in einen logischen, schrittweisen Prozess zur Überprüfung der Barrierefreiheit Ihrer Modul-Themes oder Website aufgelistet.

Beginnen Sie mit dem Einsatz automatisierter Tools

Viele Barrierefreiheitsprobleme können durch den Einsatz automatisierter Tools auf der Seite erkannt werden. Einige der automatisierten Tools sind WAVE, Tenon, Accessibility Insights, Google Lighthouse, Siteimprove und die Erweiterung Siteimprove Accessibility Checker für Chrome. Teilweise kann dies auch mit axe-core automatisiert werden. Diese Werkzeuge helfen Ihnen, schnell einige Barrierefreiheitsprobleme zu identifizieren, wie falsche Markup-Strukturen, fehlende ARIA-Attribute und unzureichenden Farbkontrast.

Tastaturnavigation testen

Tastaturnavigation ist das Hauptmittel, mit dem Benutzer, die keine Maus verwenden können oder wollen, auf alle Inhalte auf dem Bildschirm zugreifen. Dazu gehören Benutzer von Bildschirmleseprogrammen sowie Menschen mit motorischen Einschränkungen wie repetitive Belastungsverletzungen (RSI) oder Lähmungen. Für eine gute Tastaturerfahrung sollten Sie eine logische Tabulatorreihenfolge und gut sichtbare Fokusstile haben. Zudem sollte sichergestellt werden, dass der Benutzer nicht unnötig viele Tab-Positionen durchlaufen muss.

Worauf Sie achten sollten

• Können Sie wiederholte Inhalte überspringen?

Es sollte einen Überspringen-Link geben, der Nutzer direkt zum einzigartigen Inhalt der Seite führt und wiederkehrende Inhalte wie Navigationsmenüs überspringt. Der Überspringen-Link sollte die erste Tab-Position auf der Seite sein und beim Fokus sichtbar werden.

• Funktionieren alle Steuerelemente vollständig mit der Tastatur?

Jedes interaktive Element sollte mit der Tastatur bedienbar sein. Auf- und Zuklappen, Baumansichten, Slider, Dialoge und Overlays – alle sollten per Tastatur nutzbar sein oder es sollte eine alternative Möglichkeit geben, die Aktion auszuführen.

• Können Sie in beide Richtungen tabben?

Wir haben einige Anwendungen gesehen, bei denen das Tabben vorwärts durch die Seite funktioniert, aber nicht rückwärts (mit Shift + Tab), was eine Tastatursperre verursacht. Stellen Sie sicher, dass Sie sich in beide Richtungen durch die Oberfläche tabben können.

• Gibt es Tastatursperren?

Achten Sie darauf, dass der Fokus nicht vollständig an einer Stelle „gefangen“ ist. Gibt es eine Möglichkeit für den Benutzer, Overlays, modale Fenster oder Auto-Vervollständigungs-Widgets nur mit der Tastatur zu verlassen? Wenn nicht, haben Sie gerade eine Tastatursperre geschaffen.

• Ist der Fokus bei einem Dialog eingeschränkt?

Bei einem Dialog sollte der Tastaturfokus innerhalb des Dialogs eingeschränkt sein. Ansonsten kann der Fokus aus dem Dialog heraus tabben, was zu Verwirrung führt.

• Ist der Fokus immer sichtbar?

Eine allgemeine Regel ist, dass jedes Steuerungselement, mit dem Nutzer interagieren oder Eingaben machen, fokussierbar sein und eine Fokusanzeige (z. B. einen Fokusring) haben muss. Wenn Tastaturnutzer nicht sehen, worauf ihr Fokus gerichtet ist, können sie nicht mit der Seite interagieren.

• Gibt es Inhalte, die unsichtbar sind, aber per Tastatur erreichbar?

Stellen Sie sicher, dass keine Inhalte, die versteckt sein sollten, dennoch in der Tab-Reihenfolge bleiben.

• Gibt es Tastaturäquivalente für Inhalte, die nur beim Hover sichtbar sind?

Prüfen Sie mit der Maus, ob Inhalte nur beim Hover sichtbar sind, aber nicht nur per Tastatur erreichbar. Inhalte, die nur beim Hover sichtbar sind, sollten einen alternativen Zugriff ermöglichen. Das ist wichtig nicht nur für Tastaturnutzer, sondern auch für Touchscreen-Nutzer.

• Gibt es fokussierbare Elemente, die nicht fokussierbar sein sollten?

- Nicht-interaktive Inhalte sollten nicht fokussierbar sein. Wenn etwas fokussierbar ist, erwartet der Benutzer, damit etwas machen zu können. Fokussierbare, aber nicht bedienbare Inhalte können verwirrend oder frustrierend sein.

- Setzen Sie keine tabindex="0" Attribute auf Elemente, die nicht bedienbar sein sollen.

- Unnötige tabindex-Attribute auf nicht interaktive Elemente erhöhen den Aufwand für die Navigation durch Inhalte.

• Ist die Tab-Reihenfolge natürlich und logisch?

Wenn tabindex verändert wurde oder die Seitenstruktur vom natürlichen DOM-Fluss abweicht, kann das für sehende Tastaturnutzer zu einem verwirrenden Navigationsfluss führen.

Überprüfen Sie Ihre Checkpoints

Nachdem Sie alle Tastaturtests durchgeführt haben: Vergrößern Sie die Browseransicht bis zur nächsten Medienabfrage (Breakpoint) und testen Sie erneut. Nutzer mit hoher Browservergrößerung interagieren mit Ihrer Tablet- oder Mobilversion auf ihrem Laptop. Mobile Breakpoints sind nicht nur für Touchscreen-Nutzer gedacht.

Überschriften

Überschriften bilden die Struktur Ihres Inhalts. Eine gute Überschriftenstruktur spiegelt den Seiteninhalt wider, wie ein Inhaltsverzeichnis eines Buches. Beschreibende und sinnvolle Überschriftenebenen sind wichtig, da einige Bildschirmleser diese zur Navigation im Seiteninhalt verwenden.

Wenn Sie eines der automatischen Zugänglichkeitstools verwendet haben, haben Sie wahrscheinlich die meisten Überschriftenprobleme bereits geprüft.

Worauf Sie achten sollten

• Gibt es nur ein H1-Element auf der Seite?

Es sollte nur ein H1-Element auf der Seite geben, das beschreibt, worum es auf der Seite geht.

• Entsprechen die Überschriftenebenen dem Inhalt?

Es ist wichtig, Überschriften entsprechend ihrer Ebene zu verwenden und nicht nur nach Schriftgröße. Ebenen sollten nicht übersprungen werden.

• Sind die Überschriften aussagekräftig genug?

Gute Überschriften geben kurz den Inhalt an, der folgt.

Farbe und Kontrast

Ausreichender Farbkontrast ist erforderlich

Farbkontrast beschreibt das Verhältnis von Vordergrundfarbe (Text) zur Hintergrundfarbe. Text sollte ein Verhältnis von mindestens 4,5:1 zum Hintergrund haben. Sie können Farbkontrast-Checker verwenden, um zu prüfen, ob Ihre Farben diese Anforderung erfüllen.

Farbe darf nicht das einzige Mittel zur visuellen Informationsvermittlung sein

Obwohl Farbe ein zulässiges Mittel zur visuellen Informationsvermittlung ist, darf sie nicht das einzige sein. Menschen mit Farbenblindheit können Schwierigkeiten haben, wenn wichtige Informationen nur durch Farbe vermittelt werden (und sie somit komplett verpassen).

Wenn Farbe zur Informationsvermittlung verwendet wird, nutzen Sie mindestens eine der folgenden zusätzlichen Methoden:

• Verwenden Sie aussagekräftigen Text, um Informationen zu vermitteln. Zum Beispiel „ein“ und „aus“ neben einem Kreis, der von grün zu rot wechselt.
• Verwenden Sie aussagekräftige Symbole, damit Nutzer den Wert anhand der Form unterscheiden können.
• Um Formulareingabefehler anzuzeigen, sagen Sie nicht nur „Felder, die rot markiert sind“. Besser ist es, die Feldnamen auszusprechen und sie mit einem erkennbaren Fehler-Icon zu kennzeichnen.

Ein weiteres Beispiel ist das Markieren Pflichtfelder mit roter Farbe. Manche Nutzer können Rot nicht von anderen Farben unterscheiden und erhalten so nicht genügend Hinweise, um das Formular auszufüllen. Das Problem lässt sich lösen, indem ein Sternchen an das Feldetikett angefügt wird.

Fokuszustände sollten nicht nur von Farbe abhängen. Zur Anzeige des Fokus ist eine zusätzliche Form erforderlich, z. B. eine Umrandung um das fokussierte Steuerelement.

Nicht nur durch das Symbol

Wenn ein Symbol ein wichtiger Teil der Funktion ist, muss es von einem Text begleitet werden, der seine Bedeutung beschreibt. Stellen Sie sicher, dass interaktive Elemente wie Navigationsmenüs gekennzeichnet sind. Nicht jeder versteht Symbole, die für Sie offensichtlich sind. Ein Label ist auch für Screenreader wichtig, um das Element vorlesen zu können.

Ton und Video

Wenn eine Seite Ton oder Video zur Informationsvermittlung nutzt, stellen Sie sicher, dass Untertitel oder Transkripte verfügbar sind. Weitere Informationen finden Sie im WebAim-Artikel zu Untertiteln, Transkripten und Audiodeskriptionen.

• Bei informativen Videos auf Webseiten mit oder ohne Ton benötigen sehbehinderte Menschen eine Textabschrift.
• Bei informativen Videos auf Webseiten mit Ton sind geschlossene Untertitel für hörbehinderte Menschen erforderlich.
• Bei informativen und komplexen Videos mit Ton ist möglicherweise eine Audiodeskription notwendig, die Kontext der Szenen und Aktionen beschreibt, die in den Untertiteln nicht enthalten sind, für sehbehinderte Menschen.
• Bei Live-Videos müssen Untertitel für hörbehinderte Menschen bereitgestellt werden.
• Bei Live-Audio muss eine textliche Alternative für sehbehinderte Menschen bereitgestellt werden.

Dies bezieht sich auf zeitbasierte Medien, Richtlinie 1.2 der WCAG.

Animationen und automatisches Abspielen von Video und Audio

Animationen, Videos und/oder Audio, die automatisch ohne Nutzerkontrolle abgespielt werden, können die Aufmerksamkeit auf andere Seitenbereiche ablenken. Selbst wenn Animationen oder Videos an einer Stelle auf der Seite liegen, die Sie für unproblematisch halten, wissen wir nicht, wie Nutzer die Seite betrachten.

Beispiele für Animationen, automatische Video- und Audio-Wiedergabe:

• Animationen: Karussell, das automatisch eine Reihe von Bildern durchläuft;
• Automatisch startendes Video: YouTube-Video startet beim Laden der Seite;
• Automatisch startendes Audio: Radiosender spielt automatisch beim Seitenladen.

Um Ablenkungen auf der Seite zu minimieren:

• Vermeiden Sie das Abspielen von Animationen, Videos oder Audio länger als 5 Sekunden.
• Bieten Sie Steuerungen an, mit denen Nutzer Animationen, Videos und Audio anhalten, abspielen und pausieren können.

Dynamisch veränderter Inhalt

JavaScript ermöglicht es, Teile einer Seite dynamisch zu ändern, ohne sie vollständig neu zu laden. Nutzer, die diese Änderungen nicht vollständig sehen können, sollten dennoch über die Änderungen informiert werden. Beispiele für dynamische Änderungen sind die Aktualisierung von Suchergebnissen in Echtzeit oder das Anzeigen einer einzelnen Benachrichtigung, die keine Benutzerinteraktion erfordert. Das Drupal API Drupal.announce() bietet die Möglichkeit, dynamische Inhaltsänderungen an unterstützende Technologien zu melden.

Drupal.announce() ist eine API, die auf ARIA Live Regions basiert. Beispiele für die Verwendung finden Sie in der Dokumentation zu ARIA Live Regions.

Die beste Methode zum Testen dynamischer Inhalte ist die Verwendung eines Bildschirmleseprogramms.

Tests mit Bildschirmleseprogrammen

Das Durchführen automatisierter Barrierefreiheitstests und manuelles Durchgehen der Seite ist ein guter Anfang. Wenn Sie jedoch keine Erfahrung mit Bildschirmleseprogrammen haben, können viele Probleme nicht erkannt werden.

Worauf Sie achten sollten

• Haben alle Steuerelemente ein Label?

Alle Steuerelemente müssen eine Beschriftung haben, die ihren Zweck erklärt. Meistens geschieht dies mit einem label-Element, aber in komplexeren Fällen müssen Sie möglicherweise das Attribut aria-labelledby verwenden.

• Gibt es benutzerdefinierte Steuerelemente? Sind diese mit einer entsprechenden Rolle und notwendigen ARIA-Attributen versehen, die den Status beschreiben?

Nutzer unterstützender Technologien müssen dieselben Informationen erhalten wie sehende Nutzer durch visuelle Hinweise wie Formatierung, Cursor-Stil oder Position. Native Elemente bringen diese semantischen Informationen standardmäßig mit, aber für benutzerdefinierte Steuerelemente müssen Sie ARIA verwenden, um diese Informationen hinzuzufügen. Zum Beispiel könnte ein benutzerdefinierter Slider die Rolle „slider“ mit den Attributen aria-valuenow, aria-valuemin und aria-valuemax übernehmen.

• Entspricht der Informationsfluss dem, was auf dem Bildschirm zu sehen ist, und ist er sinnvoll?

Der Informationsfluss kann durch CSS verändert werden. Ist der Informationsfluss beim Zugriff mit einem Bildschirmleser sinnvoll?

• Machen die Linktexte Sinn?

Die meisten Bildschirmleser sprechen vor jedem Link „Link“. Beispielsweise wird der Link „Produkte“ als „Link Produkte“ vorgelesen. Links sollten daher nicht „Link“ im Linktext enthalten, da alle Nutzer ohnehin wissen, dass es sich um einen Link handelt.

Das Springen von Link zu Link ist eine Art, wie Bildschirmleser-Webinhalte durchsuchen. Links sollten auch außerhalb ihres Kontexts sinnvoll sein. Phrasen wie „hier klicken“, „mehr“, „für weitere Informationen klicken“ sind aus dem Kontext heraus mehrdeutig.

• Haben alle Bilder einen korrekten Alternativtext?

Alle Bilder müssen einen korrekten Alternativtext haben. Ausnahmen sind Bilder, die nur zur Präsentation dienen und keinen wesentlichen Inhalt darstellen. Wenn ein Bild vom Bildschirmleser ignoriert werden soll, setzen Sie das alt-Attribut auf einen leeren String.

Manuelles Testen mit Bildschirmleseprogrammen

Einige Probleme lassen sich nur durch manuelles Testen mit einem Bildschirmleser finden. Die gebräuchlichsten Bildschirmleser sind VoiceOver (Mac OS) und NVDA (Windows). Zum Einstieg in VoiceOver können Sie sich ein Video zu den Grundlagen von VoiceOver ansehen und das WebAIM VoiceOver-Tutorial lesen. Für NVDA gibt es ein Video zu den Grundlagen von NVDA und eine Anleitung von Marco Zehe, wie man NVDA und Firefox für Barrierefreiheitstests verwendet.

Sobald Sie mit dem Bildschirmleser vertraut sind und die wichtigsten Tastaturbefehle kennen, versuchen Sie, den Monitor auszuschalten und die Maus wegzulegen. Beachten Sie, dass die Sprachausgabe des Bildschirmlesers während des Testens nicht ausgeschaltet werden sollte.

Wenn Sie noch kein Bildschirmleser-Nutzer sind, ist das Testen mit einem solchen Programm nicht so einfach, wie es scheint. Es erfordert Zeit und Übung, sich von der visuellen Navigation zu lösen und die verfügbaren Tastenkombinationen und Methoden zu erlernen. Zudem funktionieren Bildschirmleser unterschiedlich, weshalb es wichtig ist, auf möglichst vielen Geräten, Browsern und Plattformen zu testen.