Automatische Tests der Barrierefreiheit

Bisher haben Sie in diesem Kurs etwas über die individuellen, geschäftlichen und rechtlichen Aspekte der digitalen Barrierefreiheit sowie die Grundlagen der Konformität mit den Richtlinien zur digitalen Barrierefreiheit gelernt. Sie haben sich mit bestimmten Themen im Zusammenhang mit inklusivem Design und Programmieren beschäftigt, z. B. wann ARIA im Vergleich zu HTML verwendet werden sollte, wie der Farbkontrast gemessen wird und wann JavaScript unerlässlich ist.

In den verbleibenden Modulen geht es nicht mehr um Design und Entwicklung, sondern um das Testen der Barrierefreiheit. Wir stellen einen dreistufigen Testprozess vor, der automatisierte, manuelle und assistive Technologien umfasst. Wir verwenden in diesen Testmodulen dieselbe Demo, um die Webseite von „nicht zugänglich“ zu „zugänglich“ zu entwickeln.

Jeder Test, ob automatisiert, manuell oder mit unterstützenden Technologien, ist entscheidend, um ein möglichst barrierefreies Produkt zu entwickeln. Unsere Tests basieren auf den Konformitätsstufen A und AA der Richtlinien für barrierefreie Webinhalte (WCAG) 2.1.

Denken Sie daran, dass Ihre Branche, Ihr Produkttyp, lokale und länderspezifische Gesetze und Richtlinien oder allgemeine Barrierefreiheitsziele bestimmen, welche Richtlinien Sie befolgen und welche Stufen Sie erreichen müssen. Wenn Sie für Ihr Projekt keinen bestimmten Standard benötigen, empfehlen wir, die neueste Version der WCAG zu verwenden. Weitere Informationen zu Barrierefreiheitsprüfungen, Konformitätstypen/-stufen, WCAG und POUR finden Sie unter Wie wird digitale Barrierefreiheit gemessen?.

Wie Sie jetzt wissen, ist die Einhaltung der Barrierefreiheitsrichtlinien nicht alles, was Sie tun können, um Menschen mit Behinderungen zu unterstützen. Sie ist jedoch ein guter Ausgangspunkt, da sie einen Messwert liefert, anhand dessen Sie Tests durchführen können. Wir empfehlen Ihnen, zusätzlich zu den Konformitätstests die folgenden Maßnahmen zu ergreifen, um inklusivere Produkte zu entwickeln:

• Führen Sie Usability-Tests mit Menschen mit Behinderung durch.
• Stellen Sie Menschen mit Behinderungen in Ihrem Team ein.
• Wenden Sie sich an eine Person oder ein Unternehmen mit Fachwissen im Bereich digitale Barrierefreiheit.

Grundlagen des automatisierten Testens

Beim automatisierten Barrierefreiheitstest wird Software verwendet, um Ihr digitales Produkt anhand vordefinierter Standards für die Barrierefreiheit auf Barrierefreiheitsprobleme zu prüfen.

Vorteile automatisierter Barrierefreiheitstests:

• Tests in verschiedenen Phasen des Produktlebenszyklus schnell wiederholen
• Die Ausführung ist ganz einfach und die Ergebnisse sind schnell verfügbar.
• Für die Durchführung der Tests oder das Verständnis der Ergebnisse sind nur geringe Kenntnisse im Bereich Barrierefreiheit erforderlich.

Nachteile automatisierter Tests für Bedienungshilfen:

• Automatisierte Tools erkennen nicht alle Barrierefreiheitsfehler in Ihrem Produkt.
• Gemeldete falsch positive Ergebnisse (ein Problem wird gemeldet, das keinen tatsächlichen WCAG-Verstoß darstellt)
• Für verschiedene Produkttypen und Rollen sind möglicherweise mehrere Tools erforderlich.

Automatisierte Tests sind ein guter erster Schritt, um die Barrierefreiheit Ihrer Website oder App zu prüfen. Allerdings können nicht alle Prüfungen automatisiert werden. Im Modul Manuelle Barrierefreiheitstests erfahren Sie mehr dazu, wie Sie die Barrierefreiheit von Elementen prüfen, die nicht automatisiert werden können.

Arten von automatisierten Tools

Eines der ersten automatisierten Online-Tools zum Testen der Barrierefreiheit wurde 1996 vom Center for Applied Special Technology (CAST) entwickelt und hieß The Bobby Report. Heute gibt es über 100 Tools für automatisierte Tests.

Die Implementierung automatisierter Tools variiert von Browsererweiterungen für Barrierefreiheit über Code-Linter, Desktop- und mobile Anwendungen, Online-Dashboards bis hin zu Open-Source-APIs, mit denen Sie Ihre eigenen automatisierten Tools erstellen können.

Welches automatisierte Tool Sie verwenden, kann von vielen Faktoren abhängen, darunter:

• Welche Konformitätsstandards und ‑stufen werden getestet? Dazu können WCAG 2.2, WCAG 2.1, US-Paragraf 508 oder eine modifizierte Liste von Barrierefreiheitsregeln gehören.
• Welche Art von digitalem Produkt testen Sie? Das kann eine Website, eine Web-App, eine native mobile App, ein PDF, ein Infoterminal oder ein anderes Produkt sein.
• In welcher Phase des Softwareentwicklungszyklus testen Sie Ihr Produkt?
• Wie viel Zeit ist für die Einrichtung und Nutzung des Tools erforderlich? Für eine Einzelperson, ein Team oder ein Unternehmen?
• Wer führt den Test durch: Designer, Entwickler, QA oder jemand anderes?
• Wie oft soll die Barrierefreiheit geprüft werden? Welche Details sollten im Bericht enthalten sein? Sollten Probleme direkt mit einem Ticketsystem verknüpft sein?
• Welche Tools funktionieren in Ihrer Umgebung am besten? Für Ihr Team?

Es gibt viele weitere Faktoren, die berücksichtigt werden müssen. Weitere Informationen zur Auswahl des besten Tools für Sie und Ihr Team finden Sie im WAI-Artikel Selecting Web Accessibility Evaluation Tools.

Demo: Automatisierter Test

Für die Demo zu automatisierten Tests zur Barrierefreiheit verwenden wir Lighthouse von Chrome. Lighthouse ist ein automatisiertes Open-Source-Tool, mit dem sich die Qualität von Webseiten durch verschiedene Arten von Prüfungen verbessern lässt, z. B. in Bezug auf Leistung, SEO und Barrierefreiheit.

Unsere Demo ist eine Website, die für eine fiktive Organisation, den Medical Mysteries Club, erstellt wurde. Diese Website ist für die Demo bewusst nicht zugänglich. Einige dieser Barrieren sind für Sie sichtbar, andere (aber nicht alle) werden in unserem automatisierten Test erkannt.

Schritt 1

Installieren Sie die Lighthouse-Erweiterung in Ihrem Chrome-Browser.

Es gibt viele Möglichkeiten, Lighthouse in Ihren Test-Workflow einzubinden. Für diese Demo verwenden wir die Chrome-Erweiterung.

Schritt 2

Wir haben eine Demo in CodePen erstellt. Sehen Sie sich die Meldung im Fehlerbehebungsmodus an, um mit den nächsten Tests fortzufahren. Das ist wichtig, da dadurch die <iframe> entfernt wird, die die Demowebseite umgibt und die einige Testtools beeinträchtigen kann.

Weitere Informationen zum Debug-Modus von CodePen

Schritt 3

Öffnen Sie die Chrome-Entwicklertools und rufen Sie den Tab „Lighthouse“ auf. Entfernen Sie alle Häkchen bei den Kategorieoptionen mit Ausnahme von „Barrierefreiheit“. Behalten Sie den Standardmodus bei und wählen Sie den Gerätetyp aus, auf dem Sie die Tests ausführen.

Schritt 4

Klicken Sie auf Seitenaufbau analysieren und geben Sie Lighthouse Zeit, die Tests auszuführen.

Nach Abschluss der Tests wird in Lighthouse eine Punktzahl angezeigt, die angibt, wie barrierefrei das getestete Produkt ist. Die Lighthouse-Punktzahl wird anhand der Anzahl der Probleme, der Problemtypen und der Auswirkungen der erkannten Probleme auf die Nutzer berechnet.

Der Lighthouse-Bericht enthält nicht nur eine Punktzahl, sondern auch detaillierte Informationen zu den erkannten Problemen und Links zu Ressourcen, in denen Sie mehr über die Behebung dieser Probleme erfahren. Der Bericht enthält auch bestandene oder nicht zutreffende Tests sowie eine Liste mit zusätzlichen Elementen, die manuell geprüft werden müssen.

Schritt 5

Sehen Sie sich nun ein Beispiel für jedes automatisch erkannte Problem mit der Barrierefreiheit an und korrigieren Sie die entsprechenden Formatierungen und das Markup.

Problem 1: ARIA-Rollen

Im ersten Problem wird Folgendes beschrieben: „Den Elementen mit einer ARIA-[role], deren untergeordnete Elemente eine bestimmte [role] enthalten müssen, fehlen einige oder alle dieser erforderlichen untergeordneten Elemente. Einige übergeordnete ARIA-Rollen müssen bestimmte untergeordnete Rollen enthalten, damit sie die beabsichtigten Hilfsfunktionen erfüllen können.“ Weitere Informationen zu ARIA-Rollenregeln

In unserer Demo schlägt der Newsletter-Abonnement-Button fehl:

<button role="list" type="submit" tabindex="1">Subscribe</button>

Lasst uns das beheben.

Dem „Abonnieren“-Button neben dem Eingabefeld ist eine falsche ARIA-Rolle zugewiesen. In diesem Fall kann die Rolle vollständig entfernt werden.

<button type="submit" tabindex="1">Subscribe</button>

Problem 2: ARIA hidden

"[aria-hidden="true"]-Elemente enthalten fokussierbare Nachfolgerelemente. Fokussierbare Nachfolgerelemente in einem [aria-hidden="true"]-Element führen dazu, dass Nutzer von Hilfstechnologien wie Screenreadern solche interaktiven Elemente nicht verwenden können. Weitere Informationen zu aria-hidden-Regeln

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

Lasst uns das beheben.

Auf das Eingabefeld wurde das Attribut aria-hidden="true" angewendet. Wenn Sie dieses Attribut hinzufügen, wird das Element (und alles, was darunter verschachtelt ist) für assistive Technologien ausgeblendet.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

In diesem Fall sollten Sie das Attribut aus der Eingabe entfernen, damit Nutzer mit unterstützenden Technologien auf das Formularfeld zugreifen und Informationen eingeben können.

Problem 3: Name des Buttons

Buttons haben keinen für Screenreader zugänglichen Namen. Wenn ein Button keinen barrierefreien Namen hat, wird er von Screenreadern nur als „Button“ angesagt. Dadurch ist er für Nutzer, die auf Screenreader angewiesen sind, unbrauchbar.

Weitere Informationen zu den Regeln für Schaltflächennamen

<button role="list" type="submit" tabindex="1">Subscribe</button>

Lasst uns das beheben.

Wenn Sie die ungenaue ARIA-Rolle aus dem Schaltflächenelement in Problem 1 entfernen, wird das Wort „Abonnieren“ zum zugänglichen Namen der Schaltfläche. Diese Funktion ist in das semantische HTML-Schaltflächenelement integriert. Für komplexere Situationen gibt es zusätzliche Musteroptionen.

<button type="submit" tabindex="1">Subscribe</button>

Problem 4: ALT-Attribute für Bilder

Bildelementen fehlen [alt]-Attribute. Für informative Elemente sollte ein kurzer, beschreibenden alternativer Text verwendet werden. Dekorative Elemente können mit einem leeren ALT-Attribut ignoriert werden. Weitere Informationen zu den Regeln für Alternativtext für Bilder

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

Lasst uns das beheben.

Da das Logo-Bild auch ein Link ist, wissen Sie aus dem Bildmodul, dass es sich um ein interaktives Bild handelt und alternativer Text zum Zweck des Bildes erforderlich ist. Normalerweise ist das erste Bild auf der Seite ein Logo. Sie können also davon ausgehen, dass Nutzer von AT dies wissen, und möglicherweise entscheiden Sie sich, diese zusätzlichen Kontextinformationen nicht in die Bildbeschreibung aufzunehmen.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

Problem 5: Linktext

Links haben keinen leicht erkennbaren Namen. Linktext, der erkennbar, einzigartig und fokussierbar ist, erleichtert Screenreader-Nutzern die Verwendung. Dies gilt auch für alternativen Text für Bilder, die als Links verwendet werden. Weitere Informationen zu Regeln für Linktext

<a href="#!"><svg><path>...</path></svg></a>

Lasst uns das beheben.

Alle anklickbaren Bilder auf der Seite müssen Informationen dazu enthalten, wohin Nutzer über den Link weitergeleitet werden. Eine Möglichkeit, dieses Problem zu beheben, besteht darin, dem Bild Alternativtext hinzuzufügen, der den Zweck des Bildes beschreibt, wie Sie es im Beispiel beim Logo getan haben. Das funktioniert gut für Bilder mit einem <img>-Tag, aber <svg>-Tags können diese Methode nicht verwenden.

Für die Social-Media-Symbole, die <svg>-Tags verwenden, können Sie ein anderes alternatives Beschreibungsmuster für SVGs verwenden, die Informationen zwischen den <a>- und <svg>-Tags hinzufügen und dann visuell für Nutzer ausblenden, ein unterstütztes ARIA oder andere Optionen hinzufügen. Je nach Umgebung und Codebeschränkungen kann eine Methode besser als eine andere sein.

Verwenden Sie die einfachste Musteroption mit der größten Unterstützung für assistive Technologien. Fügen Sie dazu dem <svg>-Tag ein role="img"-Attribut hinzu und fügen Sie ein <title>-Element ein.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

Problem 6: Farbkontrast

Das Kontrastverhältnis von Hintergrund- und Vordergrundfarben ist nicht ausreichend. Text mit geringem Kontrast ist für viele Nutzer schlecht oder gar nicht lesbar. Weitere Informationen zu Regeln für den Farbkontrast

Es wurden zwei Beispiele gemeldet.

Lasst uns das beheben.

Auf der Webseite wurden viele Probleme mit dem Farbkontrast erkannt. Wie Sie im Modul Farbe und Kontrast gelernt haben, gilt für Text in normaler Größe (unter 18 pt / 24 px) ein Farbkontrastverhältnis von 4,5:1, während für Text in großer Größe (mindestens 18 pt / 24 px oder 14 pt / 18,5 px fett) und wichtige Symbole ein Kontrastverhältnis von 3:1 erforderlich ist.

Für den Seitentitel muss der türkisblaue Text die Anforderung an den Farbkontrast von 3:1 erfüllen, da es sich um Text mit einer Schriftgröße von 24 Pixel handelt. Die türkisblauen Schaltflächen gelten jedoch als normal großer Text mit 16 px und fettem Schriftschnitt.Daher müssen sie die Anforderung an den Farbkontrast von 4,5:1 erfüllen.

In diesem Fall könnten wir eine dunkelblaue Farbe finden, die den Kontrast von 4,5:1 erfüllt, oder die Größe des Schaltflächentexts auf 18,5 px fett erhöhen und den Wert der dunkelblauen Farbe leicht ändern. Beide Methoden entsprechen der Ästhetik des Designs.

Der gesamte graue Text auf dem weißen Hintergrund erfüllt ebenfalls nicht die Anforderungen an den Farbkontrast, mit Ausnahme der beiden größten Überschriften auf der Seite. Dieser Text muss abgedunkelt werden, damit er den Anforderungen an das Farbkontrastverhältnis von 4,5:1 entspricht.

Problem 7: Listenstruktur

Listenelemente (<li>) befinden sich nicht in übergeordneten <ul>- oder <ol>-Elementen. Listenelemente (<li>) müssen sich in einem übergeordneten <ul>- oder <ol>-Element befinden, damit Screenreader sie richtig ansagen können.

Weitere Informationen zu Listenregeln

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

Lasst uns das beheben.

In dieser Demo haben wir eine CSS-Klasse verwendet, um die ungeordnete Liste zu simulieren, anstatt das <ul>-Tag zu verwenden. Wenn wir diesen Code falsch geschrieben haben, haben wir die semantischen HTML-Funktionen entfernt, die in dieses Tag integriert sind. Wenn wir die Klasse durch ein echtes <ul>-Tag ersetzen und das zugehörige CSS ändern, beheben wir dieses Problem mit der Barrierefreiheit.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

Problem 8: tabindex

Einige Elemente haben einen tabindex-Wert größer als 0. Ein Wert größer als 0 impliziert eine explizite Navigationsanordnung. Das ist zwar technisch möglich, aber für Nutzer, die auf Hilfstechnologien angewiesen sind, häufig frustrierend. Weitere Informationen zu tabindex-Regeln

<button type="submit" tabindex="1">Subscribe</button>

Lasst uns das beheben.

Sofern es keinen bestimmten Grund gibt, die natürliche Tab-Reihenfolge auf einer Webseite zu unterbrechen, ist keine positive Ganzzahl für ein „tabindex“-Attribut erforderlich. Um die natürliche Tab-Reihenfolge beizubehalten, können wir entweder den tabindex auf 0 ändern oder das Attribut ganz entfernen.

<button type="submit">Subscribe</button>

Schritt 6

Nachdem Sie alle automatisierten Probleme mit der Barrierefreiheit behoben haben, öffnen Sie eine neue Seite im Debug-Modus. Führen Sie die Lighthouse-Prüfung der Barrierefreiheit noch einmal aus. Ihr Ergebnis sollte viel besser sein als beim ersten Lauf.

Wir haben alle diese automatischen Barrierefreiheitsupdates auf einen neuen CodePen angewendet.

Nächster Schritt

Sehr gut. Sie haben schon viel erreicht, aber wir sind noch nicht fertig. Als Nächstes werden wir uns mit manuellen Prüfungen befassen, wie im Modul Manuelle Barrierefreiheitstests beschrieben.