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-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

Tastaturbefehle 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 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.

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.

Problem 2: Linkkontext

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>

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>

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>

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>

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>

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>

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>

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.