Bisher haben Sie in diesem Kurs die individuellen, geschäftlichen und rechtlichen Aspekte der digitalen Barrierefreiheit kennengelernt und die Grundlagen der Konformität mit der digitalen Barrierefreiheit kennengelernt. Sie haben sich unter anderem über Themen im Zusammenhang mit inklusivem Design und Programmierung informiert, z. B. wann Sie ARIA und HTML verwenden und wie der Farbkontrast gemessen wird, wenn JavaScript wichtig ist.
In den verbleibenden Modulen gehen wir vom Entwerfen und Entwickeln auf das Testen der Barrierefreiheit über. Wir verwenden einen dreistufigen Testprozess, der automatisierte, manuelle und assistive Testtools und -verfahren umfasst. In diesen Testmodulen verwenden wir dieselbe Demo, um die Webseite von „nicht zugänglich“ zu „zugänglich“ zu machen.
Jeder Test – automatisierte, manuelle und assistive Technologien – ist entscheidend, um ein möglichst barrierefreies Produkt zu erhalten.
Unsere Tests basieren auf den Richtlinien für barrierefreie Webinhalte (Web Content Accessibility Guidelines, WCAG) 2.1 Konformitätsstufe A und AA als Standards. Deine Branche, dein Produkttyp, lokale/länderspezifische Gesetze und Richtlinien sowie allgemeine Ziele zur Barrierefreiheit bestimmen, welche Richtlinien zu befolgen sind und welche Stufen erreicht werden müssen. Wenn Sie keinen bestimmten Standard für Ihr Projekt benötigen, empfiehlt es sich, der neuesten Version der WCAG zu folgen. Allgemeine Informationen zu Audits, Konformitätsarten/-leveln, WCAG und POUR finden Sie unter Wie wird die digitale Barrierefreiheit gemessen?.
Wie Sie wissen, ist Barrierefreiheit im Internet bei der Unterstützung von Menschen mit Beeinträchtigungen nicht das vollständige Geschehen. Er ist jedoch ein guter Ausgangspunkt, da er einen Messwert zum Testen bietet. Wir empfehlen Ihnen, neben den Konformitätstests für die Barrierefreiheit weitere Maßnahmen zu ergreifen, z. B. Usability-Tests mit Menschen mit Behinderungen durchzuführen, Menschen mit Behinderungen für die Arbeit in Ihrem Team einzustellen oder eine Person oder ein Unternehmen mit Fachwissen über digitale Barrierefreiheit zu beraten, um integrativere Produkte zu entwickeln.
Grundlagen automatisierter Tests
Beim automatischen Testen der Barrierefreiheit wird mithilfe von Software Ihr digitales Produkt auf Barrierefreiheit anhand vordefinierter Konformitätsstandards für Barrierefreiheit geprüft.
Vorteile automatisierter Tests zur Barrierefreiheit:
- Einfach zu wiederholende Tests in verschiedenen Phasen des Produktlebenszyklus
- Nur wenige Schritte bis zur Ausführung und sehr schnelle Ergebnisse
- Wenig Kenntnisse zur Barrierefreiheit sind erforderlich, um die Tests durchzuführen oder die Ergebnisse zu verstehen
Nachteile automatisierter Tests zur Barrierefreiheit:
- Automatisierte Tools erkennen nicht alle Fehler in Bezug auf die Barrierefreiheit in Ihrem Produkt.
- Falsch positive Ergebnisse gemeldet (ein Problem wird gemeldet, das nicht tatsächlich gegen die WCAG verstößt)
- Für unterschiedliche Produkttypen und Rollen können mehrere Tools erforderlich sein.
Automatisierte Tests sind ein guter erster Schritt, um die Zugänglichkeit Ihrer Website oder App zu prüfen. Allerdings können nicht alle Prüfungen automatisiert werden. Wie Sie die Zugänglichkeit von Elementen prüfen können, die sich nicht automatisieren lassen, erfahren Sie im Modul Manuelles Testen der Barrierefreiheit genauer.
Arten von automatisierten Tools
Eines der ersten automatischen Onlinetools für Tests zur Barrierefreiheit wurde 1996 vom Center for Applied Special Technology (CAST) mit dem Namen "The Bobby Report" entwickelt. Derzeit stehen über 100 automatische Testtools zur Auswahl.
Die automatisierte Toolimplementierung variiert von Browsererweiterungen für Barrierefreiheit bis hin zu Code-Lint-Tools, Desktop- und mobilen 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, z. B.:
- Welche Konformitätsstandards und Niveaus werden getestet? Dazu können WCAG 2.1, WCAG 2.0, US-Abschnitt 508 oder eine modifizierte Liste von Regeln für die Barrierefreiheit gehören.
- Welche Art von digitalen Produkt testen Sie? Das kann eine Website, Webanwendung, native mobile App, PDF, ein Kiosk 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 eine Einzelperson, ein Team oder ein Unternehmen?
- Wer führt den Test durch: Designschaffende, Entwickler, QA usw.?
- Wie oft soll die Barrierefreiheit überprüft werden? Welche Details sollte der Bericht enthalten? Sollten Probleme direkt mit einem Ticketsystem verknüpft sein?
- Welche Tools funktionieren in Ihrer Umgebung am besten? Für Ihr Team?
Darüber hinaus sind noch viele weitere Faktoren zu berücksichtigen. 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 zum automatisierten Test der Barrierefreiheit verwenden wir den Lighthouse von Chrome. Lighthouse ist ein automatisiertes Open-Source-Tool, mit dem die Qualität von Webseiten durch verschiedene Prüfungen wie Leistung, SEO und Barrierefreiheit verbessert werden kann.
Unsere Demo ist eine Website, die für eine erfundene Organisation, den Medical Mysteries Club, erstellt wurde. Diese Website wurde für die Demo absichtlich unzugänglich gemacht. Manche davon sind möglicherweise für dich sichtbar, andere (aber nicht alle) werden von unserem automatisierten Test erfasst.
Schritt 1
Installieren Sie im Chrome-Browser die Lighthouse-Erweiterung.
Es gibt viele Möglichkeiten, Lighthouse in Ihren Testworkflow zu integrieren. Für diese Demo verwenden wir die Chrome-Erweiterung.
Schritt 2
Wir haben eine Demo in CodePen erstellt.
Rufen Sie sie im Debug-Modus auf, um mit den nächsten Tests fortzufahren. Dies ist wichtig, da dadurch das <iframe> entfernt wird, das die Demowebseite umgibt, was einige Testtools beeinträchtigen kann. Weitere Informationen zum Debug-Modus von CodePen
Schritt 3
Öffnen Sie die Chrome-Entwicklertools und gehen Sie zum Tab „Lighthouse“. Deaktivieren Sie alle Kategorieoptionen mit Ausnahme von "Bedienungshilfen". 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 die Schaltfläche „Seitenaufbau analysieren“ und lassen Sie Lighthouse die Tests durchführen.
Nach Abschluss der Tests zeigt Lighthouse eine Bewertung an, die angibt, wie barrierefrei das Produkt ist, das Sie testen. Die Lighthouse-Wertung wird anhand der Anzahl der Probleme, Problemtypen und der Auswirkungen der erkannten Probleme auf Nutzer berechnet.
Neben einer Punktzahl enthält der Lighthouse-Bericht detaillierte Informationen zu den erkannten Problemen und Links zu Ressourcen mit weiteren Informationen zur Behebung. Der Bericht enthält auch bestandene oder nicht anwendbare Tests und eine Liste zusätzlicher Elemente, die manuell geprüft werden können.
Schritt 5
Lassen Sie uns nun ein Beispiel für jedes erkannte Problem mit der automatischen Barrierefreiheit durchgehen und die relevanten Stile und das entsprechende Markup korrigieren.
Problem 1: ARIA-Rollen
Das erste Problem besagt: „Bei Elementen mit einer ARIA-[Rolle], für die untergeordnete Elemente eine bestimmte [Rolle] enthalten müssen, fehlen einige oder alle dieser erforderlichen untergeordneten Elemente. Einige übergeordnete ARIA-Rollen müssen bestimmte untergeordnete Rollen enthalten, um die vorgesehenen Bedienungshilfen auszuführen. Weitere Informationen zu ARIA-Rollenregeln
In unserer Demo funktioniert die Schaltfläche zum Abonnieren des Newsletters nicht:
<button role="list" type="submit" tabindex="1">Subscribe</button>
Das sollten wir beheben.
Auf die Schaltfläche „Abonnieren“ neben dem Eingabefeld wurde eine falsche ARIA-Rolle angewendet. 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. Fokussierbare Nachfolgerelemente in einem [aria-hidden="true"]-Element verhindern, dass diese interaktiven Elemente für Nutzer von Hilfstechnologien wie Screenreadern verfügbar sind. 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. Durch Hinzufügen dieses Attributs wird das Element (und alle darin verschachtelten Elemente) vor 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, die assistive Technologien verwenden, auf Informationen zugreifen und diese in das Formularfeld eingeben können.
Problem 3: Schaltflächenname
Schaltflächen haben keinen barrierefreien Namen. Wenn eine Schaltfläche keinen barrierefreien Namen hat, wird sie von Screenreadern als „Schaltfläche“ angesagt. Dadurch ist sie für Nutzer, die auf Screenreader angewiesen sind, unbrauchbar. 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 Problem 1 entfernen, wird das Wort "Abonnieren" zum Namen der Schaltfläche, auf die zugegriffen werden kann. Diese Funktion ist in das semantische HTML-Schaltflächenelement integriert. Für komplexere Situationen sind zusätzliche Musteroptionen zu berücksichtigen.
<button type="submit" tabindex="1">Subscribe</button>
Problem 4: ALT-Attribute für Bilder
Den Bildelementen fehlen [alt]-Attribute. Informative Elemente sollten einen
kurzen, beschreibenden Alternativtext haben. Dekorative Elemente können mit einem leeren ALT-Attribut ignoriert werden. Weitere Informationen zu Regeln für alternativen Bildtext
<a href="index.html">
<img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>
Da das Logobild auch ein Link ist, wissen Sie aus dem Bildmodul, dass es als umsetzbares Bild bezeichnet wird und alternative Textinformationen über den Zweck des Bildes erfordert. Normalerweise ist das erste Bild auf der Seite ein Logo. Sie können also davon ausgehen, dass Ihre AT-Nutzer dies wissen, und Sie entscheiden, diese zusätzlichen Kontextinformationen nicht zu Ihrer Bildbeschreibung hinzuzufü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 alternativer Text für Bilder, wenn er als Links verwendet wird), der erkennbar, einzigartig und fokussierbar ist, verbessert die Navigation für Screenreader-Nutzer. Weitere Informationen zu Linktextregeln
<a href="#!"><svg><path>...</path></svg></a>
Alle umsetzbaren Bilder auf der Seite müssen Informationen darüber enthalten, wohin Nutzer über den Link weitergeleitet werden. Sie können dieses Problem beheben, indem Sie dem Bild alternativen Text über den Zweck hinzufügen, wie Sie es beim Logobild im Beispiel oben getan haben. Dies funktioniert hervorragend bei einem Image mit einem <img>-Tag, bei <svg>-Tags kann diese Methode jedoch nicht verwendet werden.
Für Symbole für soziale Medien, die <svg>-Tags verwenden, können Sie zum Targeting auf SVGs ein anderes alternatives Beschreibungsmuster verwenden. Fügen Sie die Informationen zwischen den Tags <a> und <svg> hinzu und blenden Sie sie dann visuell für Nutzer aus, fügen Sie eine unterstützte ARIA hinzu oder andere Optionen. Abhängig von Ihrer Umgebung und den Codeeinschränkungen ist eine Methode möglicherweise einer anderen vorzuziehen. Verwenden wir die einfachste Musteroption mit der Abdeckung mit der größten Unterstützungstechnologie: Fügen wir dem <svg>-Tag ein role="img" und ein <title>-Element hinzu.
<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 niedrigem Kontrast ist für viele Nutzende schwer oder unmöglich zu lesen. Weitere Informationen zu Farbkontrastregeln
Es wurden zwei Beispiele gemeldet.
Medical Mysteries Club hat den hexadezimalen Farbwert #01aa9d und der hexadezimale Hintergrundwert #ffffff. Das Farbkontrastverhältnis beträgt 2,9:1.
Screenshot in voller Größe anzeigen
Mermaid syndrome hat den Hex-Textwert #7c7c7c, während der Hex-Farbcode für den Hintergrund #ffffff ist. Das Farbkontrastverhältnis beträgt 4,2:1.
Screenshot in voller Größe anzeigen
Das können wir tun.
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 (weniger als 18 pt / 24 Pixel) eine Farbkontrastanforderung von 4,5:1. Für großen Text (mindestens 18 pt / 24 px oder 14 pt / 18,5 px fett) und grundlegende Symbole muss die Anforderung von 3:1 erfüllt werden.
Für den Seitentitel muss der blaugrüne Text die Anforderung an den Farbkontrast von 3:1 erfüllen, da es sich um einen großen Text mit 24 Pixeln handelt. Die blaugrünen Schaltflächen gelten jedoch als Text in normaler Größe und sind 16 Pixel fett gedruckt, sodass sie die Anforderung an den Farbkontrast von 4, 5:1 erfüllen müssen.
In diesem Fall konnten wir eine blaugrüne Farbe finden, die dunkel genug war, um 4,5:1 zu erreichen, oder wir könnten die Größe des Schaltflächentextes auf 18,5 px fett erhöhen und den blaugrünen Farbwert leicht ändern. Beide Methoden entsprechen der Designästhetik.
Auch für den grauen Text auf weißem Hintergrund tritt kein Farbkontrast ein, 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.
Medical Mysteries Club wurde der Farbwert #008576 zugewiesen. Der Hintergrund bleibt #ffffff. Das aktualisierte Farbkontrastverhältnis beträgt 4,5:1.
Screenshot in voller Größe anzeigen
Mermaid syndrome hat jetzt den Farbwert #767676 und der Hintergrund bleibt #ffffff. Das Farbkontrastverhältnis beträgt 4,5:1.
Screenshot in voller Größe anzeigen
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> befinden, damit Screenreader richtig angesagt werden 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>
In dieser Demo haben wir eine CSS-Klasse verwendet, um die unsortierte Liste zu simulieren, anstatt ein <ul>-Tag zu verwenden. Als wir diesen Code falsch geschrieben haben, haben wir die in dieses Tag integrierten semantischen HTML-Funktionen entfernt. Dieses Problem mit der Barrierefreiheit lässt sich beheben, indem die Klasse durch ein echtes <ul>-Tag ersetzt und der zugehörige CSS-Code geändert wird.
<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, oft frustrierend. Weitere Informationen zu Tabindex-Regeln
<button type="submit" tabindex="1">Subscribe</button>
Sofern es keinen bestimmten Grund dafür gibt, die natürliche TAB-Reihenfolge auf einer Webseite zu stören, muss ein Tabindex-Attribut keine positive Ganzzahl haben. Um die natürliche TAB-Reihenfolge beizubehalten, können wir entweder den Tabindex in 0 ändern oder das Attribut ganz entfernen.
<button type="submit">Subscribe</button>
Schritt 6
Nachdem Sie alle Probleme mit der automatischen Barrierefreiheit behoben haben, öffnen Sie eine neue Seite für den Debug-Modus. Führen Sie die Lighthouse-Prüfung zur Barrierefreiheit noch einmal durch. Ihre Punktzahl sollte viel besser sein als beim ersten Durchlauf.
Wir haben alle diese automatischen Updates für Bedienungshilfen auf einen neuen CodePen angewendet.
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 von Bedienungshilfen beschrieben.
Überprüfen Sie Ihr Wissen
Testen Sie Ihr Wissen über automatisierte Tests für Barrierefreiheit
Welche Tests sollten Sie durchführen, um sicherzustellen, dass Ihre Website barrierefrei ist?
Welche Fehler werden bei automatischen Tests erkannt?