Tests für Hilfstechnologien

In diesem Modul geht es um den Einsatz von assistiven Technologien (AT) für Tests zur Barrierefreiheit. Eine Person mit Beeinträchtigungen kann AT nutzen, um die Fähigkeiten zur Ausführung einer Aufgabe zu erhöhen, aufrechtzuerhalten oder zu verbessern.

Im digitalen Bereich können ATs:

• Nein/Low-Tech: Stöcke für Kopf und Mund, tragbare Lupe, Geräte mit großen Tasten
• Hightech: sprachgesteuerte Geräte, Eyetracking-Geräte, adaptive Tastaturen/Mäuse
• Hardware: Schaltertasten, ergonomische Tastaturen, Braillegerät zur automatischen Aktualisierung
• Software: Sprachausgabeprogramme, automatische Untertitel, Screenreader

Wir empfehlen Ihnen, mehrere Arten von ATs in Ihrem gesamten Testworkflow zu verwenden.

Grundlagen zum Testen von Screenreadern

In diesem Modul konzentrieren wir uns auf einen der beliebtesten digitalen ATs, den Screenreader. Ein Screenreader ist eine Software, die den zugrunde liegenden Code einer Website oder App liest und diese Informationen dann für den Nutzer in eine Sprach- oder Brailleausgabe umwandelt.

Screenreader sind wichtig für blinde und taubbinde Menschen, aber auch Menschen mit eingeschränktem Sehvermögen, Lesestörungen oder kognitiven Beeinträchtigungen können von ihnen profitieren.

Browserkompatibilität

Es gibt mehrere Screenreader-Optionen. Die gängigsten Screenreader sind JAWS, NVDA und VoiceOver für Computer sowie VoiceOver und TalkBack für Mobilgeräte.

Abhängig von Ihrem Betriebssystem, Ihrem bevorzugten Browser und dem verwendeten 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 ist, können weitere „Programmfehler“ oder unerwartetes Verhalten auftreten. Screenreader funktionieren am besten, wenn sie in den folgenden Kombinationen verwendet werden.

Screenreader-Befehle

Sobald Sie die Screenreader-Software für Ihren Desktop oder Ihr Mobilgerät korrekt eingerichtet haben, sollten Sie sich die Screenreader-Dokumentation (Link in der vorherigen Tabelle) ansehen und einige grundlegende Screenreader-Befehle durchgehen, um sich mit der Technologie vertraut zu machen. Wenn Sie bereits einen Screenreader verwendet haben, sollten Sie einen neuen ausprobieren.

Wenn Sie einen Screenreader für Tests zur Barrierefreiheit verwenden, sollten Sie Probleme in Ihrem Code erkennen, die die Nutzung Ihrer Website oder App beeinträchtigen. Es geht nicht darum, die Nutzung eines Screenreaders zu emulieren. Daher können Sie mit einem grundlegenden Wissen, ein paar Screenreader-Befehlen und ein bisschen oder viel Übung viel erreichen.

Wenn Sie mehr über die User Experience von Menschen erfahren möchten, die Screenreader und andere ATs verwenden, können Sie mit vielen Organisationen und Personen zusammenarbeiten, um diese wertvollen Erkenntnisse zu gewinnen. Denken Sie daran, dass die Verwendung eines AT zum Testen von Code anhand einer Reihe von Regeln und die Frage nach der Nutzererfahrung oft zu unterschiedlichen Ergebnissen führt. Beide Aspekte sind wichtig, um vollständig inklusive Produkte zu entwickeln.

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, aber die Art und Weise, wie Sie auf einige Fehler stoßen, unterscheidet sich möglicherweise von der Beschreibung in diesem Modul.

Schritt 1

Rufen Sie den aktualisierten CodePen auf, für den alle automatischen und manuellen Updates für Bedienungshilfen angewendet werden.

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 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 Probleme konzentrieren.

Wir haben unseren Screenreader für jedes Problem aufgezeichnet, bevor und nachdem die Fehlerbehebungen auf die Demo angewendet wurden. Wir empfehlen Ihnen, die Demo mit einem eigenen Screenreader durchzugehen.

Problem 1: Inhaltsstruktur

Überschriften und Markierungen sind eine der wichtigsten Navigationsarten für Screenreader. 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 für Frust sorgen. Wenn Sie versuchen, in der Demo zu einem der Elemente zu navigieren, werden Sie schnell feststellen, dass es nicht vorhanden ist.

• Beispiel für Sehenswürdigkeit: <div class="main">...</div>
• Beispiel für eine Überschrift: <p class="h1">Join the Club</p>

Wenn Sie alles korrekt aktualisiert haben, sollten keine optischen Änderungen vorgenommen werden, aber die Screenreader-Nutzung wird deutlich verbessert.

Das sollten wir beheben.

Einige Elemente, die nicht zugänglich sind, können nicht allein durch das Betrachten der Website beobachtet werden. Die Bedeutung von Überschriftenebenen und semantischem HTML wurde bereits aus dem Modul Inhaltsstruktur ins Gedächtnis gerufen. Inhalte können wie eine Überschrift aussehen, aber tatsächlich ist der Inhalt in ein stilisiertes <div> eingebettet.

Um das Problem mit Überschriften und Orientierungspunkten zu beheben, müssen Sie zunächst jedes Element, das als solches ausgezeichnet werden soll, identifizieren und den zugehörigen HTML-Code aktualisieren. Aktualisieren Sie unbedingt auch das zugehörige CSS.

Beispiel für Sehenswürdigkeit: <main>...</main>

Beispiel für eine Überschrift: <h1>Join the Club</h1>

Wenn Sie alles korrekt aktualisiert haben, sollten keine optischen Änderungen vorgenommen werden, aber die Screenreader-Nutzung wird deutlich verbessert.

Problem 2: Linkkontext

Es ist wichtig, Screenreader-Nutzern Inhalte über den Zweck eines Links zu geben und darüber, ob der Link sie an einen neuen Ort außerhalb der Website oder App weiterleitet.

In unserer Demo haben wir die meisten Links korrigiert, als wir den aktiven alternativen Text für das Bild aktualisiert haben. Es gibt jedoch einige zusätzliche Links zu verschiedenen seltenen Krankheiten, die von zusätzlichem Kontext profitieren könnten – insbesondere, weil sie zu einem neuen Speicherort weiterleiten.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
  Maple syrup urine disease (MSUD)
</a>

Das sollten wir beheben.

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. Und um noch mehr Menschen zu helfen, z. B. Menschen mit Lese- und kognitiven Störungen, können wir stattdessen zusätzlichen visuellen Text hinzufügen.

Es gibt viele verschiedene Muster, die wir in Betracht ziehen, um zusätzliche Linkinformationen hinzuzufügen. Basierend auf unserer einfachen Umgebung, die nur eine Sprache unterstützt, ist ein ARIA-Label in dieser Situation eine unkomplizierte Option. Sie werden möglicherweise feststellen, 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 gibt es ohne zusätzliche Informationen als „Bild“ bekannt. Dies gilt auch, wenn das role="img"-Attribut nicht explizit dem SVG hinzugefügt wurde.

<div class="section-right">
  <svg>...</svg>
</div>

Das sollten wir beheben.

Um dieses Problem zu beheben, müssen wir zuerst entscheiden, ob das Bild informativ oder dekorativ ist. Auf der Grundlage dieser Entscheidung müssen wir den entsprechenden alternativen Bildtext (informatives Bild) hinzufügen oder das Bild vor Screenreader-Nutzern verbergen (dekorativ).

Wir haben die Vor- und Nachteile bei der Kategorisierung des Bildes abgewogen und entschieden, dass es dekorativ ist. Das bedeutet, dass wir den Code hinzufügen oder ändern möchten, um das Bild zu verbergen. Eine schnelle Methode besteht darin, dem SVG-Bild direkt ein role="presentation" hinzuzufügen. Dadurch wird ein Signal an den Screenreader gesendet, dass dieses Bild übersprungen und nicht in der Bildergruppe aufgeführt wird.

<div class="section-right">
  <svg role="presentation">...</svg>
</div>

Problem 4: Aufzählungszeichen dekoriert

Vielleicht haben Sie bemerkt, dass der Screenreader das CSS-Aufzählungszeichen unter den Abschnitten zu seltenen Krankheiten liest. Auch wenn das Bild nicht zu den herkömmlichen Bildern gehört, die wir im Bildmodul besprochen haben, muss das Bild dennoch modifiziert werden, da es den Inhaltsfluss stört und Screenreader-Nutzer ablenken oder verwirren könnte.

<p class="bullet">...</p>

Das sollten wir beheben.

Ähnlich wie bei dem zuvor besprochenen Beispiel für dekorative Bilder können Sie dem HTML-Code ein role="presentation" mit der Aufzählungsklasse hinzufügen, um es vor dem Screenreader auszublenden. Ebenso würde ein role="none" funktionieren. Achten Sie aber darauf, nicht aria-hidden: true zu verwenden, da Sie sonst alle Absatzinformationen vor Screenreader-Nutzern verbergen.

<p class="bullet" role="none">...</p>

Problem 5: Formularfeld

Im Modul Formulare haben wir gelernt, dass alle Formularfelder auch ein visuelles und programmatisches Label haben müssen. Dieses Label muss immer sichtbar bleiben.

In unserer Demo fehlt sowohl ein visuelles als auch ein programmatisches Label im Feld für die E-Mail-Adresse für die Newsletter-Anmeldung. Es gibt ein Textplatzhalterelement. Dieses ersetzt jedoch nicht das Label, da es 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>

Das sollten wir beheben.

Um dieses Problem zu beheben, ersetzen Sie den Textplatzhalter durch ein nachgeahmtes Labelelement. Dieses Labelelement ist programmatisch mit dem Formularfeld verbunden und die 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 zu überprüfen.

Das Ziel dieser Tests zur Barrierefreiheit besteht darin, so viele mögliche Probleme zu beheben, auf die ein Nutzer stoßen könnte. Das bedeutet jedoch nicht, dass Ihre Website oder App vollständig zugänglich ist, wenn Sie fertig sind. Den größten Erfolg erzielen Sie, wenn Sie Ihre Website oder App während des gesamten Prozesses barrierefrei gestalten und diese Tests in Ihre anderen Pre-Launch-Tests einbinden.

Überprüfen Sie Ihr Wissen

Testen Sie Ihr Wissen über automatisierte Tests für Barrierefreiheit