Automatische Tests der Barrierefreiheit

Bisher haben Sie in diesem Kurs etwas über die Person, das Unternehmen und rechtliche Aspekte der digitalen Barrierefreiheit und Grundlagen der digitalen Barrierefreiheit. Konformität. Sie haben sich mit spezifischen Themen des inklusiven Designs befasst und z. B. wann ARIA im Vergleich zu HTML verwendet wird, wie der Farbkontrast gemessen wird, wenn JavaScript unbedingt erforderlich ist.

In den verbleibenden Modulen wenden wir uns vom Design und der Entwicklung auf das Testen für Barrierefreiheit. Wir verwenden einen Testprozess in drei Schritten, automatisierte, manuelle und assistive Technologie-Testtools und -Techniken. Wir verwenden in diesen Testmodulen dieselbe Demo, um die Webpage von nicht barrierefrei zu barrierefrei zu machen.

Jeder Test – automatisiert, manuell und mit Hilfstechnologien – ist entscheidend, um ein möglichst barrierefreies Produkt zu entwickeln.

Unsere Tests stützen sich auf die Richtlinien für barrierefreie Webinhalte (WCAG) 2.1 Konformitätsstufe A und AA zu entwickeln. Beachten Sie, dass die in Ihrer Branche und Ihrem Produkttyp geltenden Gesetze sowie die oder allgemeinen Zielen der Barrierefreiheit vorgibt, und Niveaus zu erfüllen. Wenn für Ihr Projekt kein bestimmter Standard erforderlich ist, sollten Sie die neueste Version der WCAG einhalten. Weitere Informationen finden Sie unter Wie wird die digitale Barrierefreiheit gemessen? allgemeine Informationen zu Audits zur Barrierefreiheit, zu Konformitätstypen/-stufen WCAG und POUR.

Wie Sie wissen, ist die Konformität mit der Barrierefreiheit nicht vollständig, wenn Menschen mit Beeinträchtigungen zu unterstützen. Es ist jedoch ein guter Ausgangspunkt, da es einen Messwert bietet, an dem Sie Tests durchführen können. Wir empfehlen Ihnen, zusätzliche Maßnahmen außerhalb der Konformitätstests für die Barrierefreiheit umfassen, z. B. Usability-Tests mit Menschen mit Beeinträchtigungen durchführen, Beeinträchtigungen, um in Ihrem Team zu arbeiten oder eine Person oder ein Unternehmen zu konsultieren, Fachwissen zu digitaler Barrierefreiheit, damit Sie inklusivere Produkte entwickeln können.

Automatisierte Tests – Grundlagen

Bei automatischen Barrierefreiheitstests wird Software verwendet, um Ihr digitales Produkt auf mögliche Probleme mit der Barrierefreiheit im Hinblick auf vordefinierte Konformitätsstandards für Barrierefreiheit.

Vorteile automatisierter Tests für Barrierefreiheit:

• Einfach zu wiederholende Tests in verschiedenen Phasen des Produktlebenszyklus.
• Nur wenige Schritte und sehr schnelle Ergebnisse.
• Wenige Kenntnisse zur Barrierefreiheit sind erforderlich, um die Tests auszuführen oder die Ergebnisse zu verstehen.

Nachteile automatisierter Tests für Barrierefreiheit:

• Automatisierte Tools erkennen nicht alle Barrierefreiheitsfehler in Ihrem Produkt.
• Falsch positive Meldungen (ein Problem wird gemeldet, das keinen echten WCAG-Verstoß darstellt)
• Für unterschiedliche Produkttypen und Rollen können mehrere Tools erforderlich sein.

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. Wir gehen später noch ausführlicher wie die Zugänglichkeit von Elementen überprüft werden kann, die nicht im manuelle Barrierefreiheitstests testen können.

Arten von automatisierten Tools

Eines der ersten automatisierten Onlinetools für die Barrierefreiheit wurde 1996 vom Center for Applied Special Technology (CAST) entwickelt und The Bobby Report genannt. Heute gibt es Mehr als 100 automatisierte Testtools zur Auswahl von!

Die automatische Tool-Implementierung unterscheidet sich von Browsererweiterungen für Barrierefreiheit im Internet Code-Linters, Desktop- und mobile Anwendungen, Online-Dashboards und sogar Open-Source-APIs, mit denen Sie Ihre eigenen automatisierten Tools erstellen können.

Welches automatisierte Tool Sie verwenden, hängt von vielen Faktoren ab, darunter:

• Anhand welcher Konformitätsstandards und -stufen werden Sie getestet? Dies kann WCAG 2.1, WCAG 2.0, USA Abschnitt 508 oder eine modifizierte Liste von Regeln für die Barrierefreiheit.
• Welche Art von digitalen Produkten testen Sie? Das kann eine Website, eine Webanwendung, eine native mobile App, eine PDF-Datei, ein Infoterminal oder ein anderes Produkt sein.
• In welchem Teil des Softwareentwicklungszyklus testen Sie Ihr Produkt?
• Wie lange dauert es, das Tool einzurichten und zu verwenden? Für Einzelpersonen oder das 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 sind? Sollten Probleme direkt mit einem Ticketverkauf verbunden sein? System?
• Welche Tools eignen sich am besten für Ihre Umgebung? Für Ihr Team?

Es gibt aber noch viele weitere Faktoren, die Sie berücksichtigen sollten. Lesen Sie den Artikel der WAI. über Selecting Web Accessibility Evaluation Tools (Auswahl von Tools zur Bewertung von Barrierefreiheit im Internet) finden Sie weitere Informationen dazu, wie Sie das beste Tool für Sie und Ihr Team auswählen.

Demo: Automatisierter Test

Für die Demo zu automatisierten Tests zur Barrierefreiheit Lighthouse. Lighthouse ist ein automatisiertes Open-Source-Tool, mit dem die Qualität von verschiedene Arten von Prüfungen durchgeführt, darunter Leistung, SEO und Barrierefreiheit.

Unsere Demo ist eine Website, die für eine fiktive Organisation, die Medical Mysteries, erstellt wurde. Club. Diese Website ist für die Demo absichtlich unzugänglich gemacht. Einige davon Ungenügende Barrierefreiheit kann für Sie sichtbar sein, und einige (aber nicht alle) werden unseren automatisierten Test.

Schritt 1

Installieren Sie im Chrome-Browser die Lighthouse-Erweiterung.

Es gibt viele Möglichkeiten, Lighthouse zu integrieren. in Ihren Test-Workflow integrieren. In dieser Demo verwenden wir die Chrome-Erweiterung.

Schritt 2

Wir haben eine Demo in CodePen erstellt. Sehen Sie sich die Seite im Debug-Modus an, um mit den nächsten Tests fortzufahren. Dies ist wichtig, da dadurch das <iframe> entfernt wird, das die Demo-Webseite, die einige Testtools beeinträchtigen kann.

Weitere Informationen über Debug-Modus von CodePen verwenden.

Schritt 3

Öffnen Sie die Chrome-Entwicklertools und wechseln Sie zum Tab "Lighthouse". Alle Kategorieoptionen mit Ausnahme von löschen „Bedienungshilfen“. Behalten Sie den Standardmodus bei und wählen Sie Ihren Gerätetyp aus die Tests ausführen.

Schritt 4

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

Nach Abschluss der Tests zeigt Lighthouse einen Wert an, der Aufschluss darüber gibt, das getestete Produkt barrierefrei ist. Die Lighthouse-Wert wird anhand der Anzahl der Probleme, der Problemtypen und der Auswirkungen auf die Nutzer die erkannten Probleme.

Neben einer Bewertung enthält der Lighthouse-Bericht detaillierte Informationen zu den erkannten Problemen und Links zu Ressourcen, in denen Sie mehr über die Behebung erfahren. Der Bericht enthält außerdem Tests, die bestanden oder nicht zutreffend sind, 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 der automatisch erkannten Probleme mit der Barrierefreiheit an und korrigieren Sie die entsprechenden Stile und das Markup.

Problem 1: ARIA-Rollen

Das erste Problem lautet: „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, um ihre barrierefreie Funktionen.“ Weitere Informationen zu ARIA-Rollenregeln

In unserer Demo schlägt die Schaltfläche zum Abonnieren des Newsletters fehl:

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

Wir helfen Ihnen gerne weiter.

Das „Abonnieren“ Schaltfläche neben dem Eingabefeld hat eine falsche ARIA-Rolle angewendet wird. In diesem Fall kann die Rolle vollständig entfernt werden.

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

Problem 2: ARIA ausgeblendet

"[aria-hidden="true"]-Elemente enthalten fokussierbare Unterelemente. 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>

Wir helfen Ihnen gerne weiter.

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

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

In diesem Fall sollten Sie dieses Attribut aus der Eingabe entfernen, damit Personen mithilfe von Hilfstechnologien auf Informationen zugreifen und diese in das Formularfeld eingeben können.

Problem 3: Schaltflächenname

Die Schaltflächen haben keinen zugänglichen Namen. Wenn eine Schaltfläche keinen barrierefreien Namen hat, wird sie von Screenreadern nur als „Schaltfläche“ angesagt. Dadurch ist sie für Nutzer, die auf Screenreader angewiesen sind, unbrauchbar.

Weitere Informationen zu den Regeln für die Benennung von Schaltflächen

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

Wir helfen Ihnen gern weiter.

Wenn Sie die falsche ARIA-Rolle aus dem Schaltflächenelement in Problem 1 entfernen, wird das Wort „Abonnieren“ zum barrierefreien Namen der Schaltfläche. Diese Funktion ist in das semantische HTML-Schaltflächenelement integriert. Es sind zusätzliche Musteroptionen für komplexere Situationen.

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

Problem 4: ALT-Attribute für Bilder

In Bildelementen fehlen [alt]-Attribute. Informative Elemente sollten für einen kurzen, beschreibenden alternativen Text. Dekorative Elemente können mit einem leeren ALT-Attribut ignoriert werden. Weitere Informationen zum alternativen Bildtext Regeln.

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

Wir beheben das Problem.

Da das Logobild auch ein Link ist, Bildmodul, das als umsetzbar bezeichnet wird. Bild und erfordert alternative Textinformationen zum Zweck des Bildes. Normalerweise ist das erste Bild auf der Seite ein Logo. Sie können also davon ausgehen, dass Ihre Nutzer mit Hilfstechnologien das wissen, und entscheiden, diese zusätzlichen kontextbezogenen Informationen 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 den Regeln für Linktext

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

Wir helfen Ihnen gern weiter.

Alle Bilder, auf die Sie reagieren können, müssen auf der Seite angeben, wo über den Link an die Nutzenden gesendet werden. Eine Möglichkeit, dieses Problem zu beheben, besteht darin, dem Bild einen alternativen Text zum Zweck hinzuzufügen, wie Sie es im Beispiel mit dem Logobild getan haben. Das funktioniert hervorragend für ein Bild mit einem <img>-Tag, aber für <svg>-Tags kann diese Methode nicht verwendet werden.

Für die Social-Media-Symbole, für die <svg>-Tags verwendet werden, können Sie ein anderes Muster für alternative Beschreibungen verwenden, das auf SVGs ausgerichtet ist. Sie können die Informationen zwischen den <a>- und <svg>-Tags einfügen und dann visuell für Nutzer ausblenden, eine unterstützte ARIA hinzufügen oder andere Optionen verwenden. Je nach für Ihre Umgebung und Ihre Code-Einschränkungen, könnte eine Methode besser sein als eine andere.

Verwenden Sie die einfachste Musteroption mit der größten Abdeckung durch Hilfstechnologien. Dazu fügen Sie dem <svg>-Tag ein role="img" hinzu und fügen 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 Nutzende schwierig oder unmöglich zu lesen. Weitere Informationen zu Farbkontrastregeln

Es wurden zwei Beispiele gemeldet.

Problem beheben

Auf der Webseite wurden viele Probleme mit dem Farbkontrast erkannt. Wie Sie im Modul Farbe und Kontrast erfahren haben, gilt für Text in normaler Größe (weniger als 18 pt/24 px) ein Farbkontrast von 4,5:1. Für Text in großer Schrift (mindestens 18 pt/24 px oder 14 pt/18,5 px fett) und wichtige Symbole muss das Kontrastverhältnis 3:1 betragen.

Für den Seitentitel muss der blaugrüne Text dem 3:1-Farbkontrast entsprechen da es sich um großen Text mit 24 Pixeln handelt. Die blaugrünen Schaltflächen werden als normaler Text mit einer Schriftgröße von 16 Pixeln fett betrachtet, d. h. sie müssen dem Farbformat 4,5:1 entsprechen. Kontrastanforderung.

In diesem Fall könnten wir eine Teal-Farbe finden, die dunkel genug ist, um 4,5:1 zu erreichen, oder wir könnten die Größe des Schaltflächentexts auf 18,5 px fett erhöhen und den Teal-Farbwert leicht ändern. Beide Methoden entsprechen der Ästhetik des Designs.

Der 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, um die Anforderungen an den Farbkontrast von 4,5:1 zu erfüllen.

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>

Wir helfen Ihnen gern weiter.

In dieser Demo haben wir eine CSS-Klasse verwendet, um die ungeordnete Liste zu simulieren, mit einem <ul>-Tag. Durch die fehlerhafte Codierung dieses Codes wurden die in diesem Tag enthaltenen semantischen HTML-Funktionen entfernt. Indem wir die Klasse durch ein echtes <ul>-Tag ersetzen und das zugehörige CSS anpassen, 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

Der tabindex-Wert einiger Elemente ist 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>

</ph> Problem beheben

Sofern kein bestimmter Grund vorliegt, die natürliche Tabulatorreihenfolge auf einer Webseite zu unterbrechen, ist für das Attribut „tabindex“ keine positive Ganzzahl erforderlich. Um die natürliche Tabulatorreihenfolge beizubehalten, können wir entweder den Tabindex in 0 ändern oder das Attribut vollständig entfernen.

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

Schritt 6

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

Wir haben alle automatischen Updates für Bedienungshilfen auf eine neue CodePen herunter.

Nächster Schritt

Sehr gut. Sie haben schon viel erreicht, aber wir sind noch nicht fertig. Als Nächstes geht es um manuelle Prüfungen, wie im Modul Manuelle Tests zur Barrierefreiheit beschrieben.

Wissen testen

Ihr Wissen über automatisierte Tests zur Barrierefreiheit testen