In diesem Modul geht es um den Einsatz von Hilfstechnologien für Tests zur Barrierefreiheit. Eine Person mit Beeinträchtigungen kann die AT nutzen, um die Fähigkeiten zur Ausführung einer Aufgabe zu erweitern, zu erhalten oder zu verbessern.
Im digitalen Raum können ATs:
- Nein/technisch weniger versiert: Kopf-/Mund-Stöcke, Handlupe, Geräte mit großen Tasten
- Hightech: Geräte mit Sprachsteuerung, Eyetracking-Geräten, adaptive Tastaturen/Mäuse
- Hardware: Schalter, ergonomische Tastaturen, automatisch aktualisierendes Braillegerät
- Software: Sprachausgabeprogramme, automatische Untertitel, Screenreader
Wir empfehlen Ihnen, in Ihrem gesamten Testablauf mehrere Arten von Anzeigentexten zu verwenden.
Grundlagen zum Testen von Screenreadern
In diesem Modul konzentrieren wir uns auf einen der beliebtesten digitalen ATs: Screenreader. Ein Screenreader ist eine Software, die den zugrunde liegenden Code einer Website oder App liest. Diese Informationen werden dann für den Nutzer in eine Sprach- oder Brailleausgabe umgewandelt.
Screenreader sind für blinde und taubblinde Menschen unverzichtbar, können aber auch Menschen mit eingeschränktem Sehvermögen, Lesestörungen oder kognitiven Beeinträchtigungen nutzen.
Browserkompatibilität
Es stehen mehrere Screenreader-Optionen zur Verfügung. Die beliebtesten Screenreader sind derzeit JAWS, NVDA und VoiceOver für Computer sowie VoiceOver und TalkBack für Mobilgeräte.
Je nach Betriebssystem, bevorzugtem Browser und verwendetem Gerät kann ein Screenreader die beste Option sein. Die meisten Screenreader wurden für bestimmte Hardware und Webbrowser entwickelt. Wenn Sie einen Screenreader mit einem Browser verwenden, für den er nicht kalibriert wurde, treten möglicherweise weitere „Programmfehler“ auf. oder unerwartetes Verhalten. Screenreader funktionieren am besten, wenn sie in den folgenden Kombinationen verwendet werden.
Screenreader-Befehle
Nachdem Sie die Screenreader-Software für Ihren Computer oder Ihr Mobilgerät korrekt eingerichtet haben, sollten Sie sich die Screenreader-Dokumentation (Link in der vorherigen Tabelle) ansehen und einige wichtige Screenreader-Befehle ausführen, um sich mit der Technologie vertraut zu machen. Wenn Sie schon einmal einen Screenreader verwendet haben, sollten Sie einen neuen verwenden.
Wenn Sie einen Screenreader für Tests zur Barrierefreiheit verwenden, besteht Ihr Ziel darin, Probleme in Ihrem Code zu erkennen, die die Nutzung Ihrer Website oder App beeinträchtigen. Es geht nicht darum, die Erfahrung eines Screenreader-Nutzers zu emulieren. Mit ein wenig Grundwissen, ein paar Screenreader-Befehlen und ein wenig – oder viel – Übung können Sie also viel tun.
Wenn Sie mehr über die User Experience von Personen erfahren möchten, die Screenreader und andere ATs verwenden, können Sie sich an viele Organisationen und Einzelpersonen wenden, um diese wertvollen Erkenntnisse zu gewinnen. Zur Erinnerung: Wenn Sie eine AT verwenden, um Code anhand einer Reihe von Regeln zu testen, und die Nutzer nach ihrer Erfahrung fragen, führt dies häufig zu anderen Ergebnissen. Beides sind wichtige Aspekte für die Erstellung vollständig inklusiver Produkte.
Tastaturbefehle für Desktop-Screenreader
Tastaturbefehle für mobile Screenreader
Screenreader-Testdemo
Um unsere Demo zu testen, haben wir Safari auf einem Laptop mit macOS verwendet, um Ton aufzunehmen. Sie können diese Schritte mit einem beliebigen Screenreader ausführen. Einige Fehler treten jedoch möglicherweise anders auf als in diesem Modul beschrieben.
Schritt 1
Rufe den aktualisierten CodePen auf. automatische und manuelle Updates für Bedienungshilfen angewendet wurden.
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 2
Aktivieren Sie den gewünschten Screenreader und rufen Sie die Demoseite auf. Sie können die gesamte Seite von oben nach unten durchgehen, bevor Sie sich auf bestimmte Themen konzentrieren.
Wir haben unseren Screenreader für jedes Problem aufgezeichnet, bevor und nachdem wir die Korrekturen auf die Demo angewendet haben. Wir empfehlen Ihnen, die Demo mit Ihrem eigenen Screenreader durchzugehen.
Problem 1: Inhaltsstruktur
Überschriften und Orientierungspunkte sind einige der wichtigsten Methoden, mit denen Nutzer mithilfe von Screenreadern navigieren. Sind diese nicht vorhanden, muss ein Screenreader-Nutzer die gesamte Seite lesen, um den Kontext zu verstehen. Das kann viel Zeit in Anspruch nehmen und zu Frustration führen. Wenn Sie versuchen, in der Demo von einem der Elemente aus zu navigieren, werden Sie schnell feststellen, dass es diese Elemente nicht gibt.
- Beispiel für Sehenswürdigkeit:
<div class="main">...</div>
- Beispiel für Überschrift:
<p class="h1">Join the Club</p>
Wenn Sie alles korrekt aktualisiert haben, sollte es keine visuellen Änderungen geben, aber die Screenreader-Nutzung wird erheblich verbessert.
<ph type="x-smartling-placeholder"> <ph type="x-smartling-placeholder">Einige Elemente, die nicht barrierefrei zugänglich sind, lassen sich nicht durch einen Blick auf die Website erkennen. Sie erinnern sich vielleicht noch an die Bedeutung von Überschriftenebenen und semantischem HTML aus dem Modul Inhaltsstruktur. Ein Inhalt kann wie eine Überschrift aussehen, der Inhalt ist aber in Wirklichkeit von einem stilisierten <div>
umschlossen.
Um das Problem mit Überschriften und Orientierungspunkten zu beheben, müssen Sie zuerst jedes Element identifizieren, das entsprechend ausgezeichnet werden soll, und den zugehörigen HTML-Code aktualisieren. Aktualisieren Sie auch das zugehörige CSS.
Beispiel für Sehenswürdigkeit: <main>...</main>
Beispiel für Überschrift: <h1>Join the Club</h1>
Wenn Sie alles korrekt aktualisiert haben, sollte es keine visuellen Änderungen geben, aber die Screenreader-Nutzung wird erheblich verbessert.
<ph type="x-smartling-placeholder">Problem 2: Linkkontext
Es ist wichtig, dass Sie Nutzern von Screenreadern den Zweck eines Links erläutern und angeben, ob der Link sie an eine neue Stelle außerhalb der Website oder App weiterleitet.
In unserer Demo haben wir die meisten Links korrigiert, als wir den alternativen Text für das aktive Bild aktualisiert haben. Es gibt jedoch ein paar zusätzliche Links zu den verschiedenen seltenen Krankheiten, die von zusätzlichem Kontext profitieren könnten – vor allem, da sie zu einem neuen Ort weiterleiten.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
Um dieses Problem für Nutzer von Screenreadern zu beheben, aktualisieren wir den Code, um weitere Informationen hinzuzufügen, ohne das visuelle Element zu beeinträchtigen. Um noch mehr Menschen, beispielsweise Menschen mit Lese- oder kognitiven Störungen, zu helfen, fügen wir stattdessen möglicherweise zusätzlichen visuellen Text hinzu.
Es gibt viele verschiedene Muster, die wir in Betracht ziehen können, um zusätzliche Linkinformationen hinzuzufügen. Aufgrund unserer einfachen Umgebung, die nur eine Sprache unterstützt, ist ein ARIA-Label in dieser Situation eine unkomplizierte Option. Möglicherweise stellen Sie fest, dass das ARIA-Label den ursprünglichen Linktext überschreibt. Nehmen Sie diese Informationen daher in Ihr Update auf.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
Problem 3: Dekoratives Bild
In unserem automatisierten Testmodul konnte Lighthouse das Inline-SVG, das als Haupt-Splash-Bild auf unserer Demoseite dient, nicht erfassen, aber der Screenreader findet es und meldet es als „Bild“. ohne zusätzliche Informationen. Das gilt auch ohne explizites Hinzufügen des Attributs role="img"
zur SVG-Datei.
<div class="section-right">
<svg>...</svg>
</div>
Um dieses Problem zu beheben, müssen wir zuerst entscheiden, ob das Bild informativ oder dekorativ ist. Basierend auf dieser Entscheidung müssen wir den entsprechenden alternativen Bildtext (informatives Bild) hinzufügen oder das Bild für Screenreader-Nutzer ausblenden (dekorativ).
Wir haben die Vor- und Nachteile der bestmöglichen Kategorisierung von Bildern abgewogen und entschieden, dass es dekorativ ist. Das heißt, wir möchten den Code zum Ausblenden des Bildes hinzufügen oder ändern. Eine schnelle Methode besteht darin, dem SVG-Bild direkt eine role="presentation"
hinzuzufügen. Dadurch wird dem Screenreader ein Signal gesendet, dass dieses Bild übersprungen und nicht der Bildgruppe hinzugefügt werden soll.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
Problem 4: Aufzählungszeichen
Sie haben vielleicht bemerkt, dass der Screenreader das CSS-Aufzählungsbild unter die Abschnitte über seltene Krankheiten. Auch wenn es nicht die traditionelle Art von Bildern ist, wie im Modul "Images" erläutert, muss das Image dennoch geändert werden, da es sich und könnte den Nutzer des Screenreaders ablenken oder verwirren.
<p class="bullet">...</p>
Ähnlich wie bei dem oben beschriebenen Beispiel für ein dekoratives Bild können Sie dem HTML-Code ein role="presentation"
mit der Aufzählungsklasse hinzufügen, um es vor dem Screenreader auszublenden. Genauso würde ein role="none"
funktionieren. Achten Sie aber darauf, nicht aria-hidden: true
zu verwenden, da sonst alle Absatzinformationen für Nutzer von Screenreadern ausgeblendet werden.
<p class="bullet" role="none">...</p>
Problem 5: Formularfeld
Im Modul Google Formulare haben wir gelernt, dass alle müssen außerdem ein visuelles und programmatisches Label haben. Dieses Label muss immer sichtbar sind.
In unserer Demo fehlen sowohl ein visuelles als auch ein programmatisches Label im Feld für die E-Mail-Adresse zur Newsletteranmeldung. Es gibt ein Textplatzhalterelement, das jedoch das Label nicht ersetzt, da es visuell nicht dauerhaft und nicht vollständig mit allen Screenreadern kompatibel ist.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
Um dieses Problem zu beheben, ersetzen Sie den Textplatzhalter durch ein ähnliches Labelelement. Dieses Labelelement ist programmatisch mit dem Formularfeld verbunden und eine Bewegung wurde mit JavaScript hinzugefügt, damit das Label auch dann sichtbar bleibt, wenn dem Feld Inhalte hinzugefügt werden.
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
Zusammenfassung
Glückwunsch! Sie haben alle Tests für diese Demo abgeschlossen. Sie können sich alle diese Änderungen im aktualisierten Codepen für diese Demo ansehen.
Jetzt können Sie das Gelernte anwenden, um die Barrierefreiheit Ihrer eigenen Websites und Apps.
Ziel dieser Tests zur Barrierefreiheit ist es, möglichst viele und Probleme, auf die Nutzende stoßen könnten. Das bedeutet jedoch nicht, dass Ihre Website oder App ist jederzeit perfekt zugänglich, sobald Sie fertig sind. Den größten Erfolg erzielen Sie, Ihre Website oder App während des gesamten Prozesses barrierefrei gestalten und diese Tests in deine anderen Pre-Launch-Tests einfließen lassen.
Wissen testen
Testen Sie Ihr Wissen über automatisierte Tests zur Barrierefreiheit
Welcher Screenreader eignet sich am besten zum Testen der Barrierefreiheit?
Was ist der Zweck von Tests mit Hilfstechnologien?