Barrierefreiheit prüfen

Rob Dodson

Es kann schwierig sein, festzustellen, ob Ihre Website oder Anwendung barrierefrei ist. Wenn Sie sich zum ersten Mal mit Barrierefreiheit befassen, kann die schiere Breite des Themas Sie dazu bringen, sich zu fragen, wo Sie anfangen sollen. Schließlich bedeutet die Arbeit an einer Vielzahl von Fähigkeiten, dass es eine entsprechend vielfältige Reihe von Problemen zu berücksichtigen gibt.

In diesem Beitrag werden diese Probleme in einem logischen, schrittweisen Prozess zur Prüfung einer vorhandenen Website auf Barrierefreiheit aufgeschlüsselt.

Mit der Tastatur beginnen

Für Nutzer, die keine Maus verwenden können oder möchten, ist die Tastaturnavigation die Hauptmethode, um alle Elemente auf dem Bildschirm zu erreichen. Dazu gehören Nutzer mit motorischen Einschränkungen wie einer repetitiven Belastungsverletzung (RSI) oder Lähmung sowie Nutzer von Screenreadern.

Für eine gute Bedienung per Tastatur sollten Sie eine logische Tabulatorreihenfolge und deutlich erkennbare Fokusstile verwenden.

  • Gehen Sie zuerst mit der Tabulatortaste durch Ihre Website. Die Reihenfolge, in der Elemente den Fokus erhalten, sollte der DOM-Reihenfolge entsprechen. Wenn Sie sich nicht sicher sind, welche Elemente den Fokus erhalten sollten, lesen Sie das Modul zum Fokus im Kurs „Barrierefreiheit lernen“. Idealerweise sollte jedes Steuerelement, mit dem Nutzer interagieren oder Eingaben machen können, fokussierbar sein und eine Fokusanzeige (z. B. einen Fokusring) haben.

  • Benutzerdefinierte interaktive Steuerelemente sollten fokussierbar sein. Wenn Sie mit JavaScript ein <div> in ein ausgefallenes Drop-down-Menü umwandeln, wird es nicht automatisch in die Tab-Reihenfolge eingefügt. Wenn ein benutzerdefiniertes Steuerelement den Fokus erhalten soll, geben Sie ihm ein tabindex="0". tabindex-Werte größer als 0 ändern die Tabulatorreihenfolge und können für Nutzer von Screenreadern verwirrend sein.

  • Nur interaktive Inhalte sollten fokussierbar sein. Wenn Sie nicht interaktiven Elementen wie Überschriften das Attribut „tabindex“ hinzufügen, wird die Bedienung für Tastaturnutzer, die den Bildschirm sehen können, verlangsamt. Für Nutzer von Screenreadern ist das jedoch nicht hilfreich, da der Screenreader diese Elemente bereits ansagen kann.

  • Wenn Sie einer Seite neue Inhalte hinzufügen, lenken Sie den Fokus des Nutzers zuerst auf diese Inhalte, damit er sie nutzen kann. Beispiele finden Sie unter Fokus auf Seitenebene verwalten.

  • Gestalten Sie Ihre Website so, dass Nutzer jederzeit das nächste Element fokussieren können. Achten Sie auf AutoComplete-Widgets und andere Kontexte, die den Tastaturfokus festhalten können. Sie können den Fokus vorübergehend fixieren, wenn der Nutzer mit einem modalen Dialogfeld und nicht mit dem Rest der Seite interagieren soll. Sie sollten jedoch immer eine Tastatur-Bedienungsmöglichkeit zum Verlassen des modalen Dialogfelds anbieten. Ein Beispiel finden Sie unter Modale Dialogfelder und Tastaturfallen.

Fokussteuerung nutzerfreundlich gestalten

Wenn Sie ein benutzerdefiniertes Steuerelement erstellt haben, sollten Nutzer alle Funktionen nur mit der Tastatur erreichen können. Im Artikel Fokus in Komponenten verwalten finden Sie Informationen dazu, wie Sie den Tastaturzugriff verbessern können.

Inhalte außerhalb des Bildschirms verwalten

Viele Websites haben Inhalte, die zwar im DOM (Document Object Model) vorhanden, aber nicht sichtbar sind, z. B. Links in einem responsiven Leistenmenü oder Schaltflächen in einem modalen Fenster, die noch nicht auf dem Bildschirm eingeblendet sind. Wenn diese Elemente im DOM verbleiben, kann dies in Bezug auf die Tastatureingabe leicht zu Missverständnissen führen. Dies gilt insbesondere für Screenreader, die nicht sichtbare Inhalte als Teil der Seite interpretieren.

Weitere Informationen zum Umgang mit nicht sichtbaren Inhalten

Mit einem Screenreader testen

Die allgemeine Tastaturunterstützung zu verbessern, ist eine gute Grundlage für den nächsten Schritt: Prüfen Sie die Seite auf korrekte Beschriftung und Semantik sowie auf Hindernisse für die Navigation mit Screenreadern.

Wenn Sie nicht wissen, wie semantisches Markup von Hilfstechnologien interpretiert wird, lesen Sie den Hilfeartikel Inhaltsstruktur.

  • Prüfen Sie alle Bilder auf korrekten alt-Text. Eine Ausnahme gilt, wenn Bilder hauptsächlich zu Präsentationszwecken dienen und keine wesentlichen Inhalte sind. Wenn Screenreader ein Bild überspringen sollen, setzen Sie den Wert auf einen leeren String: alt="".
  • Prüfen Sie alle Steuerelemente auf ein Label. Für benutzerdefinierte Steuerelemente ist möglicherweise die Verwendung von aria-label oder aria-labelledby erforderlich. Beispiele finden Sie unter ARIA-Labels und ‑Beziehungen.
  • Prüfen Sie alle benutzerdefinierten Steuerelemente auf eine geeignete role und alle erforderlichen ARIA-Attribute, die ihren Status kommunizieren. Ein benutzerdefiniertes Kästchen benötigt beispielsweise ein role="checkbox" und ein aria-checked="true|false", um seinen Status korrekt zu vermitteln. Im Artikel Einführung in ARIA finden Sie eine allgemeine Übersicht dazu, wie ARIA fehlende Semantik für benutzerdefinierte Steuerelemente bereitstellen kann.
  • Achten Sie darauf, dass die Informationen auf Ihrer Seite sinnvoll fließen. Da Screenreader die Seite in DOM-Reihenfolge durchgehen, werden alle Elemente, die Sie mit CSS visuell neu positioniert haben, in einer unsinnigen Reihenfolge angesagt. Wenn ein Element weiter oben auf der Seite erscheinen soll, verschieben Sie es im DOM nach oben.
  • Achten Sie darauf, dass die Navigation mit Screenreadern für alle Inhalte auf der Seite unterstützt wird. Achten Sie darauf, dass keine Bereiche der Website dauerhaft ausgeblendet oder für den Zugriff über Screenreader blockiert sind.
    • Wenn Inhalte für einen Screenreader ausgeblendet werden sollen, z. B. wenn sie außerhalb des Bildschirms oder nur zur Präsentation gedacht sind, legen Sie für diese Inhalte den Wert aria-hidden="true" fest. Weitere Informationen finden Sie unter Inhalte ausblenden.

Screenreader kennenlernen

Sie haben noch nie einen Screenreader genutzt? Keine Sorge, der Umgang mit diesen Tools lässt sich schnell erlernen. Entwickler müssen in der Regel nur einige einfache Tastenbefehle eingeben.

Wenn Sie einen Mac verwenden, sehen Sie sich dieses Video zu VoiceOver an, dem Screenreader, der in Mac OS enthalten ist. PC-Nutzer können sich dieses Video zu NVDA ansehen, einem durch Spenden unterstützten Open-Source-Screenreader für Windows.

aria-hidden verhindert nicht, dass der Tastaturfokus gesetzt wird

ARIA kann nur die Semantik eines Elements beeinflussen. Sie hat keine Auswirkungen auf das Verhalten des Elements. Mit aria-hidden="true" können Sie ein Element für Screenreader ausblenden. Das ändert jedoch nichts am Fokusverhalten dieses Elements. Für interaktive Inhalte, die nicht im Bild sind, verwenden Sie das Attribut inert, um sicherzustellen, dass sie wirklich aus dem Tastaturfluss entfernt werden. Bei älteren Browsern müssen Sie aria-hidden="true" mit tabindex="-1" kombinieren.

Interaktive Elemente sollten ihren Zweck und ihren Status angeben

Wenn Sie visuelle Hinweise oder Affordances dazu geben, was ein Steuerelement bewirkt, können viele verschiedene Nutzer auf vielen verschiedenen Geräten Ihre Website bedienen und nutzen.

  • Interaktive Elemente wie Links und Schaltflächen sollten sich von nicht interaktiven Elementen unterscheiden lassen. Es ist schwierig für Nutzer, sich auf einer Website oder in einer App zurechtzufinden, wenn sie nicht erkennen können, ob ein Element anklickbar ist. Es gibt viele Möglichkeiten, interaktive Elemente zu kennzeichnen. Häufig werden Links unterstrichen, um sie vom umgebenden Text abzuheben.
  • Ähnlich wie bei der Fokusanforderung benötigen interaktive Elemente wie Links und Schaltflächen den Status hover, um Nutzern mit Maus zu signalisieren, wenn sich der Mauszeiger auf einem anklickbaren Element befindet. Damit diese Elemente jedoch für andere Eingabemethoden zugänglich sind, müssen sie auch ohne hover-Status unterscheidbar sein.

Überschriften und Markierungen nutzen

Überschriften und Markierungselemente geben Ihrer Seite eine semantische Struktur und verbessern die Navigation für Nutzer von Hilfstechnologien erheblich. Viele Nutzer von Screenreadern geben an, dass sie in der Regel versuchen, anhand von Überschriften zu navigieren, wenn sie zum ersten Mal auf einer unbekannten Seite landen.

Screenreader bieten außerdem die Möglichkeit, zu wichtigen Markierungen wie <main> und <nav> zu springen. Aus diesen Gründen ist es wichtig, zu überlegen, wie die Struktur Ihrer Seite die Nutzererfahrung steuern kann.

  • Verwenden Sie die h1-h6-Hierarchie. Überschriften sind eine Art Gliederung für Ihre Seite. Verlassen Sie sich nicht auf das vordefinierte Styling von Überschriften. Behandeln Sie sie stattdessen so, als hätten sie alle dieselbe Größe, und verwenden Sie die semantisch richtige Ebene für primäre, sekundäre und tertiäre Inhalte. Passen Sie dann mithilfe von CSS die Überschriften an Ihr Design an.
  • Verwenden Sie Markierungselemente und Rollen, damit Nutzer sich wiederholende Inhalte überspringen können. Viele Hilfstechnologien bieten Tastenkürzel, um zu bestimmten Bereichen der Seite zu springen, z. B. zu denen, die durch <main>- oder <nav>-Elemente definiert sind. Diese Elemente haben implizite Markierungsrollen. Sie können auch das ARIA-Attribut role verwenden, um Regionen auf der Seite explizit zu definieren, wie in <div role="search">. Weitere Beispiele finden Sie unter Semantik und Navigation durch Inhalte.
  • Verwenden Sie role="application" nur, wenn Sie Erfahrung damit haben. Die Rolle „application“ weist Hilfstechnologien an, ihre Tastenkürzel zu deaktivieren und alle Tastendrücke an die Seite weiterzuleiten. Das bedeutet, dass die Tasten, mit denen sich Nutzer von Screenreadern normalerweise auf der Seite bewegen, nicht mehr funktionieren. Sie müssen alle Tastaturfunktionen selbst implementieren.

Überschriften und Markierungen mit einem Screenreader prüfen

Screenreader wie VoiceOver und NVDA bieten ein Kontextmenü, mit dem wichtige Bereiche auf der Seite übersprungen werden können. Wenn Sie die Barrierefreiheit testen, können Sie mit diesen Menüs einen Überblick über die Seite erhalten und feststellen, ob die Überschriftenebenen angemessen sind und welche Markierungen verwendet werden.

Weitere Informationen finden Sie in diesen Anleitungsvideos zu den Grundlagen von VoiceOver und NVDA.

Prozess automatisieren

Das manuelle Testen einer Website auf Barrierefreiheit kann mühsam und fehleranfällig sein. Es ist sinnvoll, Tests so weit wie möglich zu automatisieren. Sie können Browsererweiterungen und Befehlszeilen-Tests für die Barrierefreiheit verwenden.

  • Bestehen alle Tests der Browsererweiterungen aXe oder WAVE? Es gibt noch andere Optionen, aber diese Erweiterungen können einen manuellen Testprozess sinnvoll ergänzen, da sie subtile Probleme wie unzureichende Kontrastverhältnisse und fehlende ARIA-Attribute erkennen können.
    • Wenn Sie lieber mit der Befehlszeile arbeiten, bietet axe-cli dieselben Funktionen wie die aXe-Browsererweiterung, kann aber über das Terminal ausgeführt werden.
  • Um Regressionen zu vermeiden, insbesondere in einer Umgebung für kontinuierliche Integration, sollten Sie eine Bibliothek wie axe-core in Ihre automatisierte Testsuite einbinden. axe-core ist dieselbe Engine, die auch die aXe-Chrome-Erweiterung antreibt, aber in einem Befehlszeilen-Dienstprogramm.
  • Bietet das Framework oder die Bibliothek, die Sie verwenden, eigene Tools für die Barrierefreiheit? Beispielsweise das Protractor-Accessibility-Plug-in für Angular. Nutzen Sie nach Möglichkeit die verfügbaren Tools.

PWAs mit Lighthouse testen

Lighthouse ist ein Tool, mit dem die Leistung Ihrer progressiven Web-App (PWA) gemessen wird. Außerdem verwendet es die axe-core-Bibliothek für seine Barrierefreiheitstests.

Wenn Sie Lighthouse bereits verwenden, suchen Sie in Ihrem Bericht nach fehlgeschlagenen Tests zur Barrierefreiheit. Beheben Sie die Fehler, um die Nutzerfreundlichkeit Ihrer Website insgesamt zu verbessern.

Zusätzliche Ressourcen