Tests für Hilfstechnologien

In diesem Modul geht es um die Verwendung von Hilfstechnologien für die Barrierefreiheit. 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:

• Nein oder wenig Technik: Stöcke mit Kopf und Mund, Handlupe, 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 Ihnen, 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 eine Sprachausgabe oder Brailleschrift für den Nutzer umwandelt.

Screenreader sind für blinde und taubblinde Menschen unverzichtbar, können aber auch Menschen mit eingeschränktem Sehvermögen, Lesestörungen und kognitiven Beeinträchtigungen nutzen.

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 für Ihren Computer oder Ihr Mobilgerät ordnungsgemäß 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 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 bisschen (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. Beides sind wichtige Aspekte, 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 einem beliebigen Screenreader ausführen. Einige Fehler treten jedoch möglicherweise anders auf als in diesem Modul beschrieben.

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. 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 die Fehlerkorrekturen auf die Demo angewendet wurden. Wir empfehlen Ihnen, die Demo mit Ihrem eigenen Screenreader durchzugehen.

Problem 1: Inhaltsstruktur

Überschriften und Orientierungspunkte sind eines der wichtigsten Methoden, mit denen Nutzer mithilfe von 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 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 Sehenswürdigkeit: <div class="main">...</div>
• Beispiel für eine Überschrift: <p class="h1">Join the Club</p>

Wenn Sie alles korrekt aktualisiert haben, sollte es keine visuellen Veränderungen geben, aber die Screenreader-Nutzung wird erheblich verbessert.

Problem 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 entsprechend ausgezeichnet werden soll, und den zugehörigen HTML-Code aktualisieren. Vergessen Sie nicht, auch das zugehörige CSS zu aktualisieren.

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

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

Problem 2: Linkkontext

Es ist wichtig, Screenreader-Nutzern in Inhalten den Zweck eines Links mitzuteilen und anzugeben, 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 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>

Problem 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 automatisierten Testmodul konnte Lighthouse das Inline-SVG, das als Hauptbild für den Begrüßungsbildschirm auf unserer Demoseite dient, nicht erfassen. 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>

Problem 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 (dekoratives Bild).

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 ein Signal gesendet, dass er dieses Bild überspringen und nicht in der Bildgruppe auflisten soll.

<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. Es handelt sich zwar nicht um den traditionellen Bildtyp, über den wir im Modul Bilder gesprochen haben, das Bild muss dennoch geändert werden, da es den Inhaltsfluss stört und den Nutzer eines Screenreaders ablenken oder verwirren könnte.

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

Problem beheben

Ähnlich wie beim Beispiel für das dekorative Bild können Sie der HTML-Datei ein role="presentation" mit der Aufzählungszeichen-Klasse hinzufügen, um es für Screenreader auszublenden. Genauso würde ein role="none" funktionieren. 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 außerdem ein visuelles und programmatisches Label haben müssen. Dieses Label muss jederzeit sichtbar bleiben.

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>

Wir helfen Ihnen gern weiter.

Ersetzen Sie den Textplatzhalter durch ein ähnliches Labelelement, um das Problem zu beheben. Dieses Labelelement ist programmatisch mit dem Formularfeld verbunden. 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.

Wissenstest

Testen Sie Ihr Wissen über automatisierte Tests zur Barrierefreiheit