Tests für Hilfstechnologien

In diesem Modul geht es um die Verwendung von Hilfstechnologien (AT) für Barrierefreiheitstests. Menschen mit Behinderungen können assistive Technologien verwenden, um ihre Fähigkeiten zur Ausführung einer Aufgabe zu verbessern, zu erhalten oder zu steigern.

Im digitalen Raum können assistive Technologien Folgendes sein:

• Keine oder wenig Technologie: Kopf- und Mundstäbe, Handlupen, Geräte mit großen Tasten
• High-Tech: sprachaktivierte Geräte, Eye-Tracking-Geräte, adaptive Tastaturen und Mäuse
• Hardware: Schalter, ergonomische Tastaturen, automatisch aktualisierende Braillegerät
• Software: Text-to-Speech-Programme, Live-Untertitel, Screenreader

Wir empfehlen Ihnen, in Ihrem gesamten Testablauf mehrere Arten von assistiven Technologien zu verwenden.

Grundlagen von Screenreader-Tests

In diesem Modul konzentrieren wir uns auf eine der beliebtesten digitalen assistiven Technologien: Screenreader. Ein Screenreader ist eine Software, die den zugrunde liegenden Code einer Website oder App liest. Anschließend werden diese Informationen in Sprache oder Braille für den Nutzer umgewandelt.

Screenreader sind für blinde und taubblinde Menschen unerlässlich, können aber auch Menschen mit eingeschränktem Sehvermögen, Lesestörungen und kognitiven Behinderungen helfen.

Browserkompatibilität

Es gibt mehrere Screenreader-Optionen. Die beliebtesten Screenreader sind JAWS, NVDA und VoiceOver für Desktopcomputer 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 sind für bestimmte Hardware und Webbrowser konzipiert. Wenn Sie einen Screenreader mit einem Browser verwenden, für den er nicht kalibriert wurde, können mehr Fehler oder unerwartetes Verhalten auftreten. Screenreader funktionieren am besten in den folgenden Kombinationen.

Screenreader-Befehle

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

Wenn Sie einen Screenreader für Barrierefreiheitstests verwenden, besteht Ihr Ziel darin, Probleme in Ihrem Code zu erkennen, die die Nutzung Ihrer Website oder App beeinträchtigen, und nicht, die Erfahrung eines Screenreader-Nutzers zu simulieren. Mit etwas Grundwissen, einigen Screenreader-Befehlen und etwas (oder viel) Übung können Sie viel erreichen.

Wenn Sie die Nutzererfahrung von Personen, die Screenreader und andere assistive Technologien verwenden, besser verstehen möchten, können Sie sich an viele Organisationen und Einzelpersonen wenden, um diese wertvollen Informationen zu erhalten. Denken Sie daran, dass die Verwendung einer assistiven Technologie zum Testen von Code anhand einer Reihe von Regeln und das Befragen von Nutzern nach ihren Erfahrungen oft zu unterschiedlichen Ergebnissen führt. Beide Aspekte sind wichtig, um vollständig barrierefreie Produkte zu entwickeln.

Wichtige Befehle für Desktop-Screenreader

Wichtige Befehle für mobile Screenreader

Demo für Screenreader-Tests

Für den Test unserer Demo haben wir Safari auf einem Laptop mit macOS verwendet und den Ton aufgenommen. Sie können diese Schritte mit jedem Screenreader durchgehen. Die Art und Weise, wie Sie auf einige Fehler stoßen, kann jedoch von der in diesem Modul beschriebenen abweichen.

Schritt 1

Rufen Sie den aktualisierten CodePen auf, auf den alle automatisierten und manuellen Barrierefreiheitsupdates angewendet wurden.

Rufen Sie ihn im Debug-Modus auf, um mit den nächsten Tests fortzufahren. Das ist wichtig, da dadurch das <iframe> entfernt wird, das die Demo-Webseite umgibt und einige Testtools beeinträchtigen kann. Weitere Informationen zum Debug-Modus von CodePen.

Schritt 2

Aktivieren Sie den Screenreader Ihrer Wahl 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 den Screenreader für jedes Problem aufgezeichnet, bevor und nachdem die Korrekturen auf die Demo angewendet wurden. Wir empfehlen Ihnen, die Demo mit Ihrem eigenen Screenreader durchzugehen.

Problem 1: Inhaltsstruktur

Überschriften und Landmarken sind eine der wichtigsten Möglichkeiten, mit denen Nutzer mit Screenreadern navigieren. Wenn diese nicht vorhanden sind, 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 nach einem der beiden Elemente zu navigieren, werden Sie schnell feststellen, dass sie nicht vorhanden sind.

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

Wenn Sie alles richtig aktualisiert haben, sollten sich keine visuellen Änderungen ergeben, aber die Screenreader-Nutzung wird sich erheblich verbessert haben.

Wir beheben das Problem.

Einige nicht barrierefreie Elemente können nicht einfach durch Betrachten der Website erkannt werden. Sie erinnern sich vielleicht noch an die Bedeutung von Überschriftenebenen und semantischem HTML aus dem Modul Inhaltsstruktur. Ein Inhalt kann wie eine Überschrift aussehen, ist aber tatsächlich in ein stilisiertes <div> eingebettet.

Um das Problem mit Überschriften und Landmarken zu beheben, müssen Sie zuerst jedes Element identifizieren, das als solches gekennzeichnet werden soll, und das zugehörige HTML aktualisieren. Aktualisieren Sie auch das zugehörige CSS.

• Beispiel für eine Landmarke: <main>...</main>
• Beispiel für eine Überschrift: <h1>Join the Club</h1>

Wenn Sie alles richtig aktualisiert haben, sollten sich keine visuellen Änderungen ergeben, aber die Screenreader-Nutzung wird sich erheblich verbessert haben.

Problem 2: Linkkontext

Es ist wichtig, Screenreader-Nutzern Informationen zum Zweck eines Links zu geben und dazu, ob sie über den Link zu einem neuen Ort außerhalb der Website oder App weitergeleitet werden.

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

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

Wir beheben das Problem.

Um dieses Problem für Screenreader-Nutzer zu beheben, aktualisieren wir den Code, um weitere Informationen hinzuzufügen, ohne das visuelle Element zu beeinträchtigen. Alternativ können wir auch zusätzlichen visuellen Text hinzufügen, um noch mehr Menschen zu helfen, z. B. Menschen mit Lese- und kognitiven Störungen.

Es gibt viele verschiedene Muster, die wir verwenden können, um zusätzliche Linkinformationen hinzuzufügen. Da unsere Umgebung nur eine Sprache unterstützt, ist ein ARIA-Label in dieser Situation eine einfache Option. Das ARIA-Label überschreibt den ursprünglichen Linktext. Achten Sie also darauf, diese Informationen in Ihre Aktualisierung aufzunehmen.

<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 Modul zu automatisierten Tests konnte Lighthouse das Inline-SVG, das als Haupt-Splash-Image auf unserer Demoseite dient, nicht erkennen. Der Screenreader findet es jedoch und kündigt es ohne zusätzliche Informationen als „Bild“ an. Das gilt auch ohne das role="img" Attribut explizit zum SVG hinzuzufügen.

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

Wir beheben das Problem.

Um dieses Problem zu beheben, müssen wir zuerst entscheiden, ob das Bild informativ oder dekorativ ist. Je nach Entscheidung müssen wir den entsprechenden Alt-Text für das Bild hinzufügen (informativ) oder das Bild für Screenreader-Nutzer ausblenden (dekorativ).

Wir haben die Vor- und Nachteile der besten Kategorisierung des Bildes abgewogen und entschieden, dass es dekorativ ist. Das bedeutet, dass wir den Code hinzufügen oder ändern müssen, um das Bild auszublenden. Eine schnelle Methode besteht darin, dem SVG Bild direkt ein role="presentation" hinzuzufügen. Dadurch wird dem Screenreader signalisiert, dieses Bild zu überspringen und nicht in der Gruppe „Bilder“ aufzuführen.

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

Problem 4: Aufzählungszeichen

Sie haben vielleicht bemerkt, dass der Screenreader das CSS-Aufzählungszeichen unter den Abschnitten zu seltenen Krankheiten liest. Dieses Bild ist zwar nicht dasselbe wie das, was wir im Modul Bilder besprochen haben, muss aber trotzdem geändert werden, da es den Fluss des Inhalts unterbricht und einen Screenreader-Nutzer ablenken oder verwirren könnte.

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

Wir beheben das Problem.

Ähnlich wie beim zuvor besprochenen Beispiel für ein dekoratives Bild können Sie dem HTML mit der Aufzählungszeichenklasse role="presentation" hinzufügen, um es für den Screenreader auszublenden. Alternativ funktioniert auch role="none". Verwenden Sie jedoch nicht aria-hidden: true, da sonst alle Informationen im Absatz für Screenreader-Nutzer ausgeblendet werden.

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

Problem 5: Formularfeld

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

In unserer Demo fehlt sowohl ein visuelles als auch ein programmatisches Label für das E-Mail-Feld für die Newsletter-Registrierung. Es gibt zwar ein Platzhalter-Element für Text, aber dieses ersetzt das Label nicht, da es nicht dauerhaft sichtbar ist 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>

Wir beheben das Problem.

Um dieses Problem zu beheben, ersetzen Sie den Platzhalter für Text durch ein ähnliches Label-Element. Dieses Label-Element ist programmatisch mit dem Formularfeld verbunden. Mit JavaScript wurde eine Bewegung hinzugefügt, damit das Label auch dann sichtbar bleibt, wenn dem Feld Inhalt hinzugefügt wird.

<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. Alle diese Änderungen können Sie in dem aktualisierten CodePen für diese Demosehen.

Jetzt können Sie das Gelernte anwenden, um die Barrierefreiheit Ihrer eigenen Websites und Apps zu überprüfen.

Ziel all dieser Barrierefreiheitstests ist es, so viele mögliche Probleme zu beheben, wie ein Nutzer potenziell haben könnte. Das bedeutet jedoch nicht, dass Ihre Website oder App nach Abschluss der Tests perfekt barrierefrei ist. Am besten ist es, wenn Sie Ihre Website oder App während des gesamten Prozesses mit Blick auf die Barrierefreiheit entwickeln und diese Tests in Ihre anderen Tests vor der Veröffentlichung einbeziehen.