Tests für Hilfstechnologien

In diesem Modul geht es um die Verwendung von Hilfstechnologien für die Barrierefreiheitsprüfung. Menschen mit Behinderung können Hilfstechnologien nutzen, um die Möglichkeiten zur Ausführung einer Aufgabe zu erhöhen, aufrechtzuerhalten oder zu verbessern.

Im digitalen Raum können ATs:

  • Keine oder wenig Technologie: Kopf- und Mundsticks, Lupen, Geräte mit großen Tasten
  • High-Tech: sprachaktivierte Geräte, Eye-Tracking-Geräte, adaptive Tastaturen und Mäuse
  • Hardware: Schalter, ergonomische Tastaturen, Braillezeile mit automatischer Aktualisierung
  • Software: Sprachausgabeprogramme, Live-Untertitel, Screenreader

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

Grundlagen des Screenreader-Tests

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

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

Browserkompatibilität

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

Je nach Betriebssystem, bevorzugtem Browser und verwendetem Gerät eignet sich ein bestimmter Screenreader möglicherweise am besten. 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, kann es zu mehr Fehlern oder unerwartetem Verhalten kommen. Screenreader funktionieren am besten in den folgenden Kombinationen.

Screenreader Betriebssystem Browserkompatibilität
Job Access With Speech (JAWS) Windows Chrome, Firefox, Edge
Non-Visual Desktop Access (NVDA) Windows Chrome und Firefox
Erzähler Windows Edge
VoiceOver macOS Safari
Orca Linux Firefox
TalkBack Android Chrome und Firefox
VoiceOver (für Mobilgeräte) iOS Safari
ChromeVox ChromeOS Chrome

Screenreader-Befehle

Nachdem Sie die Screenreader-Software auf Ihrem Computer oder Mobilgerät richtig eingerichtet haben, sollten Sie sich die Screenreader-Dokumentation (Link in der Tabelle oben) ansehen und einige wichtige Screenreader-Befehle ausprobieren, um sich mit der Technologie vertraut zu machen. Wenn Sie schon einmal einen Screenreader verwendet haben, sollten Sie einen neuen ausprobieren.

Wenn Sie einen Screenreader für die Barrierefreiheitsprüfung verwenden, besteht Ihr Ziel darin, Probleme in Ihrem Code zu erkennen, die die Nutzung Ihrer Website oder App beeinträchtigen, und nicht, die Nutzung durch einen Screenreader-Nutzer zu emulieren. Mit einigen grundlegenden Kenntnissen, ein paar Befehlen für Screenreader und ein wenig (oder viel) Übung können Sie also viel erreichen.

Wenn Sie mehr über die Nutzererfahrung von Personen erfahren möchten, die Screenreader und andere Hilfstechnologien verwenden, können Sie sich an viele Organisationen und Einzelpersonen wenden, um diese wertvollen Informationen zu erhalten. Denken Sie daran, dass die Verwendung eines AT, um Code anhand einer Reihe von Regeln zu testen, und die Befragung von Nutzern zu ihren Erfahrungen oft zu unterschiedlichen Ergebnissen führt. Beide Aspekte sind wichtig, um vollständig inklusive Produkte zu entwickeln.

Tastenkombinationen für Screenreader auf dem Computer

Element NVDA (Windows) VoiceOver (macOS)
Tasten für allgemeine Befehle Einfügen Strg + Wahltaste
Audiowiedergabe stoppen Kontrollgruppe Kontrollgruppe
Nächstes/vorheriges Kapitel lesen oder Strg + Wahltaste + oder
Jetzt lesen Einfügen Strg + Wahltaste + A
Elementliste/Rotor NVDA + F7 Strg + Wahltaste + U
Landmarken D Strg + Wahltaste + U
Überschriften H Strg + Alt + Befehlstaste + H
Links K Strg + Alt + Befehlstaste + L
Formularsteuerelemente Fr. Strg + Alt + Befehlstaste + J
Tabellen T Strg + AltBefehlstaste + T
Innerhalb von Tabellen Einfügen Alt + Strg + Wahltaste +

Tastaturbefehle für mobile Screenreader

Element TalkBack (Android) VoiceOver (iOS)
Erkunden Ziehen Sie einen Finger auf dem Display. Ziehen Sie einen Finger auf dem Display.
Auswählen oder aktivieren Doppeltippen Doppeltippen
Nach oben oder unten verschieben Wische mit zwei Fingern nach oben oder unten Mit drei Fingern nach oben oder unten wischen
Seiten ändern Mit zwei Fingern nach links oder rechts wischen Wische mit drei Fingern nach links oder rechts
Nächster/Vorheriger Mit einem Finger nach links oder rechts wischen Mit einem Finger nach links oder rechts wischen

Demo für Screenreader-Tests

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

Schritt 1

Rufen Sie den aktualisierten CodePen auf, in dem alle automatischen und manuellen Updates zur Barrierefreiheit angewendet wurden.

Sehen Sie sich die Seite im Debug-Modus an, um mit den nächsten Tests fortzufahren. Das ist wichtig, da dadurch das <iframe> entfernt wird, das die Demo-Webseite umgibt und bei einigen Testtools zu Problemen führen kann. Weitere Informationen zum Debug-Modus von CodePen

Schritt 2

Aktivieren Sie den Screenreader Ihrer Wahl und rufen Sie die Demoseite auf. Sehen Sie sich die gesamte Seite von oben nach unten an, bevor Sie sich auf bestimmte Probleme konzentrieren.

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

Problem 1: Inhaltsstruktur

Überschriften und Markierungen sind eine der wichtigsten Navigationsmethoden für Nutzer von Screenreadern. 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 frustrierend sein.

Wenn Sie versuchen, sich in der Demo anhand eines dieser Elemente zu bewegen, werden Sie schnell feststellen, dass sie nicht vorhanden sind.

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

Wenn Sie alles richtig aktualisiert haben, sollten keine visuellen Änderungen auftreten. Die Nutzung des Screenreaders sollte sich jedoch deutlich verbessern.

Hören Sie sich an, wie der Screenreader durch dieses Problem navigiert.
Lass uns das beheben.

Einige nicht barrierefreie Elemente sind nicht einfach zu erkennen. Sie erinnern sich vielleicht noch an die Bedeutung von Überschriftenebenen und semantischem HTML aus dem Modul Inhaltsstruktur. Ein Inhalt sieht möglicherweise wie eine Überschrift aus, ist aber tatsächlich in einer stilisierten <div> eingeschlossen.

Um das Problem mit Überschriften und Markierungen zu beheben, müssen Sie zuerst jedes Element identifizieren, das so markiert werden soll, und die zugehörige HTML-Datei aktualisieren. Aktualisieren Sie auch das zugehörige CSS.

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

Wenn Sie alles richtig aktualisiert haben, sollten keine visuellen Änderungen zu sehen sein. Die Nutzung des Screenreaders sollte sich jedoch deutlich verbessert haben.

Nachdem wir die Inhaltsstruktur korrigiert haben, hören wir uns noch einmal an, wie der Screenreader durch die Demo navigiert.

Es ist wichtig, Nutzern von Screenreadern Informationen zum Zweck eines Links und dazu zur Verfügung zu stellen, ob sie über den Link zu einer neuen Seite außerhalb der Website oder App weitergeleitet werden.

In unserer Demo haben wir die meisten Links korrigiert, als wir den alternativen Text des aktiven Bildes 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 einer neuen Seite weiterleiten.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
  Maple syrup urine disease (MSUD)
</a>
Anhören, wie der Screenreader durch dieses Problem navigiert
Lass uns das 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. Um noch mehr Menschen zu helfen, z. B. solchen mit Lese- und kognitiven Störungen, fügen wir möglicherweise stattdessen zusätzlichen visuellen Text hinzu.

Es gibt viele verschiedene Muster, die wir berücksichtigen 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. Möglicherweise stellen Sie fest, dass das ARIA-Label den ursprünglichen Linktext überschreibt. Geben Sie diese Informationen daher in Ihrer Aktualisierung an.

<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>
Nachdem wir den Linkkontext korrigiert haben, hören Sie sich an, wie der Screenreader noch einmal durch die Demo navigiert.

Problem 3: Dekoratives Bild

In unserem Modul für automatisierte Tests konnte Lighthouse das Inline-SVG nicht erkennen, das als Haupt-Splash-Image auf unserer Demoseite dient. Der Screenreader findet es jedoch und liest es ohne zusätzliche Informationen als „Bild“ vor. Das gilt auch, wenn das Attribut role="img" dem SVG nicht explizit hinzugefügt wird.

<div class="section-right">
  <svg>...</svg>
</div>
Anhören, wie der Screenreader durch dieses Problem navigiert
Lass uns das beheben.

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 hinzufügen (informatives Bild) oder das Bild für Nutzer von Screenreadern ausblenden (dekorativ).

Wir haben die Vor- und Nachteile 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 auszublenden. Eine schnelle Methode ist, 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>
Nachdem wir das dekorative Bild korrigiert haben, hören wir uns an, wie der Screenreader durch die Demo navigiert.

Problem 4: Aufzählungspunkte mit Verzierungen

Möglicherweise haben Sie bemerkt, dass der Screenreader das CSS-Aufzählungszeichen unter den Abschnitten zu seltenen Krankheiten vorliest. Auch wenn es sich nicht um die Art von Bild handelt, die wir im Modul Bilder besprochen haben, muss es trotzdem geändert werden, da es den Fluss der Inhalte stört und Nutzer von Screenreadern ablenken oder verwirren könnte.

<p class="bullet">...</p>
Hören Sie sich an, wie der Screenreader durch dieses Problem navigiert.
Lass uns das beheben.

Ähnlich wie beim Beispiel für das dekorative Bild können Sie dem HTML-Code ein role="presentation" mit der Aufzählungszeichen-Klasse hinzufügen, um es für Screenreader auszublenden. Ebenso funktioniert role="none". Verwenden Sie jedoch nicht aria-hidden: true, da sonst alle Informationen zum Absatz für Nutzer von Screenreadern ausgeblendet werden.

<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 jederzeit sichtbar sein.

In unserer Demo fehlt sowohl ein visuelles als auch ein programmatisches Label im E-Mail-Feld für die Newsletteranmeldung. Es gibt ein Textplatzhalterelement, das das Label jedoch nicht ersetzt, da es nicht visuell dauerhaft 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>
Anhören, wie der Screenreader durch dieses Problem navigiert
Lass uns das beheben.

Ersetzen Sie den Textplatzhalter durch ein ähnliches Labelelement, um das Problem zu beheben. 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>
Nachdem wir das Formular korrigiert haben, hören Sie sich an, wie der Screenreader durch die Demo navigiert.

Zusammenfassung

Glückwunsch! Sie haben alle Tests für diese Demo abgeschlossen. Alle diese Änderungen finden Sie im aktualisierten Codepen für diese Demo.

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

Das Ziel all dieser Tests zur Barrierefreiheit besteht darin, so viele Probleme wie möglich zu beheben, auf die Nutzer möglicherweise stoßen. Das bedeutet jedoch nicht, dass Ihre Website oder App nach Abschluss der Prüfung vollständig barrierefrei ist. Am besten gelingt Ihnen das, wenn Sie Ihre Website oder App während des gesamten Prozesses barrierefrei gestalten und diese Tests in Ihre anderen Tests vor der Markteinführung einbinden.

Wissen testen

Testen Sie Ihr Wissen über automatisierte Tests zur Barrierefreiheit.

Welcher Screenreader eignet sich am besten für den Test der Barrierefreiheit?

JAWS
JAWS ist zwar einer der beliebtesten Screenreader, aber nicht unbedingt die beste Wahl.
VoiceOver
VoiceOver ist ein Tool für macOS- und iOS-Nutzer. Wenn Sie einen Windows-PC verwenden, müssen Sie ein anderes Tool verwenden.
Orca
Orca ist für Linux-Firefox-Nutzer gedacht. Möglicherweise müssen Sie ein anderes Tool verwenden.
Es gibt keine
Jeder Screenreader ist für ein bestimmtes Gerät, Betriebssystem oder einen bestimmten Browser konzipiert. Welcher Screenreader für Sie am besten geeignet ist, hängt davon ab, wie Sie testen. Wenn Sie Analysen oder Studien haben, die Ihnen mehr über Ihre Nutzer mit Screenreadern verraten, kann es sinnvoll sein, mit denselben Screenreadern zu testen, die sie verwenden.

Was ist der Zweck von Tests mit Hilfstechnologien?

Dieselben Funktionen wie Nutzer mit Hilfstechnologien nutzen.
Sie können die Erfahrung einer Person, die Hilfstechnologien verwendet, nicht wirklich nachahmen. Ein Test in einer Situation ist nicht mit anderen Erfahrungen vergleichbar.
Sie können damit auf Ihrer Website oder in Ihrer App nach Fehlern suchen.
Mithilfe von Tests zur Barrierefreiheit können Entwickler Probleme finden und beheben, die Nutzer mit Beeinträchtigungen auf ihrer Website oder in ihrer App möglicherweise haben.