Bisher haben Sie in diesem Kurs etwas über den Einzelnen, 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 werden Verwenden Sie in diesen Testmodulen dieselbe Demo, um die Webseite vom nicht barrierefrei zugänglich sind.
Jeder Test – ob automatisierte, manuelle und assistive Technologien – ist entscheidend, um die barrierefreies Produkt.
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 Ihre Branche, Ihr Produkttyp, lokale/länderspezifische Gesetze und Richtlinien oder allgemeinen Zielen der Barrierefreiheit vorgeben, welche Richtlinien die Sie umsetzen können. Wenn für Ihr Unternehmen kein wird die neueste Version der WCAG empfohlen. 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. Aber es ist ein guter Ausgangspunkt, da sie einen Messwert bietet, den Sie testen 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, um Sie bei der Entwicklung inklusiver Produkte zu unterstützen.
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 zur Barrierefreiheit:
- Einfach zu wiederholende Tests in verschiedenen Phasen des Produktlebenszyklus
- Nur ein paar Schritte und sehr schnelle Ergebnisse
- Wenige Kenntnisse zur Barrierefreiheit sind erforderlich, um die Tests auszuführen oder die Ergebnisse zu verstehen
Nachteile automatisierter Tests zur Barrierefreiheit:
- Automatisierte Tools erkennen nicht alle Fehler bezüglich der Barrierefreiheit in Ihrem Produkt
- Falsch-positive Ergebnisse (es wurde ein Problem gemeldet, das kein echter Verstoß gegen die WCAG ist)
- Für unterschiedliche Produkttypen und Rollen können mehrere Tools erforderlich sein.
Automatisierte Tests sind ein guter erster Schritt, um zu prüfen, ob Ihre Website oder App aber nicht alle Prüfungen können 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 automatisierter Tools
Eines der ersten automatisierten Online-Testtools für Barrierefreiheit wurde in 1996 vom Center for Applied Special Technology (CAST), unter dem Namen The Bobby Report. 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.
Für welches automatisierte Tool Sie sich entscheiden, hängt unter anderem von folgenden Faktoren ab:
- 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, native mobile App, PDF, Kiosk oder ein anderes Produkt.
- 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: Designschaffende, Entwickelnde, QA usw.?
- Wie oft soll die Barrierefreiheit überprüft werden? Welche Details sollten im Bericht enthalten sind? Sollten Probleme direkt mit einem Ticketverkauf verbunden sein? System?
- Welche Tools funktionieren in Ihrer Umgebung am besten? Für Ihr Team?
Darüber hinaus sind viele weitere Faktoren zu berücksichtigen. 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. Für diese Demo verwenden wir die Chrome-Erweiterung.
Schritt 2
Wir haben eine Demo in CodePen erstellt.
Rufen Sie es im Debug-Modus auf, um mit der
nächsten Tests. 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". Deaktivieren Sie alle Kategorieoptionen mit Ausnahme von „Bedienungshilfen“. Behalten Sie den Standardmodus bei und wählen Sie Ihren Gerätetyp aus die Tests ausführen.
Schritt 4
Klicken Sie auf den Tab „Seitenaufbau analysieren“. und lassen Sie Lighthouse Zeit zum Testen.
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 darüber, gefundene Probleme und Links zu Ressourcen mit weiteren Informationen zur Behebung . Der Bericht enthält auch bestandene oder nicht zutreffende Tests sowie eine Liste mit zusätzlichen Elementen, die manuell überprüft werden sollen.
Schritt 5
Sehen wir uns nun ein Beispiel für jedes Problem mit der automatischen Barrierefreiheit an. die relevanten Stile und Markups erkannt und korrigiert.
Problem 1: ARIA-Rollen
Das erste Problem besagt: „Elemente mit einer ARIA-Rolle [role], für die Kinder Folgendes benötigen: die eine bestimmte [role] enthalten, 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>
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 Nachfolgerelemente. Fokussierbar
Nachfolgerelemente in einem [aria-hidden="true"]
-Element verhindern, dass diese interaktiven
Elemente davon ab, dass sie für Nutzende von assistiven Technologien wie dem Bildschirm
Lesern. Weitere Informationen zu aria-hidden
-Regeln
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
Auf das Eingabefeld wurde das Attribut aria-hidden="true"
angewendet. Wird hinzugefügt
Durch dieses Attribut wird das Element (und alle untergeordneten Elemente) vor
Hilfstechnologien nutzen.
<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 kein der barrierefreie Name wird von Screenreadern als Schaltfläche angesagt, sodass sie für alle Nutzenden, die auf Screenreader angewiesen sind. Weitere Informationen zu Regeln für Schaltflächennamen
<button role="list" type="submit" tabindex="1">Subscribe</button>
Wenn Sie die falsche ARIA-Rolle aus dem Schaltflächenelement in Ausgabe 1, das Wort „Abonnieren“ wird zur barrierefreien Schaltfläche Namen. 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 ignoriert werden mit
ein leeres ALT-Attribut. Weitere Informationen zum alternativen Bildtext
Regeln.
<a href="index.html">
<img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>
Da das Logobild auch ein Link ist, Bildmodul, das als umsetzbar bezeichnet wird. Bild und erfordert alternative Textinformationen über den Zweck des Bildes. Normalerweise ist das erste Bild auf der Seite ein Logo, sodass Sie davon ausgehen können, Ihre AT-Nutzer wissen dies. Möglicherweise möchten Sie diese zusätzliche Kontextinformationen zu Ihrer Bildbeschreibung hinzufügen.
<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 erkennbaren Namen. Linktext (und alternativen Text für Bilder, die als Links verwendet werden, die erkennbar, einzigartig und fokussierbar sind, Navigation für Nutzer von Screenreadern. Weitere Informationen zu Linktext-Regeln
<a href="#!"><svg><path>...</path></svg></a>
Alle verwertbaren Bilder auf der Seite müssen Informationen darüber enthalten,
werden die Nutzer über den Link weitergeleitet. Eine Methode zur Behebung dieses Problems
ist das Hinzufügen einer alternativen
dem Bild einen Text zum Zweck hinzu, wie Sie es auf dem Logobild im
Beispiel oben. Dies funktioniert gut für ein Bild 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
Targeting von SVGs hinzufügen, fügen Sie die Informationen zwischen den Tags <a>
und <svg>
ein und
blenden Sie ihn visuell für Nutzer aus, fügen Sie eine unterstützte ARIA hinzu oder legen Sie andere Optionen fest. Je nach
für Ihre Umgebung und Ihre Code-Einschränkungen eine Methode vorzuziehen ist,
eine andere. Verwenden wir die einfachste Musteroption mit dem
Technologieabdeckung hinzugefügt. Dabei wird dem <svg>
-Tag ein role="img"
hinzugefügt und
einschließlich eines <title>
-Elements.
<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.
Auf der Webseite wurden viele Probleme mit dem Farbkontrast erkannt. Wie Sie in diesem Kurs gelernt haben, das Modul Farbe und Kontrast, Text in normaler Größe (weniger als 18 pt / 24 Pixel) hat einen Farbkontrast, der 4,5:1, bei großem Text (mindestens 18 pt / 24 px oder 14 pt / 18,5 px fett) und wichtige Symbole die 3:1-Anforderung erfüllen.
Für den Seitentitel muss der blaugrüne Text dem 3:1-Farbkontrast entsprechen da es sich um großen Text mit 24 Pixel 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 türkisfarbene Farbe finden, die dunkel genug für 4,5:1 war, oder den Schaltflächentext um 18,5 Pixel fett formatieren und die blaugrünen Farbwert leicht. Beide Methoden entsprechen dem Design die Ästhetik.
Der gesamte graue Text auf dem weißen Hintergrund beeinträchtigt ebenfalls den Farbkontrast, außer für die beiden größten Überschriften auf der Seite. Dieser Text muss abgedunkelt werden, damit Anforderungen an den Farbkontrast von 4,5:1.
Problem 7: Listenstruktur
Listenelemente (<li>
) befinden sich nicht in übergeordneten <ul>
- oder <ol>
-Elementen.
Listenelemente (<li>
) müssen für Screenreader in einem übergeordneten Element enthalten sein
<ul>
oder <ol>
, damit sie richtig angesagt werden.
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>
In dieser Demo haben wir eine CSS-Klasse verwendet, um die ungeordnete Liste zu simulieren,
mit einem <ul>
-Tag. Bei falscher Programmierung dieses Codes haben wir die inhärenten
semantische HTML-Funktionen, die in dieses Tag integriert sind. Indem sie die Klasse durch eine echte
<ul>
-Tag und durch Ändern des zugehörigen CSS-Codes wurde dieses Problem mit den Bedienungshilfen behoben.
<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 Nr. 8 – Tabindex
Bei einigen Elementen ist ein [tabindex]-Wert größer als 0. Ein Wert größer als 0 impliziert eine explizite Navigationsreihenfolge. Das ist zwar technisch möglich, für Nutzende, die auf assistive Technologien angewiesen sind, frustrierende Erfahrungen. Weitere Informationen zu Tabindex-Regeln
<button type="submit" tabindex="1">Subscribe</button>
Es sei denn, es gibt einen bestimmten Grund, die natürliche TAB-Reihenfolge im Web zu stören.
gibt es keine positive Ganzzahl für das Tabindex-Attribut. Bis
behalten Sie die natürliche Tab-Reihenfolge bei.
Wir können entweder den Tab-Index in 0
ändern oder
vollständig entfernen.
<button type="submit">Subscribe</button>
Schritt 6
Nachdem Sie nun alle Probleme mit automatischen Bedienungshilfen behoben haben, öffnen Sie ein neues Debug-Modus zu öffnen. Führen Sie die Lighthouse-Prüfung zur Barrierefreiheit noch einmal aus. Dein Punktestand viel besser aus als beim ersten Durchlauf.
Wir haben alle automatischen Updates für Bedienungshilfen auf eine neue CodePen herunter.
Nächster Schritt
Sehr gut. Sie haben bereits viel erreicht, aber wir sind noch nicht fertig! Als Nächstes gehen wir zu manuellen Prüfungen über, wie in der manuelle Barrierefreiheitstests testen können.
Wissen testen
Testen Sie Ihr Wissen über automatisierte Tests zur Barrierefreiheit
Welche Art von Tests sollten Sie durchführen, um sicherzustellen, dass Ihre Website barrierefrei ist?
Welche Fehler werden bei automatischen Tests erkannt?